Déployer un nouveau code en direct

Quelle est la meilleure pratique pour déployer un nouveau code sur un site en ligne (e-commerce)?

Pour l'instant, j'ai arrêté apache pendant +/- 10 secondes lors du changement de nom du répertoire public_html_newen public_htmlancien vers public_html_old. Cela crée un court temps d'arrêt, avant de redémarrer Apache.

La même question se pose si vous utilisez Git pour tirer le nouveau référentiel vers le répertoire en direct. Puis-je retirer le dépôt lorsque le site est actif? Et si je dois également copier une base de données?

Pendant la compression tar (à des fins de sauvegarde) du site en direct, j'ai remarqué que des changements étaient survenus dans le répertoire multimédia. Cela m'a indiqué que les fichiers continuent de changer périodiquement. Et si ces modifications peuvent interférer si Apache n'est pas arrêté pendant le déploiement.

L'utilisation d'un équilibreur de charge est une bonne idée. Si le site est suffisamment important pour s'inquiéter de quelques secondes de temps d'arrêt, il est suffisamment important pour se soucier de la tolérance aux pannes.

Cela mis à part, s'il s'agit d'un système UNIX, vous pouvez mettre Apache en attente pendant le changement de nom (ou la mise à jour du lien symbolique, etc.):

killall -STOP httpd  # Pause all httpd processes
mv public_html public_html_orig
mv public_html_new public_html
killall -CONT httpd  # Resume all httpd processes

Cela empêchera Apache d'accepter de nouvelles demandes pendant le changement de nom. Si vous préférez les liens symboliques ou une autre approche, la même idée peut être utilisée:

killall -STOP httpd  # Pause all httpd processes
rm /var/www/html
ln -s /var/www/version/03 /var/www/html
killall -CONT httpd  # Resume all httpd processes

Notez que toutes les connexions ou tous les paquets en attente seront mis en file d'attente dans le système d'exploitation. Pour un site extrêmement occupé, envisagez de régler ListenBacklog si approprié pour votre type de travailleur httpd et vérifiez les paramètres de votre système d'exploitation liés au backlog d'écoute TCP.

Vous pouvez également modifier DocumentRoot dans httpd.conf et effectuer un redémarrage gracieux ( apachectl graceful). L'inconvénient ici est le risque accru d'erreurs, car vous devez également mettre à jour toute Directoryconfiguration.

Le plus rapide et le plus simple consiste à utiliser un répertoire de version tel que

/var/www/version/01
/var/www/version/02

et utilisez un lien symbolique actuel comme racine html:

/var/www/html -> /var/www/version/02

Cette technique s'intègre parfaitement dans un système de contrôle de révision (svn, git, mercurial, ...) car vous pouvez extraire des branches et des balises, changer le lien symbolique et recharger Apache. Le temps d'arrêt est minime en utilisant cette technique et il permet une restauration très facile .

Il s'intègre également bien avec les systèmes de déploiement plus complexes tels que les packages RPM ou l'infrastructure de gestion des changements de configuration (chef, marionnette, etc.).

Renommer les répertoires sans arrêter Apache devrait également fonctionner. Cela raccourcira considérablement la fenêtre. mv public_html public_html_old && mv public_html_new public_htmldevrait se terminer en une fraction de seconde.

Quelques inconvénients sont que cette approche donnera une réponse 404à toute demande qui parvient toujours à se produire pendant la fenêtre. Et si vous exécutez la commande ci-dessus sans avoir de public_html_newrépertoire, elle échouera et vous laissera un site donnant 404à chaque demande.

Le faire atomiquement avec des répertoires n'est pas pris en charge. Mais vous pouvez le faire avec des liens symboliques. Au lieu d'avoir un répertoire nommé public_html, ayez un répertoire nommé public_html.version-numberet un lien symbolique appelé public_htmlpointant vers ce répertoire. Vous pouvez maintenant créer un répertoire appelé public_html.new-version-numberet un nouveau lien symbolique appelé public_html.new.

Ensuite, vous pouvez renommer public_html.newto public_htmlpour basculer atomiquement. Notez que mvc'est "trop ​​intelligent" pour effectuer ce changement de nom, mais cela pourrait être fait à l'aide os.renamede python ou de toute autre chose qui appellera l' renameappel système sans essayer d'être intelligent.

Que faire de la base de données dépend de la base de données que vous utilisez et de la raison pour laquelle vous l'utilisez. Vous devez fournir beaucoup plus de détails sur la base de données avant que nous puissions vous donner une bonne réponse à cette partie de votre question.

Les liens symboliques et mv sont vos amis, cependant, si vous devez vraiment éviter que les utilisateurs finaux obtiennent une page d'erreur lors du déploiement d'une nouvelle version, vous devez avoir un proxy inverse ou un équilibreur de charge devant au moins 2 serveurs backend (apache dans ton cas).

Pendant le déploiement, il vous suffit d'arrêter un backend à la fois, de déployer le nouveau code, de le redémarrer, puis d'itérer sur les backends restants.

Les utilisateurs finaux seront toujours dirigés vers de bons backends par le proxy.

Si vous appliquez régulièrement des changements sur un système de production, je m'occuperais d'un cycle de vie structuré. Une bonne pratique est Capistrano http://capistranorb.com/ . Il s'agit d'une solution open source pour déployer des logiciels sur un ou plusieurs serveurs sur plusieurs plates-formes et configurations.

Pour Magento, il existe même un plugin: https://github.com/augustash/capistrano-ash/wiki/Magento-Example

Pour un serveur unique et des transitions presque transparentes, je recommande d'utiliser des liens symboliques.

La façon dont je le fais est de valider mes modifications depuis mon environnement de développement local vers un référentiel Git en ligne tel que Github. Mon environnement de production s'exécute à partir d'un référentiel distant, donc tout ce que je dois faire est ssh sur le serveur et exécuter git pullpour apporter les dernières modifications. Pas besoin d'arrêter votre serveur web.

Si votre projet contient des fichiers dont les paramètres et / ou le contenu diffèrent de votre version locale (tels que les fichiers de configuration et les téléchargements multimédias), vous pouvez utiliser des variables d'environnement et / ou ajouter ces fichiers / répertoires à un .gitignorefichier pour empêcher la synchronisation avec le référentiel.

Ma première idée est:

# deploy into public_html_new, and then:
rsync -vaH --delete public_html_new/ public_html/

Une bonne solution consistait à utiliser rsync. Il n'a changé que les fichiers vraiment modifiés. Attention, les barres obliques à la fin des chemins sont ici importantes.

Normalement, apache n'a pas besoin d'un redémarrage, ce n'est pas le monde java. Il vérifie la modification de chaque fichier php sur demande et relit (et re-tokenise) automatiquement la modification.

Git pull était similaire et efficace, bien qu'il soit un peu plus difficile à écrire. Bien sûr, il a permis un large éventail de différentes possibilités de détection de fusion / changement.

Cette solution ne fonctionnera de manière transparente que s'il n'y a pas de changements vraiment majeurs - s'il y a de grands changements dans le déploiement, un peu de danger ne peut pas être fermé, car il y a un intervalle de temps non négligeable, lorsque le code sera partiellement modifié et surtout pas.

S'il y a de gros changements, ma suggestion était votre solution initiale (deux renommer).

Voici une solution un peu hardcore, mais 100% atomique:

(1) faire un montage alternatif de certains de votre système de fichiers, où votre magento a lieu:

mount /dev/sdXY /mnt/tmp

(2) faites un --bindmontage de votre public_html_new sur public_html:

mount --bind /path/to/public_html_new /path/to/public_html

À partir de ce moment, l'apache verra votre nouveau déploiement. Tout changement de 404 est impossible.

(3) faire la synhcronistation avec rsync, mais sur le point de montage alternatif):

rsync -vaH --delete /mnt/tmp/path/to/public_html_new/ /mnt/tmp/path/to/public_html/

(4) Retirez le support de fixation

umount /path/to/public_html

Le déplacement / remplacement du http_publicdossier peut être réalisé avec des commandes simples mvou ln -sou l'équivalent pendant que votre serveur http continue de fonctionner. Vous pouvez effectuer des scripts pour réduire considérablement les temps d'arrêt, mais vérifiez attentivement les codes retour de vos commandes dans le script si vous automatisez le processus.

Cela dit, si vous ne souhaitez obtenir aucun temps d'arrêt, votre application doit également la prendre en charge. La plupart des applications utilisent une base de données pour la persistance. Le fait de voir la version N de votre application jouer avec la version N + 1 (ou l'inverse) de votre modèle de données peut casser les choses si cela n'est pas prévu par l'équipe de développement.

Par expérience, le maintien d'une telle cohérence par le biais de mises à niveau n'est pas acquis pour la plupart des applications. Un arrêt correct, malgré le temps d'arrêt, est un bon moyen d'éviter les problèmes de cohérence.