Le 03 juillet dernier, nous étions en direct sur Youtube pour présenter une nouvelle offre de services cloud basée sur Kubernetes. Yves-Gaël Chény, responsable du pôle datacenter, et Valentin Baraise, DevOps, se sont prêtés au jeu du Live pour en expliquer le périmètre, les services complémentaires et les usages concrets en se basant sur deux cas clients. Le Live s’est terminé par une démonstration pratique de l’outil.

La nouvelle offre Cloud Empreinte Digitale vous permet d’industrialiser le déploiement d’applications en cloud hybride, grâce à Kubernetes. L’objectif est de simplifier la création d’instances clients ainsi que la mise à jour.

En complément, nous vous fournissons un outil de monitoring dédié, aux métriques personnalisables, RAM, CPU, I/O disk et autres. Ce dashboard utilise les technologies Grafana et Prometheus pour vous permettre de gérer vos consommations et d’augmenter vos capacités en toute autonomie.

Notre équipe d’administrateurs système DevOps est à votre écoute pour vous accompagner à chaque étape de la mise en place, et pour assurer le support technique à tout moment.

Transcription textuelle de la vidéo

VB = Valentin Baraise, DevOps

YGC = Yves-Gaël Chény, responsable pôle datacenter

[ensemble] Bonjour à tous !

VB : Bienvenue dans ce webinaire consacré à l’industrialisation du déploiement en cloud hybride avec Kubernetes. Le sujet va être un retour d’expérience sur la mise en place de Kubernetes chez nous et, en plus de ça, on va parler des différents cas clients qu’on a pu avoir chez Empreinte Digitale, et puis l’évolution qu’on a voulu apporter à cette offre chez Empreinte Digitale.

Tout d’abord le déroulement, comment ça va se passer ? C’est simple, c’est un stream, il y a un chat, le but c’est que ce soit intéractif alors n’hésitez pas à l’utiliser. On va vous présenter dans un premier temps la boîte, si vous ne connaissez pas Empreinte Digitale, on va essayer de vous présenter ça. On fera une rapide explication sur ce qu’est Kubernetes si vous ne vous rappelez plus.

On va rappeler rapidement l’historique de la mise en place de Kubernetes chez Empreinte Digitale, les cas clients, etc. ; et enfin un retour d’expérience. L’idée, c’est que ce soit un retour d’expérience avec une interaction, n’hésitez pas !

Posez des questions si vous en avez, si vous voulez plus de précisions, il faut être présent, on est là pour répondre également, donc ne pas hésiter ! Nous allons présenter qui nous sommes, dans un premier temps : Yves-Gaël…

YGC : Tout à fait ! Merci Valentin pour toute cette introduction ! Je me présente, je suis Yves-Gaël Chény, responsable du pôle hébergement et datacenter chez Empreinte Digitale à Angers et je travaille au quotidien avec Valentin Baraise qui a fait l’introduction.

VB : Exactement, je suis Valentin et j’ai rejoint Empreinte Digitale il y a un peu plus d’un an. Je suis rentré pour des questions de DevOps au sein d’Empreinte Digitale.

Qui est Empreinte Digitale ?

YGC : On va vous présenter vite fait la société, je ne sais pas si vous nous connaissez déjà ou pas, certains sont peut-être d’Angers et nous connaissent, d’autres sont peut-être ailleurs en France et ne nous connaissent pas. La société Empreinte Digitale, c’est une entreprise qui a 26 ans avec plus de 25 ans d’expérience dans le développement logiciel et l’hébergement. Nous on s’occupe de la partie hébergement, mais il y a aussi environ 50 collaborateurs qui font du développement, du test, de la gestion de projets et de l’édition de logiciel d’archives [sur la diapo on lit les savoir-faire d’Empreinte Digitale : le système d’informations archivistique, le développement sur-mesure, l’accessibilité numérique et les solutions de productivité et cloud]. On s’est regroupés tous en SCOP (Société COopérative et Participative) , suite au départ des précédents propriétaires de l’entreprise à la retraite. On a racheté l’entreprise en SCOP, on est donc une SCOP sur Angers de développement logiciel. Il faut savoir que l’hébergement a toujours été au cœur de notre activité depuis les 26 ans. Ça a commencé avec l’hébergement de solutions pour du Minitel et ça continue encore aujourd’hui pour des problématiques web.

VB : Voilà, globalement !

YGC : À la base, Kubernetes, c’était d’abord un besoin interne pour notre équipe de développement. Tu confirmes ?

Qu’est-ce que Kubernetes ? Quel usage chez Empreinte Digitale ?

VB : Exactement ! On va réintroduire Kubernetes pour qu’on parte à peu près tous sur les mêmes bases. Aussi, n’hésitez pas à nous dire s’il y a des choses que vous ne comprenez pas dans Kubernetes, ça peut être quelque chose d’un peu compliqué.

Donc, qu’est-ce que Kubernetes ? Il faut savoir que c’est un orchestrateur de conteneurs, qui s’appuie sur des technologies de runtimes. Kubernetes, c’est un outillage qui permet de faire tourner des conteneurs. Pour rappel des conteneurs, c’est une unité qui permet de lancer une application et de la mettre à disposition pour les utilisateurs sur le Net. C’est un système déclaratif, donc ça veut dire qu’on demande un état et que Kubernetes va s’occuper de nous donner l’état que l’on souhaite. Kubernetes, ce qu’il est important de savoir, c’est que c’est un système qui fonctionne via beaucoup d’API (Application Programming Interface / Interface de Programmation d’Application) : tout est API dans Kubernetes et cela demande de maîtriser le réseau.

Et enfin, l’outillage permet de gérer les différents déploiements avec le blue/green, le canary etc. En résumé, Kubernetes est un outil qui va permettre de demander un état de l’application et tout au long de son cycle de vie, de l’avoir en fonctionnement.

Alors maintenant, pour la suite, qu’est-ce qu’on a utilisé chez Empreinte Digitale pour les usages de Kubernetes ? Tout d’abord, on a utilisé Kubernetes dans l’optique, chez Empreinte Digitale, que le développement était fait sur des conteneurs ; donc on était habitués à utiliser ce genre de technologie pour déployer nos projets. Alors du coup, je le rappelle, les conteneurs étaient utilisés pour faire de la CI (Continuous Integration / Intégration Continue).

L’objectif de la CI est de mettre en place des outils pour augmenter la possibilité de déployer l’application que vous développez, pour l’amener auprès des utilisateurs. C’est à dire, réduire le temps entre le développement et la mise à disposition auprès des utilisateurs. Et en fait, on a utilisé ça pour améliorer les déploiements, etc. L’objectif était de réduire la charge auprès des différents développements en production et en plus de ça, augmenter la possibilité de voir le fonctionnement de son application avec l’observability. Ce sont des termes importants à comprendre dans le monde DevOps et Kubernetes.

Cas clients : deux utilisations différentes de Kubernetes pour automatiser les déploiements

Le cas de NDP systèmes

YGC : Après avoir fait ces tests en interne pour nos propres développeurs, on en a parlé un peu dans nos réseaux principalement sur Angers. À l’issue de discussions avec des partenaires et des entreprises qu’on connaissait déjà, on a rencontré deux profils clients très différents, avec qui on a fait nos premières armes comme hébergeur cloud basé sur Kubernetes.

Je vais vous présenter ces deux entreprises, et en quoi leurs deux problématiques étaient vraiment différentes de nos problématiques internes d’origine. [Diapositive Cas clients précise (avec en haut les logos de NDP Systèmes et Effidic) les objectifs : Proposer un service à des clients de nos réseaux. Leur proposer nos services d’expertise et de mise en place d’une plateforme pour leurs besoins. Les besoins : mise en place d’une plateforme hautement disponible pour du CI/CD d’un ERP et accompagnement dans l’industrialisation d’un progiciel en production pour de la Business Intelligence]

Donc le premier qui est venu travailler avec nous sur Kubernetes, c’est NDP systèmes. C’est une entreprise basée à Angers qui développe sur l’ERP Odoo, un logiciel libre codé en Python. C’est une entreprise de développement logiciel purement basé sur cet ERP. Ils font de la gestion de projet et du développement, mais ils n’ont pas de sysadmin en interne. Forcément se pose alors un problème pour eux : comment tester étant donné qu’ils développent avec des outils d’intégration continue, dont parlait Valentin tout à l’heure. Comment pouvaient-ils automatiser pour tester les différentes itérations logicielles qu’ils proposent à leurs clients ? Ils adaptent fortement le logiciel avec des modules et en modifiant un peu le cœur aussi parfois. Cette phase de test et d’intégration continue est donc essentielle pour la qualité de leur travail.

Ils sont venus nous voir justement pour palier à cette absence de sysadmin et essayer de remplacer le sysadmin par, dans le cadre d’une démarche DevOps, de l’automatisation. Ils sont venus chez nous, c’était pas des gens qui étaient spécifiquement aguerris sur Kubernetes, il savaient utiliser Docker quand même. On les a accompagnés et on a mis ça en place. Actuellement, ils l’utilisent de façon extrêmement intensive et déploient simplement leurs applications.

VB : NDP ? C’est plusieurs déploiements par jour. En plus des déploiements de l’application complète, il y a tout un système de job qui permet de tester l’application en direct. C’est à dire que dès qu’une nouvelle fonctionnalité est activée dans le produit, il y a un cronjob (une tâche) qui est lancé. Cette tâche va s’assurer du fonctionnement attendu de l’application. Une fois que ces tâches se sont déroulées correctement (ou pas), elles sont faites. Kubernetes va finir le cycle de vie de l’application et avoir un reporting auprès des développeurs pour savoir si ça fonctionne correctement.

YGC : En complément de leur outil de commit, ça leur permet d’avoir un feedback rapide sans tâche manuelle sur la qualité de leur développement.

Le cas de Effidic

YGC : Un deuxième partenaire est venu nous voir, c’était à l’issu d’un apéro Kubernetes que nous avions fait, en présentiel, il n’y avait pas encore eu le COVID. On avait présenté pourquoi Kubernetes nous plaît, et à l’issue, il y a un partenaire d’un réseau qu’on avait déjà rencontré comme ça, qui lui développe un produit. Cette entreprise c’est Effidic. La différence, c’est qu’ils développent vraiment leur produit.

Leur problématique était encore différente, c’est à dire qu’ils mettent à disposition leur produit, une sorte de location, avec de l’expertise derrière pour faire de la BI (Business Intelligence) sur des catalogues de données clientèles commerciales. Leur problématique à eux était, comme c’est leur axe de développement principal, de pouvoir le déployer rapidement. C’est vraiment une logique de vente en mode SAAS (Software As A Service) pur, de façon à ce qu’ils ne passent pas par des phases de “on va chez le client, on personnalise, on installe” ce qui est un coût humain non négligeable, eux ils utilisaient déjà aussi un peu de Docker.

VB : Ils étaient familiarisés avec Docker ! Du coup l’application d’Effidic est pré-packagée, c’est du Java. On a juste à déployer le jar avec le runtime qui va bien mais c’est beaucoup moins compliqué à gérer au niveau des dépendances, donc c’est très facile à déployer et à scaler dans le cas où il y a besoin de plus d’instances. Le besoin [d’Effidic] quand ils sont venus avec nous, c’était vraiment de se dire “bon l’application fonctionne, on ne veut pas forcément avoir des tests de Kubernetes mais on veut s’assurer que notre application fonctionne en permanence.”

YGC : Et qu’elle va être répliquée surtout !

VB : Et qu’elle va être répliquée, c’est ça ! Donc l’idée c’est, “tiens, on a un nouveau client, quelle est la marge et quelles sont les difficultés pour créer une nouvelle instance ?”. Avec Kubernetes c’est relativement simple. Ils nous ont donc demandé comment on pouvait travailler ensemble pour déployer leur application.

YGC : Il y avait des petites problématiques marrantes comme le back up de la base de données de façon dynamique par rapport aux tailles de certains conteneurs et aussi le routage sur la partie trafic sur laquelle reviendra sans doute Valentin tout à l’heure, vu que c’est sa grande passion.

VB : La création des noms de domaines personnalisés pour chaque client. Donc c’était vraiment deux problématiques clients différentes.

YGC : Deux clients très différents, mais très intéressants et qui nous ont beaucoup appris sur ce qu’on avait fait en interne. Forcément, quand on travail sur un outil comme Kubernetes en interne, on n’a pas le même niveau d’attente d’automatisation et d’exigence, que celui que l’on va avoir après en travaillant avec des clients. Ce qui nous amène à la suite…

Pourquoi du cloud pour de la mise en production ou pour le maintien d’une application en continu ?

VB : Je veux bien en parler, le pourquoi le cloud et pourquoi ça peut être intéressant pour ce genre de cas client.

Pourquoi du cloud pour ce genre de cas client, avec des problématiques différentes ? L’une c’était la mise en production avec tout un tas de tests, l’autre c’était la mise en production et le maintien de l’application en permanence. Dans ce genre d’environnement cloud, il y a des mécanismes et des informations très intéressantes à avoir.

… pour visualiser les métriques

VB : Tout d’abord les métriques, elles vont être collectées tout au long du cycle de vie de l’application. C’est ce qui va nous permettre en tant que développeurs de savoir si elle fonctionne correctement, s’il faut une nouvelle mise à jour de l’application, parce qu’avec Kubernetes c’est très simple de mettre à jour son application. C’est “tiens, je fais une nouvelle mise à jour de mon application, est-ce qu’elle réagit comme avant ou est-ce qu’elle réagit vraiment différemment ?” Avec les métriques c’est très facile de récupérer ces informations là.

… pour suivre les usages

VB : L’avantage c’est d’avoir aussi un suivi des usages. Là où on doit s’occuper nous même des machines sur lesquelles on déploie l’application, on n’a pas forcément le temps d’analyser ça. On a mis en place un ensemble d’outils permettant de revenir sur un historique assez important en arrière et de se dire, “si un jour je veux faire de l’analyse sur les dix derniers mois ou les trois derniers jours car je sais que j’ai une forte activité, c’est possible car les métriques et différentes infos que l’on récolte sont toujours persistantes !”

Évidemment, qui dit cloud hybride dit que la plateforme n’est pas managée par les développeurs de la société. Donc pour les développeurs c’est un poids en moins :  en se disant “je développe mon application et mon objectif c’est de la déployer sur le cloud où je suis client et tout ce qui est en-dessous, si il y a un problème, ça ne me concerne pas. Je peux contacter une personne directement pour leur demander si c’est normal ou pas.” Donc ça c’est un gain qui est quand même intéressant.

Des services Kubernetes sur-mesure et packagés, avec Empreinte Digitale

YGC : Pour compléter un peu sur la partie métriques et suivi des usages, ça nous arrive aussi de proposer un peu de sur-mesure sur le type de métriques que l’on va afficher et donc plus seulement les métriques classiques d’usage de puissance pure.

On propose aussi des métriques métiers qui vont avoir un lien direct avec l’application et sont intéressantes pour le client. Ça c’est important et c’est peut-être ce qui peut nous différencier de gros cloud publics, c’est ce petit côté “on va apporter un peu d’expertise et un peu de sur-mesure” ; et en plus c’est intéressant.

VB : Quand on propose des métriques on ne dit pas “voilà vous avez votre Grafana, parce qu’on utilise Grafana et vous vous débrouillez avec ça”. Si a un moment donné, il y a une demande particulière, parce que votre application expose des informations que vous voulez récupérer, nous on va pouvoir les récupérer de manière personnalisée et les afficher. Ce n’est pas un problème pour nous. Forts de ces expériences avec les différents clients qu’on a eu, et les différentes expériences en interne …

YGC : Les difficultés rencontrées et les solutions trouvées [rire]

Nos expérimentations pour faciliter la mise à disposition de nos services Kubernetes

VB : On s’est dit voilà, on a beaucoup travaillé dessus, on a appris et on s’est dit “Comment est-ce que l’on peut rendre ça un peu plus automatisable ? Comment est-ce qu’on peut mieux “packager” l’accès à Kubernetes ?”  Et donc on a appris, on a avancé, et on s’est dit “avant, on faisait tout manuellement”, et par manuellement, j’entends “on a créé des scripts et on automatise”. Mais il manquait un peu cette “glue” qui nous permet de facilement travailler dessus et de le mettre à disposition des clients externes et même internes. [La diapositive représente des schémas qui expliquent le passage du mode manuel à l’automatisation : un petit personnage humain pour le côté manuel et un robot pour la partie automatisation]

En fait dans Kubernetes, il faut savoir qu’il y a pléthore d’informations. C’est un modèle descriptif. Sauf que ce modèle descriptif est tellement fourni, c’est aussi la force du produit, que si on n’a pas un outil permettant de gérer un peu ça, c’est compliqué. Donc on a essayé de voir comment on pouvait passer de la partie manuelle à la partie automatisation. Alors pour ça, on s’est appuyé sur des outils qui étaient clairement présents dans la communauté Kubernetes.

YGC : On a un peu hésité au départ !

VB : Alors, ce n’est pas qu’on a hésité ! On a expérimenté !

YGC : C’est ça ! On peut dire ça comme ça.

Des débuts avec Rook, OpenEBS, Kubeadm, Kubespray

VB : On a expérimenté, on est parti sur des solutions donc là on peut le voir sur la diapo [Sur la diapositive il y a 5 logos et le texte suivant : Outils CNCF, référence dans le monde Kubernetes, retour d’expérience] : Rook par exemple, c’est un système qui permet de faire du stockage Ceph à l’intérieur du cluster Kubernetes. Donc ça fonctionne globalement bien, mais on a eu quelques effets de bords sur des cas vraiment particuliers. Le fait d’avoir ce type de petites problématiques, ça nous a fait revenir un peu en arrière, changer d’outil donc pour un nouvel outil qui s’appelle OpenEBS. Il permet de faire globalement la même chose que Rook, mais en plus, ils ont une stabilité sur les usages que l’on a identifié comme potentiellement problématique, ils étaient déjà matures.

YGC : Tu peux en parler un peu des problèmes que l’on a rencontrés ! C’est intéressant pour ceux qui nous écoutent.

VB : Alors, Rook c’est complet, ça propose tous les outillages pour faire de l’object storage, du NFS (Network File System / système de fichiers en réseau) etc., sauf que ces outillages sont encore parfois en bêta, ils ne le disent pas forcément on le découvre en discutant avec les autres personnes de la communauté, les différents développeurs etc. Ce qui fait que ça peut poser problème. Contrairement à OpenEBS qui lui s’occupe de faire du stockage, et si on veut ajouter du stockage objet on va utiliser un composant externe qui s’appelle MinIO. Là j’ai mis le logo de MinIO au milieu. Si on veut faire du NFS, on va utiliser l’outillage NFS.

En fait, OpenEBS, son seul objectif c’est de proposer du stockage, qu’il soit répliqué et hautement disponible et qu’il fonctionne. C’est aussi pour ça qu’on a fait évoluer la plateforme. C’est avec ce genre d’apprentissages là qu’on s’est rendus compte qu’on pouvait partir sur plus ou moins de logiciels.

Voilà, j’ai mis quelques logos [sur la diapositive 5 logos : à gauche Kubeadm et Kubespray à droite Rancher et OpenEBS et au milieu MinIO] comme Kubeadm ou comme Kubespray, on automatise la création de nouveaux nœuds dans Kubernetes avec Kubeadm et Kubespray, qui est l’outil de référence. Il est recommandé d’utiliser cet outil là et ça fonctionne très très bien.

La plateforme Rancher pour manager les clusters et gérer l’authentification

VB : Et surtout pour l’interface et la gestion d’authentification, comme c’est un sujet complexe qui nécessite de passer beaucoup de temps et de ne pas le prendre à la légère, parce que l’accès au cluster ça crée forcément des besoins avec la partie autorisation, qui a droit à quoi etc. Eh bien on s’appuie sur Rancher, c’est un système qui permet de manager ces différents clusters Kubernetes, ça peut être on premise, un peu partout, ça gère tout. Mais surtout, c’est un outillage qui est complet et qui est une référence, vraiment une référence dans le monde Kubernetes.

YGC : Avec une super API !

VB : Avec une super API, c’est important ! C’est grâce à nos différents retours d’expérience, avec nos différents clients et les usages internes, qu’on s’est rendus compte qu’on pouvait avancer dans notre produit.

L’objectif c’est d’avoir une plateforme qui permet l’autonomie et le contrôle de ses ressources auprès des utilisateurs. Avec la plateforme Rancher, les utilisateurs vont être indépendants pour accéder aux différentes ressources. Les utilisateurs ont des ressources qui leur sont affectées et qu’ils ne peuvent pas extrader les unes des autres. C’est contrôlé donc c’est un gain de sécurité en plus et surtout, dedans, il y a l’outillage pour avoir des métriques, pour gérer le nombre de réplicas, augmenter les versions etc. et ça permet vraiment de simplifier l’usage au quotidien pour les développeurs, comme pour nous d’un point de vue administration de la plateforme.

Démonstration de la plateforme Rancher et blue/green deployment

YGC : Une petite démonstration Valentin ?

VB : Oui je peux faire une démonstration ! Si il y a des gens dans le chat qui ont des questions sur les différents outils, sur la philosophie Kubernetes etc.

YGC : Ou une déclaration d’amour [rire]

VB : Ou une déclaration d’amour [rire]. Je ne sais pas si tu es toujours là Thibault, mais merci ! Ou peut-être des questions d’un point de vu plus général sur Kubernetes, je peux en profiter car on n’a pas toujours le temps de poser ces questions là. S’il n’y a pas de questions je vais faire une petite démo sur Rancher.

YGC : On a hâte !

VB : Il y a une interface qui a été développée en interne qui permet de créer un compte directement sur une sorte de back office chez nous et d’accéder ensuite à ses ressources Rancher. Je vais vous présenter Rancher rapidement. C’est un outil avec une interface, je suis en admin donc j’ai accès un peu à tout !

L’objectif de la démo va être de déployer une application qui est juste un nginx. À l’intérieur, une page qui me dit que c’est sur l’instance blue, donc on va faire du blue deployment. On va voir que l’outil Rancher, en plus des outils Kubernetes, permet d’avoir une retranscription visuelle de ce que l’on est en train de faire. C’est intéressant d’un point de vue développeur de se dire, “j’ai pas besoin d’avoir une approche hyper dark avec la ligne de commande etc.”, l’outil Rancher permet de vraiment simplifier ça.

YGC : Côté sysadmin, ça permet de retrouver une bouffée d’air dans ses relations avec les développeurs.

VB : Exactement. Donc, j’ai déployé une application qui s’appelle « demo nginx blue » [l’écran montre l’interface de l’outil Rancher et l’onglet Workload est sélectionné. On voit, le nom de l’application de démo : démo-nginx-blue et dans la colonne état la mention “active” pour signifier que l’application fonctionne] qui est disponible à l’adresse demo-app.k8s.cloud-ed.fr. Alors, on va avoir l’interface Rancher qui est tellement bien faite que toutes les ressources Kubernetes sont présentes dans son interface. [l’écran affiche l’application de démo, deux phrase sur fond blanc : bienvenue sur mon site ! Mon application fait tourner la version blue (blue est écrit en bleu)]. Cette application elle fonctionne, je peux refresh autant que je peux ça fonctionne très bien. Elle est déployée sur mon cluster Kubernetes, elle fonctionne, j’ai envie de la mettre à jour, comment est-ce que ça va se passer ? Alors déjà, si je suis nouveaux sur le projet, je peux arriver dans l’interface, aller dans mon namespace ou mon projet [sur l’écran il clique sur la partie namespace puis ensuite sur k8s-saas-prod, puis sur Valentin, le nom du projet], donc là il y a une notion de projet qui est présente dans Kubernetes. L’idée c’est vraiment de faire une démo.

Je ne vais pas expliquer de manière très exhaustive le fonctionnement, parce que ça prendrait beaucoup de temps et on n’a pas toute la nuit ! Mais je vais expliquer quand même que l’outil est très intéressant parce qu’on retrouve toutes ses ressources.

Comprendre le load balancing dans Kubernetes

VB : Le load balancing, dans Kubernetes c’est une ressource qui permet d’accéder à son application de l’extérieur. On peut la retrouver dans Kubernetes et on peut d’ailleurs, je l’ai fait tout à l’heure, cliquer directement sur le lien qu’on a configuré et se retrouver sur son application [sur l’interface Rancher, il clique sur le lien de l’application lié au load balancing et la page ré-affiche l’application de la démo, puis revient sur l’interface Rancher]. On a également les services [sur l’interface Rancher, il clique sur la rubrique Service Discovery], qui permettent de lier les codes au load balancing, c’est un peu la glue entre l’application et l’extérieur. Là aussi on a les différentes ressources qui sont disponibles dans Rancher et on peut les visualiser [dans Rancher, il clique sur ressources, on arrive sur une page décrivant les informations de l’application, dont le nom de l’application, le type de création : ici une application, le namespace qui travaille dessus et la valeur : webserver]. On a d’autres informations comme les volumes [il clique sur l’onglet Volumes]. L’idée c’est que là [on revient sur la page workload de Rancher affichant l’application de démo nginx-blue] j’ai une application, qui s’appelle workload dans le monde de Rancher, qui s’appelle démo nginx blue ici.

Si je clique dessus ça m’emmène dedans [il clique sur le nom du workload dans Rancher (toujours dans l’onglet workload) une page s’affiche avec les caractéristiques de l’application de démo] et [il descend dans la partie Pods de la page, où l’on lit que l’application nginx-blue , petite indication en vert avec écrit “running” sur Rancher] on voit que j’ai mon application qui tourne trois fois. C’est ce qu’on appelle des pods dans le monde Kubernetes ; les pods c’est la plus petit entité présente, c’est ce qui contient le conteneur. L’application démo est en train de fonctionner.

Comment faire du blue green deployment ?

VB : Là c’est ce que je vous ai dit, on va essayer de faire un blue green deployment. L’idée de blue green deployment c’est de se dire, “j’ai une version bleue et je veux passer à une version verte, mais je veux quand même avoir le fonctionnement de la version bleue pour, au cas où il y ai un problème, revenir rapidement dessus.” Dans le monde classique, ce serait : « je créé un deuxième serveur, strictement identique au premier, avec la nouvelle version de l’application. » C’est pas très compliqué à mettre en place mais c’est rarement fait en production car ça demande beaucoup de ressources, et d’un point de vu sysadmin il faut recréer une application, un serveur, c’est chronophage.

YGC : Et ça permet d’avoir une continuité de service totale.

VB : Exactement. Donc, j’ai mon application bleue avec différentes informations, et déjà on peut voir que j’ai de la métrique directement ici [il descend dans la page et déroule la rubrique métriques de la charge de travail]. Si je veux voir l’application sur une heure [il clique sur un menu déroulant pour sélectionner un ordre de temps pour affiner les métriques, il sélectionne une heure dans le menu et les métriques se mettent à jour], on voit les différents pods, [trois graphiques sont affichés : utilisation CPU, utilisation de la mémoire, I/O du disque] comment ils réagissent etc., si vous spammez et que vous faites refresh [il clique sur le site de la démo à plusieurs reprise] à un moment on devrait voir une augmentation du CPU. On a également les events [il déroule le menu de la partie events], donc ça c’est le cycle de vie donc là il n’y a pas de cycle de vie particulier, il n’y a pas de pod qui a été tué. Mais on pourrait avoir les informations comme ça.

Donc j’ai mon application bleue qui fonctionne. Là je vais lancer une application verte [il passe dans son terminal pour utiliser l’outil en ligne de commande Kubectl]. Rancher ça permet de gérer ses ressources, mais surtout, ça n’empêche pas d’utiliser des outils classiques comme Kubectl. Alors ça peut être Kubectl, comme ça peut être gitlab CI, comme ça peut être Github, l’idée c’est que moi j’utilise du Kubectl parce que j’ai créé moi-même mes manifestes. Si on veut faire du GitOps, il est facile de créer une connexion entre son GitOps et son Git et de déployer automatiquement ses ressources.

Je le fais ici, je vais déployer mon application verte [Dans le terminal, il tape la commande kubectl – f green et tape sur entrée;i ajoute une ligne en dessous la commande kubectl apply – f green]. Alors green, c’est un dossier dans lequel j’ai deux manifestes. Si je vais voir ce qu’il y a, il y a [dans la partie haute du terminal, il fait descendre un les lignes de codes pour montrer la partie containers nommés nginx] un autre déploiement avec dedans mes conteneurs nginx ; des informations qui sont essentielles et une bonne pratique qui sont des limites [il sélectionne en surbrillance la partie limites avec écrit en dessus CPU et memory] ; pour éviter que ça s’emballe. Et enfin, ici [il descend dans la partie configmap et en dessous on voit le code du site] j’ai la config map, donc c’est en gros mon site. D’ailleurs, je vois que j’ai fait une petite erreur, donc je vais la corriger en live [dans la ligne de code du texte du site, il remplace la commande <font color = blue> par <font color = green]. C’est magique !

Donc, j’ai deux applications. Si je retourne sur le site [retour sur la page du site avec les phrases et le mot blue écrit en bleu], vous allez me dire “attendez je ne comprends pas, vous m’aviez dit qu’on faisait du blue green deployment, sauf que quand je fais un refresh [il clique sur refresh sur la page], j’ai les deux qui peuvent arriver”. Alors, le fait que la requête elle soit load balancée, comme on utilise un load balancer, elle est des fois envoyée sur un pod et des fois sur un autre. On voit que des fois on est sur le green, des fois on est sur le blue alors qu’on s’est dit moi je veux passer du bleu au vert une fois que c’est prêt. Là, c’est typiquement un exemple parfait [sur Rancher dans la partie workload l’application démo green affiche une indication updating en rouge signifiant un quota dépassé].

Dans Rancher, il nous dit les problèmes qu’il peut y avoir avec les pods. Là, on se rend compte que j’ai un quota sur mon namespace et le quota je l’ai atteint : je ne peux pas déployer plus de pods.

Alors on va régler ça, effectivement j’ai un petit quota donc on va l’augmenter en live [il repasse sur le terminal et entre la commande Kubectl get quota puis tape Kubectl edit quota. D’autres lignes de codes apparaissent et il change le chiffre sur la ligne limits cpu de 100 à 1000, puis passe de 1 à 2g et sur la ligne limits memory]. Je regarde mon quota de nouveau, “get quota”, c’est bon [Il entre à nouveau la commande Kubectl get quota et repasse ensuite sur l’interface Rancher]. Voilà, je vais pouvoir continuer mon déploiement. Je vais même relancer mon déploiement directement depuis l’interface [il clique sur le bouton de commande avec trois petits points sur le logiciel et sélectionne dans le menu déroulant la commande redeploy]. Ce qui fait que je n’ai pas besoin de relancer l’ensemble des commandes directement depuis la CNI, je peux le faire directement dans l’interface et c’est un gain incroyable pour mettre à jour ces applications.

On voit directement les différentes informations qui sont faites à travers l’interface [il descend sur la page dans le menu déroulant ouvert appelé pods, déroule le menu events] et en plus de ça on a le suivi d’événement et de déploiement de son application. Donc il y a du log d’intégré et ça c’est top. Maintenant, on a de nouveau l’application avec le green et le blue [retour sur le site de l’application, il clique sur refresh et la fin de la phrase passe par interval du green au blue]. C’est ce qu’on disait, ce n’est pas le comportement qu’on veut. Donc il faut savoir que dans Kubernetes [il retourne sur Rancher, clique sur l’onglet ressources, puis sur workload et sur l’application demo-nginx-green], en plus des objets, il y a aussi ce qu’on appelle des labels.

Les labels dans Kubernetes, identifier et connecter les ressources entre elles

VB : [il descend sur la page jusqu’au menu déroulant Labels & Annotations] Ces labels sont importants pour identifier les ressources et les connecter ensemble. C’est grâce à ces labels qu’on va pouvoir orienter correctement les différentes ressources. Alors je ne sais pas du tout s’il y a des questions.

YGC : Pour l’instant, notre public est tellement attentif et captivé par l’aventure qu’il reste silencieux et coi.

VB : Comme je le disais, l’interface de Rancher nous permet d’avoir toutes les informations et là on se rend compte qu’il y a la version intégrée dans les labels. [dans le menu déroulant Labels & Annotations il surligne en surbrillance la version qui indique green]Alors les labels, c’est vraiment une étiquette : c’est “je mets une information sur quelque chose”. Là je mets une information sur mon déploiement et donc du coup sur mes pods.

Donc, que fait-on ?[il retourne sur l’onglet ressources et clique sur workload et ensuite sur service discovery] On va aller voir mon service, sur quoi il s’appuie, pour avoir les informations et mettre en relation avec le load balancer. Et là on voit que la clé sur laquelle il va se caler pour récupérer l’information, c’est uniquement le sélecteur application = web server [il surligne en surbrillance dans la partie cible le texte application = webserver].

Donc on fait des allers retours [il retourne sur la partie workload], mais on aime ça, on aime bien jouer avec Kubernetes ! On n’hésite pas à faire des allers retours. On peut retourner ici dans les labels[retour sur la liste de menus déroulants dans l’onglet workload, il déroule le menu Labels] et on voit qu’effectivement la clé app web server existe dans ce déploiement [il surligne en surbrillance dans le menu Labels web server dans la colonne valeur], le green. Et si je vais voir dans mon develop engine nginx blue, je vois également que ma clé app web server existe [il clique dans workload sur l’appli démo nginx-blue et descend dans le menu labels également]. C’est pour ça qu’en fait lorsque je refresh ici et que je mets à jour l’application [il retourne sur le site de l’application et clique sur refresh et le mot change une fois sur deux de green à blue], une fois je suis sur green, une fois je suis sur blue, une fois sur green, une autre fois sur green, une fois sur blue. Donc là il y a du load balancing qui se crée, il y a 6 pods soit potentiellement 6 serveurs qui me répondent ; et ça, ce n’est pas le comportement qu’on voulait…

Exemple : l’application green et blue sont lancées en même temps, comment faire ?

VB : Là typiquement, en tant que développeur, on peut se dire, “mince j’ai déployé mes deux applications ensemble, comment est-ce que je peux gérer ce cas là ?” C’est tout simple, on peut aller dans son service [il clique dans Rancher sur l’onglet service discovery puis l’édite en cliquant sur un bouton en haut à droite avec trois petits points. Il arrive sur la rubrique éditer l’enregistrement de la démo blue green], l’éditer directement depuis l’interface, ajouter un nouveau sélecteur [dans la partie sélecteur, en face de version = il tape blue dans la colonne valeur et clique sur enregistrer], se dire “je veux la version uniquement blue”, l’enregistrer et la magie de Kubernetes fait que le load balancer est bien connecté avec le blue et maintenant je peux refresh autant que je veux je serai uniquement sur l’application blue[de retour sur la page du site il clique sur refresh et le texte reste blue].

Ouf ! L’application fonctionne sur la première version, maintenant je peux déployer ma nouvelle version. [il retourne sur Rancher et dans la partie éditer, accessible par le bouton avec trois points en haut à droite]. Si on sait utiliser uniquement un sélecteur pour avoir une version de l’application bleue, on peut utiliser également le sélecteur pour avoir la version green[Cette fois-ci il tape green en face de version = dans la colonne valeur].

C’est là où Kubernetes et Rancher sont intéressants, parce que si je retourne dans les workload ici, je pourrais aller directement sur Grafana mais on va se contenter des logs, enfin des éléments qu’on a ici [il re-clique sur l’application bleu et descend dans le menu déroulant des métriques].

Je peux avoir les métriques de mon application en fonctionnement avec la partie blue, donc c’est intéressant de se dire, “tiens, je vois que le fonctionnement de l’application blue est comme ça.” [trois graphiques apparaissent : utilisation CPU, utilisation de la mémoire et I/O du disque. Il filtre la durée des statistiques en sélectionnant 5 minutes dans le menu déroulant]. Donc là si je refresh un peu ça créé du trafic [il retourne sur le site de l’application et clique plusieurs fois sur refresh]. Quand je vais vouloir passer sur la version green [de retour sur Rancher il clique sur workload puis sur l’application démo green], il suffit d’aller dans le service discovery, d’éditer ma version en green [il clique sur l’onglet service discovery puis retourne dans la partie éditer pour l’application green et tape dans la partie sélecteur green en face de version = dans la colonne valeur], et c’est pareil quand je refresh [il retourne sur le site de l’application et clique plusieurs fois sur refresh]. Bon, le load balancer doit faire l’aménagement avant, et hop ! Évidemment, on pourrait demander à ce que ce soit de l’instantané mais Kubernetes a quand même un petit temps, il y a des routines qui tournent pour que ça se mette à jour. Finalement, on est sur l’application green et ça fonctionne.

L’avantage c’est que maintenant dans le workload [sur Rancher il reclique sur l’onglet workload], je peux consulter l’évolution de mon application avec les métriques qui lui sont dédiées et vérifier que j’ai le même comportement qu’avant tout simplement[il descend sur la page jusqu’au menu déroulant des métriques].

Voilà, l’idée c’était de vous montrer que je pouvais utiliser la ligne de commande Kubernetes pour lancer mes applications. Je l’ai fait ici [il retourne sur la ligne de commande avec Kubectl], à l’ancienne, j’ai créé mes manifestes ; d’ailleurs je suis sur mon dépôt Git donc comme ça j’ai une version de mes applications. Je l’ai lancée à l’ancienne et je la vois directement dans Rancher. De ce fait, dans mon application Rancher [retour sur Rancher dans la partie workload], je peux voir les différentes évolutions de comportement de mes applications. Si je veux, parce que je vois qu’il y a vraiment une augmentation de la charge, je peux augmenter le nombre de pods que je veux. Et hop, automatiquement c’est mis à jour, et c’est magique !

YGC : C’est toujours assez impressionnant !

VB : Et évidemment, une fois que j’ai fini, je peux supprimer mon workload directement depuis Rancher [il retourne sur rancher dans la partie workload, sélectionne l’application démo green et descend dans un menu déroulant jusqu’à supprimer], ou le faire directement depuis ma ligne de commande Kubernetes comme habituellement. C’est à dire que si je vais ici [il retourne sur le terminal, et dans la partie du code “terminal” tape la commande delete – f green/]: Kubectl, delete f green, tout ce qu’il y a dans mon dossier green, je vois que ça a été instantané parce que je n’ai même pas eu le temps de retourner sur l’interface [il retourne sur Rancher et l’application green a déjà disparue], mais mon déploiement est déjà supprimé et mon application ne fonctionne pas [en actualisant le site de l’application le message 503 Service Temporarily Unavailable apparaît] ce qui est normal ! Il ne faut pas oublier que le service discovery se base sur une version et donc là c’est pareil, je peux facilement revenir en arrière et supprimer un label entier [sur Rancher, il sélectionne l’application démo blue clique sur éditer et supprimer un label dans le sélecteur].

Donc, c’était la petite démo de Rancher. L’idée de la nouvelle version de l’outil Kubernetes, chez Empreinte Digitale, c’est de donner un peu plus de liberté et de visibilité sur l’application et la possibilité de voir comment évolue son application auprès des développeurs.

YGC : Merci Valentin pour cette démonstration de haut vol, en live ! En plus, ça s’est très bien passé donc chapeau ! Profitez-en pour poser des questions, on est là pour ça. Ce serait avec plaisir, s’il y en a d’autres qui vous viennent plus tard n’hésitez pas à nous envoyer un mail.

Tester gratuitement Kubernetes et le déploiement d’applications automatisé avec Empreinte Digitale

VB : Donc ça c’est la petite surprise on va dire. Vas-y je te laisse en parler Yves.

YGC : On a le plaisir, avec cette nouvelle offre que l’on lance aujourd’hui officiellement, de vous proposer de participer à la bêta de ce nouveau cluster et de ces nouveaux outils. Vous nous envoyez un mail à beta@empreintedigitale.fr et on vous offre 30€ de consommation de ressources Kubernetes pendant toute la durée de la bêta. N’hésitez pas, envoyez-nous des mails on vous donnera accès à l’interface et vous pourrez tester avec vos propres applications notre plateforme. Et nous aider à vérifier s’il arrive à résister à la charge et être robuste.

VB : Et en plus de ça, si vous avez des questions il ne faut pas hésiter à nous solliciter.

YGC : Vous pouvez envoyer sur beta@empreintedigitale.fr une question.

VB : Sachant qu’au fur et à mesure des communications qui ont été faites par Eulalie, il y a aussi nos contacts personnels. Eulalie, c’est notre responsable communication chez Empreinte Digitale qui a mené cette campagne de teasing d’une main de fer ! Il y a nos contacts personnels, si vous souhaitez entrer en contact avec nous n’hésitez pas !

Remerciements

YGC : On espère que ça vous a plu !

VB : J’espère aussi !

YGC : Valentin a beaucoup travaillé pour cette présentation, sûrement beaucoup plus que moi en tout cas ! Bravo Valentin !

VB : Ah tu veux applaudir ? On peut applaudir !

YGC : Merci à tous ceux qui sont venus nous voir sur ce stream. Le premier d’une longue série !

VB : On essaiera sûrement d’en refaire d’autres ! D’ailleurs, si vous avez des idées de sujets, je ne sais pas s’il y a encore du monde dans le chat mais si vous avez des idées de choses que vous aimeriez aborder, liées à Kubernetes, j’en serais ravi parce que c’est quelque chose qui me passionne. Mais si c’est d’autres choses il ne faut pas hésiter ! Sur du Ceph…

YGC : Sur de la machine virtuelle, sur de la micro VM ou autre…

VB : Plus ou moins technique aussi. On a parlé de CI/CD donc de Continuous Innovation et Continuous Deployment mais on l’a vaguement évoqué. Se dire tiens, est-ce que vous avez des retours d’expérience, on en avait parlé au workshop qu’on avait fait en local ici. Mais si il y a des besoins ou des envies, d’avoir plus d’informations la-dessus, on peut en parler de nouveau en stream !

YGC : Ce serait avec plaisir ! On sera rodés la prochaine fois !

VB : C’est ça [rire]

YGC : Merci en tout cas de votre patience et de votre attention.

VB : Exactement, merci à tous et bonne soirée !

YGC : Bonne soirée !