Scripts de mise en production sur une plateforme de haute disponibilité

Contrôle du load-balancer

La première consiste à pouvoir contrôler le load-balancer simplement, sans créer de coupure. Le load-balancer que nous utilisons, haproxy, possède un moyen de contrôle simple et efficace : une socket Unix qui permet de recevoir des commandes.

Il est possible d'activer/de désactiver des frontaux applicatifs avec des commandes simples du type :

echo "disable server webfarm/djazfront1" | socat stdio /var/run/haproxy.stat

Lorsqu'un frontal est désactivé ainsi, haproxy n'enverra plus de nouvelles requêtes vers le serveur en question. Les requêtes déjà envoyées vers ce frontal mais non encore traitées ne sont pas affectées, ce qui correspond parfaitement à nos besoins d'éviter toute coupure, mais nécessite une précaution supplémentaire.

Vérifier qu'un frontal est coupé

Puisque les requêtes déjà en cours ne sont pas affectées, il ne faut pas commencer la mise en production sur un frontal qui vient d'être retiré du load-balancer avant que toutes les requêtes en cours ne soient traitées.

La solution que nous avons retenue consiste à utiliser le programme netstat qui donne des informations sur la couche réseau (processus en écoute, socket ouvertes, etc.), et de vérifier qu'il n'y a plus de connexions actives (en état ESTABLISHED) vers le processus Apache, avec une commande du type :

netstat -anp | grep -q ESTABLISHED.*apache

Par mesure de sécurité, nous attendons que pendant trois secondes consécutives aucune connexion ne soit active vers le processus Apache, avant de considérer le frontal comme disponible.

Accès à distance : ssh et sudo

Afin de gérer l'accès à distance pour le meta-meta-script, nous utilisons les outils ssh et sudo. En particulier, nous utilisons des clés ssh pour permettre de se connecter sans mot de passe, et une configuration qui permet de lancer les autres scripts en root lorsque nécessaire, depuis un compte dédié aux mises en production, le tout sans effectuer de demande de mot de passe, mais uniquement pour ces commandes là.

Notre autre ami : screen

Parmi les nombreux amis de l'administrateur Unix, il en est un qui nous est critique pour ces mises en production : l'outil GNU screen.

Cet outil rend énormément de services, mais dans notre cas précis, il permet de s'assurer que même si la connexion Internet entre nos bureaux (ou éventuellement le domicile, voire la gare ou l'aéroport...) d'où nous effectuons la mise en production et le datacenter où se trouvent les serveurs venait à sauter, la mise en production se termine sans encombre.

L'astuce consiste à lancer le script à l'intérieur d'un screen, sur l'une des machines du parc de serveurs. Ainsi, si la connexion venait à sauter, les opérations continueraient, et il nous serait possible de récupérer le screen par la suite pour en vérifier le bon déroulement.

Multiplexer les flux

Pour minimiser le temps de la mise en production (pendant lequel la plateforme, ne fonctionnant que sur la moitié de ses frontaux, n'est plus aussi robuste en cas de pic de charge), les opérations sont effectuées en parallèle sur plusieurs frontaux.

Il est donc nécessaire de multiplexer les flux, c'est à dire d'afficher sur le terminal les sorties des commandes sur plusieurs frontaux à la fois, en les préfixant du nom du frontal considéré.

La solution la plus simple pour effectuer ceci en Python est de passer par les threads : au lieu de lancer directement une commande, nous lançons un thread, qui lui exécute la commande, récupère la sortie, et l'écrit, préfixée du nom de la machine, à l'écran.

Une subtilité de Python est à noter ici : utiliser la syntaxe for line in file pose de problèmes de buffering, et provoque l'arrivée des lignes par bloc, au lieu de leur arrivée au fur et à mesure. Il est nécessaire de les lire plus manuellement, en utilisant la méthode readline des objets fichiers.

Traitement des erreurs

« Des erreurs ? Quelles erreurs ? Il n'y pas d'erreurs dans mon code ! » est hélas rarement applicable. Il faut donc gérer les erreurs. Qui peuvent survenir à tous les niveaux.

Il y a deux types d'erreur, au niveau système :

1. Quand un programme se termine anormalement (code de retour différent de 0).
2. Quand un message est affiché sur l'erreur standard (descripteur de fichier numéro 2).

Notre solution est de considérer les erreurs de type 1 (l'une des commandes se termine avec un code différent de 0) comme une erreur fatale, qui interrompt immédiatement le processus de mise en production, et demande une intervention manuelle. Sur un script shell, nous utilisons un set -x qui implémente ce comportement, sur un script Python, nous effectuons le test et l'arrêt nous-même.

Pour les erreurs de type 2, il peut s'agir d'un simple avertissement. Nous avons donc opté pour le mode de fonctionnement suivant : les erreurs affichées par les différents scripts et programmes sur l'erreur standard sont remontées comme les messages normaux, et n'interrompent pas le fonctionnement du programme.

En plus de les afficher au fur et à mesure, nous conservons les messages d'avertissement à part, et les affichons sous forme de récapitulatif à la fin de l'ensemble des opérations, pour être sûr que l'utilisateur du script les ait prises en compte.

Entre en scène le célèbre select

Et c'est là que tout se complique. Tant qu'on gère la sortie d'erreur comme la sortie standard, on peut fusionner les deux flux au niveau du module subprocess de Python, et les traiter de notre côté comme un seul fichier. Le thread est alors simple : il lit ce fichier, préfixe, écrit sur le terminal.

Gérer la sortie d'erreur séparément nous oblige à utiliser le module select de Python, qui est une très fine surcouche à la fonction select du C. Cette fonction prend en paramètre une liste de fichiers. Elle attend ensuite qu'au moins un de ces fichiers soit disponible et nous informe duquel (ou desquels) il s'agit.

En réalité elle prend trois listes de fichiers en paramètre pour attendre des conditions différentes (lecture, écriture et exceptions), mais nous n'utiliserons ici que la première liste : en lecture.

Nous devons donc effectuer un appel du type :

res, _, _ = select.select([child.stdout, child.stderr], [], [])

Et ensuite regarder ce qui se trouve dans res. Si nous y trouvons child.stdout, un message normal est disponible. Si nous y trouvons child.stderr un message d'erreur est disponible. Il est possible d'avoir les deux à la fois, si deux messages ont été mis très rapidement.