Combien de conteneurs devrait exister par hôte en production? Comment les services devraient-ils être répartis?
J'essaie de mieux comprendre les avantages de Docker et je ne comprends pas vraiment comment cela fonctionnerait en production.
Disons que j'ai une interface Web, un serveur api backend et une base de données. Cela fait 3 conteneurs.
Disons que je veux 3 du front-end, 5 du backend et 7 du db. (Question mineure: est-il toujours logique d'avoir moins de DBS que de serveurs d’arrière-plan?)
Maintenant, étant donné le scénario ci-dessus, si je les regroupe tous sur le même hôte, je bénéficie de l’utilisation efficace des ressources de l’hôte, mais je suis alors DOA lorsque cet ordinateur tombe en panne ou possède une partition réseau.
Si je les sépare en 1 application complète (c.-à-d. 1 FE, 1 BE & 1 DB) par hôte et que je mets des conteneurs supplémentaires sur leur propre hôte, j'obtiens certains avantages d'une utilisation efficace des ressources, mais il me semble que je perds encore beaucoup. lorsque j’ai une partition réseau, car plusieurs services seront supprimés.
Par conséquent, je suis presque convaincu que je devrais mettre un conteneur par hôte, mais cela signifie que j'utilise mes ressources de manière assez inefficace et quels sont les avantages des conteneurs dans la production? Je veux dire, un système d’exploitation peut représenter un couple supplémentaire de concerts par ordinateur en taille de stockage, mais la plupart des fournisseurs de cloud vous proposent un minimum de 10 concerts de stockage. Et avouons-le, un back-end api ou un serveur web ne sera même pas proche des 10 concerts ... même avec l'OS.
Donc, après tout cela, j'essaie de savoir si je manque le point des conteneurs? Le fait de conserver tous les conteneurs d'une application sur un hôte est-il principalement lié aux avantages liés aux tests et au développement?
Je sais qu'il est avantageux de déplacer facilement des conteneurs entre différents fournisseurs/machines, mais pour la plupart, je ne considère pas cela comme un gain énorme personnellement, car cela était faisable avec des images ...
Y a-t-il d'autres avantages pour les conteneurs en production qui me manquent? Ou sont les principaux avantages pour les tests et le développement? (Est-ce que je pense mal aux conteneurs dans la production)?
Note: La question est très large et pourrait remplir un livre entier mais je vais éclairer un peu.
Avantages des conteneurs
La partie excitante sur les conteneurs ne concerne pas leur utilisation sur un seul hôte, mais leur utilisation sur des hôtes connectés sur un grand cluster. Ne considérez pas vos machines comme des hôtes indépendants du menu fixe, mais comme un pool de ressources pour héberger vos conteneurs.
Les conteneurs seuls ne sont pas révolutionnaires (c'est-à-dire. La CTO de Docker a déclaré lors du dernier DockerCon que "personne ne se soucie des conteneurs"), mais couplée à des planificateurs et à des cadres d'orchestration , ils deviennent une abstraction très puissante pour manipuler des logiciels de production.
En ce qui concerne l'argument selon lequel il s'applique également aux ordinateurs virtuels, c'est bien le cas, mais les conteneurs présentent un avantage technique (voir: Quelle est la différence entre Docker et un ordinateur virtuel normal ) par rapport aux ordinateurs virtuels, ce qui facilite leur utilisation?.
Sur un hôte unique
Sur un hôte unique, les avantages que vous pouvez tirer des conteneurs sont (parmi beaucoup d'autres):
- Utilisez-le comme environnement de développement imitant le comportement d'un cluster de production réel.
- Constructions reproductibles indépendantes de l'hôte (pratique pour le partage)
- Testez de nouveaux logiciels sans gonfler votre ordinateur avec des paquets que vous n'utiliserez pas quotidiennement.
Extension d'un hôte unique à un pool de machines (cluster)
Lorsque vient le temps de gérer un cluster de production, il existe deux approches:
- Créez deux hôtes docker et exécutez/connectez les conteneurs ensemble "manuellement" à l'aide de scripts ou à l'aide de solutions telles que docker-compose. La surveillance de la durée de vie de vos services/conteneurs est à votre charge et vous devez être prêt à gérer les temps d'arrêt du service.
- Laissez un orchestrateur de conteneurs s'occuper de tout et surveiller la durée de vie de vos services afin de mieux faire face aux échecs.
Il y a beaucoup d'orchestrateurs de conteneurs: Kubernetes, Essaim, Mesos, Nomade, Cloud Foundry et probablement beaucoup d'autres. Ils alimentent de nombreuses grandes entreprises et infrastructures, comme Ebay, et ont donc trouvé un avantage à les utiliser.
Choisissez la bonne stratégie de réplication
Il est préférable d'utiliser un conteneur en tant que ressource jetable, ce qui signifie que vous pouvez arrêter et redémarrer la base de données indépendamment, sans impact sur le backend (à l'exception du fait de générer une erreur car la base de données est en panne). En tant que tel, vous devriez être capable de gérer tout type de partition réseau tant que vos services sont correctement répliqués sur plusieurs hôtes.
Vous devez choisir une stratégie de réplication appropriée, afin de vous assurer que votre service reste opérationnel. Vous pouvez par exemple répliquer votre base de données sur les zones de disponibilité du fournisseur de sorte que vos données restent disponibles lorsqu'une zone entière tombe en panne.
En utilisant Kubernetes, par exemple, vous pouvez placer chacun de vos conteneurs (1 FE, 1 BE & 1 DB) dans un conteneur. Kubernetes s'occupera de la réplication de ce pod sur de nombreux hôtes et veillera à ce que ces pods soient toujours opérationnels, sinon un nouveau pod sera créé pour faire face à l'échec.
Si vous souhaitez atténuer l’effet des partitions réseau, spécifiez node affinities, en indiquant au planificateur de placer les conteneurs sur le même sous-ensemble d’ordinateurs et de les répliquer sur un nombre approprié d’hôtes.
Combien de conteneurs par hôte?
Cela dépend vraiment du nombre de machines que vous utilisez et des ressources dont elles disposent.
La règle est que vous ne devriez pas surcharger un hôte avec trop de conteneurs si vous ne spécifiez aucune contrainte de ressource (en termes de CPU ou de mémoire). Sinon, vous risquez de compromettre l'hôte et d'épuiser ses ressources, ce qui aura un impact sur tous les autres services de la machine. Une bonne stratégie de réplication est importante non seulement pour un seul niveau de service, mais également pour garantir la bonne santé du groupe de services partageant un hôte.
Les contraintes de ressources doivent être traitées en fonction du type de votre charge de travail: une base de données utilisera probablement plus de ressources que votre conteneur Front-end, vous devez donc dimensionner en conséquence.
Par exemple, en utilisant Swarm, vous pouvez spécifier explicitement le nombre de CPU ou de mémoire dont vous avez besoin pour un service donné (voir documentation du service de docker ). Bien qu'il existe de nombreuses possibilités et que vous pouvez également donner une limite supérieure/inférieure en termes d'utilisation du processeur ou de la mémoire. En fonction des valeurs choisies, le planificateur épingle le service sur la bonne machine avec les ressources disponibles.
Kubernetes fonctionne à peu près de la même manière et vous pouvez spécifier des limites pour vos pods (Voir documentation ).
Mesos dispose de stratégies de gestion des ressources plus fines avec des frameworks (pour des charges de travail spécifiques comme Hadoop, Spark, etc.) et des fonctionnalités de sur-engagement. Mesos est particulièrement pratique pour les types de charges de travail Big Data.
Comment les services devraient-ils être répartis?
Cela dépend vraiment de la solution d'orchestration:
- Dans Docker Swarm, vous créez un service pour chaque composant (FE, BE, DB) et définissez le numéro de réplication souhaité pour chaque service.Dans Kubernetes, vous pouvez créer un module englobant l’ensemble de l’application (FE, BE, DB et le volume associé au DB) ou créer des modules distincts pour le volume FE, BE, DB +.
- Généralement: utilisez un service par type de conteneur. En ce qui concerne les groupes de conteneurs, déterminez s'il est plus pratique de redimensionner l'ensemble du groupe de conteneurs (en tant qu'une unité atomique, c'est-à-dire une nacelle) plutôt que de les gérer séparément.
Résumer.
Les conteneurs sont mieux utilisés avec un framework/plate-forme d'orchestration. Il existe de nombreuses solutions disponibles pour gérer la planification des conteneurs et la gestion des ressources. Choisissez-en un qui convient à votre cas d'utilisation et apprenez à vous en servir. Choisissez toujours une stratégie de réplication appropriée, en gardant à l'esprit les modes de défaillance possibles. Spécifiez les contraintes de ressources pour vos conteneurs/services lorsque cela est possible afin d'éviter l'épuisement des ressources pouvant potentiellement conduire à la suppression d'un hôte.
Containers are better used with an orchestration framework/platform. There are plenty of available solutions to deal with container scheduling and resource management. Pick one that might fit your use case, and learn how to use it. Always pick an appropriate replication strategy, keeping in mind possible failure modes. Specify resource constraints for your containers/services when possible to avoid resource exhaustion which could potentially lead to bringing a Host down.
Cela dépend du type d'application que vous exécutez dans vos conteneurs. Je peux imaginer différentes manières de regarder ceci:
- votre espace disque est-il lourd?
- avez-vous besoin que l'application échoue, sauvegardez sur plusieurs machines?
- pouvez-vous exécuter plusieurs instances différentes d'applications différentes sur le même hôte sans en diminuer les performances?
- utilisez-vous des logiciels tels que kubernetes ou swarm pour gérer vos machines?
Je pense que la plupart des questions sont intéressantes, même sans les conteneurs. Les conteneurs peuvent vous éviter de penser à des hôtes uniques, mais vous devez toujours décider et mesurer vous-même la charge de vos machines hôtes.
Question mineure: Est-il toujours logique d'avoir moins de DBS que les serveurs principaux?
Oui.
Examinez les cas où vous appuyez sur des instructions de sélection SQL normales (sans beaucoup de jointures) pour obtenir des données de la base de données, mais votre logique applicative nécessite trop de calculs. Dans ces cas, vous pouvez envisager de maintenir un nombre élevé de services de back-end et un nombre de services de base de données bas.
Tout dépend du cas d'utilisation à résoudre.