‫D'accord.
‫Où que vous utilisiez votre Docker, nous pouvons créer un seul groupe de nœuds pour nos propres
‫tests.
‫La façon dont je peux savoir si Swarm est activé ou non, je peux simplement faire une information sur le menu fixe et vous remarquerez que Swarm
‫est inactif.
‫Nous savons donc que Swarm n’a pas été activé ici. De nouveau, par défaut, Docker n’active aucune
‫des fonctionnalités de Swarm.
‫Je peux exécuter un init Darmer Swarm pour l'initialisation. Cela a pris environ une demi-seconde et nous avons terminé.
‫Nous avons maintenant un essaim à un seul nœud avec toutes les caractéristiques et fonctionnalités que nous
‫obtenons immédiatement.
‫C'était donc probablement la démonstration la plus courte de tout ce cours.
‫Je veux dire, que vient-il d'arriver? Nous avons tapé une commande et de la magie. Ce n'était pas vraiment une magie.
‫Il y avait beaucoup de choses très rapides et efficaces dans la programmation de Go de Docker, mais en gros, dès la sortie de la
‫boîte, il
‫y a beaucoup de choses sur la PKI et la sécurité. Il crée un certificat racine pour l'essaim qu'il utilisera pour établir
‫des certificats de confiance et de signature pour tous les nœuds et tous les gestionnaires. Il créera un certificat spécial pour ce
‫premier nœud de gestionnaire, car il s’agit d’un gestionnaire ou d’un ouvrier.
‫Ensuite, il crée ces jetons que nous pouvons réellement utiliser sur d’autres nœuds pour rejoindre cet essaim.
‫Ensuite, il y a beaucoup d'autres choses en arrière-plan qui activent l'API swarm et créent ce qu'on appelle la base de
‫données de consensus Raft, dont nous parlerons plus loin dans une partie du cours consacrée à la production.
‫Pour votre information, Raft est un protocole qui assure la cohérence sur plusieurs nœuds. Il est idéal pour une
‫utilisation dans le Cloud où nous ne pouvons garantir la disponibilité d’un élément quelconque à
‫tout moment.
‫Il crée cette base de données sur le disque. Il stocke la configuration de l'essaim et
‫de ce premier gestionnaire, et le chiffre en fait.
‫En supposant que vous soyez sur la version 1. 13 ou plus récent. Ensuite, il attendra les autres nœuds avant
‫de commencer à répliquer la base de données sur eux.
‫Encore une fois, tout le trafic qu’il produirait une fois que nous aurions créé d’autres nœuds sera crypté.
‫L'un des composants clés de Swarm qui l'a différencié lors de sa première apparition a été
‫le fait que nous n'avions pas besoin d'un système de stockage de valeur clé supplémentaire ni d'une architecture de base de données pour gérer
‫la configuration de base de notre essaim.
‫Si vous êtes dans l'industrie depuis des années, voire des décennies, il existe ce concept typique de la base
‫de données config, qui est ce système de base de données distinct que vous devez généralement rendre redondant et qui stockera toutes
‫les informations relatives à votre système d'orchestration et d'automatisation. En fait, Swarm a intégré cela
‫directement dans Docker, directement dans le démon, et le gère pour nous.
‫Nous n'avons jamais vraiment besoin de faire quoi que ce soit. Il n'y a pas de mots de passe à s'inquiéter. Il n'y a pas de services
‫spéciaux à démarrer ou quelque chose comme ça.
‫Revenons donc à la ligne de commande.
‫Vous remarquerez ici qu'il est question de ... si je veux ajouter un ouvrier à
‫l'essaim, j'ai juste besoin de couper et coller cela sur les autres serveurs que j'ajouterais.
‫Plus tard, nous allons en fait construire un essaim à plusieurs nœuds, mais pour le moment, nous allons simplement
‫le garder sur un nœud unique. Jetons un coup d'œil à quelques commandes qui en sortiront.
‫La première chose à faire, c'est que nous pouvons faire le noeud docker ls. Dans ce cas, nous ne voyons que le nœud de gestionnaire que nous
‫avons créé.
‫Vous remarquerez qu'il est marqué comme leader et qu'il ne peut y avoir qu'un seul dirigeant à la fois parmi tous les managers.
‫Encore une fois, puisque nous n'en avons qu'un, alors évidemment, c'est le chef. Nous pouvons regarder aide voir
‫quelles autres options nous avons ici. Vraiment, les commandes de nœuds utilisées pour amener vos
‫serveurs dans l’essaim, pour les promouvoir, des ouvriers aux gestionnaires, ou pour les rétrograder des gestionnaires aux ouvriers.
‫Si vous revenez un peu en arrière sur la commande swarm des dockers, nous remarquerons qu’il s’agit d’une portée très étroite
‫à commander.
‫C'est juste pour initialiser, rejoindre ou quitter.
‫La nouvelle commande de déverrouillage, dont nous pourrons parler dans une conférence ultérieure.
‫Pour l'instant, concentrons-nous sur la nouvelle commande de service Docker.
‫De nouveau, le service dans un essaim remplace l'exécution de Docker.
‫Je ne le sais pas vraiment, mais je pense vraiment que cela reposait sur l'idée que
‫nous ne voulions pas casser la fonctionnalité d'exécution de Docker existante, mais l'exécution de Docker a toujours été conçue comme
‫une solution hôte unique.
‫L'idée était de mettre l'accent sur les conteneurs locaux du système avec lequel il parle. Tandis que lorsque nous commençons à
‫parler d'un cluster, nous ne nous soucions pas beaucoup des nœuds individuels.
‫En fait, nous ne les nommons probablement pas. Nous les traitons comme du bétail, si vous avez
‫déjà entendu parler de l'analogie animaux de compagnie-bétail, où ce n'est qu'un nombre.
‫Nous n'allons pas vraiment individuellement sur chaque noeud et ne démarrons pas un conteneur individuel.
‫Nous définissons simplement les besoins sous la forme de services et essaierons ensuite comment il doit disposer de tout cela, sur
‫quels nœuds ils doivent être, et nous savons simplement que nous
‫en avons pour notre dos. Le service docker crée est la
‫façon dont nous lui donnons de nouvelles commandes. Faisons quelque chose de très simple.
‫En réalité, commençons l'image alpine. Ensuite, nous allons avoir l’image Alpine, il suffit d’utiliser
‫ping pour frapper 8. 8 8 8, qui est en fait un serveur DNS Google, mais nous voulons
‫simplement lui donner quelque chose à faire pendant que nous enquêtons sur ce qui se passe.
‫Ensuite, vous verrez que docker est exécuté, il renvoie un ID, mais ce n’est pas l’ID du conteneur. C'est en fait l'identifiant
‫du service.
‫Vous verrez que nous avons maintenant un service répertorié. Tout comme avec notre commande d'exécution de docker, comme nous
‫ne l'avons
‫pas nommée, elle lui a donné un nom aléatoire. Nous pouvons voir que c'est en fait déjà filé.
‫L'un de l'un. Lorsque vous regardez les services, vous verrez toujours ce
‫nombre avec un / au milieu. Cela représente celui de gauche qui représente réellement le nombre de personnes en cours d'exécution.
‫Et celui de droite est le nombre que vous avez spécifié pour qu'il s'exécute.
‫L'objectif de l'orchestrateur est de faire correspondre ces chiffres, peu importe ce qu'il faut.
‫Mais cela encore ne nous montre pas réellement le conteneur réel.
‫Cela ne fait que nous montrer une liste de nos services, afin que nous puissions approfondir un peu plus loin.
‫Nous faisons un ps de service docker, puis nous lui donnons le nom ou l’ID du service, ce qui nous
‫indiquera les tâches ou les conteneurs de ce service. Vous verrez que cette commande est similaire à la commande docker container
‫ls, mais elle contient en fait ce composant de nœud car, dans le cas de scénarios multi-serveurs, il peut être
‫nécessaire de savoir sur quel serveur il est exécuté. Vous remarquerez qu'il lui a en
‫fait donné le nom d'un incrément sur le nom du service.
‫Si nous revenons à la commande ls du conteneur docker, cela fonctionne toujours.
‫Dans ce cas, l'orchestration de Swarm ajoute des informations aux noms et aux
‫images en cours d'exécution. Nous aborderons également certaines de ces différences subtiles plus tard.
‫Pour le moment, prenons ce service et étendons-le. Pour cela, nous utilisons la mise à jour du service Docker,
‫puis le nom de notre service, ou l'ID dans ce cas, je ferai l'ID. Et je veux changer un attribut sur
‫le service.
‫Dans ce cas, je souhaite modifier le nombre de réplicas.
‫Donc, si nous faisons un service fixe à nouveau, nous en voyons maintenant trois sur trois. Si nous faisons un ps service docker, nous
‫voyons maintenant trois tâches. Vous remarquerez que deux d'entre elles ont été créées il y a quelques secondes.
‫Si nous étions assez rapides et si nous déployions quelque chose d'assez gros, nous pourrions exécuter le service ls et
‫voir qu'il nous indiquait zéro sur trois. Un sur trois.
‫Cela augmentera au fur et à mesure que les choses commencent. Il se trouve que Alpine était déjà sur cette machine, en
‫termes d’image, et qu’il n’a pas fallu beaucoup de temps pour lancer une commande ping.
‫Nous ne pourrions pas être aussi rapides.
‫L’intérêt de cette commande de mise à jour est que vous pouvez imaginer la différence entre la commande d’exécution
‫de Docker que vous pourriez utiliser sur un seul serveur de développement ou de test ou sur votre ordinateur local,
‫et l’objectif de production qui consiste à toujours garder un élément
‫disponible le plus possible.
‫C'est l'un des objectifs de conception de Swarm. Cette commande que nous n'avons pas encore
‫utilisée est la commande de mise à jour Docker. C’était une commande pour les conteneurs d’exécution de Docker qui nous permettait de
‫mettre à jour certaines variables de notre conteneur en cours d’exécution sans avoir à le tuer ni à le redémarrer.
‫Presque toutes ces options sont liées à la limitation et au contrôle de l'utilisation des ressources pour ce conteneur.
‫Parce que l’une des caractéristiques typiques d’une application à long terme est qu’il est nécessaire
‫de modifier ses ressources, peut-être parce que les bases de données sont devenues plus volumineuses et ont besoin de plus de RAM.
‫Ou peut-être avez-vous un processus incontrôlable qui consomme trop de temps processeur et vous devez le limiter.
‫Si nous faisons une aide sur la commande docker service update, vous verrez que nous avons beaucoup plus d’options.
‫Parce que l'objectif d'un service Swarm est qu'il soit capable de remplacer des conteneurs et de mettre à jour les
‫modifications apportées au service sans supprimer le tout.
‫Si vous disposez d'un service contenant trois conteneurs, vous pouvez techniquement supprimer un à la fois pour effectuer un changement et effectuer une mise à jour
‫progressive, qui correspond au modèle bleu-vert dont nous avons parlé. C’est pourquoi nous voyons beaucoup plus d’options
‫car nous pouvons modifier ces options pouvant nécessiter un redémarrage du conteneur, mais l’essaim
‫s'assurera intelligemment que la façon dont nous les mettons à jour se fait selon un modèle
‫garantissant une disponibilité constante.
‫Revenons donc à notre liste de conteneurs docker très rapidement. Vous remarquerez que nous avons ces trois maintenant, et
‫si j'y allais et, en quelque sorte comme un voyou, faisais une boîte à conteneurs docker, et je spécifiais un de ces
‫conteneurs, et je le forçais ... Disons que je bat le premier et le sors juste.
‫D'accord.
‫Maintenant, je fais un service fixe, et vous voyez comment il montre deux des trois?
‫Parce que je suis entré dans le dos de Swarm et que j’ai emporté un conteneur en cours
‫d’exécution, il va identifier ce conteneur et en lancer un nouveau en quelques secondes pour remplacer celui qui
‫est tombé.
‫Donc, si j’ai fait un ps de Docker Service sur Frosty, vous verrez qu’il montre l’historique de la première tâche ici dans la liste, c’est qu’elle en
‫avait une qui a échoué et qu’elle en a démarré une nouvelle il ya 24 secondes.
‫L’une des responsabilités du système d’orchestration de conteneur est de s’assurer que les services que
‫vous avez spécifiés sont toujours en cours d’exécution
‫et qu’ils échouent lorsqu’ils échouent. Quelle est la différence avec le docker, non? docker run ne
‫recréerait jamais un conteneur.
‫C'est pourquoi chaque fois que nous exécutons l'une de ces commandes de service Docker, nous ne parlons pas
‫directement d'une action telle que la création d'un conteneur.
‫En fait, nous disons à un système d'orchestration, hé, mettez ce travail dans votre file d'attente.
‫Lorsque vous pourrez y accéder, veuillez effectuer les actions sur l'essaim que j'ai demandé ici. C'est une grande
‫différence.
‫C'est subtile dans la ligne de commande, mais c'est une grande différence car cela signifie qu'il y a des possibilités de restauration.
‫Il y a une atténuation des échecs et beaucoup d'intelligence intégrée à cela.
‫Dans ce cas, si je voulais réellement supprimer tous ces
‫conteneurs, je devrais supprimer le service. Je devrais faire le service de docker.
‫Et puis le glacial.
‫Si nous faisons un service fixe, nous ne voyons rien. Si nous faisons un
‫conteneur docker ls, nous voyons trois conteneurs.
‫Oh et c'est parti.
‫Cela montre ici l'automatisation qui se passe sur le backend.
‫Nous avons pu rapidement montrer que nous avions supprimé le service, mais le système d’orchestration n’avait pas suivi tous ses
‫processus de nettoyage du service et de la tâche qui le sous-tendait. Ces concepts doivent être assez faciles à comprendre car ils
‫développent vraiment les concepts de gestion de Docker que nous avons abordés précédemment dans
‫ce cours.
‫Ensuite, construisons un nuage de nœuds multiples et commençons à redimensionner nos conteneurs.