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 comme 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 ; pendant que le déploiement s'effectue sur un serveur - il est exclu de la liste de parcours, 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.
Une telle nouvelle solution a été proposée pour les applications PHP, fonctionnant en plus d'Apache, par le fondateur de ce langage de programmation et, simultanément, le conseiller technique de CloudPAAS - Rasmus Lerdorf. Cette solution, activement utilisée chez Etsy, et donc testée sur le terrain, a ensuite servi de base à la fonction "Zero Downtime & Atomic Deployment" de CloudPAAS . L'idée principale de cette méthode 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), bascule entre les différentes versions de l'application après chaque mise à jour, en pointant sur celle qui devrait être utilisée actuellement
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.
Notez que la disponibilité de cette fonctionnalité nécessite la version 3.3 ou supérieure de la plate-forme CloudPAAS et dépend des paramètres de votre fournisseur d'hébergement.
Ci-dessous, nous allons explorer ce mécanisme plus en détail en le décrivant :
Flux de travail pour le déploiement de ZDT
comment la fonctionnalité ZDT est assurée chez CloudPAAS
comparaison des modes de déploiement atomique et classique
Alors, continuons !
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 sans interruption de service de PHP décrit ci-dessus fonctionne réellement sur CloudPAAS - examinons tous ces processus étape par étape à l'aide d'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é (selon le type de source de projet utilisé) afin d'activer l'option de déploiement ZDT :
pour le déploiement via un fichier local ou une URL directe
Notez que 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 le déploiement via VCS (par exemple à partir de GIT/SVN ou Bitbucket repo) :
le drapeau Activer le déploiement sans interruption 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 les dépôts 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_year.mm.dd-hh.mm.ss) et un fichier ROOT spécial comme lien asymétrique 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 où le traitement a commencé avant le changement de lien symbolique).
Il est à noter que lors de la mise à jour d'une version de l'application à l'aide d'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é à côté (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.
Mise en œuvre de ZDT sur les serveurs PHP
En approfondissant les détails de la mise en œuvre technique, le support de l'option de déploiement atomique chez CloudPAAS 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 outre (si nécessaire) par le biais du tableau de bord CloudPAAS dans le fichier conf.d > mod_realdoc.conffile.
Conseil : 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, prévenir les ralentissements des E/S.
Cette valeur peut être facilement modifiée pour en faire une valeur personnalisée si nécessaire (n'oubliez pas de redémarrer votre nœud de serveur d'application pour son appliance). Toutefois, si vous utilisez la fonction de déploiement ZDT, nous vous recommandons de ne pas la fixer trop haut, car cela entraînerait des retards dans la commutation des liens symboliques.
Comparaison et résumé
Pour prouver les avantages de l'approche de la mise à jour 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ée (c'est-à-dire sa distribution par défaut sans contenu lourd)
outil de génération de charge - Apache JMeter, configuré pour envoyer en continu le nombre requis de demandes simultanées à notre application pendant le processus de redéploiement
calendrier - le test commence peu de temps avant le début du processus de redéploiement 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 couramment utilisée pour le 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 secondes en moyenne
le rétablissement rapide de l'opérabilité normale (c'est-à-dire lorsque toutes les demandes 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
n'apparaît que pendant deux secondes - 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 le deuxième concurrent - 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 demandes. Ainsi, il n'y a même pas une seule erreur dans l'ensemble du test.
Ainsi, on peut supposer que le déploiement sans interruption de service permet de surmonter le problème des requêtes échouées lors du 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 implique normalement le déploiement de la toute nouvelle version de l'application)
Vous pouvez également remarquer que le temps de traitement des demandes minimales 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 CloudPAAS (c'est-à-dire si l'on utilise les repos 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 demandes entrantes commencent à échouer au même moment - cela est indiqué par un pic sur le graphique des erreurs). Tout le reste reste similaire au type de déploiement précédent.
Notez que contrairement au déploiement d'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 du travail 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 va également dans le sens de nos attentes en apportant un temps de réponse stable avec sa petite incrémentation lors du déroulement simultané d'opérations telles que la gestion des sessions des utilisateurs et la copie/mise à jour des projets.
Dans le même temps, vous pouvez constater qu'aucune erreur n'est apparue et que toutes les demandes reçues 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 dans le CloudPAAS Cloud, il est temps de résumer et de conclure sur les principaux avantages qu'elle apporte pour l'hébergement de votre application PHP :
ZDT ne nécessite aucune ressource supplémentaire, 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). Il peut être considéré comme une solution presque gratuite, surtout si on le compare à la majorité des autres options possibles, qui peuvent nécessiter des serveurs d'application, des équilibreurs, des services externes supplémentaires, etc.
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, de sorte qu'aucun retard n'est prévu
enfin, le déploiement Zero-Downtime porte bien son nom en garantissant à 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 indolore et invisible pour les clients, ce qui vous permet de tirer le meilleur parti de votre application !