‫Très bien, maintenant que nous avons appris tout sur la mise à l'échelle Swarm avec un réseau superposé et un maillage de routage,
‫je souhaite que vous assistiez au processus de création des actifs, ou objets, que vous devez déployer dans
‫un scénario Swarm.
‫Nous n’utilisons donc plus la commande docker run, mais la mise en réseau et les
‫volumes sont identiques mais légèrement différents.
‫Je souhaite vous présenter un scénario concret d’application à plusieurs niveaux et nous allons utiliser l’application de vote distribué
‫de Docker.
‫C'est ce qu'on appelle l'exemple d'application de vote.
‫Vous l'avez peut-être vu dans les notes principales de Docker, dans d'autres laboratoires ou dans des tutoriels.
‫C'est une application assez courante, et je pense, une excellente application, car elle comporte au moins cinq rôles
‫ou différents conteneurs à déployer.
‫Et ils remplissent tous une fonction spéciale et ils font en fait des choses qui fonctionnent, qui font ce qu’ils
‫sont censés faire.
‫Et vous pouvez ainsi jouer avec ce dernier et ses composants d'architecture distribuée très typiques, tels que l'interface
‫Web et le serveur, ainsi
‫que la valeur clé d'une base de données. Je pense que c'est vraiment utile à faire. Dans ce cas, vous allez
‫utiliser le répertoire swarm-app-1. C'est en fait dans notre repo de cours. Dans il n'y a
‫rien mais un readme et une image. À partir de ce readme, vous devez créer le volume, deux réseaux
‫et cinq services nécessaires au bon fonctionnement de cette application.
‫Cela peut vous aider d’essayer certaines de ces commandes localement, ou bien de les écrire dans votre éditeur de texte et de les composer en quelque sorte, parce
‫qu’elles vont être un peu complexes, d’accord. Lorsque vous créez ce
‫service, vous devrez le connecter à un réseau spécifique, ouvrir des ports, l'appeler par
‫un nom spécifique et utiliser une image spécifique. Ainsi, il sera peut-être plus facile de le modifier localement, puis de
‫le copier-coller dans votre shell, où que se trouve votre Swarm.
‫Mais c'est juste moi.
‫Tout va utiliser les images de Docker Hub car dans Swarm de production, vous ne voulez pas construire.
‫Ce n'est pas un processus que vous voulez sur votre Swarm de production, en général.
‫Habituellement, vous souhaitez créer votre bâtiment via un service en ligne automatisé tel que Docker Hub
‫ou Docker Cloud, ou quelque part dans votre pipeline CI / CD qui ne consomme pas de ressources sur votre Swarm de production.
‫Dans ce scénario, nous pouvons imaginer que nos images sont construites ailleurs et stockées
‫sur Docker Hub et nous devons simplement les récupérer, quelles que soient les dernières versions, dans notre Swarm.
‫Et je dirai simplement ceci, comme beaucoup de choses en informatique, il s’agit d’une moitié science, une moitié forme artistique.
‫Vos commandes peuvent être dans des ordres totalement différents ou avoir des ordres d’option totalement différents des miens.
‫Vous pourriez appeler vos réseaux de différentes choses.
‫C'est très bien.
‫Le résultat final est que l’application fonctionne, qu’ils sont capables de se parler correctement,
‫que tous les ports sont publiés et que les données sont protégées dans un volume.
‫Jetons un coup d'oeil à ce que vous affrontez.
‫Imaginez que vous deviez concevoir les commandes et l'architecture pour cela.
‫Et voici ce que le développeur vous donnerait qui a écrit cette application.
‫Eh bien dans ce cas, c'est probablement beaucoup de développeurs qui ont écrit cette application, non?
‫Parce que nous avons en fait une interface Web en Python, nous avons un serveur Web en cours
‫d'exécution dans Node.
‫Nous avons un processus de travail en cours d'exécution. NET, puis nous avons un magasin de valeurs de clés
‫Redis et une base de données PostgreSQL.
‫C’est en fait quelque chose que je vois de plus en plus souvent, où différentes équipes écrivent différentes parties d’une
‫solution et qu’elles ne peuvent choisir que la langue qui, selon elles, convient le mieux à ce scénario.
‫Et dans le monde des conteneurs, ce type d'application brille vraiment. Étant donné que nos applications sont toutes
‫segmentées, elles peuvent
‫toujours être exécutées techniquement sur le même ordinateur, mais elles sont toutes protégées les unes
‫des autres afin d'éviter tout conflit entre Node et dépendances sur Python ou autre.
‫Vous remarquerez également ici le flux de trafic, et l’application de vote ne l’a pas, mais il devrait y
‫avoir une petite flèche indiquant que c’est là que les utilisateurs entreraient dans le volet appli
‫de vote.
‫Et vous pouvez voir que l'application de vote doit en fait pousser vos votes pour cette application qui, en passant, vous allez
‫voter pour les chats et les chiens.
‫Cela poussera cela dans Redis, puis le travailleur vérifiera le système Redis pour tout ce
‫qui se trouve dans la file d'attente, puis transmettra les résultats dans Postgres, qui seront ensuite affichés
‫sur un backend WebSockets mis à jour en temps réel. vote.
‫Si nous sautons rapidement dans le répertoire, j'ai mis quelques notes ici pour vous aider tout au long du processus,
‫car certaines choses sont un peu différentes et nouvelles.
‫Mais le domaine des services serait un peu écrit comme si quelqu'un connaissait leur application mais ne savait
‫pas réellement comment l'implémenter dans Docker. Et c'est un scénario assez commun.
‫Vous pouvez voir que dans les services que j'ai énumérés quelle image vous devez déployer, le nom
‫réel que vous devez lui donner, car ceux-ci sont importants.
‫Malheureusement, ces images sont codées en dur pour les noms qu’elles vont rechercher sur le réseau.
‫Idéalement, vous voudriez des applications que vous pouvez configurer à la volée pour ce qu’elles doivent faire pour les
‫noms, mais dans ce cas, vote cherchera spécifiquement un enregistrement DNS appelé redis. Vous pouvez voir qu'il y a en fait
‫deux réseaux ici. Nous avons un réseau frontal et un réseau backend. C'est également assez typique d'une
‫application plus grande dans laquelle vous souhaitez peut-être protéger votre base de données sur un réseau backend
‫afin que l'application utilisateur frontale n'y ait pas d'accès direct.
‫Et c’est ce que nous montrons ici et vous remarquerez que le travailleur est réellement connecté à deux réseaux.
‫Ainsi, lorsque vous utilisez votre commande create, rappelez-vous que vous utilisez le service Docker create docker run.
‫Donc, lorsque vous utilisez votre commande de création du service Docker, vous devez spécifier le --network
‫deux fois, une fois pour le frontend et une fois pour le backend.
‫Évidemment, vous savez d’abord créer vos réseaux.
‫Donc, certaines de ces choses sont spécifiées ici. Et si vous avez à nouveau besoin de l'image, le
‫diagramme d'architecture est également ici, juste au cas où cela vous aiderait conceptuellement à déployer cela.
‫Et, bien sûr, vous allez avoir la documentation Docker. Vous devrez peut-être utiliser l'option --help de la
‫commande service create qui vous donnera toutes les options dont vous pourriez avoir besoin.
‫Vous n'aurez besoin que de trois ou quatre d'entre eux. Si vous êtes coincé avec les commandes
‫elles-mêmes, vous voudrez peut-être consulter la documentation, que je mettrai aux ressources de cette section.
‫Mais ce document particulier sous Swarm va en fait à la création de services et à la configuration de services.
‫Donc, c'est un peu verbeux, mais il contient beaucoup d'informations qui pourraient vous aider si vous êtes coincé
‫ici.
‫La vidéo suivante, je vais en parler moi-même comme si j'étais toi.
‫Bonne chance et amusez-vous.