‫Laissez-moi vous parler des pistes sèches et des diff, ce
‫qui est nouveau.
‫Les dernières versions de Kubernetes commençant par 1. 13 ont cette
‫nouvelle option qui nous permet de voir ce
‫que nous allons changer avant de le changer.
‫Nous avons vu cela auparavant.
‫Je vous ai montré quelques exemples plus tôt dans le cours.
‫Mais cette méthode d'utilisation avec
‫la commande apply est nouvelle
‫et meilleure. Ce que nous avions par
‫le passé, c’est que nous avions une période difficile, mais c’était
‫uniquement pour le client. Le client n'a pas réellement
‫parlé au serveur pour lui dire: ces ressources sont-elles déjà présentes?
‫Dois-je les recréer, ou vont-ils être mis à jour ou que va-t-il
‫se passer? Droite.
‫Cela n'est pas arrivé avant.
‫Il existe maintenant une option d'exécution à sec
‫du serveur qui envoie notre YAML au serveur et le
‫compare, détermine ce qui doit réellement se passer, puis fait
‫rapport à la ligne de commande ce
‫qui va changer. Voyons cela en action.
‫Je suis dans le répertoire KAMs YAML, comme je l’ai déjà expliqué dans une
‫conférence. Si vous êtes dans le dépôt de Docker Mastery et que vous ne possédez
‫pas ce répertoire, vous devez alors effectuer
‫une extraction git pour obtenir les dernières mises à jour.
‫Ceci est un fichier que nous avons vu
‫dans une précédente conférence, app. yml. Ceci est un service,
‫plus un déploiement, dans un fichier.
‫Techniquement, deux ressources sont créées avec une
‫commande apply et elles sont liées.
‫Le service utilise un sélecteur, dont nous
‫n'avons pas encore parlé. Les sélecteurs déterminent comment un
‫objet trouve les ressources avec lesquelles il veut parler ou
‫faire quelque chose.
‫Un service doit parler aux pods, il doit donc trouver
‫un moyen d’y accéder.
‫Il utilise des sélecteurs essentiellement comme correspondance
‫de motif pour faire correspondre les étiquettes des
‫clés et des valeurs. Si je réalisais la traditionnelle
‫épreuve à sec ici, alors tout ce que cela ferait serait que le client
‫examine l'application et dise, oui, je vais créer ces objets.
‫D'accord. Il va toujours revenir et dire créé.
‫C'est parce que la demande n'est pas
‫très spécifique. Si vous utilisiez une commande de mise
‫à jour, de création ou de suppression, ce qui, encore une fois,
‫ne me semble pas être un flux de travail très basé sur DevOps.
‫Ces commandes feraient juste un essai et vous savez que la mise
‫à jour dirait oui, elles seront mises
‫à jour toutes les deux. Mais, il ne sait pas vraiment
‫sur votre cluster, non. Il n'a pas demandé au serveur de le savoir.
‫Nous voulons essayer le test à sec du serveur qui est
‫activé par défaut sur n'importe quoi 1. 13 ans et plus récent.
‫Quand je le ferai, il ira ensuite parler au serveur et me
‫donnera une réponse appropriée.
‫Allons-y et créons ceci.
‫Je vais enlever le serveur à sec.
‫Cela créera les deux ressources, le déploiement et
‫le service.
‫Maintenant, si je clique sur la flèche vers le haut et que je reviens à la marche
‫à sec du serveur, vous verrez que le message dit inchangé pour les deux.
‫Cela ne me dit pas ce qui a changé ou s'il
‫y avait quelque chose qui allait changer
‫ce que ce serait. C'est juste pour me dire
‫qu'une ressource va être changée ou non. C'est une sorte de bascule, oui ou non.
‫Pourquoi ne pas obtenir la différence entre ce que
‫nous voulons donner au serveur et l’état
‫actuel de nos ressources?
‫C'est la commande kubectl diff.
‫Si je lui donne simplement un diff au
‫lieu d’un apply, il comparera le YAML
‫que j’ai avec les spécifications présentes dans les serveurs
‫en cours d’exécution. ce statut revient, et il fera un
‫diff sur cela. Faisons cela.
‫Ça ne dit rien parce qu'il n'y a pas de différence.
‫Mais que faire si nous allons changer le YAML?
‫Et si je change les répliques en deux?
‫Ensuite, j'ajoute une étiquette dans les métadonnées et je vais lui donner
‫quelque chose comme ... quelque chose comme.
‫Serveurs dmz.
‫Je l'ai fait. Ca n'a pas d'importance.
‫Ensuite, nous avons les répliques de deux.
‫Si je fais la même différence, cela revient avec les avantages
‫et les inconvénients.
‫Si vous avez l'habitude de lire les diff,
‫cela vous semble parfaitement logique. Si vous n'êtes pas habitué aux diff,
‫le signe moins signifie que cette ligne disparaîtrait.
‫Ensuite, ces lignes seraient ajoutées.
‫Ensuite, ici, il vous montre quelle ligne et
‫quel caractère dans la ligne
‫sont supprimés.
‫Ceci est ajouté.
‫C'est garder le formatage YAML, ce qui est agréable.
‫Cela nous permet de savoir que de nombreux changements se produisent.
‫Génial. Bien sûr, cela ne fait pas vraiment quelque
‫chose comme un canari, un déploiement de test ou quoi que ce soit.
‫Ce n'est pas essayer de faire la chose et ensuite voir
‫quel est le résultat. Il ne s’agit que de
‫regarder la spécification enregistrée, et celle que nous avons sur
‫notre disque. Vérifiez pour
‫plus d'informations à ce sujet sur les liens de ressources.
‫C'est un article de blog de l'équipe Kubernetes sur l'avenir de
‫ces derniers et sur la façon dont ils vont se jouer lorsqu'ils
‫sortiront de la version bêta. Rappelez-vous que ces fonctionnalités sont actuellement en version
‫bêta, au moins en 1. 15 ils sont.
‫Espérons que cela vous permette de créer votre propre flux
‫de travail pour créer des YAML de
‫toutes pièces, gérer les spécifications de ces YAML, puis utiliser la
‫commande apply plusieurs fois pour apporter vos modifications.
‫C'est une infrastructure beaucoup plus conviviale pour DevOps en tant que
‫type de code pour le faire.
‫Tout ce que vous faites est documenté, espérons-le dans Git.
‫Donc, vous espérez que vous ferez un git-commit pour chaque changement que vous
‫apporterez dans votre YAML avant de le déployer sur le serveur.
‫Ensuite, vous avez cette belle documentation dans Git, ainsi que la documentation lorsque
‫vous faites quelque chose comme un diff pour voir ce que vous avez
‫par rapport à ce qui est réellement en cours d'exécution.