Docker Compose en production : la limite du serveur unique

Docker Compose reste un choix raisonnable en production si l’application tient sur un seul serveur et si l’interruption causée par une panne de cet hôte est acceptable. La documentation de Docker sur Compose en production présente le serveur unique comme la solution de déploiement la plus simple et évoque un cluster Swarm pour faire évoluer l’application.

Si le service doit continuer après la perte d’une machine, il faut des réplicas sur d’autres hôtes, de la capacité pour accueillir la charge et un chemin pour acheminer le trafic vers les instances disponibles. Kubernetes peut automatiser une partie de cette reprise dans un cluster conçu à cette fin. Le nombre de conteneurs, à lui seul, ne détermine donc pas le moment de changer d’architecture.

Quand Compose reste proportionné

Compose convient à une application dont la charge tient sur un hôte et dont les utilisateurs peuvent attendre sa remise en service. Une application composée de plusieurs conteneurs ne réclame pas, pour cette seule raison, plusieurs machines. Pour une petite équipe déjà familière de Docker, conserver un déploiement simple peut aussi libérer du temps pour les tâches qui conditionnent réellement la reprise.

Cette simplicité ne dispense pas de préparer la production : configuration adaptée, journaux exploitables, surveillance, sauvegardes et procédure de restauration. Une politique de redémarrage peut relancer un conteneur qui s’arrête alors que son hôte fonctionne. Elle ne transfère pas l’application ailleurs si le serveur devient inaccessible. Le temps nécessaire pour obtenir une autre machine, restaurer les données et remettre le service en ligne fait donc partie du choix.

Il faut distinguer deux questions souvent confondues. La capacité répond à « la machine suffit-elle pour la charge ? » ; la disponibilité répond à « que se passe-t-il quand cette machine disparaît ? ». Une application peu sollicitée peut exiger une forte continuité, tandis qu’un traitement chargé mais interrompable peut rester sur un hôte correctement dimensionné.

La panne de l’hôte change la décision

L’alimentation coupée de l’unique hôte Docker Compose interrompt les services qui en dépendent.

Sur un serveur unique, la perte de l’alimentation, du système ou de l’accès réseau coupe les services qui y tournent. Redémarrer leurs conteneurs sur ce même hôte ne résout rien tant que celui-ci reste indisponible. Une sauvegarde protège la possibilité de reconstruire les données ; elle ne fournit pas une instance déjà en service pour recevoir les requêtes.

La bascule vers une autre machine peut rester manuelle si le délai correspondant entre dans la tolérance du service. Dans ce cas, il faut savoir où se trouvent les données, comment lancer l’application ailleurs et comment rediriger le trafic. Installer un second serveur sans définir ces opérations ne suffit pas à assurer la continuité.

Lorsque même ce délai de bascule est trop long, le besoin change : les instances doivent être réparties avant l’incident, et la défaillance doit pouvoir être détectée puis prise en charge sans attendre une intervention. C’est le signal le plus net pour évaluer une orchestration sur plusieurs machines. Il s’agit d’un seuil fondé sur l’interruption acceptable, pas d’une limite universelle de trafic.

Une matrice de choix fondée sur les contraintes du service

Le nombre de serveurs ne prend son sens qu’avec la panne tolérée, la variation de charge et les moyens de l’équipe. Ces situations donnent des seuils de décision, sans prétendre fixer un nombre maximal de requêtes ou de conteneurs pour Compose :

Un serveur, interruption acceptable : Compose reste cohérent si la capacité de l’hôte suffit et si une restauration organisée respecte le délai admis. Si la charge augmente, dimensionner la machine ou optimiser l’application peut répondre au problème sans modifier l’exigence de disponibilité.
Plusieurs serveurs, bascule manuelle acceptable : répartir certains composants ou préparer un hôte de secours peut répondre au besoin. L’équipe doit toutefois maîtriser le placement des données, la remise en route de l’application et le changement de destination du trafic.
Plusieurs serveurs, perte d’un hôte à absorber automatiquement : le placement de réplicas, la détection des défaillances et l’acheminement du trafic deviennent des fonctions nécessaires. Une orchestration se justifie davantage si les déploiements ou les variations de charge multiplient aussi les interventions manuelles.
Continuité élevée, peu de compétences pour exploiter un cluster : la charge d’administration pèse dans le choix autant que les fonctions disponibles. Un plan de contrôle géré peut retirer une partie de cette charge, mais l’équipe doit toujours concevoir la disponibilité de ses applications et de leurs données.

Le seuil de migration le plus utile est atteint lorsque le temps de reprise prévu après la perte d’un hôte dépasse l’interruption que le service peut supporter. Si le problème porte seulement sur la capacité d’une machine, ce constat ne suffit pas à imposer Kubernetes. Si le problème porte sur la continuité, ajouter des ressources au même serveur laisse subsister la dépendance à cet hôte.

Ce que Kubernetes reprend automatiquement

Des nœuds Kubernetes distincts permettent de maintenir un réplica disponible lorsqu’un hôte tombe en panne.

Les mécanismes d’autoréparation de Kubernetes comprennent le redémarrage d’un conteneur défaillant, la création d’un pod de remplacement pour conserver le nombre de réplicas demandé et le retrait d’un pod défectueux des points de terminaison d’un Service. Kubernetes peut également replanifier une charge lorsque son nœud devient indisponible.

Pour qu’un service reste accessible pendant la perte d’un hôte, ses réplicas doivent effectivement se trouver sur des machines distinctes et les instances restantes doivent pouvoir traiter le trafic. Une capacité disponible est aussi nécessaire pour replacer la charge perdue. Avec une seule instance, ou si tous les réplicas dépendent du même hôte, le mécanisme de remplacement ne garantit pas la continuité pendant la panne.

Les dépendances persistantes réclament leur propre solution. Déplacer un processus applicatif ne rend pas automatiquement disponible une base de données, un volume ou un service externe dont il dépend. Kubernetes prévoit des mécanismes de rattachement de volumes dans certains cas, mais un stockage indisponible peut encore nécessiter une reprise. Une erreur de configuration commune à tous les réplicas ne disparaît pas non plus parce que les processus sont relancés.

Le cluster doit lui aussi résister à la panne

Passer à Kubernetes sur une seule machine conserve le même point de défaillance physique. La documentation Kubernetes sur l’environnement de production indique qu’un plan de contrôle limité à une machine n’est pas hautement disponible. Elle décrit notamment la réplication de ses composants, la répartition des requêtes vers l’API et la disponibilité des nœuds de travail parmi les éléments à prévoir.

Un cluster exploité par l’équipe ajoute la gestion des accès, des mises à jour, du réseau, de la surveillance et de la reprise de ses propres composants. Un fournisseur peut prendre en charge le plan de contrôle, voire une partie de la gestion des nœuds. Cela réduit le travail d’infrastructure, mais ne décide ni du nombre de réplicas applicatifs, ni de leur placement, ni de la disponibilité du stockage et du trafic entrant.

Le choix dépend finalement du délai réel de reprise que le service peut accepter et de la capacité de l’équipe à exploiter la solution retenue. Si une remise en service planifiée suffit, Compose sur un hôte reste proportionné. Si une autre machine doit servir les utilisateurs pendant la perte de cet hôte, la continuité doit être conçue pour l’application, ses données et le cluster qui l’exécute.