Déploiement de RAGNARØKKR Zero Down Time (ZDT) pour PHP
La majorité des services web modernes devraient être accessibles aux utilisateurs à tout moment. Un problème courant, mais souvent négligé, est le processus de redéploiement du projet (c'est-à-dire la mise à jour), ce qui entraîne l'arrêt de votre application ou le renvoi d'erreurs jusqu'à ce que l'opération soit terminée. Ce problème peut être résolu avec divers outils tels que Capistrano, Fabric et d'autres. Cependant, ces compléments nécessitent souvent du temps, des dépenses et des connaissances spécialisées supplémentaires pour être intégrés avec succès et configurés correctement (par exemple, cela peut être réalisé en mettant en place plusieurs serveurs avec un équilibreur de charge devant eux ; alors que le déploiement s'effectue sur un serveur - il est exclu de la liste de routage, après quoi d'autres serveurs pourraient être mis à jour). Il est évident qu'une telle mise en œuvre est assez compliquée et nécessite beaucoup de ressources supplémentaires, d'où la nécessité d'une meilleure méthode.
L'idée principale de la fonction Zero Down Time repose sur les deux points suivants :
• Chaque fois qu'un nouveau processus de déploiement est lancé, les fichiers de l'application correspondante sont dupliqués, étant stockés dans un répertoire de serveur séparé (qui est automatiquement nommé en fonction de sa date/heure de création pour une identification facile)
• Un redirecteur de requêtes spéciales, appelé symlink (c'est-à-dire lien symbolique), passe d'une version d'application à l'autre après chaque mise à jour, en indiquant celle qui doit être utilisée
De cette manière, les fichiers de projet mis à jour peuvent être déployés de manière transparente, tandis que la version initiale du code continue à fonctionner et à gérer les sessions des utilisateurs. Et lorsque le déploiement est entièrement terminé, le lien symbolique passe instantanément à la version la plus récente de l'application déployée avec succès, en commençant à rediriger toutes les demandes entrantes vers celle-ci. Tous ces éléments réunis rendent le processus de déploiement totalement atomique et implicite pour vos clients, vous évitant ainsi de devoir effectuer de nombreuses opérations manuelles.
Flux de travail pour le déploiement de ZDT
Tout d'abord, nous allons examiner plus précisément comment le mécanisme de déploiement ZDT de PHP décrit ci-dessus fonctionne réellement sur RAGNARØKKR. Examinons tous ces processus étape par étape avec un exemple réel.
1. Pour commencer, vous aurez besoin d'un environnement PHP (nouveau ou déjà existant), nous utiliserons Apache pour cet exemple :
2. Ensuite, procédez au déploiement de l'application requise. Au cours de cette procédure, vous devez cocher la case correspondante dans le cadre de confirmation approprié (en fonction du type de source de projet utilisé) afin d'activer l'option de déploiement de ZDT :
• Pour un déploiement via un fichier local ou une URL directe :
Remarque : si vous effectuez cette opération pour la première fois pour l'application déjà existante, déployée dans le contexte ROOT, toutes les données précédentes seront normalement effacées et écrasées avec l'installation de l'application "nue" (pour le déploiement via archive/URL uniquement).
• Pour un déploiement via VCS (par exemple à partir de GIT/SVN ou de Bitbucket) :
Remarques :
- L'option « Empêche tout temps d'arrêt pendant le déploiement » (ZDT) ne devient actif que lors du déploiement dans le contexte ROOT de votre serveur d'application PHP. Dans le cas contraire, la méthode classique sera utilisée.
- Lorsque vous travaillez avec des référentiels VCS, le mode de déploiement choisi sera mémorisé et utilisé pour toutes les mises à jour automatiques ultérieures de cette application jusqu'à ce que vous le changiez manuellement.
- En général, nous recommandons de ne pas utiliser les chemins absolus « codés en dur » dans le code et la configuration de votre application lorsque vous utilisez la fonction de déploiement atomique, afin de garantir qu'elle reste opérationnelle quel que soit le nom du répertoire du projet.
3. Lors du déploiement initial, un dossier ROOT_timestamp (c'est-à-dire ROOT_année.mm.jj-hh.mm.ss) et un fichier ROOT spécial comme lien symbolique vers ce dossier sont créés dans le répertoire webroot de votre serveur d'application.
Comme d'habitude, l'application est prête à traiter les demandes juste après la fin du processus de déploiement.
4. Lors du deuxième déploiement (c'est-à-dire lors du déploiement d'une mise à jour), un nouveau dossier ROOT_timestamp est créé. De cette manière, la version réelle de l'application et les clients qui travaillent actuellement avec elle ne sont pas influencés.
Juste après le déballage des nouveaux fichiers, le lien symbolique passe à ce nouveau dossier, redirigeant toutes les demandes nouvellement reçues vers celui-ci. Ainsi, le premier dossier est conservé pour le traitement des "anciennes" sessions d'utilisateurs (c'est-à-dire là où le traitement a commencé avant le changement de lien symbolique).
Remarques :
Lors de la mise à jour d'une version d'application utilisant archive/URL, tout le contenu généré par l'utilisateur (s'il y en a) doit être déplacé manuellement vers le répertoire de l'application nouvellement créée à partir de l'ancien répertoire, stocké parallèlement (ici, une telle opération implique l'écrasement complet de toutes les données de contexte).
Si vous utilisez le VCS, le contenu du répertoire de l'application est entièrement copié (fichiers suivis et non suivis), de sorte qu'aucune opération manuelle n'est nécessaire. Cependant, nous recommandons d'adopter la pratique de l'utilisation de la liste .gitignore pour les fichiers inutiles de votre projet, car cela vous permettrait d'économiser des ressources et du temps lors de redéploiements répétitifs.
5. Tous les déploiements atomiques suivants seront effectués de la même manière. Au cours de chacun d'entre eux, le plus ancien dossier du projet est supprimé, tandis qu'un nouveau répertoire ROOT_timestamp pour la version la plus récente du projet est ajouté.
Ainsi, seules deux versions de l'application déployée (la plus récente et la précédente) sont stockées simultanément sur un serveur d'applications (toutefois, la plus ancienne peut aussi être facilement supprimée manuellement lorsqu'elle n'est plus nécessaire). Cela permet de ne pas consommer d'espace disque supplémentaire.
Remarque : si vous souhaitez éviter qu'une version du projet ne soit automatiquement effacée, il suffit de renommer le dossier correspondant avant de lancer le nouveau déploiement.
Toutes les opérations sont entièrement automatisées, de sorte qu'aucune intervention supplémentaire du développeur n'est nécessaire, tandis que le déploiement lui-même est effectué en mode "soft", c'est-à-dire même sans redémarrage du serveur d'applications et, par conséquent, sans aucun temps d'arrêt des applications.
Implémentation de ZDT sur les serveurs PHP
En approfondissant les détails de l'implémentation technique, le support de l'option de déploiement atomique chez RAGNARØKKR est assuré par les ajustements suivants, appliqués aux instances PHP correspondantes :
• Apache PHP
La fonctionnalité appropriée est traitée à l'aide du module mod_realdoc, qui contrôle la commutation de liens symboliques mentionnée ci-dessus. Il peut être configuré en plus (si nécessaire) par le biais du tableau de bord RAGNARØKKR dans le fichier conf.d > mod_realdoc.conf.
Remarque : ici, le paramètre RealpathEvery définit la période de temps pendant laquelle le chemin de liaison symbolique est stocké et la fréquence de son rafraîchissement. Sa valeur par défaut (0, comme indiqué dans les commentaires du code) a été changée en 2 pour garantir que toutes les opérations requises (c'est-à-dire le déploiement et la commutation) soient effectuées avant de rediriger les demandes vers la nouvelle version du projet et ainsi, éviter les ralentissements des E/S.
Cette valeur peut facilement être modifiée pour en faire une valeur personnalisée si nécessaire (n'oubliez pas de redémarrer le nœud de votre serveur d'application pour son équipement). Toutefois, si vous utilisez la fonction de déploiement ZDT, nous vous recommandons de ne pas la fixer à un niveau trop élevé, car cela entraînerait des retards dans la commutation des liens symboliques.
• NGINX-PHP
Ici, le déploiement atomique est assuré au moyen de la fonctionnalité intégrée sans inclusion de modules supplémentaires. Les paramètres correspondants se trouvent à la toute fin du fichier nginx > nginx.conf :
Pour l'instant, comme vous savez comment tout cela fonctionne, nous pouvons comparer les méthodes de déploiement classiques et atomiques.
Comparaison et résumé
Pour prouver les avantages de l'approche de mise à jour du ZDT, un simple test de charge a été effectué, sur la base des paramètres suivants :
• Application : une version de base du CMS WordPress déployé (c'est-à-dire sa distribution par défaut sans contenu lourd)
• Outil de génération de charge : Apache JMeter, configuré pour envoyer en permanence le nombre requis de requêtes simultanées à notre application pendant le processus de redéploiement
• Le délai : le test commence peu de temps avant que le processus de redéploiement ne soit lancé et se termine quelques secondes après son achèvement
Évaluons donc les résultats des deux méthodes de déploiement à l'aide des simples statistiques que nous avons reçues.
Déploiement des archives
Commençons par la variante la plus courante du déploiement du projet, à savoir classique, c'est-à-dire l'installation à partir d'un seul paquet archivé sans options supplémentaires comme ZDT activé :
Comme vous pouvez le voir, nous obtenons en fait d'assez bons résultats :
• Temps de réponse rapide et régulier (le graphique bleu), seulement 1,2 seconde en moyenne
• Le retour rapide à un fonctionnement normal (c'est-à-dire lorsque toutes les requêtes entrantes sont traitées avec succès (ligne verte) sans qu'aucune erreur ne se soit produite (graphique rouge)) après le déploiement du nouveau paquet
• Echoue à apparaître pendant deux secondes seulement : voir le pic de la ligne rouge (cependant, le déploiement d'un projet plus lourd et plus complet augmentera cet intervalle à coup sûr)
Maintenant, effectuons le même test avec l’option ZDT. Pour une meilleure perception de la comparaison, nous allons garder la même légende de couleur qu'auparavant :
Le temps de réponse reste stable et presque inchangé, mais vous pouvez remarquer son léger élargissement au cours de la procédure de mise à jour, qui est causé par le processus de déploiement supplémentaire qui se déroule parallèlement à la notification des requêtes. Ainsi, il n'y a même pas une seule erreur pendant tout le test.
Ainsi, on peut supposer que le déploiement sans temps d’arrêt surmonte le problème des requêtes échouées pendant le redéploiement de l'application, tout en maintenant le temps de réponse moyen au même niveau. De plus, l'option atomique vous laisse la possibilité de sauvegarder tout le contenu généré par l'utilisateur, situé dans le répertoire de l'application, et de le déplacer facilement vers la nouvelle version de l'application si nécessaire (alors que la méthode classique n'implique normalement que le déploiement d'une version entièrement nouvelle de l'application).
Vous pouvez également remarquer que le temps minimal de traitement des requêtes pour la méthode classique est nettement inférieur à celui de la méthode atomique et semble donc plus performant. Mais ne vous y trompez pas, car ce n'est qu'un effet secondaire de la présence de requêtes échouées (où le temps de traitement est également compté, bien qu'il ne soit pas traité), alors que le temps de réponse moyen est presque le même pour les deux méthodes.
Déploiement du VCS
Ensuite, répétons notre test pour le deuxième type de déploiement RAGNARØKKR (c'est-à-dire si l'on utilise des référentiels Git/SVN) afin de savoir si ZDT conserve ses avantages dans ce cas. Et à nouveau, nous commencerons par la méthode classique :
Comme les sources de déploiement sont placées sur la ressource distante, cela demandera un peu plus de temps que l'installation à partir de l'archive déjà téléchargée, ce qui, en fait, nous aide à voir clairement la différence. Le temps de réponse a maintenant une chute assez longue (pendant près de 4 secondes dans notre cas), causée par l'indisponibilité de l'application (vous pouvez voir que les requêtes entrantes commencent à échouer au même moment, cela est indiqué par un pic au niveau du graphique des erreurs). Tout le reste demeure similaire au type de déploiement précédent.
Remarque : contrairement au déploiement des archives (où l'ancien projet est entièrement supprimé avant le redéploiement, ce qui entraînera toujours un temps d'arrêt), ici la procédure de mise à jour suppose le changement des différents fichiers uniquement. Par conséquent, vous ne risquez pas d'être confronté à une interruption de service si les fichiers qui doivent être modifiés sont actuellement inutilisés.
Enfin, le dernier test pour l'approche de déploiement de ZDT via VCS répond également à nos attentes en apportant un temps de réponse stable avec sa petite incrémentation lors de l'exécution simultanée d'opérations telles que la gestion des sessions des utilisateurs et la copie/mise à jour des projets.
En même temps, vous pouvez constater qu'aucune erreur n'est apparue et que toutes les requêtes entrantes sont traitées avec succès.
Conclusion
Maintenant que vous avez toutes les informations (à la fois techniques brutes et visualisées dans des graphiques pratiques) sur l'enquête et que vous avez vu comment il est facile d'utiliser l'option ZDT au sein de RAGNARØKKR, il est temps de résumer et de tirer une conclusion sur les principaux avantages qu'elle apporte pour l'hébergement de votre application PHP :
• ZDT ne nécessite pas de ressources supplémentaires comme des instances/outils séparés pour être appliqué - tout ce dont vous avez besoin est juste assez d'espace disque pour stocker deux versions du projet (la version actuelle et la précédente)
• Le déploiement reste aussi simple qu'auparavant - aucune configuration supplémentaire ou intervention humaine n'est nécessaire
• Le temps nécessaire au déploiement atomique est exactement le même que pour la méthode classique, aucun retard n'est donc à prévoir
• Enfin, le déploiement Zero Down Time (aucun temps d'arrêt) porte bien son nom en assurant à vos clients une procédure de mise à jour sans erreur (contrairement à la variante classique qui, sans être améliorée, provoque un nombre assez important d'erreurs même dans le cas d'un petit redéploiement d'application)
Ainsi, l'utilisation du déploiement ZDT rend la mise à jour de vos projets totalement sans problème et invisible pour les clients, vous aidant à tirer le meilleur parti de votre application !
