Quand utiliser Docker-Compose et quand utiliser Docker-Swarm ?

Question

J'essaie de comprendre les différences ou les similitudes entre Docker-Compose y Docker-Swarm .

En lisant la documentation, j'ai compris que docker-compose fournit un mécanisme pour lier différents conteneurs ensemble et travailler en collaboration, comme un seul service (je suppose qu'il utilise la même fonctionnalité que -lien utilisée pour lier deux conteneurs)

De plus, si j'ai bien compris, docker-swarm vous permet de gérer un cluster de différents systèmes d'exploitation. docker-hosts chacun d'entre eux exécute plusieurs instances de conteneurs de certaines images docker. Nous pourrions définir les connexions comme réseaux superposés entre les différents conteneurs de l'essaim (même s'ils traversent deux dockers-hôtes dans l'essaim) pour les connecter comme une unité.

Ce que j'essaie de comprendre, c'est que docker-swarm a succédé à docker-compose et que les réseaux superposés sont le nouveau moyen (recommandé) de connecter les conteneurs ?

Ou bien est-ce que docker-compose fait toujours partie intégrante de l'ensemble de la famille docker et qu'il est attendu et conseillé de l'utiliser pour connecter les conteneurs afin de travailler en collaboration. Dans ce cas, est-ce que docker-compose fonctionne avec des conteneurs sur différents nœuds de l'essaim ?

Ou est-ce que les réseaux superposés servent à connecter les conteneurs entre les différents hôtes de l'essaim 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 -liens n'est plus recommandé et sera bientôt obsolète.

Je suis un peu confus ? ??

Merci beaucoup !

Answer 1

Il sera probablement utile de commencer par quelques définitions :

• docker-compose : Commande utilisée pour configurer et gérer un groupe de conteneurs liés. C'est un frontal aux mêmes api utilisées par le docker cli, donc vous pouvez reproduire son comportement avec des commandes comme docker run .
• docker-compose.yml : Fichier de définition pour un groupe de conteneurs, utilisé par docker-compose et maintenant aussi par le mode swarm.
• mode essaimage : Utilisé pour gérer un groupe de moteurs docker comme une seule entité et fournir une orchestration (en essayant constamment de corriger toute différence entre l'état actuel et l'état cible).
• service : Un ou plusieurs conteneurs pour la même image et la même configuration au sein de l'essaim, plusieurs conteneurs assurent l'évolutivité.
• pile : Un ou plusieurs services dans un essaim, ceux-ci peuvent être définis à l'aide d'un DAB ou d'un fichier docker-compose.yml.
• réseau de ponts : Réseau géré par un seul moteur docker où plusieurs conteneurs peuvent communiquer entre eux. Vous pouvez avoir plusieurs réseaux gérés par un moteur, et les conteneurs peuvent être attachés à zéro ou plusieurs réseaux.
• réseau superposé : Similaire à un réseau de pont mais couvrant plusieurs moteurs docker. Ceux-ci nécessitent un magasin de clés/valeurs pour maintenir leur état. Le mode essaim le fournit, mais si le mode essaim est désactivé, vous pouvez également utiliser etcd, consul ou zookeeper.
• liens : une méthode pour connecter les conteneurs entre eux, antérieure au réseau ponté. Son utilisation n'est plus recommandée.
• essaimage classique : Un prédécesseur du mode swarm intégré qui s'exécute comme un conteneur, permet à plusieurs moteurs d'apparaître comme un seul, mais ne fournit pas d'orchestration et n'inclut pas son propre magasin k/v.

Pour répondre aux questions :

docker-swarm a succédé à docker-compose et les réseaux superposés sont la nouvelle façon (recommandée) de connecter les conteneurs ?

Ou bien est-ce que docker-compose fait toujours partie intégrante de toute la famille docker et qu'il est attendu et conseillé de l'utiliser pour connecter les conteneurs afin de travailler en collaboration. Dans ce cas, est-ce que docker-compose fonctionne avec des conteneurs sur différents nœuds de l'essaim ?

Ils fournissent des fonctionnalités différentes et continueront tous deux à avoir leur utilité. docker-compose ne peut pas démarrer les conteneurs en mode essaim, 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 essaim sans utiliser docker-compose lui-même. docker-compose est nécessaire pour gérer les conteneurs en dehors du mode essaim, sur un seul moteur docker ou avec un essaim classique.

Ou est-ce que les réseaux superposés servent à connecter les conteneurs entre les différents hôtes de l'essaim et que docker-compose sert à créer des liens internes ?

En outre, je vois également qu'il est mentionné dans la documentation de Docker que --links n'est plus recommandé et sera bientôt obsolète.

docker-compose à partir de la version 2 du fichier yml connecte plusieurs conteneurs ensemble par défaut avec un nouveau réseau ponté par projet (le projet correspond par défaut au nom du répertoire). Avec un essaim classique, cela correspondrait par défaut à un réseau superposé utilisant un magasin k/v externe. Et avec une pile en mode swarm, ce serait un réseau superposé.

L'utilisation des réseaux docker est le moyen privilégié pour faire communiquer les conteneurs entre eux. Vous voulez un réseau par groupe de conteneurs que vous souhaitez isoler du reste de votre environnement Docker. docker-compose automatise la création de ce réseau, mais vous pouvez également le faire en ligne de commande à l'aide des commandes suivantes docker networks create .

Les liens ont été largement remplacés par des réseaux docker avec découverte DNS intégrée. Lorsque vous supprimez les liens de votre fichier docker-compose.yml, vous pouvez avoir besoin de les remplacer par un fichier depends_on pour faire respecter l'ordre de démarrage du conteneur. Sinon, il y a très peu de scénarios où la liaison a un sens et tout l'usage que j'ai vu est celui de quelqu'un qui suit une documentation périmée.

Answer 2

composer ou essaimer ou essaimer des réseaux superposés

Vous constaterez que vous devez utiliser tous les éléments ci-dessus si vous faites autre chose qu'une démo sur votre ordinateur portable, etc.

J'ai délibérément séparé les réseaux d'essaims et les réseaux d'essaims superposés, car il n'est pas nécessaire d'utiliser les deux, mais il est impossible d'obtenir un réseau superposé sans avoir un essaim en dessous.

Compose sert à faire apparaître plusieurs conteneurs ensemble. Maintenant, il est logique qu'ils soient liés les uns aux autres, même s'ils ne le sont pas forcément. Mais supposons un cas typique où les conteneurs sont destinés à des services qui sont liés les uns aux autres, alors vous voudriez qu'ils communiquent entre eux d'une certaine manière, tout en contrôlant la façon dont ils communiquent entre eux en utilisant des réseaux. Par exemple, prenons une application à trois niveaux comprenant un serveur Web, un serveur d'applications et une base de données. Supposons que les trois composants soient dockerisés et que vous utilisiez compose pour les réunir au lieu d'exécuter docker run.. trois fois avec des paramètres différents, etc. Les trois s'afficheront, mais vous voudrez contrôler la façon dont ils se connectent les uns aux autres. Vous voulez que le serveur web soit capable de parler au serveur d'applications, mais pas directement à la base de données. Et vous voudriez que le serveur d'applications puisse parler (ping) au conteneur du serveur de données et aussi au serveur web. Toutes les connexions sont bidirectionnelles, mais limitées aux seuls services que vous souhaitez voir communiquer entre eux. Pour ce type d'arrangement, vous devez généralement configurer deux réseaux - disons frontend y backend . Les conteneurs web et app sont connectés au réseau frontal. Les conteneurs app et db sont connectés au réseau backend. Comme il n'y a pas de réseau commun entre les conteneurs web et db, ils ne peuvent pas se toucher (ping), ce qui est votre intention.

Maintenant, si vous voulez que ces trois services puissent fonctionner sur votre cluster de centaines de machines, et que vous voulez également les faire évoluer, vous aurez besoin d'un réseau qui s'étende sur plusieurs hôtes. C'est là que le réseau superposé (dans swarm) entre en jeu. La mise en réseau superposée n'est rien d'autre qu'un réseau multi-hôtes construit sur la technologie VxLAN. Il n'est pas nécessaire de connaître VxLAN, si ce n'est qu'il s'agit d'une topologie réseau standard prise en charge par presque toutes les infrastructures réseau modernes.

J'espère que cela clarifie les choses.

Edit : Je n'avais pas vu que vous aviez déjà obtenu une réponse !

Answer 3

Je pense que vous avez compris l'essentiel de ce qu'est chacun d'entre eux, mais quelques ajustements sont nécessaires.

Vous avez raison, docker-compose permet de créer des applications multi-conteneurs. Auparavant, vous aviez l'habitude de faire docker run .. pour démarrer chaque conteneur. En général, les applications modernes qui adoptent le paradigme des micro-services peuvent être composées de dizaines de services et utilisent docker run .. va devenir très vite fatiguant. C'est pourquoi docker-compose vous permet d'exprimer tous les conteneurs et leurs propriétés, ainsi que la manière dont ils se connectent les uns aux autres, sous la forme d'un fichier yaml o json afin que vous puissiez le gérer plus facilement.

Donc, docker-compose est la partie orchestration de conteneurs dans l'écosystème docker.

Les liens sont différents, ils font partie de docker-compose ou de docker run et sont dépréciées au profit de la commande software defined networks dont overlay networks ne sont que l'un d'entre eux.

Swarm est le composant d'ordonnancement de Docker. Qu'est-ce que la planification ? Il s'agit simplement de déterminer où "placer" vos conteneurs dans votre cluster d'hôtes Docker. Vous pouvez avoir un cluster de centaines de serveurs, et vous pouvez avoir des centaines de conteneurs, chacun encapsulant un service pour une douzaine d'applications différentes. Maintenant, comment ces conteneurs doivent-ils être répartis sur votre cluster de centaines de serveurs, certains conteneurs doivent-ils être placés uniquement sur certains hôtes parce qu'ils répondent à un critère particulier ou peut-être doivent-ils être plus proches (ou non) d'autres conteneurs qui sont d'une manière ou d'une autre liés... tout cela fait partie du composant de planification qui est effectué par docker Swarm.

Je vous suggère de consulter la documentation de démarrage sur docker.com ici : https://docs.docker.com/engine/getstarted-voting-app/