Vos conteneurs tournent chez nous, en France

Ce que le conteneur résout

Une image contient l’application et tout ce dont elle a besoin pour tourner. Elle se déplace d’un poste de développement à la production sans que l’environnement change — c’est l’essentiel de ce que Docker apporte, et c’est beaucoup : la moitié des incidents de mise en production venait de là.

Ce que le conteneur ne résout pas, c’est le reste : où tourne l’image, ce qui la redémarre quand elle s’arrête, comment le trafic arrive jusqu’à elle, où sont les données qu’elle écrit, et qui regarde tout cela à trois heures du matin. C’est cette partie que nous prenons.

Swarm plutôt qu’une usine à gaz

Nous exploitons Docker en mode Swarm. C’est l’orchestrateur intégré à Docker : il répartit les conteneurs sur plusieurs machines, les redémarre ailleurs si un nœud tombe, et gère les montées de version sans coupure.

Il fait moins de choses qu’un orchestrateur plus lourd, et c’est précisément son intérêt pour la majorité des projets : moins de pièces mobiles, moins de configuration, moins de choses à comprendre le jour où quelque chose casse. Si votre besoin dépasse ce cadre, c’est un travail d’architecture — pas un hébergement sur catalogue.

Comment un service tourne réellement

En Swarm, vous ne lancez pas un conteneur : vous déclarez un service, et le nombre de réplicas que vous voulez en voir tourner. L’orchestrateur se charge du reste, et c’est ce « reste » qui fait le travail d’exploitation :

• Si un conteneur s’arrête ou cesse de répondre à son health check, il est recréé — sur le même nœud ou sur un autre.
• Si un nœud entier disparaît, ses conteneurs sont replanifiés sur les nœuds restants, à condition que le cluster ait la capacité de les accueillir.
• Une nouvelle version se déploie en mise à jour progressive : les réplicas sont remplacés un par un, et le déploiement s’arrête tout seul si les nouveaux ne passent pas leur contrôle de santé. C’est ce qui permet de livrer sans fenêtre de maintenance, et de revenir en arrière sans drame.
• Le réseau overlay relie les conteneurs entre nœuds : vos services se parlent par leur nom, sans que vous ayez à connaître l’adresse de la machine qui les héberge.

Les mots de passe, clés d’API et certificats passent par les secrets de Swarm : ils sont montés dans le conteneur au démarrage, et ne se retrouvent ni dans l’image, ni dans une variable d’environnement lisible par tout le monde.

Ce qui compte, c’est l’état

Un conteneur est jetable ; vos données ne le sont pas. La question qu’il faut trancher avant tout déploiement est où vit l’état : la base de données, les fichiers déposés par les utilisateurs, les sessions.

Nous sortons ces éléments des conteneurs — bases répliquées, stockage partagé, caches en mémoire — pour qu’un conteneur puisse être détruit et recréé sans que personne s’en aperçoive. C’est ce qui rend une infrastructure conteneurisée réellement robuste, et c’est ce qu’on omet le plus souvent.

Les volumes, le piège classique

Le cas qui revient : une application écrit ses fichiers dans un volume local, tout fonctionne, puis le conteneur est replanifié sur un autre nœud — et les fichiers ne suivent pas. L’application ne plante pas ; elle perd simplement ce qu’elle avait écrit, ce qui est bien pire à diagnostiquer.

Un volume local n’a de sens que pour du cache jetable. Dès que la donnée doit survivre au déplacement d’un conteneur, elle va sur du stockage partagé — NFS, GlusterFS, iSCSI ou SAN selon le volume et les performances attendues — accessible depuis n’importe quel nœud du cluster.

C’est le premier point que nous regardons dans une pile qu’on nous confie, avant même de parler de dimensionnement.

Voir ce qui se passe

Un conteneur qui redémarre en boucle sans qu’on s’en aperçoive est un incident en préparation. Les journaux sortent des conteneurs — ils disparaissent avec eux, sinon — et les métriques du cluster sont surveillées comme celles de nos autres serveurs : en cas d’alerte, nos outils corrigent automatiquement et préviennent un administrateur d’astreinte.