Pourquoi est-il recommandé d'exécuter un seul processus dans un conteneur?

Dans de nombreux articles de blog et dans l'opinion générale, il y a un dicton qui dit "un processus par conteneur".

Pourquoi cette règle existe-t-elle? Pourquoi ne pas exécuter ntp, nginx, uwsgi et davantage de processus dans un même conteneur nécessitant le fonctionnement de tous les processus?

les articles de blog mentionnant cette règle:

• "Un seul processus par conteneur est un modèle de conception recommandé pour les applications Docker."
• "Docker sert uniquement à créer des conteneurs à processus unique ou à service unique."
• "Mieux vaut utiliser un processus par conteneur"
• "Exécuter un seul service en tant que conteneur"
• "Un processus par conteneur"
• "un processus par conteneur"

Oublions les arguments architecturaux et philosophiques de haut niveau pour un moment. Il peut y avoir des cas où plusieurs fonctions dans un même conteneur peuvent avoir un sens, mais il y a des raisons très pratiques pour lesquelles vous pouvez envisager de suivre "une fonction par conteneur" en règle générale:

• La mise à l'échelle des conteneurs horizontalement est beaucoup plus facile si le conteneur est isolé d'une seule fonction. Besoin d'un autre conteneur Apache? Faites-en tourner une autre part. Cependant, si mon conteneur Apache contient également ma DB, mon cron et d’autres pièces, cela complique les choses.
• Avoir une seule fonction par conteneur permet de réutiliser facilement le conteneur pour d’autres projets ou objectifs.
• Il est également plus facile et prévisible pour les développeurs de retirer un composant de la production pour le dépannage local, plutôt que d’un environnement d’application complet.
• Les correctifs / mises à niveau (à la fois le système d'exploitation et l'application) peuvent être effectués de manière plus isolée et contrôlée. Jongler avec plusieurs objets dans votre conteneur crée non seulement des images plus grandes, mais lie également ces composants. Pourquoi faut-il arrêter les applications X et Y uniquement pour mettre à niveau Z?
  • Ce qui précède est également valable pour les déploiements et les restaurations de code.
• La division des fonctions en plusieurs conteneurs offre davantage de flexibilité du point de vue de la sécurité et de l'isolation. Vous pouvez souhaiter (ou exiger) que les services soient isolés au niveau du réseau, que ce soit physiquement ou au sein de réseaux superposés, afin de maintenir une position de sécurité renforcée ou de vous conformer à des éléments tels que le PCI.
• D'autres facteurs plus mineurs tels que le traitement de stdout / stderr et l'envoi de journaux au journal des conteneurs, la conservation des conteneurs aussi éphémère que possible, etc.

Notez que je dis fonction, pas processus. Ce langage est obsolète. La documentation officielle du menu fixe a cessé de dire "un processus" au lieu de recommander "une préoccupation" par conteneur.

Après avoir tué un conteneur "deux processus" il y a quelques jours, j'ai eu quelques problèmes qui m'ont amené à utiliser deux conteneurs au lieu d'un script python qui a démarré deux processus:

1. Docker sait reconnaître les conteneurs écrasés. Cela ne peut pas être le cas lorsque le processus principal semble aller bien, mais un autre processus est mort d'une mort horrible. Bien sûr, vous pouvez surveiller votre processus manuellement, mais pourquoi le réimplémenter?
2. Les journaux de Docker deviennent beaucoup moins utiles lorsque plusieurs processus vomissent leurs journaux sur la console. Là encore, vous pouvez écrire le nom du processus dans les journaux, mais docker peut également le faire.
3. Tester et raisonner sur un conteneur devient beaucoup plus difficile.

La recommandation provient de l'objectif et de la conception de la virtualisation au niveau du système d'exploitation.

Les conteneurs ont été conçus pour isoler un processus pour d'autres en lui donnant son propre espace utilisateur et son système de fichiers.
Il s’agit de l’évolution logique chrootqui consistait à fournir un système de fichiers isolé. La prochaine étape consistait à isoler les processus des autres afin d’éviter les écrasements de mémoire et à utiliser la même ressource (par exemple, le port TCP 8080) de plusieurs processus sans conflit.

L'intérêt principal d'un conteneur est de conditionner la bibliothèque nécessaire au processus sans se soucier des conflits de version. Si vous exécutez plusieurs processus nécessitant deux versions de la même bibliothèque dans le même espace utilisateur et le même système de fichiers, vous deviez ajuster au moins LDPATH pour chaque processus afin que la bibliothèque appropriée soit trouvée en premier et que certaines bibliothèques ne puissent pas être modifiées de cette façon. parce que leur chemin est codé en dur dans l'exécutable au moment de la compilation, consultez cette question SO pour plus de détails.
Au niveau du réseau, vous devrez configurer chaque processus pour éviter d'utiliser les mêmes ports.

L'exécution de plusieurs processus dans le même conteneur nécessite de lourdes modifications et, en fin de journée, annulez l'objectif d'isolation. Si vous êtes autorisé à exécuter plusieurs processus dans le même espace utilisateur, en partageant le même système de fichiers et les mêmes ressources réseau, pourquoi ne pas les exécuter sur l'hôte lui-même?

Voici la liste non exhaustive des torts / pièges lourds auxquels je peux penser:

• Manipulation des grumes

  Que ce soit avec un volume monté ou entrelacé sur stdout, cela apporte un peu de gestion. Si vous utilisez un volume monté, votre conteneur doit avoir sa propre "place" sur l'hôte ou deux conteneurs identiques se battront pour la même ressource. Entrelacer sur stdout pour en tirer parti docker logspeut devenir un cauchemar pour l'analyse si les sources ne peuvent pas être identifiées facilement.

• Attention aux processus zombies

  Si l'un de vos processus se bloque dans un conteneur, Supervisord risque de ne pas pouvoir nettoyer les enfants dans un état zombie, et l'hôte init ne les héritera jamais. Une fois que vous avez épuisé le nombre de pids disponibles (2 ^ 22, soit environ 4 millions), un tas de choses vont échouer.

• Séparation des préoccupations

  Si vous exécutez deux choses séparées, comme un serveur Apache et logstash dans le même conteneur, cela peut faciliter la gestion des journaux, mais vous devez fermer apache pour mettre à jour logstash. (En réalité, vous devez utiliser le pilote de journalisation de Docker. Sera-ce un arrêt gracieux d’attendre la fin des sessions en cours ou non? Si c'est un arrêt gracieux, la nouvelle version peut prendre un certain temps et devenir longue. Si vous faites un kill, vous aurez un impact sur les utilisateurs d'un expéditeur de journaux, ce qui devrait être évité à mon humble avis.

Enfin, lorsque vous avez plusieurs processus, vous reproduisez un système d'exploitation. Dans ce cas, l'utilisation d'une virtualisation matérielle semble plus adaptée à ce besoin.

Comme dans la plupart des cas, ce n'est pas du tout ou rien. L’indication "un processus par conteneur" découle de l’idée que les conteneurs doivent avoir un objectif distinct. Par exemple, un conteneur ne doit pas être à la fois une application Web et un serveur Redis.

Il existe des cas où il est judicieux d'exécuter plusieurs processus dans un même conteneur, à condition que les deux processus prennent en charge une seule fonction modulaire.

Le processus que j'appellerai comme service ici, 1 conteneur ~ 1 service , si l'un de mes services est défaillant, je ne ferai qu'activer ce conteneur respectif et dans quelques secondes tout sera à nouveau opérationnel. Donc, il n'y aura pas de dépendances entre les services. Il est recommandé de conserver une taille de conteneur inférieure à 200 Mo et maximale de 500 Mo (à l'exception de 2 Go pour les conteneurs natifs Windows), sinon, elle sera similaire à la machine virtuelle, mais pas exactement, mais les performances suffiront. Prenez également en considération quelques paramètres tels que la mise à l'échelle, comment puis-je rendre les services résilients, le déploiement automatique, etc.

Et c’est purement votre appel, comment vous devez adapter vos schémas architecturaux tels que le micro-service dans un environnement polygot à l’aide de la technologie de conteneur la mieux adaptée à votre environnement et l’automatisant pour vous.