‫Mises à jour du service. Vous avez probablement toujours pensé qu'il y avait un moyen de mettre à jour vos services même
‫si nous ne nous sommes pas encore concentrés sur cela.
‫Parlons-en parce que les mises à jour contiennent une foule de choses cachées. La fonctionnalité de mise à jour de Swarm est centrée sur
‫un modèle de mise à jour évolutif pour vos répliques. Ce qui signifie que si vous avez un service avec plusieurs
‫réplicas, et espérons-le, il les parcourra par défaut, un à la fois, en mettant à jour chaque
‫conteneur en le remplaçant par les nouveaux paramètres que vous avez mis dans la mise à
‫jour. commander.
‫Beaucoup de gens diront que les orchestrateurs empêchent les temps d'arrêt dans les mises à jour, mais je ne dirai pas que
‫cela empêche les temps d'arrêt.
‫Je vais dire que cela limite les temps d'arrêt. Parce que prévenir les temps d'arrêt dans n'importe quel système est le travail de test.
‫Vous devez vraiment commencer à tester comment vous faites vos mises à jour et à déterminer si cela a un impact sur mes utilisateurs.
‫La mise à jour d'une base de données a-t-elle un impact sur mon application Web? C'est probablement le cas.
‫Chaque application pour laquelle vous disposez d'un service va être mise à jour et avoir un impact différent sur
‫les autres éléments.
‫Ce n'est pas le travail d'un orchestrateur.
‫Un orchestrateur ne peut pas déterminer que celui-ci est un protocole de base de données, et celui-ci est un protocole d'application
‫REST simple.
‫Donc, ce sont des choses différentes et compliquées que vous devez gérer.
‫Dans le cas des mises à jour de service, s'il s'agit simplement d'une API REST ou d'une interface Web ne faisant rien de fantaisiste,
‫comme des sockets Web ou une longue interrogation, si c'est quelque chose de très simple comme celui-ci ou d'un site Web statique, vous
‫aurez probablement une mise à jour facile. ce ne sera pas un problème.
‫Mais d'autres services comme les bases de données ou le stockage persistant ou tout ce qui nécessite une connexion persistante ...
‫ce sera toujours un défi, peu importe ce que vous essayez de mettre à jour.
‫Alors testez tôt et testez souvent.
‫Comme je l'ai dit auparavant, cela remplacera certainement les conteneurs dans la plupart des mises à jour. À moins que vous ne mettiez à
‫jour une étiquette ou une autre métadonnée avec le service,
‫le contenu sera transféré et remplacé par chaque conteneur par un tout nouveau.
‫Juste être préparé pour cela. Il a beaucoup d'options. En fait, la dernière fois que
‫j'ai compté, il y avait au moins 77 options pour la commande de mise à jour. Mais à peu près tout ce que vous voulez
‫faire peut être modifié.
‫La plupart des options de la commande de mise à jour sont en fait des options de création
‫comportant un -rm et un -add à la fin. Parce que si c'est une option qui peut être utilisée
‫pour plusieurs valeurs, disons un port à publier ou une variable d'environnement, vous pouvez en utiliser beaucoup.
‫Droite?
‫Vous devez donc pouvoir indiquer à la commande de mise à jour celles que vous ajoutez et celles que vous supprimez.
‫Nous verrons cela dans une minute.
‫Cela inclut également les options de restauration et de vérification de l'état.
‫Vous devez examiner les options pour celles-ci et voir si leurs valeurs par défaut ne sont pas idéales pour votre application
‫et tester différents paramètres pour voir si cela facilite la mise à jour pour vous et votre système.
‫Vous verrez également que nous avons ici des options d'échelle et de restauration qui sont leurs propres commandes maintenant.
‫C'étaient des options que vous deviez spécifier avec l'option --rollback ou --scale, mais tant de personnes les ont
‫utilisées si souvent que Docker est en train de les transformer en citoyens de première classe en
‫ligne de commande.
‫Ils pourraient ajouter plus de ceux à l'avenir.
‫Enfin, avant de passer à quelques exemples, si vous créez des piles, une pile déployée sur la même pile est une mise
‫à jour.
‫En fait, il n'y a pas d'option séparée pour les mises à jour de la pile.
‫Vous venez de déployer une pile avec le même fichier que celui qui a été modifié.
‫Ensuite, cela fonctionnera avec les commandes de service et les réseaux, et tout le reste. Cela fonctionnera avec eux pour
‫s'assurer que si des modifications sont nécessaires, elles seront appliquées.
‫Regardons quelques exemples rapides et ensuite nous passerons à la ligne de commande.
‫Celui-ci est probablement l'exemple le plus courant que vous utiliserez, à savoir modifier l'image d'un
‫service.
‫Chaque fois que vous mettez à jour votre application et que vous créez une nouvelle image, vous devez exécuter
‫une commande de mise à jour du service, avec le nom de l'image, puis le nom du service.
‫Donc, dans ce cas, j'ai peut-être eu ma demande avec une étiquette de 1. 2 0.
‫Et dans ce cas, je suis en train d'appliquer un 1. 2 1 image, et le service
‫déterminera, ah oui, c'est une image différente de celle que
‫j'ai dans mon service, et nous allons les mettre à jour. Sur cette prochaine, nous montrons comment faire plusieurs choses à la fois avec une
‫seule commande de mise à jour.
‫Vous pouvez ajouter une variable d'environnement avec env-add, puis supprimer un port avec la commande
‫publish -rm.
‫Nous pourrions également ajouter et supprimer des variables d'environnement et publier des ports dans la même commande de
‫mise à jour autant que nous le souhaitons. Sur ce dernier, cela montre comment nous pouvons utiliser ces
‫nouvelles commandes d'échelle et de restauration sur plusieurs services à la fois. L’un des avantages de leur utilisation par
‫rapport à la commande update est qu’ils peuvent s’appliquer à plusieurs services.
‫Dans ce cas, je vais en fait changer le nombre de répliques du Web et des services
‫d'API en même temps.
‫Comme je l'ai dit il y a quelque temps, dans les mises à jour de Swarm, vous ne disposez pas d'une commande de déploiement différente.
‫Il s’agit du même déploiement de pile de docker, avec le fichier que vous avez modifié, et de travailler
‫avec toutes les autres parties de l’API pour déterminer si des
‫modifications sont nécessaires, puis de les déployer avec une mise à jour de service.
‫D'accord. Commençons par créer un service afin de pouvoir le manipuler avec des commandes de mise à jour.
‫docker service create -p 8088 80 nom Web, nous allons utiliser Nginx et nous allons spécifier une version comme
‫nous le devrions toujours en production.
‫C'est bien, maintenant que nous avons effectivement, au cours du dernier semestre de 2017, l'option de détachement avec nos commandes de création et de mise à jour
‫de service, nous pouvons le voir se dérouler de manière synchrone en temps réel.
‫Ce sera donc utile pour les commandes de mise à jour pour voir comment les mises à jour se déploient via la ligne de commande.
‫D'accord. Maintenant, si nous faisons un service docker ls, nous voyons que notre
‫service est en cours d’exécution et qu’il possède 1 réplique sur 1, il est donc bon de partir.
‫Développons maintenant notre service afin que nous puissions disposer de davantage de répliques. échelle de service docker
‫Web = 5. Et vous venez de voir que l'un de ceux-ci fonctionnait déjà
‫et que les 4 autres devaient commencer. Cela m’a pas mal volé parce que j’avais
‫déjà l’image téléchargée, mais la vôtre peut prendre quelques minutes avant qu’elle soit en attente de téléchargement de l’image sur
‫les autres nœuds.
‫D'accord.
‫Faisons une mise à jour progressive en changeant l'image de ce Nginx.
‫Vous verrez ici que j'ai choisi une image plus ancienne.
‫Maintenant, Docker ne se soucie pas de ce que l’image est réellement.
‫Ce pourrait être une application
‫complètement différente pour tous les soucis. Il sait simplement que dans ce service, je le change en une image différente.
‫Rappelez-vous que, par défaut, il sera traité ici un à la fois.
‫Il va d'abord l'enlever, en créer un nouveau, et ensuite, quand ça va aller, et
‫que ça a l'air en bonne santé, ça commence au prochain. Dans l'exemple suivant, nous allons changer le port
‫publié.
‫Mais vous ne pouvez pas changer de port.
‫Vous devez en fait les ajouter et les supprimer en même temps.
‫Donc, dans ce cas, puisque nous l’avons d'abord publié avec un 8088, nous devons créer une mise à jour du service
‫docker pour publier la mémoire 8088. Je n'ai pas besoin de spécifier la valeur. Je dois juste spécifier la clé. Ensuite, nous
‫allons publier le nouveau numéro 9090. Ensuite, la valeur, qui dans ce cas est 80. Vous verrez qu'il fera le
‫même processus de mise à jour qu'avant.
‫Le dernier exemple dont je veux parler est une sorte de conseil. Parce que vous aurez souvent un défi
‫avec quelque chose appelé rééquilibrage. Ou si vous modifiez le nombre de nœuds ou si vous déplacez beaucoup de choses, si vous
‫avez beaucoup de conteneurs dans votre essaim, vous constaterez peut-être qu'ils ne sont pas vraiment égaux. Vous avez peut-être des nœuds
‫qui indiquent assez peu le nombre de conteneurs en cours
‫d’exécution et d’autres qui en ont beaucoup. Si vous avez beaucoup de choses qui changent, Swarm ne bougera pas pour ne
‫pas tout équilibrer en termes de nombre de ressources utilisées.
‫Cependant, vous pouvez forcer la mise à jour d'un service même sans rien changer à ce service.
‫Ensuite, il réémettra les tâches et, dans ce cas, il sélectionnera les nœuds les moins utilisés, ce qui constitue une forme de rééquilibrage.
‫Souvent, dans un essaim plus petit, lorsque je déplace quelque chose de grand ou que j'ajoute un groupe de nœuds, j'ai soudainement un groupe
‫de serveurs vides qui ne font rien et j'ai besoin de travailler dessus.
‫Donc, ce que je vais faire, c'est prendre un ou deux de mes services, et je vais faire une mise
‫à jour du service docker - force, et dans ce cas, elle va exécuter et remplacer complètement les tâches.
‫Bien sûr, il utilisera la planification par défaut, qui consiste à rechercher des nœuds avec le moins
‫de conteneurs et le moins de ressources utilisées.
‫C'est un peu une astuce pour contourner une quantité inégale de travail sur vos nœuds.
‫N'oubliez pas de nettoyer en supprimant le service que nous avons créé dans cette conférence.