Quand utiliser Docker-Compose et quand utiliser Docker-Swarm
J'essaie de comprendre les différences ou les similitudes entre D-Compose et D-Swarm.
En lisant la documentation, j'ai compris que docker-compose fournit un mécanisme permettant de lier différents conteneurs et de travailler en collaboration, en tant que service unique (je suppose qu'il utilise la même fonctionnalité que - link commande utilisée pour lier deux conteneurs)
De plus, ma compréhension de docker-swarm est qu’elle vous permet de gérer un cluster de différents dockers-hôtes , chacun exécutant plusieurs instances de conteneur de des images de docker. Nous pourrions définir les connexions comme réseaux superposés entre différents conteneurs de l’essaim (même s’ils traversent deux hôtes dockers de l’essaim) pour les connecter en tant qu’unité.
Ce que j'essaie de comprendre, c’est que docker-swarm a réussi à docker-composer et à superposer des réseaux est le nouveau moyen (recommandé) de connecter des conteneurs?
Ou bien est-ce que docker-compose fait toujours partie intégrante de toute la famille des dockers et il est recommandé et souhaitable de l'utiliser pour connecter des conteneurs afin de travailler en collaboration. Si tel est le cas, docker-compose fonctionne-t-il avec des conteneurs sur différents nœuds de l'essaim?
Ou est-ce que les réseaux superposés permettent de connecter des conteneurs entre différents hôtes de swarm et que docker-compose sert à créer des liens internes?
De plus, je vois aussi qu'il est mentionné dans la documentation de docker que - links n'est plus recommandé et sera bientôt obsolète.
Je suis un peu confus???
Merci beaucoup!
Il sera probablement utile de commencer par quelques définitions:
- docker-compose: Commande permettant de configurer et de gérer un groupe de conteneurs associés. Il s'agit d'une interface avec les mêmes API utilisées par le docker cli, vous pouvez donc reproduire son comportement avec des commandes telles que
docker run. - docker-compose.yml: fichier de définition pour un groupe de conteneurs, utilisé par docker-compose et désormais aussi par le mode essaim.
- mode swarm: utilisé pour gérer un groupe de moteurs de menu fixe en tant qu'entité unique et fournir une orchestration (en essayant constamment de corriger les différences entre l'état actuel et l'état cible).
- service: un ou plusieurs conteneurs pour la même image et la même configuration dans swarm, plusieurs conteneurs offrent une évolutivité.
- stack: un ou plusieurs services au sein d'un essaim, ceux-ci peuvent être définis à l'aide d'un fichier DAB ou d'un fichier docker-compose.yml.
- pont résea: réseau géré par un seul moteur de menu fixe, dans lequel plusieurs conteneurs peuvent communiquer entre eux. Vous pouvez avoir plusieurs réseaux gérés par un moteur et des conteneurs peuvent être attachés à zéro réseau ou plus.
- réseau superposé: Semblable à un réseau en pont, mais couvrant plusieurs moteurs de menu fixe. Celles-ci nécessitent un magasin de clés/valeurs pour conserver leur état. Le mode Swarm fournit cela, mais si le mode Swarm est désactivé, vous pouvez également utiliser etcd, consul ou zookeeper.
- links: une méthode de connexion des conteneurs qui précède le réseau ponté. Son utilisation n'est plus recommandée.
- essaim classique: Un prédécesseur du mode essaim intégré qui fonctionne en tant que conteneur, permet à plusieurs moteurs d'apparaître comme un seul, mais ne fournit pas d'orchestration ni n'inclut son propre magasin k/v.
Pour répondre aux questions:
docker-swarm a-t-il réussi à docker-composer et à superposer des réseaux est-il le nouveau moyen (recommandé) de connecter des conteneurs?
Ou bien est-ce que docker-compose fait toujours partie intégrante de toute la famille des dockers et il est recommandé et souhaitable de l'utiliser pour connecter des conteneurs afin de travailler en collaboration. Si tel est le cas, docker-compose fonctionne-t-il avec des conteneurs sur différents nœuds de l'essaim?
Ils offrent des fonctionnalités différentes et continueront à servir l'un et l'autre. docker-compose ne peut pas démarrer les conteneurs en mode swarm, mais une version plus récente du fichier docker-compose.yml (version 3) peut être utilisée pour définir une pile directement en mode swarm sans utiliser docker-compose. docker-compose est nécessaire pour gérer les conteneurs en dehors du mode essaim, sur un seul moteur de docker ou avec un essaim classique.
Ou est-ce que les réseaux superposés permettent de connecter des conteneurs entre différents hôtes de swarm et que docker-compose sert à créer des liens internes?
De plus, je vois aussi qu'il est mentionné dans la documentation de docker que - les liens ne sont plus recommandés et seront bientôt obsolètes.
docker-compose à partir de la version 2 du fichier yml connecte plusieurs conteneurs entre eux par défaut avec un nouveau réseau ponté par projet (le nom du projet est par défaut). Avec swarm classique, le réseau en superposition utilise par défaut un magasin k/v externe. Et avec une pile en mode essaim, il s'agirait d'un réseau superposé.
L'utilisation de réseaux fixes est le moyen préféré pour que les conteneurs communiquent les uns avec les autres. Vous voulez un réseau par groupe de conteneurs que vous souhaitez isoler du reste de votre environnement de menu fixe. docker-compose automatise cette création de réseau, mais vous pouvez également le faire depuis la ligne de commande avec docker networks create.
Les liaisons ont été en grande partie remplacées par des réseaux fixes avec découverte DNS intégrée. Lorsque vous supprimez des liens de votre fichier docker-compose.yml, vous devrez peut-être les remplacer par un depends_on section pour appliquer la commande de démarrage du conteneur. Autrement, il existe très peu de scénarios dans lesquels la liaison a du sens et où l'utilisation que j'ai vue provient d'une personne qui suit une documentation obsolète.
composer ou essaimer ou superposer des réseaux
Vous constaterez que vous devez utiliser tout ce qui précède si vous faites autre chose qu'une démonstration sur votre ordinateur portable, etc.
J'ai délibérément séparé les réseaux par essaim et par superposition d'essaims, car vous n'avez pas besoin d'utiliser les deux, mais vous ne pouvez pas obtenir un réseau de superposition sans avoir un essaim en dessous.
Compose sert à élever plusieurs conteneurs ensemble. Maintenant, il est logique qu'ils soient liés les uns aux autres, même s'ils ne le sont peut-être pas. Mais supposons un cas typique où les conteneurs sont destinés à des services liés les uns aux autres, alors vous voudriez qu'ils se parlent d'une manière ou d'une autre, tout en contrôlant la façon dont ils se parlent via des réseaux. Par exemple, prenons une application à 3 niveaux comportant un serveur Web, un serveur d'applications et une base de données. Supposons que les trois composants sont dockérisés et que vous utilisez compos pour les faire apparaître ensemble au lieu d'exécuter docker run.. trois fois avec des paramètres différents, etc. Tous les trois apparaîtront, mais vous voudrez peut-être contrôler la façon dont ils se connectent. Vous voulez que le serveur Web puisse communiquer avec le serveur d'applications, mais pas directement avec la base de données. Et vous voudriez que le serveur d'applications parle (ping) du conteneur de serveur de base de données et envoie également une requête ping au serveur Web. Toutes les connexions sont bidirectionnelles, mais limitées aux services avec lesquels vous souhaitez pouvoir communiquer. Pour un tel arrangement, vous devez généralement configurer 2 réseaux - disons frontend et backend. Les conteneurs Web et d'applications sont connectés au réseau frontal. Les conteneurs app et db sont connectés au réseau backend. Parce qu'il n'y a pas de réseau commun entre les conteneurs de base de données et Web, ils ne peuvent pas se toucher (ce qui est votre intention).
Désormais, si vous souhaitez que ces 3 services puissent s'exécuter sur votre cluster de 100 machines et souhaitez également les faire évoluer, vous aurez besoin d'un réseau couvrant plusieurs hôtes. C'est là qu'intervient le réseau de superposition (en essaim). La mise en réseau superposée n’est rien d’autre que la mise en réseau multi-hôtes sur la technologie VxLAN. Vous n'avez pas besoin de connaître VxLAN, sauf qu'il s'agit d'une topologie de réseau standard prise en charge dans la plupart des infrastructures de réseau modernes.
J'espère que ça clarifie.
Edit: Je n'ai pas vu que vous avez déjà une réponse!
Je pense que la plupart des gens comprennent bien ce qu’il en est, mais quelques ajustements sont nécessaires.
Vous avez raison, docker-compos est de faire apparaître des applications multi-conteneurs. Auparavant, vous faisiez docker run .. pour démarrer chaque conteneur. Habituellement, les applications modernes englobant le paradigme des micro-services peuvent être composées de dizaines de services et utilisant docker run .. deviendra très fatigant très bientôt. Ainsi, docker-compose vous permet d’exprimer tous les conteneurs, leurs propriétés et la façon dont ils se connectent en tant que fichier yaml ou json afin que vous puissiez le gérer plus facilement.
Ainsi, docker-compose est la partie d'orchestration de conteneur dans l'écosystème de docker.
Les liens sont différents, ils font simplement partie de docker-compose ou docker run les commandes et sont déconseillées en faveur de software defined networks dont overlay networks ne sont que l’un d’eux.
Swarm est le composant de planification dans le menu fixe. Qu'est-ce que la planification - ce n'est rien d'autre que de déterminer où "placer" vos conteneurs dans votre cluster d'hôtes hôtes. Vous pouvez avoir un cluster de centaines de serveurs et des centaines de conteneurs, chacun encapsulant un service pour une douzaine d'applications différentes. Maintenant, comment ces conteneurs devraient-ils être répartis sur votre cluster de centaines de serveurs? Certains conteneurs devraient-ils être placés uniquement sur certains hôtes, car ils répondent à un critère particulier ou devraient être plus proches (ou non) d’autres conteneurs qui sont en quelque sorte liés ... tout cela fait partie du composant de planification exécuté par le docker Swarm.
Je vous suggère de consulter la documentation de mise en route sur docker.com ici: https://docs.docker.com/engine/getstarted-voting-app/