‫L'une des grandes promesses des conteneurs est que nous pouvons facilement déployer nos applications comme si nous étions un service de plate-forme, vous savez, comme
‫Heroku ou quelque chose du genre. Nous pouvons le faire sur n'importe quel matériel, que ce soit sur
‫notre matériel ou sur un fournisseur de cloud, qu'il soit virtuel ou physique. Avec Docker, nos applications peuvent fonctionner de la
‫même manière, qu’elles soient Amazon, Azure, DigitalOcean, Linode, Rackspace, Google Cloud ou autre. Sans toutes ces fonctionnalités de plate-forme, comment déployer
‫et gérer facilement nos dizaines, voire des centaines, voire des milliers de conteneurs sur
‫de nombreux serveurs ou instances? Ou des nœuds ou des gouttelettes ou autre chose.
‫Cela soulève des problèmes vraiment nouveaux qui n’étaient pas auparavant des problèmes pour les petites organisations.
‫Nous connaissons tous Netflix et les grandes organisations comme celle-ci pouvant atteindre des milliers et des milliers de nœuds, et
‫des dizaines de milliers de nœuds, et ils ont beaucoup d'ingénieurs.
‫Mais, si vous avez seulement quelques personnes dans votre équipe, ou si vous êtes juste un développeur en solo, comment
‫prenez-vous vos conteneurs, les adaptez-vous et gérez-vous leur cycle de vie? De les déployer, de les démarrer, de les
‫redémarrer, de les recréer, de les supprimer et de les mettre à jour, etc.
‫Nous commençons à nous demander comment Docker fait exactement cela ou le fait même du tout.
‫Certaines des questions que nous nous posons sont, par exemple, comment évoluer? Comment pouvons-nous augmenter? Comment pouvons-nous nous
‫assurer que nos conteneurs redémarrent s'ils échouent?
‫Comment pouvons-nous remplacer ces conteneurs quand nous avons réellement une mise à jour pour eux? Ce qui s'appelle de nos jours bleu vert
‫déployer, ce qui signifie que vous avez zéro temps d'immobilisation et vous sortez les serveurs du
‫pool afin d'en amener de nouveaux. Vous vous retrouvez avec toujours quelque chose de disponible
‫pour ne jamais être vraiment en panne lorsque vous mettez à jour. Comment savoir si nous avons des dizaines de nœuds ou même trois nœuds à
‫partir desquels nous avons démarré ces conteneurs? Sur quel noeud se trouve notre conteneur? Comment pouvons-nous communiquer sur
‫ces différents nœuds ou serveurs avec notre réseau dans les conteneurs?
‫En matière de sécurité, comment pouvons-nous être sûrs que nos conteneurs ne fonctionnent que sur les machines
‫sur lesquelles nous avions l'intention de fonctionner?
‫Maintenant que nous déplaçons des éléments et les déployons de manière dynamique à la volée, comment stockons-nous les informations privées
‫dont nous avons besoin pour nos conteneurs, telles que les secrets ou les mots de passe?
‫Cela nous amène donc à une évolution majeure de la portée de ce que Docker tente de résoudre.
‫Quand les gens me parlent et pensent que Docker n'est qu'un runtime de conteneur, je ne
‫fais que mentionner Swarm Mode, une toute nouvelle fonctionnalité disponible en 2016 qui rassemble des années de compréhension des besoins des
‫conteneurs et de la manière de les gérer en direct. en production.
‫Swarm est donc essentiellement une solution de clustering de serveurs qui regroupe différents systèmes d’exploitation ou hôtes,
‫ou nœuds, ou
‫ce que vous voulez appeler, dans une seule unité gérable dans laquelle vous pourrez ensuite orchestrer le
‫cycle de vie de vos conteneurs. Soyons clairs: nous ne parlons pas réellement de Swarm, que
‫je vais appeler Swarm Classic, qui était un composant supplémentaire de Docker avant 1. 12 est sorti. C’était vraiment un conteneur qui s’exécutait à l’intérieur
‫de Docker, qui ne contenait
‫que vos commandes d’exécution de Docker et les répétait sur plusieurs serveurs.
‫Cela a résolu quelques problèmes, mais nous n’avions pas vraiment besoin de résoudre réellement 80% des
‫problèmes de gestion de vos conteneurs.
‫À l'été 2016,
‫lors de dockercon 2016, Docker a en fait annoncé Swarm Kit, un ensemble de bibliothèques ou une boîte à outils liée à
‫de nombreuses nouvelles fonctionnalités de Swarm.
‫Ensuite, ils ont collé cela directement dans le serveur Docker. Tout au long de ce cours, vous avez eu
‫accès aux fonctionnalités disponibles dans la CLI et sur votre serveur.
‫Maintenant, nous pouvons enfin plonger dedans.
‫En janvier 2017, 1. 13 sont sortis, et bien sûr, Swarm Mode
‫étant une nouveauté en 2016, ils vont continuer à l'améliorer dans les années à venir.
‫En janvier, ils ont ajouté des fonctionnalités supplémentaires appelées Piles et Secrets, ainsi que d'autres
‫bonus dont nous parlerons plus tard. Il est important de noter que Swarm n’est pas activé à l’origine.
‫En fait, sur votre ordinateur, vous ne pouvez pas utiliser les commandes répertoriées ici pour le moment. Cela vous donnerait une
‫erreur car Swarm doit être activé.
‫C’était l’un des objectifs de conception: aucun des codes de Swarm n’affecterait le
‫démon Docker existant, et tous les outils et systèmes qui utilisaient déjà Docker, ou
‫peut-être qu’ils avaient leur propre orchestration sur Docker, continuer à fonctionner et ne pas être
‫gêné
‫par Swarm faisant maintenant partie de Docker. Avant de commencer à plonger, voici quelques concepts de base: ces boîtes
‫bleues que vous voyez au-dessus sont ce que nous appelons des nœuds de gestion. Elles contiennent en fait une base
‫de données connue sous le nom de base de données Raft.
‫Il stocke leur configuration et leur donne toutes les informations dont ils ont besoin pour être l'autorité
‫à l'intérieur d'un essaim.
‫Nous avons donc trois gestionnaires différents qui ont tous été ajoutés à l'essaim. Ils conservent
‫tous une copie de cette base de données et cryptent leur trafic afin de garantir l'intégrité et de garantir la confiance dont
‫ils disposent pour gérer cet essaim en toute sécurité. .
‫Ci-dessous dans le vert, nous avons effectivement des notes de travailleur. Maintenant, vous pouvez voir dans le concept de Swarm, nous
‫avons maintenant des gestionnaires et des travailleurs.
‫Chacun de ceux-ci serait une machine virtuelle ou un hôte physique exécutant une distribution de serveur
‫Linux ou Windows.
‫Cela montre comment ils communiquent tous via ce que nous appelons le plan de contrôle, c'est-à-dire la manière
‫dont les ordres sont envoyés autour de l'essaim, en participant à des actions. Dans une vue un peu plus compliquée, nous avons cette base
‫de données de consensus Raft que j'ai mentionnée, qui est reproduite à nouveau parmi tous les nœuds.
‫Ils donnent des ordres aux travailleurs.
‫Les gestionnaires eux-mêmes peuvent également être des travailleurs. Bien sûr, vous pouvez rétrograder et promouvoir les travailleurs et
‫les gestionnaires dans les deux rôles différents.
‫Lorsque vous pensez à un gestionnaire, pensez généralement à un travailleur disposant des autorisations nécessaires pour contrôler l'essaim.
‫Encore une fois, la seule condition requise pour chacun de ces serveurs est
‫qu’ils utilisent le même Docker que vous utilisez déjà. Avec ce concept d'essaim et ces gestionnaires, nous avons maintenant de nouveaux concepts de
‫ce à quoi nos conteneurs ressemblent.
‫Ainsi, avec la commande d'exécution Docker, nous ne pouvons vraiment déployer qu'un seul conteneur.
‫Cela créerait simplement un conteneur.
‫C'était toujours sur la machine avec laquelle la CLI de Docker parlait.
‫C'est généralement votre ordinateur local, ou peut-être un serveur auquel ils sont connectés. Cette commande d'exécution de Docker n'avait pas
‫de concepts sur la manière de faire évoluer ou de développer.
‫Nous avions donc besoin de nouvelles commandes pour gérer cela.
‫C'est de là que provient la commande de service Docker. Dans un essaim, il remplace la
‫commande d'exécution Docker et nous permet d'ajouter des fonctionnalités supplémentaires à notre conteneur lorsque nous l'exécutons, telles que
‫des répliques pour nous dire le nombre de celles qu'il souhaite exécuter.
‫Celles-ci sont appelées tâches.
‫Un seul service peut avoir plusieurs tâches, et chacune de ces tâches lancera un conteneur.
‫Dans cet exemple, nous avons créé un service utilisant docker service create pour créer un service Nginx à l'aide de l'image Nginx,
‫comme nous l'avons déjà fait plusieurs fois auparavant.
‫Mais nous lui avons dit que nous aimerions trois répliques.
‫Donc, il utilisera les nœuds de gestion pour décider où placer l’essaim. Par défaut, il essaie de les
‫répartir.
‫Chaque nœud obtiendrait sa propre copie du conteneur Nginx jusqu'aux trois répliques dont nous avions
‫indiqué avoir besoin.
‫Il s’agit d’une compréhension rapide et élémentaire du fonctionnement des gestionnaires et de ce qu’ils font en arrière-plan.
‫Toutes ces fonctionnalités sont nouvelles.
‫Il ne s'agit pas simplement de prendre votre commande et de l'exécuter sur une API, comme nous le ferions avec
‫une commande d'exécution Docker.
‫En fait, il s'agit d'une API Swarm totalement nouvelle, qui regroupe de nombreux services d'arrière-plan, tels que le planificateur, le répartiteur,
‫l'allocateur et l'orchestrateur, qui permettent de prendre des décisions concernant ce que les travailleurs doivent
‫exécuter à un moment donné.
‫Ainsi, les travailleurs se rapportent constamment aux gestionnaires et demandent un nouveau travail.
‫Les gérants travaillent constamment à de nouvelles tâches et évaluent ce que vous leur avez dit de faire par rapport à
‫ce qu’ils font réellement.
‫Ensuite, s’il y a un rapprochement à effectuer, ils apporteront ces modifications, par exemple en leur demandant
‫de créer trois tâches de réplication supplémentaires dans ce service.
‫Donc, l'orchestrateur va se rendre compte de cela et ensuite donner des ordres aux ouvriers et ainsi de suite.
‫Avec ce mode Swarm, nous disposons réellement d'un ensemble de fonctionnalités qui nous permettent d'utiliser déjà les compétences Docker existantes
‫pour déployer nos conteneurs sur Internet de manière fiable et résoudre de nombreux problèmes. problèmes
‫que nous aurions une fois que nous allons
‫la production.