Une entreprise du Bassin Genevois fait développer un outil interne de suivi de chantier par un prestataire indépendant. L'application tourne dans des conteneurs sur un serveur loué et rend service pendant deux ans sans incident. Puis le prestataire change d'activité, une mise à jour de sécurité devient nécessaire, et l'entreprise découvre qu'aucun document ne décrit comment l'application démarre, où ses données sont stockées, ni ce qu'il faut faire si le serveur redémarre mal un dimanche. Le logiciel fonctionne toujours. C'est son mode d'emploi qui n'existe pas.
Cette situation ne remet pas en cause la technologie employée. La mise en conteneur d'une application, c'est-à-dire le fait d'emballer un logiciel avec toutes ses dépendances dans une image figée que l'on peut relancer à l'identique, résout de vrais problèmes. Elle demande simplement d'être exploitée comme le reste de votre informatique, avec des versions connues, des sauvegardes vérifiées et une procédure écrite. Nous posons ce type d'installation en mission cloud à 1000 HT / jour, à distance dans toute la France et en Suisse, ou dans l'exploitation d'un serveur local lorsque la machine se trouve dans vos murs, à Saint-Julien-en-Genevois, à Genève ou à Annemasse.
Ce que la mise en conteneur apporte réellement à une application
Trois objets suffisent à comprendre le mécanisme. L'image est un modèle figé qui contient le code de l'application, le langage qui l'exécute, les bibliothèques dont elle dépend et sa configuration de départ. Le conteneur est l'exécution de cette image à un instant donné, et il est jetable par construction : vous l'arrêtez, vous le supprimez, vous le recréez à partir de la même image sans rien perdre. Le volume est l'espace de stockage qui survit à cette opération, et c'est là que vivent la base de données, les fichiers déposés par vos collaborateurs et tout ce qui a réellement de la valeur.
Le premier bénéfice est la reproductibilité. L'image validée sur votre environnement de recette est exactement celle qui part en production, ce qui supprime toute une catégorie d'incidents où le logiciel fonctionne chez le développeur et échoue sur le serveur. Le deuxième est l'isolation, puisque deux applications qui réclament deux versions différentes de PHP ou de Python cohabitent sur la même machine, là où une installation classique obligerait à trancher. Le troisième est la rapidité du retour en arrière : revenir à la version précédente consiste à relancer l'image précédente, en quelques secondes plutôt qu'en une soirée de réinstallation.
Un conteneur n'est pas une machine virtuelle. Il partage le noyau du système Linux qui l'héberge au lieu d'embarquer un système d'exploitation complet, ce qui le rend beaucoup plus léger mais aussi moins cloisonné. Les deux approches se complètent bien : si vous exploitez déjà un hyperviseur, sujet que nous comparons dans Proxmox, ESXi ou Hyper-V, une machine virtuelle par environnement avec des conteneurs à l'intérieur reste une organisation lisible et facile à sauvegarder.
Ce que Docker ne fera pas à votre place
Une erreur fréquente consiste à considérer qu'une application conteneurisée est administrée. Elle ne l'est pas davantage qu'un logiciel installé classiquement, et quatre besoins restent entièrement à votre charge.
- La sauvegarde des volumes n'existe pas par défaut. Docker sait recréer un conteneur, il ne sait pas ressusciter une base de données effacée. Il faut donc une copie régulière des volumes, stockée ailleurs que sur le serveur qui les héberge, selon le principe que nous détaillons dans la règle de sauvegarde 3-2-1.
- Le nom de domaine, le certificat et son renouvellement automatique restent à configurer. Un conteneur qui écoute sur un port ne devient pas une adresse publique valide en HTTPS.
- La supervision reste à installer. Sans sonde qui remonte le remplissage du disque et l'état des services, vous apprendrez la panne par un utilisateur, généralement le lundi matin.
- La directive
restart: always, qui relance automatiquement un conteneur arrêté, n'est pas un plan de reprise. Elle protège d'un plantage applicatif, pas de la perte du serveur ou du compte d'hébergement.
Le socle compte lui aussi : le système qui porte les conteneurs doit recevoir ses correctifs, disposer d'accès nominatifs et d'un pare-feu, comme nous l'expliquons dans notre article sur l'exploitation d'un serveur Linux en PME.
Le fichier Compose comme mode d'emploi exécutable de votre application
Docker Compose est l'outil qui rend une pile de conteneurs compréhensible sans orchestrateur. Vous décrivez dans un seul fichier texte les services qui composent l'application, l'image et la version exactes de chacun, les volumes qu'ils utilisent, le réseau interne qui les relie et les variables dont ils ont besoin. La commande docker compose up -d démarre l'ensemble, docker compose down l'arrête proprement. Ce fichier joue alors deux rôles à la fois : il exécute l'application et il documente sa structure, ce qui répond exactement au problème du prestataire parti sans laisser de notes.
Pour que ce fichier tienne dans la durée, nous appliquons quelques règles simples. Il vit dans un dépôt Git qui appartient à votre entreprise et non au prestataire. Les images y sont figées sur une version précise plutôt que sur l'étiquette mouvante latest. Les mots de passe et les clés sortent du fichier, dans un fichier d'environnement jamais versionné et conservé dans un coffre d'équipe, comme nous le recommandons dans notre article sur le gestionnaire de mots de passe. Enfin, un reverse proxy unique, c'est-à-dire un service en frontal qui reçoit toutes les requêtes et les distribue aux bons conteneurs, expose les ports 80 et 443 et gère les certificats.
Les quatre défauts que nous retrouvons le plus souvent sur une pile héritée
Nous reprenons régulièrement des installations en conteneurs mises en place dans l'urgence, et les mêmes constats reviennent.
- Les images ne sont figées sur aucune version, si bien qu'un
docker compose pullde routine ramène un jour une version majeure incompatible et immobilise l'application un après-midi entier. - Les identifiants de la base de données figurent en clair dans le fichier Compose poussé sur un dépôt partagé, ce qui les rend lisibles par toute personne ayant eu accès au projet, y compris après son départ.
- Des ports d'administration ou de base de données sont publiés directement sur Internet parce que c'était pratique pendant le développement, et personne n'a refermé l'accès à la mise en production.
- Trois fichiers Compose légèrement différents coexistent sur le serveur, sans que l'on sache lequel décrit ce qui tourne réellement, et aucune note n'indique comment redémarrer la pile.
L'étape suivante n'est pas forcément l'orchestration de conteneurs, c'est-à-dire un logiciel qui répartit automatiquement les conteneurs sur plusieurs machines, et nous expliquons quand elle devient pertinente dans notre article sur le moment où Kubernetes se justifie. Quand l'infrastructure se répète sur plusieurs environnements, c'est plutôt l'infrastructure décrite sous forme de code qui apporte le plus, sujet traité dans Terraform et Ansible.
Notre méthode pour reprendre une installation en conteneurs existante
Nous commençons par un inventaire de ce qui tourne : la liste des conteneurs actifs, les images et leurs versions, les volumes et leur volumétrie, les ports ouverts et les accès existants sur la machine. Nous reconstituons ensuite un fichier Compose unique et fidèle à la réalité, versionné dans un dépôt qui vous appartient, puis nous figeons les versions d'images afin qu'une mise à jour devienne une décision et non une surprise.
Nous mettons ensuite en place ce qui manquait presque toujours : une sauvegarde des volumes vers un stockage extérieur avec une restauration testée, un reverse proxy avec certificats renouvelés automatiquement, une supervision du disque et de la disponibilité des services, et une procédure écrite de démarrage, d'arrêt et de restauration compréhensible par une personne qui n'a pas construit la plateforme. Ce travail entre dans nos missions d'optimisation cloud à 1000 HT / jour, avec le même montant hors taxes en euros et en francs. Lorsque la machine est suivie ensuite dans la durée, elle rejoint un contrat d'infogérance à partir de 120 HT / mois.
Le principe qui guide ces choix est la sobriété technique : nous installons la solution la plus simple qui tient la charge attendue et que votre équipe saura exploiter. Pour beaucoup d'applications internes de PME, un fichier Compose lisible, sauvegardé et documenté remplit ce contrat pendant des années. Si vous avez hérité d'une pile de conteneurs dont personne ne connaît le fonctionnement, décrivez-nous la situation : nous commencerons par écrire ce qui existe, avant de changer quoi que ce soit.