Stefan Prodan sur la livraison progressive, Flagger et GitOps


00:01 Daniel Bryant: Bonjour et bienvenue sur le podcast InfoQ. Je suis Daniel Bryant, responsable des actualités chez InfoQ et architecte produit chez Datawire. Et j'ai récemment eu le plaisir de m'asseoir avec Stefan Prodan, ingénieur d'expérience de développement chez Weaveworks et créateur du projet Flagger. Stefan fait beaucoup de travail dans les espaces de livraison continue et de livraison progressive depuis un certain temps maintenant. Et donc j'étais désireux de puiser dans ses expériences ici. Je voulais comprendre l'espace problématique pour quelque chose comme la livraison progressive et aussi explorer comment des outils tels que Flagger et Flux s'intègrent. J'avais envie de choisir les cerveaux de Stefan autour du rôle des passerelles API et des maillages de service dans ce domaine et d'entendre ses expériences avec la course à pied Versions Canary, test des API et intégration de celles-ci dans les pipelines de livraison. Bonjour Stefan et bienvenue sur le podcast InfoQ. Merci de me rejoindre aujourd'hui.

00:45 Stefan Prodan: Salut, Daniel. Merci de m'avoir. Je suis très content d'être ici.

00:49 Présentations

00:49 Bryant: Pourriez-vous vous présenter brièvement pour les auditeurs, s'il vous plaît?

00:51 Prodan: Salut à tous. Je suis Stefan Prodan. Je travaille pour Weaveworks. Je fais partie de l'équipe de l'expérience développeur. Je suis vraiment un ingénieur. Je fais aussi des choses autour de la communauté et de l'open source ici chez Weaveworks. Je travaille principalement sur des projets open source depuis près de trois ans, et je suis heureux de parler aujourd'hui des projets open source auxquels je contribue.

01:11 Pourriez-vous expliquer brièvement le problème dans lequel se trouve l'outil de livraison progressive de Flagger?

01:11 Bryant: Des trucs géniaux. Alors hors micro, nous avons déjà discuté de Flagger et Flux. Nous allons certainement couvrir les deux. J'étais d'abord intéressé par l'outil Flagger. Donc, Flagger est commercialisé en tant qu'opérateur de livraison progressive pour Kubernetes et on vient de voir que c'est celui que je vais lancer. Super excitant. Vous et moi en parlions sur Twitter. Pourriez-vous expliquer brièvement l'espace problématique dans lequel se trouve Flagger?

01:32 Prodan: Oui. Ainsi, Kubernetes ajoute beaucoup à la machinerie de déploiement lorsque, disons, vous souhaitez publier une nouvelle version de votre application sur un cluster de production, Kubernetes vous propose quelques stratégies de déploiement sur la façon dont nous pouvons le faire en toute sécurité. Vous pouvez considérer Flagger comme un complément à l'API Kubernetes et à la machinerie de déploiement, qui ajoute plus de stratégies, ajoute plus d'options, sur la façon dont nous pouvons faire le déploiement. Par exemple, vous pouvez utiliser le trafic public pour tester votre application, ou vous pouvez déclencher des tests pour vous assurer que ces tests réussissent dans votre système de production avant d'exposer votre nouvelle version aux utilisateurs finaux. C'est donc une sorte d'extension de la partie déploiement.

02:15 Bryant: Très gentil. Donc, regarder sur le site Web, le site Web de Flagger, et il disait que des versions plus sûres, un routage flexible du trafic et la validation des extensions étaient les éléments clés. Que voulez-vous dire par ces trois choses?

02:26 Prodan: Donc Flagger, c'est un opérateur. Ce que signifie un opérateur dans Kubernetes land, signifie que vous pouvez l'exécuter dans votre cluster. Ensuite, vous le contrôlez via l'API Kubernetes. Vous avez donc une chose appelée la ressource personnalisée, qui disons que c'est un fichier YAML, que vous pouvez placer dans un référentiel Git, que vous pouvez appliquer avec kubectl. Et cette ressource de Flagger s'appelle Canary. Vous pouvez donc définir une politique sur la manière dont vous souhaitez effectuer ces types de déploiements. Et même si la ressource s'appelle Canary, vous pouvez en fait faire plus que de simples déploiements Canary. Vous pouvez également faire des choses comme des tests A / B ou un déploiement bleu / vert normal, etc.

03:08 Prodan: Maintenant, pour la partie observabilité, lorsque vous déployez une nouvelle version de votre application, vous voulez voir comment elle se comporte dans votre cluster de production. Et ce que Flagger vous permet de définir, c'est un moyen de déplacer progressivement le trafic vers la nouvelle version. Et vous pouvez également définir dans cette politique de déploiement, quel type de métrique et quel type de KPI vous intéresse.

03:35 Prodan: Par exemple, l'exemple le plus simple que je pourrais donner est que vous déployez une nouvelle version et que vous voulez que le taux d'erreur soit inférieur à un certain seuil. Disons que si mon application renvoie 500 erreurs, soit plus de 1% du trafic total, alors peut-être que ce n'est pas une bonne chose de la déployer en production. Ainsi, Flagger peut effectuer une restauration automatique en fonction de ce KPI que vous avez défini.

04:01 Prodan: Maintenant, la définition des KPI n'est pas quelque chose qui est corrigé d'une certaine manière. Comme, d'accord, Flagger est livré avec deux KPI intégrés. L'un est le taux d'erreur et l'autre est la latence. Nous pouvons donc dire si ma nouvelle version est que le temps de réponse moyen est inférieur, disons, une demi-seconde, alors mon application est trop lente. Je vais rompre certains SLA et ainsi de suite. Je ne veux pas que cela se termine en production, mais vous avez généralement des KPI spécifiques pour chaque application que vous développez. Ainsi, la partie extensibilité est l'endroit où vous pouvez définir vos propres KPI, vos propres métriques, et Flagger en tiendra compte lors de l'analyse du déploiement.

04:42 Bryant: Très gentil, Stefan. Donc, à titre d'exemple ici, je pourrais dans mon code d'application, disons la taille moyenne du panier, comme si je faisais une application de commerce électronique. Et si j'ai déployé quelque chose et que la taille du panier a considérablement baissé, de sorte que les gens ne pouvaient pas ajouter de produits à leur panier, alors je veux annuler ma dernière version. Donc Flagger sera parfait pour ça. Je pourrais définir cette taille de panier métrique, par exemple, et faire surveiller Flagger lorsque je déploie ma nouvelle version de l'application, afin que cette mesure ne tombe pas en dessous d'un seuil critique. Est-ce correct?

05:09 Prodan: Ouais. Nous pouvons imaginer de très nombreux cas d'utilisation pour faire vos propres KPI. D'une certaine manière, plusieurs équipes devraient collaborer lors de la définition de ces KPI. Par exemple, disons que l'équipe d'ingénierie aura ses propres KPI, comme, d'accord, le taux de réussite, la latence, peut-être combien de connexions sont ouvertes à la base de données, n'est-ce pas? Si la nouvelle version ouvre une connexion par demande, cela pourrait créer ce goulot d'étranglement au niveau de la base de données. Donc, disons, ceux-ci sont plus un côté technique des KPI, mais vous pouvez également avoir ce type de contrôles métriques provenant du côté commercial, comme vous l'avez dit, avec le panier ou le nombre de clics sur un bouton ou une bannière en particulier , des trucs comme ça, non? Nous pouvons donc également entrer dans le domaine des tests A / B, où vous voulez simplement tester les choses et les comparer.

05:57 Quel est le public principal de Flagger? S'agit-il de développeurs? S'agit-il d'opérateurs ou d'un mélange des deux?

05:57 Bryant: Cela mène parfaitement à ma prochaine question ici. Parce que j'allais dire, quel est le public principal de Flagger? S'agit-il de développeurs? S'agit-il d'opérateurs ou d'un mélange des deux peut-être?

06:06 Prodan: Ouais, je pense que c'est un mélange des deux. Et peut-être aussi que le marketing pourrait être impliqué dans ce processus ou pour les grandes entreprises électroniques qui ont des équipes d'assurance qualité dédiées. Tous ces éléments pourraient définir leurs propres contrôles de métriques, leurs propres KPI et définir un SLA pour l'application à partir de plusieurs perspectives, telles que des perspectives techniques, un impact sur l'utilisateur final, etc.

06:29 Prodan: Mais je pense principalement que Flagger est destiné à être utilisé au niveau des opérations car il interagit également avec les maillages de service et d'autres composants de votre cluster. Vous devez donc comprendre quel est votre fournisseur de routage sous-jacent? Quels proxys utilisez-vous? Vous prenez donc la bonne décision, comment vous installez Flagger pour quel type de fournisseur, puis vous pouvez collaborer avec d'autres équipes pour définir les KPI.

06:54 Est-ce que Flagger prend en charge à la fois les cas d'utilisation de version en périphérie et dans le graphique de service?

06:54 Bryant: Et cela mène parfaitement à la prochaine chose dans laquelle je voulais me plonger, c'est autour de ce genre de gestion du trafic Nord-Sud contre Est-Ouest. Nous disons donc que Nord-Sud est en quelque sorte votre Ingress, généralement là où vos proxys de périphérie ou vos passerelles API fonctionnent. Et puis l'Est-Ouest est à peu près le type de communications de service où vous avez déjà mentionné le service mesh fonctionne généralement. Flagger prend-il en charge les deux cas d'utilisation en périphérie et dans le graphique de service?

07:20 Prodan: Oui, c'est vrai. Et vous pouvez également les mélanger. Donc l'idée est que vous avez, disons, différents types d'applications. Premièrement, certaines applications sont directement exposées à l'extérieur du cluster via un proxy, via une passerelle API. C'est un proxy avec un proxy plus sophistiqué, disons bien, une API qui vous permet de définir beaucoup d'autres choses. Ainsi, pour les applications frontales exposées, Flagger peut parler directement à la passerelle API ou, disons, au contrôleur Ingress, qui est une implémentation spécifique pour Kubernetes. Et il y a quelques contrôleurs Ingress qui sont pris en charge dans Flagger. Je prévois d'élargir cette liste lorsque Kubernetes Ingress V2 deviendra une chose, deviendra populaire. Et c'est une histoire pour les applications qui peuvent exposer à l'extérieur.

08:09 Prodan: Pour les applications qui s'exécutent à l'intérieur du cluster, disons toutes sortes d'applications backend, d'API, etc., alors vous n'utiliserez pas de solution Ingress pour cela. Le trafic va directement du service A au service B.Et pour contrôler le trafic entre deux services qui s'exécutent à l'intérieur de Kubernetes, le CNI de Kubernetes ne suffit pas, quel que soit le type d'implémentation, car Kubernetes CNI I est généralement la couche trois, couche quatre. Pour acheminer le trafic, vous devez comprendre qu'il y en a plusieurs, disons que HTTP et GRPC sont les plus utilisés.

08:45 Prodan: Donc, pour que Flagger manipule le trafic, change le trafic de manière dynamique, il a besoin d'une solution de maillage de service qui permet à une automatisation externe de définir toutes ces règles de routage en fonction de leurs sept protocoles, comme les en-têtes HTTP, c'est un bon exemple. Un autre exemple est d'acheminer 1% de l'ensemble du déploiement spécifique au trafic et 99% vers un déploiement différent.

09:13 Quelles passerelles API et quels maillages de service sont actuellement pris en charge par Flagger?

09:13 Bryant: Quelles passerelles et quels maillages de service sont actuellement pris en charge par Flagger?

09:16 Prodan: Donc, en termes de passerelles, la première qui a été prise en charge était Solo Gloo. Ensuite, les gens ont demandé NGINX parce que NGINX est si populaire. Le contrôleur NGINX Ingress fait partie du projet Kubernetes lui-même et il a sa propre maintenance et ainsi de suite. L'utilisation de NGINX présente certains inconvénients en raison du fait que l'implémentation actuelle d'Ingress dans Kubernetes ne permet pas de modèle déclaratif du fonctionnement du routage. Nous devons donc utiliser des annotations. Donc, ce que fait Flagger, il manipule les annotations sur l'objet Ingress pour acheminer le trafic. Et la dernière édition est le projet Contour réalisé initialement par Heptio. Et maintenant je pense qu'il est en train d'être donné à la CNCF. Gloo et Contour sont basés sur Envoy, NGINX est bien sûr NGINX. Et une fois qu'Ingress V2 deviendra populaire, je pense que Flagger fonctionnera avec n'importe quel type de passerelle API qui implémente simplement Ingress V2, car dans la nouvelle spécification d'API Ingress, vous avez un objet spécial qui permet à Flagger d'acheminer le trafic en fonction du poids ou en fonction sur les en-têtes. Cela pourrait donc être complètement indépendant de l'implémentation réelle d'Ingress. Et c'est pour l'histoire d'Ingress.

10:34 Prodan: Pour le maillage de service, c'est encore plus compliqué parce que, eh bien, chaque maillage de service est livré avec ses propres API de portée, ensemble de portée d'APIS. Donc, quand j'ai commencé Flagger, Istio était une chose. Les gens ont commencé à utiliser Istio. Et l'API Istio vous permet de faire tellement de choses. Et Flagger a d'abord travaillé avec Istio et nous maintenons une compatibilité avec toutes les versions d'Istio actuellement utilisées. Je pense que cela fonctionne du 1.4 au dernier 1.6 et ainsi de suite. Et nous avons une infrastructure de test de bout en bout assez étendue pour nous assurer que chaque fois que nous changeons quelque chose dans Flagger, cela fonctionne très bien avec Istio, ainsi qu'avec Linkerd.

11:17 Prodan: Donc le prochain maillage de service que nous avons implémenté est Linkerd avec la note que l'implémentation de Linkerd passe par SMI. Donc SMI est le projet d'interface de maillage de service qui définit un ensemble d'API que nous espérons qu'un jour plus de mailles de service l'utiliseront. Je sais par exemple que Console Connect fait partie de SMI et j'espère qu'à un moment donné, ils implémenteront, par exemple, l'API d'objet de décalage de trafic, puis Flagger fonctionnera simplement avec Console Connect comme il fonctionne aujourd'hui avec Linkerd. Et enfin dans la zone de maillage de service, Flagger fonctionne très bien intégré à App Mesh d'Amazon.

11:56 Bryant: Oh bien. C'était également alimenté par Envoy. Est-ce correct?

11 h 58 Prodan: Oui. Oui. Istio et App Mesh sont donc alimentés par Envoy, et Linkerd est livré avec sa propre implémentation du proxy made in Rust.

12:07 Pourriez-vous expliquer ce que vous entendez par le terme livraison progressive et comment cela se rapporte à la livraison continue?

12:07 Bryant Donc, quelque chose sur lequel je voulais passer maintenant, Stefan, concerne la livraison progressive. Je sais donc que vous avez mentionné que la livraison progressive est au cœur de Flagger et de Flux sur lesquels vous travaillez. Pourriez-vous expliquer brièvement aux auditeurs ce que vous entendez par le terme de livraison progressive et en quoi cela se rapporte à la livraison continue?

12:23 Prodan: Oui. Donc, en livraison continue, combien d'entre nous le faisons aujourd'hui, par exemple, si nous utilisons, disons, une approche GitOps, n'est-ce pas? Nous avons nos définitions de charges de travail dans un référentiel Git, tout le déploiement Kubernetes, les services, les ensembles avec état, tout ce qui constitue votre cluster de production.

12:43 Prodan: Ensuite, disons, vous publiez une nouvelle version de votre application. Ce que cela signifie, disons, changez l'image du conteneur à l'intérieur du pack de déploiements et vous dites: "Hé, maintenant à partir de 1.0, c'est 2.0." Une fois que vous avez effectué ce changement, l'opérateur GitOps, quelque chose qui surveille votre référentiel effectuera ce changement dans votre cluster. Droite? Et ce qui se passe, c'est que l'ancienne version est entièrement remplacée par la nouvelle version un pod à la fois.

13h10 Prodan: Kubernetes propose désormais des contrôles de santé via des contrôles de vivacité et de préparation. Droite? Donc, si ces deux contrôles réussissent, alors votre nouvelle version est entièrement déployée dans votre cluster de production et tous les utilisateurs l'utiliseront.

13:25 Prodan: Maintenant, que se passe-t-il si après une ou deux minutes, votre nouvelle application commence à planter? La livraison progressive tente d'améliorer ce processus lorsque vous ne déployez pas complètement une nouvelle version, mais que vous la déployez à un pourcentage de vos utilisateurs. Vous avez donc besoin d'un moyen de segmenter vos utilisateurs. C'est la première exigence, comment vous pouvez le segmenter. Pour, disons, les applications frontales, vous pouvez utiliser des éléments comme un cookie ou un en-tête spécifique et vous pouvez dire: "Seuls les utilisateurs qui sont sur Safari vont tester ma nouvelle version," à droite ", ou tous les utilisateurs qui viennent de une région particulière. " Il y a des choses comme CloudFlare, par exemple, qui injectent à l'intérieur de la requête le pays ou la région de l'utilisateur. Vous pouvez donc utiliser ces données pour effectuer la segmentation des utilisateurs.

14:17 Prodan: Et pendant que la nouvelle version est en cours de test, vous avez besoin d'une sorte de composant d'observabilité dans votre processus de livraison qui peut regarder ce qui se passe avec la nouvelle version lorsqu'un segment de vos utilisateurs y est acheminé et basé sur cela , prenez des décisions, faites-le avancer ou reculer. Alors oui, la livraison progressive essaie d'étendre la livraison continue et d'ajouter plus de filets de sécurité.

14:44 Bryant: J'aime ça, parce que j'ai discuté avec Steve Smith à Londres, beaucoup à propos de ce concept de livraison continue consiste à aller aussi vite que l'entreprise le souhaite, mais aussi en toute sécurité que l'entreprise le souhaite. Et ce que je vous entends dire ici, c'est que la livraison progressive vous donne vraiment à la fois en termes de concentration, peut-être que la sécurité en termes de vous pourrait empêcher quelque chose de mal d'être complètement déployé, mais cela nous permet quand même d'aller vite en termes de nous libérons constamment de nouveaux services et transférons progressivement le trafic entre eux.

15:12 Prodan: Oui. Et ce sont des conditions de race ici, après tout, non? Vous ne pouvez pas publier si vite que vos tests, vos tests de production sur du trafic réel, ce n'est pas assez rapide, non? Alors maintenant, nous nous rattrapons. Donc, ce que fait Flagger, c'est quand, disons, vous avez une version qui est en cours de test et que vous publiez une nouvelle version, puis Flagger voit que, d'accord, c'est une nouvelle version. Annulons cette analyse et recommençons avec la nouvelle version. Donc, cela ne passe pas avec la révision actuelle, car une nouvelle est là. Ainsi, vous avez une chance de rattraper, disons, la vitesse de déploiement.

15:49 Comment Flagger prend-il en charge les webhooks pour que vous puissiez exécuter des tests dans le cadre d'un déploiement?

15:49 Bryant: Ouais. Très intéressant. Et j'ai donc lu sur le site Flagger que vous aviez une sorte de web hooks et ainsi de suite où vous pouvez exécuter des tests dans le cadre d'un déploiement. Est-ce exact?

15:57 Prodan: Oui. Un grand nombre d'utilisateurs qui comptent sur Helm pour effectuer des déploiements. Helm a une chose appelée tests Helm, où vous avez essentiellement des pods que vous ajoutez à votre graphique Helm et à l'intérieur de ces pods, vous exécuterez des tests d'intégration, des tests de fumée, etc. Lorsque vous utilisez Flagger, lorsque vous définissez l'analyse Canary, vous pouvez dire à Flagger: "Hé, avant de commencer à acheminer tout type de trafic vers la nouvelle version, exécutez les tests Helm."

16:27 Prodan: Si ceux-ci échouent, cela n'a aucun sens d'exposer votre application aux utilisateurs finaux car elle échoue, bien sûr. Alors faites-le reculer. C'est un cas d'utilisation sur la façon dont nous pouvons déclencher des tests d'intégration au sein de votre cluster. Mais Flagger a une implémentation Web générique, de sorte que vous pouvez réellement implémenter votre propre récepteur de hook Web qui communique avec votre exécuteur de test personnalisé et ainsi de suite. Et je sais que les gens ont fait quelques intégrations. Comme ils appellent des services externes comme CircleCI, comme Jenkins et d'autres, lancez tous ces tests et Flagger attendra la fin de la réponse du crochet Web.

17:03 Prodan: Et une fois que c'est fait, disons, dans 10 minutes, alors vous dites à Flagger: "Hé, maintenant vous êtes autorisé à avancer et à commencer à acheminer le trafic parce que mes tests sont terminés." Ce n'est donc en aucun cas lié à une technologie particulière, comme Helm. Cela fonctionne avec Helm, mais aussi bien qu'avec d'autres.

17:20 Bryant: Vous pouvez imaginer que quelqu'un comme presque sombre lancerait un service. Ils pourraient aimer faire le crochet Web de CircleCI pour en exécuter comme la surveillance sémantique ou une sorte de test de comportement des utilisateurs avec ce service qui n'est pas exposé au public. Si ces tests réussissent, alors lancent-ils le déploiement progressif?

17:36 Prodan: Ouais. Il y a aussi des crochets pendant le déploiement. L'une des premières choses que j'ai aidé à implémenter dans Flagger a été le test de charge. Pourquoi? Le problème est que vous souhaitez déployer à tout moment, mais peut-être que maintenant, lorsque vous effectuez le déploiement, personne n'utilise votre application. Donc, Flagger ne peut prendre aucune décision car il n'y a pas d'aide pour les métriques. Personne ne fait un nouveau test, alors comment Flagger peut-il décider si c'est bon ou pas?

18:06 Prodan: Donc, un autre type de crochet Web est celui que Flagger exécute pendant l'analyse et peut faire appel à un outil de test de charge qui générera du trafic pour des points finaux particuliers que vous souhaitez tester, etc. Il a donc des informations et peut prendre cette décision. Bien sûr, ce n'est pas la même chose que d'analyser le trafic réel, mais au moins c'est quelque chose. Cela vous donne donc la possibilité d'exécuter des tests de charge. Et il a un petit service en tant qu'addition sur Flagger que vous pouvez déployer, qui utilise un outil appelé "hey". C'est comme un outil génial qui vous permet de bombarder votre application et de décider, y a-t-il un problème de latence ou mes routes sont-elles erronées après un certain nombre de requêtes par seconde? C'est donc un autre cas d'utilisation des hooks Flagger.

18:53 Quel a été le succès de Flagger? Connaissez-vous des gens qui l'utilisent en production?

18:53 Bryant: Très gentil, Stefan. Avant de passer à certains des plus gros éléments de contexte, je veux également me plonger dans Flux. Quel a été le succès de Flagger? Connaissez-vous des gens qui l'utilisent en production? Existe-t-il une sorte de cas d'utilisation que les gens peuvent lire en ligne?

19:04 Prodan: J'ai commencé une liste d'entreprises qui sont prêtes à dire: "Hé, nous utilisons Flagger en production." Disons que Chick-fil-A est l'un des plus gros utilisateurs de Flagger. Il y en a d'autres répertoriés sur le site Web. Je sais qu'il y a beaucoup plus d'utilisateurs que lorsque vous travaillez pour une banque ou une grande entreprise, il est difficile d'obtenir ce genre de reconnaissance, mais je travaille avec la communauté pour agrandir cette liste. Je pense que l'équipe de Flagger a beaucoup de retours d'utilisateurs.

19:34 Prodan: Ce que j'aime vraiment dans les commentaires que nous obtenons, c'est le fait que les gens ont en fait toutes ces sortes de modèles de déploiement personnalisés, disons qu'ils ont mis en œuvre pour répondre à certains besoins de l'entreprise en matière de déploiement. Et avec tous ces retours d'expérience, nous pouvons rendre Flagger plus dynamique, permettre le déploiement de tous ces cas d'utilisation. Et le dernier était le fait que … Laissez-moi vous expliquer un peu comment fonctionne un déploiement Canary.

20:02 Prodan: Vous avez une fortune en production. Supposons que vous ayez 10 pods avec un autoscaler et que vous déployez une nouvelle version. Cela commence avec ce pod. Ensuite, vous commencez à transférer le trafic vers cette nouvelle version. Il existe donc un autoscaler différent qui examinera également le trafic, les ressources nécessaires pour faire évoluer le déploiement Canary, n'est-ce pas? Vous avez donc deux autoscalers et Flagger au milieu. Et cela fonctionne très bien. Le problème est avant Flagger 1.0, quand l'analyse s'est terminée, et disons que tout a bien fonctionné, je vais déployer complètement cette nouvelle version. Ensuite, le déploiement s'est produit immédiatement. Comme, tout le trafic est allé à la nouvelle version à la fois.

20:46 Prodan: Et certains utilisateurs ont dit: "Hé, nous utilisons des centaines de pods. Vous ne pouvez pas évoluer aussi vite si vous effectuez le changement final, 100% de trafic." Nous avons donc implémenté un nouvel avenir, disponible dans Flagger 1.0. et lorsque Flagger fait la promotion, il utilise également un déploiement progressif.

21:06 Bryant: Un étranglement.

21:07 Prodan: Ouais. Il déplace le trafic progressivement. De la même manière, il effectue les tests Canary, de la même manière qu'il fait maintenant la promotion. Donc, si, disons, vous déplacez 10% du trafic toutes les deux minutes, alors nous avons besoin que la promotion se déroule de la même manière, ou vous pouvez changer le poids. Mais je veux dire, il se comporte mieux à forte charge avec des tonnes de trafic.

21:31 Bryant: C'est la chose clé.

21:32 Prodan: Et c'est quelque chose qui est venu des utilisateurs de production qu'ils voyaient, "Hé, nous avons un pic de latence où Flagger fait la dernière étape." Et nous avons identifié où est le problème, avons trouvé une solution. Et sur la demande de pod, vous pouvez également voir les graphiques des utilisateurs où ils présentent, "Hé, maintenant ça marche comme il se doit."

21:50 Prodan: Il n'y a rien de tel que lorsque votre logiciel est utilisé à grande échelle en production. Vous voyez toujours les cas extrêmes, les trucs que vous n'auriez tout simplement pas pu imaginer pendant que vous le codez, non? Quand le caoutchouc rencontre la route, vous vous dites soudainement "Whoa", comme … Et c'est le signe d'un projet adopté avec succès, je pense.

22:06 Prodan: Oui. C'est l'un des signes. Un autre signe est que si vous n'obtenez aucun rapport de bogue, quelque chose ne va pas.

22:13 Comment Flagger s'intègre-t-il dans une vue d'ensemble? Comment ça marche avec des outils comme Flux?

22:13 Prodan: D'accord. Totalement. Totalement. Donc ça ne me dérangerait pas de prendre un peu de recul maintenant, Stefan, avec notre temps restant. Comment Flagger s'intègre-t-il dans une vue d'ensemble? Parce que, évidemment, nous travaillons à faire beaucoup de bonnes choses, par exemple Flux, livraison continue, etc. J'ai hâte de connaître votre point de vue sur la place de Flagger avec ces autres outils que nous examinons.

22:30 Prodan: Donc, si nous considérons l'ensemble du processus comme un simple pipeline, Flagger se trouve juste à la fin, car c'est fondamentalement la porte finale jusqu'à ce que votre application atteigne vos utilisateurs finaux. Au début du pipeline, et je parle ici de ce qui se passe à l'intérieur du cluster Kubernetes, bien sûr, vous avez CI, vous devez exécuter des tests unitaires, des tests d'intégration, vous devez créer votre application. Mais l'entreprise pour laquelle je travaille s'occupe de la partie de la livraison continue, qui est quelque chose que vous pouvez entièrement orchestrer à l'intérieur de votre cluster Kubernetes sans, disons, aucun processus externe.

23:06 Prodan: Et Flux est le composant qui apporte des changements externes à l'intérieur du cluster. Comment vous définissez ces changements externes, nous avons pensé à Git comme le principal moyen de stocker l'état souhaité de vos clusters, car vous pouvez le versionner. Vous pouvez y accéder par la rue. Vous pouvez utiliser les demandes de pod lorsque vous effectuez des modifications, n'est-ce pas? Ainsi, plusieurs équipes peuvent collaborer sur le fonctionnement de votre système de production et sur le type d'opérations que vous essayez de faire, si vous souhaitez mettre à niveau quelque chose, rétrograder quelque chose, déployer une nouvelle version, etc.

23:42 Prodan: Donc le voyage commence avec quelqu'un qui fait une demande de pod qui est fusionnée dans une branche que Flux regarde, puis Flux appliquera ces changements sur le cluster, et c'est ce qui se passe. Et à partir de là, Flagger détecte ce changement. Ainsi, Flagger surveille les changements, si vous le souhaitez, les événements Kubernetes, etc. Et quand il détecte un changement, il exécute une analyse pour ce changement particulier.

24:08 Prodan: Et comment Flagger fonctionne dans cette configuration, il ne se contente pas de regarder: "Hé, quelqu'un a changé l'application elle-même qui contenait le problème." Nous avons vu, disons ces dernières années, que les plus gros incidents pour les fournisseurs de cloud, par exemple, n'étaient pas un bogue dans le code. C'était un problème de configuration. Donc, Flagger ne regarde pas seulement: "Hé, le code a-t-il changé. Le conteneur a-t-il changé?" Il examine également toutes les choses qui créent votre application dans Kubernetes, et quelles sont ces choses. Peut-être quelques ConfigMaps. Pourrait être des secrets où vous avez toutes sortes d'autres types de configuration, mais c'est, à la fin, c'est une configuration, non?

24:48 Prodan: Donc Flagger réagit à tout type de changement, et pour ce changement exécute une analyse Canary. Et un exemple est que je vais changer les limites de mon conteneur. Je dirai: "Mon conteneur devrait fonctionner correctement avec 500 mégaoctets de RAM." Peut-être que ce n'est pas le cas, non? Ainsi, au lieu de simplement déployer cette nouvelle limite en production, Flagger voit la limite, fait tourner un pod avec cette configuration particulière, puis la nouvelle configuration commence à acheminer le trafic vers elle, et peut-être après une minute ou deux, votre application s'exécutera. de mémoire. Flagger le détecte et le renvoie automatiquement.

25:24 Prodan: L'idée est donc avec GitOps, vous définissez fondamentalement tout ce qui compose votre application dans un référentiel. Vous avez des opérateurs, un outil qui surveille les changements dans Git, les applique sur le cluster, puis Flagger vient et s'assure que ces changements conviennent à vos utilisateurs finaux.

25:44 Flux est-il un projet CNCF?

25:44 Bryant: Très gentil. C'est un argument convaincant, Stefan. Très beau effectivement. Maintenant je comprends que Flux est un projet CNCF maintenant?

25:50 Prodan: Oui. Flux est à la CNCF depuis l'année dernière et nous avons vu beaucoup d'utilisateurs essayer Flux, l'utiliser en production. L'utilisateur de la production Flux est énorme. Flux existe depuis longtemps maintenant. Et les mainteneurs de Flux, l'équipe Flux travaille actuellement sur une nouvelle proposition sur l'apparence du futur Flux. Ce que nous faisons, c'est rendre Flux plus modulaire. Donc Flux s'occupe maintenant des opérations Git, comme les moniteurs, les clones de référentiel Git, que le référentiel Git vérifie les clés PGP. Il fait SSH et ainsi de suite. C'est une chose. Il fait également la réconciliation. Il applique tous ces YAML, effectue un garbage collection sur les objets Kubernetes et ainsi de suite.

26:36 Prodan: Nous envisageons donc un Flux dans lequel vous pouvez choisir quel type de comportement et comment vous voulez que votre cluster soit réconcilié. Et la première étape que nous avons faite, nous avons créé une chose appelée le GitOps Toolkit, qui est développé au sein de l'organisation Flux CD.

26:51 Prodan: Et le premier composant du GitOps Toolkit s'appelle le contrôleur de source, qui est un agent Kubernetes spécialisé, l'opérateur Kubernetes qui gère les sources. Une source peut être un référentiel Git. Une autre source peut être un référentiel Helm dans lequel vous stockez tous vos graphiques Helm, etc.

27:11 Prodan: Une autre source pourrait être, je ne sais pas, il y a trois seaux, ou quelque chose comme ça. Et nous permettons maintenant à d'autres de déployer et de développer des conciliateurs spécialisés. Par exemple, nous développons un contrôleur personnalisé, qui sait comment gérer les superpositions personnalisées. Un autre contrôleur sera un contrôleur Helm qui est spécialisé uniquement dans l'application des versions Helm et ainsi de suite. Mais vous pouvez imaginer que d'autres entreprises, d'autres personnes contribueront à cette boîte à outils avec leurs propres éléments spécialisés, que peut-être qu'elles s'étendent sur des clusters ou même en dehors de Kubernetes, vous souhaitez créer d'autres choses autour de Kubernetes en termes d'infrastructure, d'infrastructure cloud, etc. sur.

27:54 Prodan: C'est donc quelque chose que nous sommes très, très désireux d'impliquer la communauté parce que c'est juste au début. Tout est piloté via un objet API Kubernetes. Disons que vous pouvez définir plusieurs sources. Vous pouvez dire que mon cluster, mon état de cluster est composé des trois référentiels Git, un référentiel Git qui contient toutes mes applications et un autre référentiel Git qui a, disons, tout le modèle de sécurité, les comptes de service, l'accès basé sur les rôles, les politiques OPA et tout ça. Et peut-être un autre référentiel qui n'est même pas sous votre contrôle. Vous voulez, disons, installer Istio à partir du référentiel d'historique, installer la liste officielle des choses. Nous pouvons donc ajouter les référentiels Istio, les placer dans votre cluster et dire au réconciliateur chaque fois qu'Istio fait encore une version semver, si c'est dans cette plage semver, je veux mettre à niveau automatiquement mon cluster vers cette version Istio.

28:50 Prodan: Prenons l'ambassadeur par exemple, non? Il y a un CVE et un Envoy. Vous ferez une version de patch. Avec la boîte à outils GitOps, vous pouvez dire: "Surveillez le référentiel Ambassador. Et chaque fois qu'il y a une version de correctif, appliquez-la automatiquement sur le cluster." Mais s'il s'agit d'une, disons, une version majeure ou une version mineure, ouvrez une requête de pod et des trucs comme ça, car quelqu'un doit le récupérer et l'améliorer, ou le déployer uniquement sur le cluster intermédiaire et cherchons le nouveau mineur version d'un investisseur là-bas, testez-la et à un moment donné, quelqu'un décidera: "D'accord, nous voulons promouvoir cette version en production."

29:27 Prodan: L'idée est qu'au lieu de copier-coller tous ces YAML, tous ces graphiques et tout, vous pouvez vous adresser directement à la source de celui-ci, comme le référentiel officiel. C'est un exemple que nous essayons de cibler.

29:40 Bryant: Je pense que c'est un cas d'utilisation vraiment convaincant, Stefan. Parce qu'il y a quelque chose de mes jours Java, nous avions souvent des plugins Maven ou Gradle qui analysaient constamment les dépendances: utilisez-vous la dernière version d'une dépendance? Y a-t-il des CVE connus dans cette dépendance? Et comme vous le dites, avec le semver, vous obtenez au moins le correctif majeur et mineur afin que vous puissiez en quelque sorte prendre des décisions sur le changement de fonctionnalité? Une API est-elle en train de changer?. Je pense que faire ce genre de chose pour l'infrastructure est parfois assez difficile, n'est-ce pas, en termes de comment savoir quand une vulnérabilité de sécurité Envoy se produit? Eh bien, nous y prêtons attention, mais est-ce que les utilisateurs finaux? Peut être pas.

30:11 Prodan: Peut-être pas. Ouais. En tant qu'utilisateur final, disons qu'un utilisateur final est quelqu'un d'une équipe de plateforme qui doit fournir Kubernetes en tant que service à sa propre organisation, disons, non? Combien de choses cette personne doit-elle regarder? Sa liste de diffusion est énorme, non? Donc, au lieu de faire cela, il peut, ou elle peut décider de faire confiance à des référentiels particuliers, à une organisation particulière et dire: "Hé, ils font une version de correctif, je veux que cela soit automatiquement déployé sur mon cluster de préparation."

30:40 Prodan: Une fois qu'il est là, vous l'utilisez réellement. S'il a des problèmes, vous devriez être en mesure de le détecter lors de vos déploiements normaux et ainsi de suite. Nous essayons de le faire avec GitOps pour donner aux gens plus de liberté sur ce qu'ils veulent ajouter au cluster, mais en même temps, en sécurisant l'ensemble du pipeline avec des choses comme le gatekeeper, avec des politiques réseau et toutes ces choses qui plus vous donnez de pouvoir à l'opérateur, à la fin, cela pourrait signifier qu'il est plus facile d'avoir une faille de sécurité et ainsi de suite. Nous essayons donc de travailler de ce côté également.

31:16 Bryant: Faites en sorte qu'il soit facile de faire la bonne chose.

31:18 Prodan: Ouais. Et c'est un peu difficile.

31:20 Pouvez-vous expliquer la nouvelle boîte à outils Weaveworks GitOps?

31:20 Bryant: Ouais, ça l'est. Ce que j'entends de vous, c'est que beaucoup d'entre nous construisent des plates-formes ces jours-ci. Vous avez mentionné que les entreprises ont souvent des équipes de plate-forme qui construisent un PaaS basé sur Kubernetes pour leur consommation interne ou pour la consommation de leur équipe interne. Ce que j'ai entendu de vous, c'est que vous pouvez considérer la nouvelle boîte à outils GitOps presque comme une plate-forme pour une livraison continue et progressive, mais avec des interfaces et des abstractions claires permettant aux gens de définir leurs propres choses. Serait-ce une description juste?

31:45 Prodan: Ouais. Je dis que le GitOps Toolkit, vous pouvez utiliser le GitOps Toolkit pour créer votre propre plate-forme de livraison continue. Et c'est à vous de décider de ce que vous choisissez, des types d'opérateurs que vous y mixez. Normalement dans Kubernetes, la plupart des choses devraient fonctionner correctement, car si vous avez des opérateurs avec leurs propres API, cela limite la responsabilité d'un opérateur. Mais les choses ne sont pas si faciles. Le meilleur exemple est l'autoscaler de pod horizontal, non? Un autoscaler de pod horizontal agit sur un objet comme un déploiement, non? Flagger agit également sur le déploiement car il doit le faire évoluer, etc.

32:26 Prodan: Flux ou tout ce que vous utilisez, RBC ou tout ce que vous utilisez pour obtenir ce déploiement dans votre cluster agit également sur lui, non? Ainsi, vous pouvez voir, par exemple, prenons le champ d'une réplique à l'intérieur du déploiement, il y a au moins trois opérateurs automatisés qui se battront pour cela. Il y a Flux qui essaie d'appliquer ce que vous avez décrit dans Git, c'est l'autoscaler de pod horizontal qui change ce compte de réplique en fonction de l'utilisation des ressources, et c'est Flagger qui changera ce compte de réplique en fonction de son Canary ou non. Dois-je le mettre à zéro ou dois-je le démarrer? Ces opérateurs doivent donc travailler ensemble d'une manière ou d'une autre, pour ne pas se battre.

33:07 Sur quels autres trucs passionnants travaillez-vous? Selon vous, qu'est-ce qui est passionnant dans l'espace natif du cloud?

33:07 Bryant: C'est comme la vraie vie, où les opérateurs se battent les uns les autres dans la vraie vie. Ouais. C'est comme l'emmener dans le monde virtuel. Ouais. Je n'avais pas pensé à ça. C'est en fait un point vraiment très intéressant. Oui. Les gens regardent cet espace. Je suis donc conscient du temps maintenant, Stefan. Cela a été super intéressant. Je pense que toi et moi pourrions discuter à peu près toute la journée sur ce sujet. En guise de dernière petite, quelques questions, qu'est-ce que vous attendez le plus avec impatience au cours des six, 12 prochains mois? Sur quels trucs passionnants travaillez-vous, peut-être vous et l'équipe, ou qu'est-ce qui vous semble passionnant dans l'espace natif du cloud?

33:33 Prodan: Je mentionnerai d'abord Flagger. Avec Flagger, nous avons une nouvelle façon de définir les contrôles métriques. Donc, jusqu'à Flagger 1.0, un utilisateur ne pouvait définir que des requêtes Prometheus. Vous devez donc avoir un serveur Prometheus quelque part et tous vos KPI doivent être exposés dans les métriques Prometheus. Et de nombreux utilisateurs sont venus nous voir et nous ont dit: "Hé, nous utilisons d'autres choses que Prometheus. Nous utilisons Prometheus parce que, eh bien, il est livré avec Istio, il est livré avec Linkerd, il est livré avec quelque chose que nous utilisons. Flagger vient également avec son propre Prometheus, si vous n'en avez pas. Mais généralement, les statistiques commerciales se trouvent peut-être ailleurs.

34:11 Prodan: Nous avons donc maintenant un modèle appelé modèles de métriques, dans lequel vous pouvez connecter d'autres fournisseurs de métriques et nous avons implémenté Datadog et CloudWatch comme les deux premiers. Et le mois prochain, je cherche à étendre les intégrations à d'autres plates-formes.

34:30 Prodan: Il y a tellement de choses comme s'il y avait un problème l'autre jour pour ajouter une nouvelle relique. Ouais. Il y a tellement de plates-formes là-bas. InFluxDB est une autre requête. Je cherche donc des personnes qui utilisent réellement ces fournisseurs et qui sont prêtes à m'aider à l'implémenter ou à l'implémenter elles-mêmes, et je vais examiner la demande par demande. Et je pense que c'est un territoire où Flagger pourrait s'étendre.

34:53 Prodan: Une autre grande chose que je veux entrer dans Flagger est Ingress V2. L'une des premières implémentations que nous ayons eues avec Ambassador, nous avons implémenté Ingress V2. Je serai la première fois à sauter dessus. Et un autre espace dans lequel je souhaite vraiment intégrer Flagger est celui des déploiements multi-cluster. Linkerd vient d'annoncer la mise en place du multi-cluster. Istio a quelques options. Et Flagger fonctionne avec le multi-cluster Istio uniquement lorsque Istio est déployé dans un mode de plan de contrôle partagé. Mais d'accord, vous avez un plan de contrôle partagé et Flagger peut en parler. Mais lorsque vous avez comme un plan de contrôle dédié par cluster, que Flagger a besoin de changements sérieux et d'effet pour pouvoir

35:34 Bryant: Fédérer.

35:35 Prodan: Ouais. Pour parler à une flotte, pas à un seul cluster, d'accord? C'est donc un grand domaine pour Flagger à l'avenir. De plus, beaucoup de gens m'ont dit que l'API de cluster permet, je ne sais pas, de créer des clusters si facilement. Il peut créer un nouveau cluster chaque fois que vous déployez une nouvelle version de votre application. Eh bien, ce n'est pas si facile, mais à un moment donné, nous y arriverons, non? Donc un Flagger pour les clusters

36:01 Bryant: Oh, c'est intéressant. Droite.

36:03 Prodan: … pourrait aussi être quelque chose d'intéressant pour le futur où vous, au lieu de simplement regarder une application, vous examinerez les métriques qui proviennent d'un cluster entier et déciderez si le nouveau cluster doit être promu ou pas.

36:14 Bryant: Très intéressant.

36:15 Prodan: Le principe est le même, non? Les tests Canary ou A / B sont identiques. La machinerie est tellement différente parce que maintenant Flagger ne parle qu'à la seule API Kubernetes et surveille ses déploiements, ConfigMaps, secrets. Maintenant, il doit surveiller les définitions de cluster, les machines, etc.

36:33 Bryant: Nous disons comme des tortues tout en bas, Stefan. Ouais? Mais ce sont des conteneurs, puis des clusters, et puis comme … Oui, il y a beaucoup de choses là-dedans.

36:39 Prodan: Ouais. Ouais. C'est pour Flagger. Ouais. En ce qui concerne les autres projets de la CNCF, je regarde beaucoup l'espace Ingress. Je veux vraiment voir une implantation d'Envoy dans CNCF et j'espère que Contour y arrivera et sera mélangé avec Ingress V2, je pense que nous aurons un bel avenir pour Ingress et Egress sur Kubernetes. Parce que pour le moment, nous avons ce concept Ingress, mais l'implémentation réelle est en quelque sorte bloquée dans le passé avec NGINX, Ingress étant la chose par défaut. Je pense que l'une des implémentations de l'Envoy devrait également être là. J'espère que cela se produira réellement cette année à un moment donné.

37:17 Prodan: J'espère la même chose. Très cool. Ça y est. Ouais. Une discussion fantastique. Si les gens veulent vous suivre en ligne, quel est le meilleur moyen, Twitter, LinkedIn?

37:25 Prodan: Twitter. Twitter est le seul média social que j'utilise. @stefanprodan, c'est moi.

37:30 Prodan: Parfait. Je ne manquerai pas de lier votre pseudo Twitter dans les notes de l'émission lorsque nous le ferons, ainsi que les gens peuvent très facilement vous suivre. Mais oui, ça a été super de te parler aujourd'hui, Stefan. Merci beaucoup.

37:37 Prodan: Merci beaucoup, Daniel, de m'avoir invité.



Source link

Un situation commerce électronique donne l’occasion de se lancer à moindres frais en rapport aux entreprises classiques. De plus, vous pouvez vous lancer bien plus rapidement. La contrôle d’un site commerce électronique ne demande pas de présence physique à un endroit précis, sauf peut-être quant au stockage et la préparation des commandes que vous avez la possibilité tout à fait externaliser, mais aussi mieux dans l’hypothèse ou vous ne possédez pas de provision (on en parlera plus tard dans l’article).