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: Once it's there, you are actually using it. If it has problems, you should be able to detect it while doing your normal deployments and so on. We're trying to do it with the GitOps to give people more freedom of what things they want to add the cluster, but on the same time, securing the whole pipeline as well with things like gatekeeper, with network policies and all these things that the more power you give to the operator, in the end, it could mean it's easier to have a security breach and so on. So we are trying to work on that side as well.

31:16 Bryant: Make it easy to do the right thing.

31:18 Prodan: Yeah. And it's kind of hard.

31:20 Could you explain the new Weaveworks GitOps toolkit?

31:20 Bryant: Yeah, it is. What I'm hearing from you is, because a lot of us are building platforms these days. You mentioned like companies often have platform teams that kind of build a PaaS based on Kubernetes for their internal consumption or for their internal team's consumption. What I heard from you is you can look at the new GitOps Toolkit almost as a platform for continuous and progressive delivery, but with clear interfaces and abstractions that people can define their own stuff. Would that be a fair description?

31:45 Prodan: Yeah. I'm saying that the GitOps Toolkit, you could use the GitOps Toolkit to build your own continuous delivery platform. And it's up to you what you choose, what types of operators you mix there. Normally in Kubernetes, most things should work smoothly because if you have operators with their own APIs, so that limits the responsibility of an operator. But things are not that easy. The best example is Horizontal Pod Autoscaler, right? An Horizontal Pod Autoscaler acts on a object like a deployment, right? Flagger also acts on the deployment because it needs to scale it up and so on.

32:26 Prodan: Flux or whatever you are using, RBC or whatever you are using to get that deployment inside your cluster also acts on it, right? So you can see, for example, let's take a replica's field inside the deployment, there are at least three automated operators that will fight over it. There's Flux that is trying to apply what you have described in Git, it's the Horizontal Pod Autoscaler that is changing that replica account based on resource usage, and it's Flagger that will change that replica account based on it's Canary or not. Should I scale it to zero or should I start it? So these operators have to work together in some way, so they will not fight each other.

33:07 What other exciting stuff are you working on? What do you think is exciting in the cloud native space?

33:07 Bryant: It's like real life, where we get operators fighting each other in real life. Ouais. This is just like taking it to the virtual world. Ouais. I hadn't thought about that. That is actually a really, really interesting point. Oui. People watch this space. So I'm conscious of time now, Stefan. This has been super interesting. I think you and I could pretty much chat all day on this stuff. As a kind of final little, couple of questions, what are you most looking forward to over the next six, 12 months? What exciting stuff are you working on, perhaps you and the team, or what do you think is exciting in the cloud native space?

33:33 Prodan: I'll mention Flagger first. With Flagger, we have a new way of defining metric checks. So until Flagger 1.0, a user could only define Prometheus queries. So you have to have a Prometheus server somewhere and all your KPIs must be exposed in Prometheus metrics. And a lot of users came to us and say, "Hey, we are using other things than Prometheus. We use Prometheus because, well, it comes with Istio, it comes with Linkerd, it comes with something that we use. Also Flagger comes with its own Prometheus, if you don't have one. But usually business metrics are in other places, maybe. Right?

34:11 Prodan: So we now have a model that it's called metrics templates, where you can hook up other metrics providers and we've implemented Datadog and CloudWatch as the first two. And in the next month, I'm looking at expanding the integrations to other platforms.

34:30 Prodan: There are so many things like there was an issue the other day to add new Relic. Ouais. There are so many platforms out there. InFluxDB is another request. So I'm looking at people that actually use these providers and are willing to help me implement it or implement it themselves, and I'll be reviewing the per request. And I think this is a territory where Flagger could expand.

34:53 Prodan: Another big thing that I want to get into Flagger is Ingress V2. One of the first implementation we had on with Ambassador, we've implement Ingress V2. I'll be the first time to jump on it. And another space that I really want to get Flagger into is multi-clustered deployments. Linkerd just announced the multi-cluster set up. Istio has a couple of options. And Flagger works with Istio multi-cluster only when Istio is deployed in a shared control plane mode. But okay, you have a shared control plane and Flagger can talk to that. But when you have like a dedicated control planes per cluster, than Flagger needs some serious changes and effecting to be able to

35:34 Bryant: Federating.

35:35 Prodan: Yeah. In order talk to a fleet, not to a single cluster, all right? So that's a big area for Flagger in the future. Also a lot of people have told me that cluster API is making, I don't know, creating clusters so easy. It can spin up a new cluster every time you deploy a new version of your app. Well, it's not that easy, but at some point, we'll get there, right? So a Flagger for clusters

36:01 Bryant: Oh, that's interesting. Droite.

36:03 Prodan: … could also be something interesting for the future where you, instead of just looking at an app, you'll be looking at metrics that are coming from a whole cluster and decide if the new cluster should be promoted or not.

36:14 Bryant: Very interesting.

36:15 Prodan: The principle is the same, right? Canary or A/B testing is the same. The machinery is so much different because now Flagger only talks to the single Kubernetes API and watch its deployments, ConfigMaps, secrets. Now, it has to watch cluster definitions, machines and so on.

36:33 Bryant: We say like turtles all the way down, Stefan. Yeah? But it's containers, then it's clusters, and then like… Yes, there's a lot of stuff in there.

36:39 Prodan: Yeah. Ouais. That's for Flagger. Ouais. In terms of other CNCF projects, I'm watching the Ingress space a lot. I really want to see an Envoy implantation in CNCF and hopefully Contour will get there and mixed together with Ingress V2, I think we will have a bright future for Ingress and Egress on Kubernetes. Because right now, we have this Ingress concept, but the actual implementation is somehow stuck in the past with NGINX, Ingress being the default thing. I think one of the Envoy's implementation should also be there. I hope it will actually happen this year at some point.

37:17 Prodan: I hope the same. Very cool. This is it. Ouais. A fantastic chat. If folks want to follow you online, what's the best way, Twitter, LinkedIn?

37:25 Prodan: Twitter. Twitter is the only social media I use. @stefanprodan, that's me.

37:30 Prodan: Perfect. I'll be sure to link your Twitter handle in the show notes when we do it, as well as the folks can very easily follow you. But yeah, it's been great talking to you today, Stefan. Thanks very much.

37:37 Prodan: Thank you very much, Daniel, for having me.



Source link

Pourquoi créer une boutique en ligne ?

On voit clairement qu’il est possible de se lancer dépourvu argent et inconscient technique particulière. Je vous conseille de vous jeter en dropshipping et de malgré tout ne pas mettre trop d’argent sur votre site. Il vous faut notamment avoir un budget marketing pour réaliser venir les internautes sur votre boutique : c’est le nerf de la guerre. Car tel que je l’ai dit, vous pouvez avoir la plus belle boutique. Sans trafic, vous ne ferez jamais de chiffre d’affaires. Une que vous aurez testé, votre marché vous pourrez alors séduire un stock.