 Ok, merci tout le monde d'être ici, je sais qu'il y a beaucoup d'héritiers qui sont en train de parler dans une autre maison, donc merci d'être ici pour moi. Je vais parler de l'opérateur custom sur l'API Gateway. Donc, première, un petit peu sur moi. Mon nom est Vincent. Je travaille sur Ubisoft. Vous pouvez me trouver sur les médias sociaux. Twitter, Slack, Github, etc. Avant de commencer, je ne sais pas si vous connaissez le Bingo Game, mais si vous avez des bords pendant cette session, vous pouvez jouer et me dire à la fin si vous avez des points pendant cette session. Mais, j'espère que c'est une bonne session, vous n'aurez pas de bords. Parce que je vais parler de pourquoi nous avons créé notre propre opérateur custom pour l'API Gateway, pourquoi quelqu'un veut faire ça. Je vais commencer avec un petit peu de contexte, sur Ubisoft, nous avons créé des jeux de vidéo. Nous avons beaucoup de choses pour nous, des jeux de vidéo, des services online, des websites e-commerce, etc. Nous avons donc déployé un professeur public-cloud, et aussi notre propre private cloud. La main question que nous avons, c'est que, selon le professeur cloud, nous avons différents services de management. Pour exemple, si un équipe veut mettre un public-cloud, il y aura une façon différente de faire ça sur AWS, GCP, ou notre private cloud. C'est pourquoi nous avons commencé, il y a deux ans, de construire notre propre plateforme de développeurs d'internel, pour donner des services de management pour tout le monde à Ubisoft, avec un professeur cloud. C'est-à-dire avec une même API, vous pouvez demander pour un clé de public-cloud, pour exemple, dans le private cloud, ou dans AWS, GCP, etc. La même chose pour le database, etc. Une chose importante de cette plateforme, c'est que c'est ouvert à contribution, à Ubisoft. Nous avons beaucoup de team à Ubisoft, c'est de 20 000 personnes qui travaillent là-bas. Pour exemple, il y a une autre team, qui a investi dans un métier primaire, et qui a intégré leur service dans notre plateforme. Le but, c'est que cette plateforme n'est pas seulement construite par notre team, mais la service peut être contribuée par quelqu'un à Ubisoft. Une chose importante, c'est que nous voulons avoir une expérience unifiée pour cette plateforme. C'est-à-dire que les gens vont pouvoir créer leur projet, les utilisateurs, etc. Et puis, ils peuvent créer une ressource liée à ce projet. C'est la même manière que vous pouvez le faire avec AWS, par exemple. D'exemple, vous pourrez faire ça pour assurer votre ressource dans d'autres providers de cloud. Une chose importante, c'est que nous exposons un JSON OS API pour tous les services dans la plateforme, parce que nous faisons beaucoup d'opérations, parce que c'est un plan de contrôle, d'updater et d'élite Kubernetes cluster, etc. Donc c'est un bon match. Et tous ces API doivent être spécifiés par le standard d'opérations. C'est très important, parce que nous utilisons ça pour documenter tous les API, mais aussi pour générer des codes, comme CLI, SDK, Terraform provider, etc. Et donc, tous ces API sont exposés par un API Gateway. Ce API Gateway est seulement pour le plan de contrôle. On doit créer le ressource et le manager. Tout le trafic de votre Kubernetes cluster va sur une autre route, qui est basée sur Kong. Donc, comme je l'ai dit, l'API Open est une partie très importante de ce que nous faisons avec l'API. Parce que nous utilisons ça pour avoir de bonnes mappings entre l'API Open et la route au niveau Kong, pour que nous puissions avoir de précisions par l'opérations, par un point. Par exemple, le premier service Matrix. Et nous pouvons avoir de customes behaviors, ainsi que l'authentication et l'autorisation. Donc, nous voulons assurer que nous avons l'authentication pour tous les API de la même manière, en utilisant l'API OpenID Connect par l'activité Azure. Donc, nous avons notre propre projet sur l'utilisateur. Donc, nous utilisons l'API Open Policy Agents pour avoir de customes règles pour assurer que un specific user ne peut pas apporter une ressource dans un autre projet. Alors, c'est bien. Comment pouvons-nous manager ça ? Nous avons un équipe qui s'appelle l'Admin Gateway, par exemple, qui est responsable pour tout. Managons le Gateway, mais c'est pour la configuration. Donc, tout ce que nous avons fait en UML, avec un peu de Python script, pour procéder à ça, etc. Nous avons utilisé un deck, qui est un outil de l'écosystème congé pour synchroniser le set local de la configuration avec une instance de congé remote. Donc, ça marche bien. Et nous avons exécuté ça avec un Githlab pipeline. Donc, c'était notre initial attempt. Il a travaillé bien au début. C'est facile. C'est facile à installer, c'est facile à opérer. Excepte ça. Après un temps, nous avons commencé à voir un challenge. La première, comment pouvons-nous renforcer un outil specific ? Par exemple, la sécurité. Nous voulons assurer que nous avons l'authentification partout. Nous n'avons pas de points, comme un typo dans le config qui a un bad effect d'avoir un point publiquement d'autorisation. Nous voulons que partout, nous avons des demandes pour un projet, nous avons des bonnes mappings et nous pouvons assurer que nous avons notre propre plugin sous notre propre autorisation. Et nous voulons assurer que la mapping entre l'opinion et la route est toujours synchronisée afin que si le développement change quelque chose, nous voulons assurer qu'il soit appliqué. Et bien sûr, le problème qu'on a avec ça, c'est qu'on dépend beaucoup de la knowledge humaine parce que notre configuration a été faite dans la première place qui était une façon facile mais ce n'est pas scale quand nous sommes intégrés à beaucoup de différents équipes de l'API Gateway. C'est donc le deuxième challenge. Nous avons une seule équipe qui est en charge de tout. C'est d'obtenir des nouveaux équipes de nouvelles équipes des manuels de travail et d'autres. Et aussi, nous avons de la knowledge humaine, donc d'autres personnes, si elles veulent contribuer, elles ont besoin de apprendre au moins un peu de coin avant. Donc il y a deux... La première chose que nous pouvons faire et nous avons commencé un peu, c'était d'accompagner notre initial setup pour travailler sur ce sujet. C'est de prendre un step-back et de penser sur nos goals, ce que nous voulons faire, ce que nous voulons accomplir. La première chose, c'est que nous voulons une safe way d'obtenir cette configuration de l'API Gateway. Autre génération de routes des documents de l'API open et d'enforcer la sécurité. Donc des règles spécifiques définies par le Gateway admins. Validation de la configuration parce que maintenant, c'est appliqué avec un pipeline, c'était appliqué avec un pipeline. C'est-à-dire que si quelque chose d'autre s'est passé sur le côté con de l'API, à un moment, il n'y a pas de ressentance et nous devons manualement rouler le pipeline pour réappliquer. Mais la main point pour nous c'est d'enlever un service pour les développeurs du service afin qu'ils n'aient pas de dépendance sur le Gateway admins. Cela peut être autonome. Donc nous ne voulons pas avoir mais en même temps, nous n'avons pas de complétement de con de l'API parce que l'une des bénéfices de con de l'API est l'écosystème de plug-in. Donc nous voulons que le service admins puisse aller sur le site con de l'API, voir un plug-in et pouvoir juste couper par exemple la configuration, ajuster et utiliser. Si il n'y a pas d'accueil custom, limiter ou quelque chose. Et la réplique. Donc juste pour avoir une récapitation visuelle de cela. A l'arrière, nous avons un Gateway admins qui a 4 règles spécifiques. Et l'autre, nous voulons avoir un service pour les développeurs du service. Nous voulons automatiquement ingester nos documents de l'API. Quelque chose dans le milieu qui va faire des magiques et synchroniser cela à con de l'API. Donc la question est, qu'est-ce qui va être dans le milieu ? Pourquoi pas un opérateur de Kubernetes ? Parce que c'est le topic d'aujourd'hui, parce que nous sommes en cours de Kubernetes. Et il y a des services, des ressources, des ressources, une validation. C'est construit au top de l'API que tout le monde est utilisé pour utiliser. La main question que nous avons c'est, comment pouvons-nous renforcer nos propres règles ? Et comment pouvons-nous faire sure d'ingester automatiquement les documents d'API et de générer les routes basées sur cela ? Il y a quelques choix. Nous pouvons essayer de construire nos propres opérateurs. Et par exemple, utiliser l'API existant, l'API Ingress ou l'API Gateway ou notre propre CRD. Nous allons commencer avec des alternatives différentes. La première solution était d'utiliser le Kong Ingress qui est un controller Ingress. Il peut utiliser l'API Ingress. Il peut aussi utiliser le nouveau API et il y a aussi des ressources customes. Vous pouvez configurer une partie très précise de l'API Kong. Alors, c'est aussi l'API Kong integration. Il ne supporte pas l'API nativale mais on peut travailler sur cela pour construire quelque chose sur le top. Mais la vraie chose que nous ne pouvons pas utiliser c'est qu'il n'y a aucun moyen de renforcer les rousses pour l'utilisateur, pour l'Admin Gateway. Parce que de la façon dont l'API Kong est composée même si, comme l'Admin Kong nous définissons un plugin à un niveau global si un développeur service définit le même plugin avec différentes configurations à l'application de la route. Ce qui est logique dans la usk de Chinewa mais pour notre usk, la deuxième option c'est de construire nos propres opérateurs. Nous allons essayer de construire nos propres opérateurs mais en utilisant l'API existant comme l'API Ingres, pour exemple, tout le monde le connait, l'Ressource Ingres, il est stable, bien connu mais il est trop limité donc, bien sûr, il ne supporte pas l'API. Il n'y a pas de moyen d'avoir une spécifique team pour renforcer les rousses pour nous. Nous avons une nouvelle Gateway API qui a deux parties, en fait. Il y a une Ressource Gateway qui peut être utilisé pour installer une nouvelle Gateway qui nous n'a pas besoin parce qu'on a une seule Gateway et c'est déjà là donc c'est quelque chose qu'on n'a pas besoin au moins pour le moment dans notre usk et la route HTTP qui est la ressource pour configurer une Gateway et toute la route qui est la partie que nous sommes intéressés dans. La bonne partie de la Gateway API c'est qu'ils ont déjà une notion d'un rôle différent comme un rôle admin et un rôle dev donc, nous pouvons renforcer des routes admins mais pas de la manière dont nous voulons c'est trop global et nous voulons une configuration fingraine donc, dans une spécifique plug-in pour exemple, nous voulons des fields spécifiques pour être renforcés mais d'autres qui peuvent être changés par le service développeur donc, ce n'est pas très bien ce que nous voulons faire ou ce sera complexe au-delà de cela, c'est un API qui est encore en beta et qui ne supporte pas un API et c'est un API très complexe pour l'implementer donc, nous ne pouvons pas l'implementer c'est pas grave, donc, la prochaine étape c'est nous voulons construire notre propre opérateur mais avec notre propre ressource définition donc, CRD donc, en fait, nous avons deux types de utilisateurs le service développeur et l'admin de Gateway donc, nous voulons maintenir cela simple donc, un CRD pour les riches donc, l'admin de Gateway sera capable d'utiliser une ressource workspace qui appartient à un workspace cong donc, un workspace cong est l'équivalent d'une place de Kubernetes en cong Enterprise donc, nous utilisons cong Enterprise et c'est un bon moyen pour notre Gateway d'admin, d'être capable de placer et d'évaluer les règles que j'ai besoin d'abord nous allons avoir un exemple dans la prochaine étape et le service développeur sera capable d'avoir le service CRD où ils peuvent définir les ressources upstream et ceci et où trouver le document opérateur sera utilisé pour générer toutes les routes donc, nous avons un document opérateur CRD qui est optionnel dans le sens que le service développeur n'a pas besoin d'évaluer il peut être, par défaut, évalué par le contrôleur parce que nous voulons maintenir quelque chose simple pour l'utilisateur et nous voulons avoir une seule CRD je pense que c'est quelque chose important parce que quand vous avez trop de choses, ça va être plus complexe pour voir les issues, les statuts et tout on va parler de cela plus tard par défaut, une seule CRD pour le service développeur mais si ils ne veulent pas, ils peuvent customiser où le document opérateur est réveillé donc, le document opérateur est juste pour régulièrement faire et réveiller le document opérateur d'une source upstream donc, nous allons voir un exemple il sera plus facile j'espère que vous pouvez voir à la gauche nous avons le workspace donc, le Gateway Admin va pouvoir utiliser pour évaluer la configuration custom que ils veulent à la valeur défaut ou à la valeur renforcée donc, ici, dans cet exemple il est venu d'une référence config il peut être un secret ou en ligne pour une seule plug-in, nous pouvons avoir une partie de la configuration qui sera la valeur défaut une autre partie qui sera la valeur renforcée et puis le service développeur sera capable d'évaluer un service à la valeur renforcée donc, le minimum qu'ils ont besoin est la source upstream d'où s'est envoyé la requête d'où on peut trouver le document opérateur et si ils n'ont pas, ils peuvent définir une plug-in à la valeur globale qui sera appliquée à toute la route ou pour des routes spécifiques avec une configuration spécifique et les configurations qu'ils vont évaluer si c'est le même fil que quelque chose qui est renforcé par l'admin de Gato il sera renforcé par la valeur renforcée donc, c'est exactement ce qu'on veut ce qui est bon comment ça fonctionne pour le contrôleur service rapidement, quand il voit un nouveau ressource de service il fera un document opérateur il fera un parcit et génére une route pour chaque opération et puis pour chaque route il va évaluer toutes les plug-ins ensemble et toutes les configurations donc, nous faisons cela localement à l'octobre opérateur on va prendre les valeurs défautes par exemple, pour des plug-ins spécifiques puis on va mettre au-dessus de ces valeurs par le service développeur et puis les valeurs renforcées donc, de cette façon, nous sommes sûrs que nous avons exactement ce qu'on veut et le next step c'est de s'occuper avec Kong donc, c'est la prochaine question je pense que je parle trop vite donc, j'arrête comment pouvons-nous synchroniser notre ressource local qu'on a construite avec Kong donc, de nouveau, nous avons deux choix soit on peut réutiliser quelque chose d'existent comme le Kong et le contrôleur grec donc, nous avons deux opérateurs en fait, notre propre opérateur et le contrôleur grec et le contrôleur grec sera en charge de la synchronisation avec l'instance de Kong et notre opérateur va juste mettre les ressources de Kubernetes donc, c'est bien parce que pour la réconciliation dans notre propre opérateur, nous pouvons juste utiliser l'API de Kubernetes, c'est plus facile la réconciliation devrait être simple en fait, pas trop parce que si l'API de Kubernetes change, par exemple, il y a une route une opération qui est retirée c'est-à-dire, la route est retirée donc, nous devons faire un SmartDeaf voir que nous avons une route pour retirer donc, c'est un peu de travail mais le problème est que nous avons maintenant deux opérateurs pour le manager donc, plus de complexité plus d'attention donc, quand nous allons procéder une réquest nous devons procéder localement et ensuite, nous devons procéder la synchronisation avec Kong, il va revenir et tout et nous avons limité le statut de Kong nous sommes limités par ce que le contrôleur de Kong et l'API donc, nous pouvons faire tout ce que nous voulons faire sur l'autre côté, l'alternative c'est de la construire de scratch c'est-à-dire, nous devons synchroniser directement avec Kong donc, si nous faisons ça la réconciliation avec Kong parce que, en fait, nous pouvons réutiliser donc, comme je l'ai dit au début nous avons utilisé un deck qui est un CLI qui peut synchroniser un state local avec un Kong pour l'instant c'est une application de goût donc, nous pouvons réutiliser le deck c'est-à-dire que la réconciliation est très facile nous avons juste généré les routes et toutes les configurations, les plugins et nous avons juste demandé le deck de la réconciliation pour le faire donc, nous ferons tous les calls pour Kong pour synchroniser, pour retirer ce qu'on n'a pas besoin donc, c'est très bien nous avons moins de compétences pour le management nous avons plein d'accès pour le status de Kong donc, c'est important parce que de cette façon, nous pouvons donner plus d'informations à l'utiliste sur ce qu'est-ce qui se passe qui nous tient à la prochaine étape qui est l'expérience de l'utilisateur donc, nous avons dit qu'une des raisons c'est d'éloigner le service de service pour le service de développement donc, nous devons avoir une bonne expérience de l'utilisateur parce que si il y a quelque chose qui se passe ou qu'ils ont un problème si ils viennent de l'équipe de l'Admin ils ne sont pas vraiment autonomistes donc, nous devons leur faire sentir autant autonomiste que possible et quand vous commencez à apprendre un nouveau API c'est toujours un peu difficile parce que vous devez voir le deck il ne faut pas essayer d'ouvrir le YAML il ne marche pas la première fois donc, vous essayez un peu de temps mais il y a toujours une feature en Kubernetes qui n'est pas utilisé assez qui est le service dry run donc, je ne sais pas si les gens utilisent le service dry run dans la salle vous avez des gens ? oui, pas si bien c'est une très bonne feature c'est pas la même que le client-side dry run qu'il y a sur le CTIL c'est un lien au service on peut en parler plus longtemps d'autre jour mais basiquement, vous envoyez les invités à Kubernetes avec le service dry run il va aller à tous les web-books mais il ne sera pas persisté dans la TCD et le service API va juste retourner le résultat de YAML c'est-à-dire que dans notre opérateur si nous avons un web-book qui est généralement des valeurs defaultes nous pouvons voir si il y a un flag un flag dry run et en ce cas, à l'aide de justifier les valeurs defaultes nous pouvons rouler toutes les choses qu'on fait dans le contrôleur c'est-à-dire établir l'opérateur générer toutes les routes la configuration de plug-in et envoyer ça à Kong et la bonne news c'est que Kong aussi supporte un dry run sur le service la configuration pour Kong qui va procéder valider faire sure qu'il n'y ait pas de conflits et tout et envoyer ça sans le sauver localement donc nous pouvons envoyer tout ça à l'utilisateur et nous pouvons voir dans le fil prévu je n'ai pas mis tout parce que ça serait trop long mais nous pouvons avoir un document qui a été utilisé sur le plug-in et tout et nous avons aussi une idée si on veut voir toutes les opérations qui ont apporté à l'aide de Kong donc c'est un outil très beau pour pouvoir utiliser et si vous avez écrit votre propre opérateur je vous recommande d'appliquer le service de dry run oui, l'expérience de l'utilisateur alors pourquoi nous pensions sur ce topic, nous nous demandons donc, bien sûr, les gens sont utilisés pour avoir des réponses en utilisant le statut les conditions, les événements, etc nous avons un peu de challenge avec le statut nous ne savons pas combien d'informations nous devons mettre dans l'application si nous devons mettre beaucoup d'informations mais ce sera difficile de lire mais c'est bien si vous avez besoin de cette information ou si nous devons avoir moins d'informations c'est facile de lire mais parfois ça signifie que vous devez revenir à Kong pour avoir plus d'informations quand vous avez une issue donc ce que nous avons fait c'est juste de mettre les choses dans le statut et d'appliquer notre propre plugin pour que nous puissions avoir une visibilisation interactive de la ressource une vue négociative une intégration avec d'autres systèmes donc, j'ai dit au début que nous faisions tout ça avec l'application de la route et d'autres applications pour différentes raisons nous voulons avoir un point de vue de la ressource donc un métier prométhéous pour chaque opération et pour que nous puissions rétablir et évoluer donc je vous montre un petit démon qui est récordé parce que je ne suis pas sur le Wi-Fi donc, c'est le plugin donc nous pouvons voir le workspace nous pouvons cliquer sur l'ID pour voir ce qui s'est passé dans la réconciliation avec l'open telemetry trace nous pouvons voir un service avec toute la route donc, une fois de suite nous pouvons voir la réconciliation tout ce qui s'est passé toutes les requises que nous avons faites tout le route qui s'est généré d'un document de l'open API qui a l'authentication, l'autorisation le plugin, la configuration qui a été appliquée et nous pouvons voir les requises qui viennent d'un métier prométhéous en fait, c'est de notre test donc ce n'est pas un cas real mais encore, nous pouvons intégrer avec un système différent en conclusion, quand vous voulez construire votre propre opérateur si vous voulez avoir un service bien sûr bien sûr, quand vous êtes déjà utilisé le Kubernetes et que vos utilisateurs sont déjà utilisés dans le Kubernetes API quand vous avez un cas bien défini il marche mieux, parce que je n'ai pas parlé de version upgrade mais c'est un pain real donc si vous pouvez l'aider, c'est mieux et il y a un moyen d'éviter d'avoir moins de chances d'avoir besoin de version upgrade si vous avez vraiment besoin vous savez vraiment que vous avez utilisé le cas bien sûr, si vous avez prévu une expérience de Kubernetes, c'est mieux parce que ça peut être beaucoup de prendre au début et si il n'y a pas une solution existante donc je veux juste finir avec les bénéfices les bénéfices que vous avez contrôles sur votre opérateur, sur ce que vous voulez la flexibilité, l'intégration custom avec Prometheus, etc et vous pouvez contrôler l'expérience d'utilisation donc vous avez une expérience d'utilisation si vous avez plus de points dis-moi d'ailleurs, merci si vous avez des questions, on a le temps pour les questions oui, hi pouvez-vous mettre la mic ? merci pour votre présentation je suis curieux d'une chose pouvez-vous estimer le nombre de lignes de code que vous avez à faire si je vous souviens que c'est un plugin Ctl pour travailler avec votre opérateur custom peut-être que j'ai perdu quelques choses donc vous voulez savoir le nombre de lignes soit le nombre de lignes ou pouvez-vous estimer le temps ou l'effort que vous avez à mettre en code ok c'est pas facile le plugin Ctl c'est très facile c'est comme 1 ou 2 jours pour avoir un peu plus quand vous voulez avoir un outil fancier mais c'était très facile et la main 80% de la code c'est assez facile quand vous ne connaissez pas les cubanités et la connaissance internelle parce que la partie plus complexe c'est le loop de la réconciliation comment vous synchronisez et pour nous, c'était déjà en train de s'occuper par le library donc après ça c'est la main glue code comme en récupérer un document OpenAPI en utilisant le library white pour pouvoir s'occuper d'un API V2 et V3 et détaillé c'est un peu il y a quelques mois mais il n'y a pas ok, merci bonjour avez-vous utilisé un OSDK ou un OSM d'écosystème? non, pas un OSDK mais un Qbuilder mais en fait c'est un contrôleur en temps si vous devez le faire encore aujourd'hui avez-vous utilisé un OSDK au lieu de... un OSDK c'est plus un Qbuilder et un contrôleur en temps surtout si vous voulez le déployer publicement donc pour notre use case je pense que ça ne fera pas beaucoup de change pour la paix de la version peut-être les OSM oui, peut-être pour le moment nous n'avons pas à augmenter la version pour cet opérateur merci hi avez-vous considéré que vous avez utilisé un crossplane au lieu de créer votre opérateur donc pas pour cette use case parce qu'on a quelque chose très spécifique donc crossplane nous n'avons pas beaucoup mais on va utiliser un crossplane sur le top de notre API donc pour la plate-forme on va construire un API c'est le niveau bas et sur ça on va construire des terraformes et on va utiliser un crossplane pour que les gens utilisent un crossplane pour interagir avec l'API merci