Ce tutoriel va parcourir le nouveau mode Docker Swarm, sur lequel le support d'orchestration de conteneur a été intégré dans le jeu d'outils Docker lui-même. Cet article représente des apprentissages personnels et explore le mode Docker Swarm.
Pourquoi vouloir un système d'orchestration de conteneur ?
Pour faire simple, imaginez que vous deviez exécuter des centaines de conteneurs. Vous pouvez facilement voir que s'ils s'exécutent dans un mode distribué, il existe plusieurs fonctionnalités dont vous aurez besoin d'un point de vue de la gestion afin de vous assurer que le cluster est opérationnel, sain et plus.
La plupart de ces fonctionnalités indispensables comprennent :
- Les bilans de santé sur les conteneurs
- Le lancement d'un ensemble fixe de conteneurs pour une image Docker particulière
- La mise à l'échelle du nombre de conteneurs de haut en bas en fonction du chargement
- L'exécution de la mise à jour continue du logiciel à travers les conteneurs
- et plus...
Vous découvrirez comment faire la plupart de ces tâches en utilisant Docker Swarm. La documentation de Docker et le tutoriel pour essayer le mode Swarm ont été excellents.
Les conditions pré-requises :
- Vous devez connaitre les commandes Docker de base
- Vous devez avoir Docker Toolbox installé sur votre système
- Vous devez avoir au moins la version Docker 1.12
Créer des machines Docker
La première étape consiste à créer un ensemble de machines Docker qui serviront de nœuds dans votre Docker Swarm. Vous allez créer 6 Docker Machines, où l'un d'entre eux agira en tant que gestionnaire (Leader) et les autres seront des nœuds de travail. Vous pouvez créer moins de machines selon vos besoins.
On utilise la commande standard pour créer une Machine Docker nommé manager1 comme indiqué ci-dessous :
docker-machine create --driver hyperv manager1
Gardez à l'esprit que c'est fait sur Windows 10, qui utilise le gestionnaire Hyper-V natif, c'est pourquoi on utilise ce pilote. Si vous utilisez la boîte à outils Docker avec Virtual Box, cela ressemblerait à ceci :
docker-machine create --driver virtualbox manager1
De même, créez les autres nœuds de mots. Dans ce cas ci, comme mentionné, il faut créer 5 autres nœuds de travail.
Après la création, il est conseillé de lancer la commande docker-machine ls pour vérifier l'état de toutes les machines Docker (sans oublier le PILOTE.)
NAME DRIVER URL STATE manager1 hyperv tcp://192.168.1.8:2376 Running worker1 hyperv tcp://192.168.1.9:2376 Running worker2 hyperv tcp://192.168.1.10:2376 Running worker3 hyperv tcp://192.168.1.11:2376 Running worker4 hyperv tcp://192.168.1.12:2376 Running worker5 hyperv tcp://192.168.1.13:2376 Running
Notez l'adresse IP du manage1, puisque vous en aurez besoin. Vous pouvez l'appeler MANAGER_IP plus tard dans le texte.
La méthode pour obtenir l'adresse IP de la machine manager1 est la suivante :
$docker-machine ip manager1 192.168.1.8
Vous devriez être à l'aise pour faire un SSH dans l'une des machines Docker. Vous en aurez besoin car vous exécuterez principalement les commandes du docker depuis la session SSH vers cette machine.
Gardez à l'esprit qu'en utilisant l'utilitaire de la machine docker, vous pouvez utiliser SSH sur l'une des machines comme suit :
docker-machine ssh <nom-machine>Votre cluster swarm
Maintenant que vos machines sont configurées, vous allez procéder à la configuration de Swarm.
La première chose à faire c'est d'initialiser Swarm. Vous allez faire un SSH dans la machine manager1 et initialiser Swarm là-dedans.
$ docker-machine ssh manager1
Effectuez les étapes suivantes :
$ docker swarm init -advertise-addr MANAGER_IP
Génial !
Vous remarquerez également que la sortie mentionne la commande de jointure docker swarm à utiliser dans le cas où vous souhaitez qu'un autre nœud se joigne en tant que travailleur. Gardez à l'esprit que vous pouvez joindre un nœud en tant que travailleur ou en tant que gestionnaire. À tout moment, il n'y a qu'un seul LEADER et les autres nœuds du gestionnaire seront utilisés en tant que sauvegarde au cas où le LEADER actuel se désengagerait.
À ce stade, vous pouvez voir le statut de votre Swarm en entrant la commande suivante, comme indiqué ci-dessous :
docker@manager1:~$ docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS 5oof62fetd..* manager1 Ready Active Leader
Cela montre qu'il n'existe qu'un seul nœud à ce jour, c'est-à-dire gestionnaire1 et qu'il a la valeur de Leader pour la colonne MANAGER.
Restez dans la session SSH elle-même pour manager1.
Rejoindre en tant que travailleur de Node
Pour savoir quelle commande docker swarm doit être utilisée pour se connecter en tant que nœud, vous devez utiliser la commande jeton de jointure <rôle>.
Pour connaître la commande de jointure d'un travailleur, exécutez la commande suivante :
docker@manager1:~$ docker swarm join-tokenworker To add a worker to this swarm, run the following command:
docker swarm join \
- token SWMTKN-1-5mgyf6ehuc5pfbmar00njd3oxv8nmjhteejaald3yzbef7osl1-ad7b1k8k3bl3aa3k3q13zivqd \
192.168.1.8:2377
docker@manager1:~$
Rejoindre en tant que gestionnaire de Node
Pour connaître la commande de jointure d'un gestionnaire, exécutez la commande suivante :
docker@manager1:~$ docker swarm join-tokenmanager To add a manager to this swarm, run the following command:
docker swarm join \ - token SWMTKN-1-5mgyf6ehuc5pfbmar00njd3oxv8nmjhteejaald3yzbef7osl1-8xo0cmd6bryjrsh6w7op4enos \ 192.168.1.8:2377
docker@manager1:~$
Notez dans les deux cas ci-dessus que vous avez reçu un jeton et qu'il rejoint le nœud gestionnaire (vous pourrez identifier que l'adresse IP est identique à l'adresse MANAGER_IP).
Gardez le SSH sur gestionnaire1 ouvert. Et lancez d'autres terminaux de commande pour travailler avec d'autres machines dockers.
Ajout de nœuds de travail à votre Swarm
Maintenant que vous savez comment vérifier la commande pour rejoindre en tant que travailleur, vous pouvez l'utiliser pour faire un SSH dans chacune des machines Docker, puis déclencher la commande de jointure correspondante.
Dans ce cas ci, il y a 5 machines travailleurs (travailleur1 / 2/3/4/5). Pour la première machine Docker travailleur1, on fait ce qui suit:
SSH dans la machine travailleur1, c'est-à-dire docker-machine ssh travailleur1
Ensuite, lancez la commande correspondante que vous avez obtenu en tant que travailleur. Dans ce cas ci, la sortie est indiquée ci-dessous:
docker@travailleur1:~$ docker swarm join \
- token SWMTKN-1-
5mgyf6ehuc5pfbmar00njd3oxv8nmjhteejaald3yzbef7osl1-ad7b1k8k3bl3aa3k3q13zivqd \
192.168.1.8:2377
Ce nœud a rejoint un essaim en tant que travailleur.
docker@travailleur1:~$ Faites la même chose en lançant des sessions SSH pour travailleur2/3/4/5 et en collant la même commande puisque l'on veut que tous soient des nœuds de travail.
Après avoir fait que tous les nœuds de travail rejoignent l'Essaim, retournez à votre session SSH travailleur1 et lancez la commande suivante pour vérifier l'état de votre Essaim, c'est-à-dire voir les nœuds qui y participent :docker@gestionnaire1:~$ docker node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER
STATUS
1ndqsslh7fpquc7fi35leig54 travailleur 4 Ready Active
1qh4aat24nts5izo3cgsboy77 travailleur 5 Ready Active
25nwmw5eg7a5ms4ch93aw0k03 travailleur 3 Ready Active
5oof62fetd4gry7o09jd9e0kf * gestionnaire1 Ready Active Leader
5pm9f2pzr8ndijqkkblkgqbsf travailleur 2 Ready Active
9yq4lcmfg0382p39euk8lj9p4 travailleur 1 Ready Active
docker@gestionnaire1:~$ Comme prévu, vous pouvez voir qu'il y a 6 nœuds, un en tant que gestionnaire (gestionnaire1) et les 5 autres en tant que travailleurs. Vous pouvez également exécuter la commande standard docker info ici et zoomer dans la section Swarm pour vérifier les détails de votre Essaim.Swarm: active
NodeID: 5oof62fetd4gry7o09jd9e0kf
Is Manager: true
ClusterID: 6z3sqr1aqank2uimyzijzapz3
Gestionnaires: 1
Nodes: 6
Orchestration:
Task History Retention Limit: 5
Raft:
Snapshot Interval: 10000
Heartbeat Tick: 1
Election Tick: 3
Dispatcher:
Heartbeat Period: 5 seconds
CA Configuration:
Expiry Duration: 3 months
Node Address: 192.168.1.8 Notez quelques-unes des propriétés :L'essaim est marqué comme actif. Il a 6 nœuds au total et 1 gestionnaire parmi eux.Comme vous exécutez la commande docker info sur le gestionnaire1 lui-même, le gestionnaire montre que le ls est exact. La section Raft est l'algorithme de consensus Raft utilisé. Consultez les détails ici. Créer un service Maintenant que votre essaim est opérationnel, il est temps de planifier vos conteneurs. C'est toute la beauté de la couche d'orchestration. Vous allez vous concentrer sur l'application et ne pas vous soucier de l'endroit où l'application va s'exécuter. Tout ce que vous allez faire est de dire au gestionnaire de faire fonctionner les conteneurs pour vous et il prendra soin de programmer les conteneurs, d'envoyer les commandes aux nœuds et de les distribuer. Pour démarrer un service, vous devez disposer des éléments suivants : Quelle est l'image Docker que vous souhaitez exécuter ? Dans ce cas ci, vous exécuterez l'image nginx standard qui est officiellement disponible depuis le Docker hub.Vous exposerez votre service sur le port 80.Vous pouvez spécifier le nombre de conteneurs (ou d'instances) à lancer. Ceci est spécifié via le paramètre des répliques.Vous déciderez du nom de votre service. Et gardez ça à portée de main. Ce que vous allez faire ensuite est de lancer 5 répliques du conteneur nginx. Pour ce faire, allez à nouveau dans la session SSH pour votre nœud gestionnaire1. Et entrez la commande de création de service docker suivante : docker service create -replicas 5 -p 80:80 -name web nginxctolq1t4h2o859t69j9pptyye Ce qui s'est passé, c'est que la couche d'orchestration va maintenant fonctionner.Vous pouvez connaître l'état du service en donnant la commande suivante: docker@gestionnaire1:~$ docker service ls
ID NAME REPLICAS IMAGE COMMAND
ctolq1t4h2o8 web 0/5 nginx Cela montre que les répliques ne sont pas encore prêtes. Vous devrez entrer cette commande plusieurs fois. En attendant, vous pouvez également voir l'état du service et comment il est orchestré pour les différents nœuds en utilisant la commande suivante: docker@gestionnaire1:~$ docker service ps web
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR
7i* web.1 nginx travailleur3 Running Preparing 2 minutes ago
17* web.2 nginx gestionnaire1 Running Running 22 seconds ago
ey* web.3 nginx travailleur2 Running Running 2 minutes ago
bd* web.4 nginx travailleur5 Running Running 45 seconds ago
dw* web.5 nginx travailleur4 Running Running 2 minutes ago Cela montre que les nœuds sont en cours d'installation. Cela pourrait prendre un moment.Mais remarquez quelques petites choses. Dans la liste des nœuds ci-dessus, vous pouvez voir que les 5 conteneurs sont planifiés par la couche d'orchestration sur gestionnaire1, travailleur2, travailleur3, travailleur4 et travailleur5. Aucun conteneur n'est prévu pour le nœud travailleur1 et c'est très bien.Quelques exécutions du service docker ls montrent les réponses suivantes:docker@gestionnaire1:~$ docker service ls
ID NAME REPLICAS IMAGE COMMAND
ctolq1t4h2o8 web 3/5 nginx
docker@gestionnaire1:~$ Et enfin :docker@gestionnaire1:~$ docker service ls
ID NAME REPLICAS IMAGE COMMAND
ctolq1t4h2o8 web 5/5 nginx
docker@gestionnaire1:~$ Si vous regardez les processus de service à ce stade, vous pouvez voir ce qui suit: docker@gestionnaire1:~$ docker service ps web
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR
7i* web.1 nginx travailleur3 Running Running 4 minutes ago
17* web.2 nginx gestionnaire1 Running Running 7 minutes ago
ey* web.3 nginx travailleur2 Running Running 9 minutes ago
bd* web.4 nginx travailleur5 Running Running 8 minutes ago
dw* web.5 nginx travailleur4 Running Running 9 minutes ago Si vous faites un docker ps sur le nœud gestionnaire1 maintenant, vous constaterez que le démon nginx a été lancé. docker@gestionnaire1:~$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
933309b04630 nginx:latest " nginx -g 'daemon off " 2 minutes ago Up 2 minutes 80/tcp, 443/tcp web.2.17d502y6qjhd1wqjle13nmjvc
docker@gestionnaire1:~$ Accéder au serviceVous pouvez accéder au service en cliquant sur l'un des nœuds du gestionnaire ou du travailleur. Cela n'a pas d'importance si le nœud en particulier n'a pas de conteneur planifié dessus. C'est toute l'idée de l'essaim.Essayez une boucle sur n'importe quelle adresse IP de la machine Docker (gestionnaire1 ou travailleur1 / 2/3/4/5) ou tapez l'URL (http: // <machine-ip>) dans le navigateur. Vous devriez être en mesure d'obtenir la page d'accueil NGINX standard. Ou si vous touchez l'adresse IP du travailleur. Excellent, n'est-ce pas ?Idéalement, vous devriez mettre le service Docker Swarm derrière un équilibreur de chargement. Mise à l'échelle et réduction d'échelleCeci est fait via la commande d'échelle de service docker. Il y a actuellement 5 conteneurs en cours d'exécution. Augmentez-le jusqu'à 8 comme indiqué ci-dessous en exécutant la commande sur le nœud gestionnaire1. $ docker service scale web=8web scaled to 8 Maintenant, vous pouvez vérifier l'état du service et les tâches de processus via les mêmes commandes comme indiqué ci-dessous:docker@gestionnaire1:~$ docker service ls
ID NAME REPLICAS IMAGE COMMAND
ctolq1t4h2o8 web 5/8 nginx Dans la commande ps web ci-dessous, vous trouverez qu'il a décidé de planifier les nouveaux conteneurs sur travailleur1 (2 d'entre eux) et gestionnaire1 (l'un d'entre eux) docker@gestionnaire1:~$ docker service ps web
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE
ERROR
7i* web.1 nginx travailleur3 Running Running 14 minutes ago
17* web.2 nginx gestionnaire1 Running Running 17 minutes ago
ey* web.3 nginx travailleur2 Running Running 19 minutes ago
bd* web.4 nginx travailleur5 Running Running 17 minutes ago
dw* web.5 nginx travailleur4 Running Running 19 minutes ago
8t* web.6 nginx travailleur 1 Running Starting about a minute ago
b8* web.7 nginxgestionnaire1 Running Ready less than a second ago
0k* web.8 nginxtravailleur 1 Running Starting about a minute ago Vous attendez un moment, puis tout va bien, comme indiqué ci-dessous: docker@gestionnaire1:~$ docker service ls
ID NAME REPLICAS IMAGE COMMAND
ctolq1t4h2o8 web 8/8 nginxdocker@gestionnaire1:~$ docker service ps web
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR
7i* web.1 nginx travailleur3 Running Running 16 minutes ago
17* web.2 nginx gestionnaire1 Running Running 19 minutes ago
ey* web.3 nginx travailleur2 Running Running 21 minutes ago
bd* web.4 nginx travailleur5 Running Running 20 minutes ago
dw* web.5 nginx travailleur4 Running Running 21 minutes ago
8t* web.6 nginx travailleur1 Running Running 4 minutes ago
b8* web.7 nginx gestionnaire1 Running Running 2 minutes ago
0k* web.8 nginx travailleur1 Running Running 3 minutes agodocker@gestionnaire1:~$ Inspecter les nœudsVous pouvez inspecter les nœuds à tout moment via la commande d'inspection de nœud.Par exemple, si vous êtes déjà sur le nœud (par exemple gestionnaire1) que vous voulez vérifier, vous pouvez utiliser le nom self pour le nœud. $ docker node inspect self Ou si vous voulez vérifier sur les autres nœuds, donnez le nom du nœud. Par exemple : $ docker node inspect travaileur1 Drainer un nœudSi le nœud est ACTIF, il est prêt à accepter des tâches provenant du maître, c'est-à-dire le gestionnaire. Par exemple vous pouvez voir la liste des nœuds et leur statut en entrant la commande suivante sur le nœud gestionnaire1. docker@gestionnaire1:~$ docker node ls
ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS
1ndqsslh7fpquc7fi35leig54 travailleur4 Ready Active
1qh4aat24nts5izo3cgsboy77 travailleur5 Ready Active
25nwmw5eg7a5ms4ch93aw0k03 travailleur3 Ready Active
5oof62fetd4gry7o09jd9e0kf * gestionnaire1 Ready Active Leader
5pm9f2pzr8ndijqkkblkgqbsf travailleur2 Ready Active
9yq4lcmfg0382p39euk8lj9p4 travailleur1 Ready Active
docker@gestionnaire1:~$ Vous pouvez voir que leur DISPONIBILITÉ est réglée sur PRET.Selon la documentation, lorsque le nœud est actif, il peut recevoir de nouvelles tâches:Au cours d'une mise à jour de service pour intensifierLors d'une mise à jour progressiveLorsque vous définissez un autre nœud pour drainer la disponibilitéLorsqu'une tâche échoue sur un autre nœud actifMais parfois, vous devez mettre le nœud pour une raison de maintenance. Cela signifiait en définissant la Disponibilité sur le mode drain. Essayez cela avec l'un de vos nœuds.Mais d'abord, vérifiez l'état de vos processus pour les services Web et sur les nœuds qu'ils exécutent: docker@gestionnaire1:~$ docker service ps web
ID NAME IMAGE NODE DESIRED STATE
CURRENT STATE ERROR
7i* web.1 nginx travailleur3 Running Running 54 minutes ago
17* web.2 nginx gestionnaire1 Running Running 57 minutes ago
ey* web.3 nginx travailleur2 Running Running 59 minutes ago
bd* web.4 nginx travailleur5 Running Running 57 minutes ago
dw* web.5 nginx travailleur4 Running Running 59 minutes ago
8t* web.6 nginx travailleur1 Running Running 41 minutes ago
b8* web.7 nginx gestionnaire1 Running Running 39 minutes ago
0k* web.8 nginx travailleur1 Running Running 41 minutes ago Vous voyez que vous avez 8 répliques de votre service:2 sur gestionnaire12 sur travailleur11 chacun sur travailleur2, travailleur3, travailleur4 et travailleur5Maintenant, utilisez une autre commande pour vérifier ce qui se passe dans le nœud travailleur1. docker@gestionnaire1:~$ docker node ps travailleur1
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE 8t* web.6 nginx travailleur1 Running Running 44 minutes ago
0k* web.8 nginx travailleur1 Running Running 44 minutes ago docker@gestionnaire1:~$ Nous pouvons également utiliser la commande docker d'inspection de nœud pour vérifier la disponibilité du nœud et comme prévu, vous trouverez une section dans la sortie comme suit: $ docker node inspect travailleur1
..... "Spec ": {
" Role ": " travailleur ",
" Availability ": " active "
}, Oudocker@gestionnaire1:~$ docker node inspect - pretty travailleur1
ID: 9yq4lcmfg0382p39euk8lj9p4
Hostname: travailleur1
Joined at: 2016-09-16 08:32:24.5448505 +0000 utc
Status:
State: Ready
Availability: Active
Platform:
Operating System: linux
Architecture: x86_64
Resources:
CPUs: 1
Memory: 987.2 MiB
Plugins:
Network: bridge, host, null, overlay
Volume: local
Engine Version: 1.12.1
Engine Labels:
- provider = hypervdocker@gestionnaire1:~$ Vous pouvez voir qu'il est " Actif " pour son attribut Disponibilité. Maintenant, définissez la disponibilité sur DRAIN. Lorsque vous entrez cette commande, le gestionnaire arrête les tâches s'exécutant sur ce nœud et lance les répliques sur d'autres nœuds avec la disponibilité ACTIVE. Donc, ce que l'on attend, c'est que le Gestionnaire amènera les 2 conteneurs en cours d'exécution sur travailleur1 et les planifie sur les autres nœuds (gestionnaire1 ou travailleur2 ou travailleur3 ou travailleur4 ou travailleur5). Cela se fait en mettant à jour le nœud en définissant sa disponibilité sur " drain ". docker@gestionnaire1:~$ docker node update -availability drain ravailleur1 travailleur1 Maintenant, si vous faites un état de processus pour le service, vous voyez une sortie intéressante (la sortie a été découpée pour un formatage correct): docker@gestionnaire1:~$ docker service ps web
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE
7i* web.1 nginx travailleur3 Running Running about an hour ago
17* web.2 nginx gestionnaire1 Running Running about an hour ago
ey* web.3 nginx travailleur2 Running Running about an hour ago
bd* web.4 nginx travailleur5 Running Running about an hour ago
dw* web.5 nginx travailleur4 Running Running about an hour ago
2u* web.6 nginx travailleur4 Running Preparing about a min ago
8t* \_ web.6 nginx travailleur1 Shutdown Shutdown about a min ago
b8* web.7 nginx gestionnaire1 Running Running 49 minutes ago
7a* web.8 nginx travailleur3 Running Preparing about a min ago
0k* \_ web.8 nginx travailleur1 Shutdown Shutdown about a min agodocker@gestionnaire1:~$
Vous pouvez voir que les conteneurs sur le travailleur1 (que vous avez demandé à être drainé) sont reprogrammés sur d'autres travailleurs. Dans le scénario ci-dessus, ils ont été planifiés respectivement sur travailleur2 et travailleur3. Ceci est requis car vous avez demandé que les 8 répliques soient exécutées lors d'un exercice de mise à l'échelle antérieur.
Vous pouvez voir que les deux conteneurs sont toujours à l'état de " Préparation " et après un certain temps si vous exécutez la commande, ils s'exécutent tous comme indiqué ci-dessous:
docker@gestionnaire1:~$ docker service ps web
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE
7i* web.1 nginx travailleur3 Running Running about an hour ago
17* web.2 nginx gestionnaire1 Running Running about an hour ago
ey* web.3 nginx travailleur2 Running Running about an hour ago
bd* web.4 nginx travailleur5 Running Running about an hour ago
dw* web.5 nginx travailleur4 Running Running about an hour ago
2u* web.6 nginx travailleur4 Running Running 8 minutes ago
8t* \_ web.6 nginx travailleur1 Shutdown Shutdown 8 minutes ago
b8* web.7 nginx gestionnaire1 Running Running 56 minutes ago
7a* web.8 nginx travailleur3 Running Running 8 minutes ago
0k* \_ web.8 nginx travailleur1 Shutdown Shutdown 8 minutes ago
Vous pouvez simplement utiliser la commande service rm comme indiqué ci-dessous:
docker@gestionnaire1:~$ docker service rm web
webdocker@gestionnaire1:~$ docker service ls
ID NAME REPLICAS IMAGE COMMANDdocker@gestionnaire1:~$ docker service inspect web
[] Error: no such service: web
C'est simple. Dans le cas où vous avez une image Docker mise à jour à déployer vers les nœuds, tout ce que vous devez faire est de lancer une commande de mise à jour de service.
Par exemple:
$ docker service update -image <nomimage>:<version> web
ConclusionLa simplicité de Docker Swarm est définitivement impressionnante. Tout comme les commandes de base fournies avec le jeu d'outils Docker standard, il a été judicieux d'introduire les commandes Swarm dans le même jeu d'outils.
Docker Swarm a beaucoup plus à offrir et vous devriez creuser davantage dans la documentation.
Il est difficile de savoir lequel de Kubernetes ou de Swarm ressortira gagnant, mais il ne fait aucun doute que vous devriez comprendre les deux pour voir quelles sont leurs capacités et ensuite prendre une décision.
Jeu de briques
Snake
Pacman
Bubble