Déploiement de code sur plusieurs serveurs frontaux

Nous avons une situation où nous avons plusieurs serveurs à charge équilibrée pointant vers une base de données commune.

Dans le cours normal des choses, cela fonctionne bien et donne une redondance, une évolutivité, etc.

Cependant, nous trouvons que le déploiement est un peu une corvée.

Nous utilisons largement les fonctionnalités et essayons d'automatiser le déploiement. Le déploiement pour le moment n'est pas très fiable.

Dans une forme simplifiée, le script de déploiement pour chaque serveur comporte deux étapes

1. Mettre à jour les fichiers

2. Rétablir les fonctionnalités (qui géreront les dépendances, les changements de paramètres, etc.)

Existe-t-il des meilleures pratiques pour le déploiement sur plusieurs serveurs sans les mettre dans un état incohérent?

Pour autant que je sache, si vous déployez les étapes 1 et 2 sur le serveur A, cela entraînera la rupture du serveur B.Si vous essayez l'étape 1 sur les deux serveurs avant de passer à l'étape 2, ils seront tous les deux interrompus pendant un certain temps.

Vous devriez probablement vous pencher sur Aegir , qui est de loin le système de gestion / déploiement de site Drupal le plus flexible et le plus puissant. Il est capable de gérer des «plates-formes» qui s'étendent sur plusieurs têtes Web ou «clusters», ainsi que diverses autres configurations.

Je suggère de lire la documentation de leur communauté qui est généralement assez bonne, ainsi que de lire l'excellent article d'introduction et de présentation de mig5 et certains de ses autres articles comme celui-ci .

Vous pouvez également obtenir un bon support sur le canal IRC #aegir.

Ce sera un peu un changement de flux de travail, ce qui peut certainement prendre un certain temps pour se mettre en tête, mais une fois que vous y êtes, vous ne regarderez pas en arrière.

Dans notre entreprise, nous maintenons BEAUCOUP de sites Drupal, notre configuration actuelle ressemble à ceci:

• La base de code de chaque site a son propre dépôt git
• Les nouvelles fonctionnalités ne devraient pas être suffisamment stables pour la prochaine version obtenir leur propre branche de fonctionnalités dans git

Je dirais que ce qui précède est assez courant pour la plupart des sites Drupal.

Ce que nous faisons de spécial dans notre entreprise, c'est le paquet Debian des sites à déployer à l'aide d'une commande drush personnalisée - « Drush Debian Packaging ».

Drush Debian Packaging fournit une commande Drush pour construire des paquets Debian de sites Drupal comme moyen de déployer des sites Drupal sur des serveurs Debian ou Ubuntu.

Drush Debian Packaging utilise le système de crochets Drupal pour construire un paquet Debian qui correspond le mieux aux besoins de vos sites. Les fonctionnalités incluent:

• Configuration d'hôte virtuel automatique pour les serveurs Web Apache2 et Nginx
• Configuration de Cron dans /etc/cron.d
• Déploiement de code automatisé avec partitionnement des sites / par défaut / fichiers
• Configuration automatisée via l'outil de configuration de dpkg debconf
• Processus de déploiement automatisé
• gestionnaire Git VCS personnalisé pour la création de packages à partir de Git

Qu'est-ce que ça veut dire?

Pour créer une version:

cd /path/to/drupal-root
drush dh-make

Pour déployer une version, commencez par SCP le .deb sur tous les serveurs Web du cluster. Ensuite, exécutez tous les serveurs Web (vous pouvez utiliser le package linux cssh pour taper la commande sur tous les serveurs de la batterie en même temps):

sudo dpkg -i drupal-site-yoursitehere.2011.05.25-1.all.deb

Sur un serveur Web exécuté:

cd /path/to/drupal-root
sudo -u drupal-site-yoursitehere drush updb && drush fra -y && drush cron

Terminé

Bien sûr, pour restaurer cela est désormais trivial du point de vue de la base de code, installez simplement la version précédente du .deb sur tous les serveurs Web et restaurez la base de données.

Heureux de répondre à toutes les questions à ce sujet

Quelle partie du processus de déploiement est une corvée / peu fiable?

S'il s'agit du problème "mise à jour du serveur A puis B / incohérence", qu'en est-il de la mise en place de la page de maintenance pendant la durée de vos pushs? Page de maintenance vers le haut, mettre à jour le code sur les deux têtes Web, exécuter update.php sur l' une d'entre elles, page de maintenance vers le bas. C'est assez facilement scriptable.

Une autre option: selon le type de site que vous utilisez, vous pouvez créer un "mode en lecture seule" qui met tous les utilisateurs hors ligne et désactive la connexion / l'enregistrement. Clonez votre base de données vers une seconde base de données sur la même boîte de base de données, clonez votre frontal vers un nouveau docroot, faites vos mises à jour là-bas, puis liez symboliquement le docroot d'Apache au nouveau frontro docroot. Le workflow est quelque chose comme:

1. Mode lecture seule activé
2. SELECT current_db INTO new_db
3. cp -R current_docroot new_docroot
4. new.votredomaine.com ==> / new_docroot
5. mettre à jour le code dans new_docroot
6. update.php
7. lien symbolique / new_docroot ==> current_docroot
8. Mode lecture seule désactivé.

Cela dépendra des changements que vous apportez, comme le suggère Entendu. Quelle proportion de mises à jour de code peut être exécutée sans provoquer d'erreurs si la base de données n'est pas encore mise à jour? Pour tout ce qui ne dépend pas des mises à jour de la base de données (et vous pouvez peut-être modifier un peu le processus de développement pour le rendre plus courant), il n'y a vraiment rien de spécial à faire. Je suppose que vous souhaitez effectuer des déploiements avec un temps d'arrêt minimal, sinon cela ne prendrait que quelques opérations de synchronisation de base. Dans ce cas, il y aura toujours une fenêtre de temps avec des effets indésirables (même si c'est juste avoir le site en mode lecture seule) mais je pense que cela pourrait être assez petit la plupart du temps.

Vous pouvez faire une optimisation de base comme configurer un "nouveau" répertoire sur chaque serveur à l'avance, puis les basculer tous pour pointer vers le nouveau répertoire en même temps (peut-être en utilisant des liens symboliques comme dans la réponse d'Entendu) afin que vous puissiez obtenir tous les les serveurs sont passés aux nouveaux fichiers en 5 à 10 secondes.

Cela laisse le problème des mises à jour de la base de données. S'ils sont du type à effectuer à partir d'un seul serveur, vous pouvez mettre les autres en mode maintenance ou ajuster l'équilibreur de charge pour ne pas les utiliser pendant que cela se produit. Bien sûr, si cela ne peut pas être fait pendant que les utilisateurs sont actifs sur le site, vous aurez juste besoin de tout avoir en mode maintenance, mais pour les mises à jour simples, cela peut être quelque chose que vous pouvez faire en 30 secondes ou moins.

Il peut être utile d'avoir différents scripts de déploiement pour différents types de modifications, vous pouvez donc exécuter le processus minimal nécessaire, qu'il s'agisse de copier des fichiers, d'exécuter une petite mise à jour de la base de données ou d'effectuer une modification majeure de la base de données.

Si vous pouvez optimiser vos mises à jour de fichiers et de bases de données et voir s'il y a des changements simples que vous pouvez apporter à la façon dont les choses sont développées, cela pourrait vous rapprocher, mais je ne sais pas si cela est nouveau pour vous :)

Aegir est utile pour gérer un réseau de sites. Je l'ai utilisé pour déployer et gérer plus de 2000 sites pour un seul client.

Votre question suggère que vous souhaitez gérer un seul site avec plusieurs têtes Web. Si tel est le cas, Aegir pourrait vous être moins utile. Au lieu de cela, je vous suggère d'utiliser un système de fichiers qui prend en charge la mise en réseau. Cela garantit non seulement que votre code est synchronisé, mais que vos téléchargements sont disponibles sur tous les nœuds.

Historiquement, les gens ont utilisé NFS, ce qui permet de partager le système de fichiers d'un serveur avec d'autres nœuds. Malheureusement, cela introduit un seul point de défaillance, car si le serveur NFS se bloque ou meurt, votre site ne peut pas être servi.

Si vous êtes prêt à compromettre un peu les performances d'io en faveur d'un serveur plus fiable, je recommanderais GlusterFS . J'ai utilisé dans quelques environnements de production. Ce n'est pas parfait mais c'est mieux que NFS. Gluster permet à la tête Web de toujours lire localement et les écritures sont ensuite répliquées sur les autres nœuds.

En termes de stratégie de déploiement, vous devriez avoir drush comme premier outil de votre liste. Avec drush, vous devriez être en mesure d'automatiser les étapes de votre déploiement. Vous devriez envisager d'ajouter Jenkins au mélange afin de pouvoir suivre vos travaux de déploiement et identifier les modèles en cas d'échec. Capistrano peut être utile pour automatiser les étapes impliquées dans le déploiement. Si vous faites les choses correctement, vous pouvez faire en sorte que vos utilisateurs ne sachent même jamais que vous avez effectué un déploiement.