cloud on Zwindler's Reflection

REX : Mon parcours vers le titre de Kubestronaut

Sun, 18 Jan 2026 12:00:00 +0200

Introduction

J’avais un peu annoncé la couleur lors de mon précédent post “À quoi ça sert, des certifs en 2025 ?”.

J’ai passé, avec succès, les 5 certifications “officielles” de la CNCF / de Kubernetes, ce qui devrait me donner (pour l’instant ça n’est pas officiel, a priori ce n’est pas immédiat) le titre tant convoité (ou non ?) de Kubestronaut.

Et comme c’est un side project sur le long cours (j’ai commencé en 2025 le parcours complet), je vous propose un petit REX de comment je l’ai vécu.

Note : pas mal de gens ont déjà raconté leur expérience, et il y a déjà de supers articles de la communauté Cloud Native FR. Je vais essayer de ne pas trop faire de redite et je vous ai mis plein de liens en fin d’article vers d’autres ressources similaires en français.

C’est quoi ces certifs déjà ??

Les 5 certifications officielles Kubernetes de la CNCF sont :

KCNA (Kubernetes and Cloud Native Associate) : certification d’entrée de gamme qui valide les concepts de base de Kubernetes et du cloud native
KCSA (Kubernetes and Cloud Native Security Associate) : certification d’entrée de gamme focalisée sur les concepts de sécurité dans Kubernetes
CKA (Certified Kubernetes Administrator) : certification pratique qui valide les compétences d’administration d’un cluster Kubernetes
CKAD (Certified Kubernetes Application Developer) : certification pratique qui valide les compétences de développement d’applications sur Kubernetes
CKS (Certified Kubernetes Security Specialist) : certification pratique avancée qui valide les compétences en sécurisation d’un cluster Kubernetes (prérequis : CKA)

Pourquoi Kubestronaut ??

D’abord, pour ceux qui ne me connaissent pas, je suis expert de Kubernetes depuis 2017/2018, donc j’aurais pu avoir ces certifs, ou au minimum un sous-ensemble de ces 5 certifs depuis longtemps. Mais ayant toujours travaillé chez des clients finaux (donc pas de consulting, que ce soit en freelance ou en ESN, où avoir un papier peut apporter un peu de légitimité complémentaire pour décrocher un client), je n’en ai jamais ressenti le besoin.

Je ne vais pas mentir et dire que je n’avais pas du tout ENVIE de les avoir. C’est toujours agréable de se dire qu’on a la CNCF qui a validé officiellement qu’on sait de quoi on parle (même si en vrai, les compétences validées sont discutables. On en reparlera). Mais le tarif prohibitif (en tout cas si j’avais dû les payer de ma poche) m’avait toujours rebuté.

La moula

Car OUI, ça coûte bonbon (pour rester poli).

Comptez 445$ l’unité pour les CKA, CKAD, CKS
250$ l’unité pour les KCNA / KCSA

How will the CKA benefit me?

Credential Recognition

Career Advancement

Networking Opportunities

Cross-industry Career Opportunities

Source : https://training.linuxfoundation.org

C’est bien gentil mais ça fait quand même plus de 1500€. Heureusement, on peut compter sur les promos très régulièrement et des prix de gros via des bundles pour diminuer la douloureuse.

Le but du jeu est de trouver la meilleure combinaison Bundle + promo pour économiser le plus, et a priori à présent, le mieux que j’ai trouvé est d’acheter pendant la “Cyber Monday week” (-50/-60% selon les bundles), et d’acheter séparément le bundle KCNA+KCSA à -60% et CKA+CKAD+CKS également à -60% (le bundle avec les 5 est moins intéressant car plafonné à -50%)

Ce qui fait au total un peu plus de 600€ (tout de même).

À partir de là, vous avez 1 an pour passer les 5 certifs (mais vous pouvez le faire en 2 fois. C’est ce que j’ai fait en prenant les CKx fin 2024, les KCxA en 2025).

Note : mon employeur m’a payé les CKx, dans l’idée de motiver des juniors à passer sérieusement ces certifs. Sans cela, je ne l’aurais probablement jamais fait.

Déroulé et difficulté

Je ne vais pas présenter les examens dans l’ordre où je les ai passés, mais plutôt dans l’ordre de difficulté dans lequel on les présente d’habitude. Car, a posteriori, je trouve que c’est relativement représentatif, de mon point de vue, de leur difficulté réelle.

KCNA : un QCM de culture générale sur le Cloud Native. Vraiment, payer 250$ pour ça, c’est du vol. C’est vraiment tout ce que je déteste dans les certifs (dont je parlais dans l’article sur les certifications techniques). Sur les 60 questions, il n’y a toujours qu’une bonne réponse et on peut “deviner” les 3/4 juste en éliminant les mauvaises réponses, souvent ridicules. Pour moi, la KCNA n’a aucune valeur technique. J’ai fait 97%, ce qui correspond à 2 erreurs sur 60, probablement des questions ambiguës ou des mauvaises réponses où j’ai cherché “trop compliqué” (la réponse la plus simple est la bonne, il faut ignorer les edges cases que seuls les experts peuvent connaître). Je l’ai terminé en 30 minutes au lieu des 90.

KCSA : un QCM un poil plus corsé. J’y suis allé là aussi sans préparation, et j’ai fait un score honnête (93%, 4 fautes). Certaines questions m’ont donné plus de fil à retordre. Il y a une ou deux questions sur le “NIST SP 800-161 Rev. 1” que je ne connaissais pas, et 4-5 questions sur lesquelles je voyais 2 réponses “moyennes” plausibles, sans pour autant parvenir à les départager parce qu’à mon avis pas 100% exactes. Ça peut être un problème de compréhension de l’anglais de ma part, ou juste que je ne suis pas aussi bon que je le pense. 93, ça reste très honnête, sachant qu’on a droit à 15 fautes. Je l’ai terminé en 50 minutes car j’ai passé beaucoup de temps à réfléchir sur ces fameuses questions que je trouvais ambiguës.

CKAD : une des deux certifications historiques. Être Certified Kubernetes Application Developer fait de vous quelqu’un capable de “concevoir, construire et déployer des applications cloud native”. Ce qu’il y a de bien avec les CKx, c’est que ce sont des examens pratiques. On a une liste de ~17 tâches simples à réaliser en 2h sur des machines virtuelles. Si vous y arrivez, ça veut dire que vous êtes capables techniquement de réaliser de vraies tâches sur de vrais clusters, pas juste que vous avez bachoté. L’inconvénient, c’est que les tâches à réaliser sont extrêmement lointaines de la réalité des tâches qu’on doit faire : créer des manifestes YAML de deployments et de services Kubernetes à la main. Personne ne fait ça (enfin, j’espère ?). En termes de difficulté, j’ai peut-être eu de la chance, mais je l’ai trouvée triviale. Je l’ai terminée en 1h au lieu de 2 et j’ai eu quasiment 100%.

CKA : l’autre certification historique. Là aussi, 17 exercices pour manipuler des applications dans Kubernetes et aussi jouer un peu avec les composants du control plane (notamment l’api-server et etcd). Petit accident de parcours ici, j’ai bien réussi les simulateurs (on en reparlera) et pour autant, je n’ai pas réussi entièrement à finir au bout des 2h et j’ai eu un score assez médiocre (71%). Au-delà des connaissances précédentes nécessaires pour la CKAD, il faut avoir une très bonne connaissance des clusters créés avec kubeadm puisque vous allez manipuler et modifier 17 clusters créés de cette manière.

CKS : la dernière certification pratique (en dehors des QCM), mais avec un focus sur la sécurité par rapport à la CKA / CKAD. Celle-ci a réellement de la valeur selon moi. Elle est à la fois complexe, avec un panel assez large d’aspects à maîtriser, et surtout utile, car elle couvre des sujets réalistes en termes de sécurité, quel que soit le cluster. Contrairement à la CKA / CKAD, on repart vraiment avec des compétences qu’on imagine utiliser en production dans un scénario plus réaliste que les clusters kubeadm fournis.

Aparté : PSI proctored exam

Vraiment un des trucs que je déteste le plus avec ces certifications. Contrairement à d’autres certifications tech qui peuvent être passées soit à la maison sous surveillance, soit dans une salle gérée par un organisme spécialisé, les certifs CNCF ne peuvent être passées QUE à distance via “proctored exam”.

N’ayons pas peur des mots, l’expérience est désastreuse. Je ne compte pas les retours que j’ai pu avoir de gens qui ont perdu un “try” à cause de bugs du logiciel ou autre problème technique. À titre perso, j’ai dû tester plusieurs machines pour en trouver une qui fonctionnait avec leur bouse de “navigateur sécurisé”. Et encore, parce que je m’y suis pris suffisamment à l’avance et que j’ai fait le test.

Ça, plus le fait d’avoir à sa disposition une pièce fermée, sans papiers/affiches, sans caméras, sans écrans, dont il va falloir faire le tour en balayant de bas en haut à 360° pour prouver à l’examinateur que “non, c’est bon on ne va pas tricher”.

Il serait tellement plus simple d’avoir des centres d’examen partenaires, mais non, la LF maintient que “c’est pour notre bien”. Moi, j’ai dû passer les 5 examens dans la chambre de mon fils, sur une planche et 2 tréteaux, car c’était la seule pièce qui convenait. J’ai lu des gens qui le font dans leurs WC… Quel enfer.

Aparté : killer.sh

C’est un peu caché, mais tous les examens CKA/CKAD/CKS donnent l’accès à 2 examens blancs sur le site killer.sh. Vraiment, je ne peux QUE vous conseiller de les faire, car ils sont très utiles.

D’une part, ils sont selon les cas similaires en termes de difficulté, voire beaucoup plus durs. Si vous avez une bonne note sur killer.sh, il y a de grandes chances que vous ayez votre CKA/AD/S.

Et comme il y a 2 runs, vous pouvez commencer par tester un run, voir ce que vous avez fait faux (vous avez la plateforme de chaque run pendant 36h, ça laisse le temps de tryhard pour obtenir 100%) et savoir quoi réviser par la suite. Une fois que vous êtes confiants, vous pouvez faire le 2ème run et valider que vous pouvez lancer le vrai examen.

Si jamais vous n’avez pas assez de “runs”, vous pouvez toujours chercher d’autres simulateurs, comme sailor-sh/CK-X. Pour ce qui est des KCNA/KCSA, il y a aussi pas mal de quiz qui ont été générés à la volée à l’aide de LLM mais ils sont rarement qualitatifs et les questions sont très éloignées, ainsi que des sites “pirates” avec des questions authentiques. À vous de voir ce que vous en pensez.

Ce que je savais déjà vs ce j’ai appris

KCNA / KCSA : Je n’ai rien appris. Ce sont des QCMs basiques, qui n’ont aucun intérêt et ne démontrent aucune compétence sur un CV.

CKAD : Je n’ai pas appris grand-chose, à part quelques sous-commandes kubectl permettant de gagner du temps, comme kubectl expose, ou quelques détails sur la façon dont sont gérés les cycles de vie des API de Kubernetes. Comme une grosse partie de l’examen consiste à générer des manifestes YAML pour les différentes API de Kubernetes, il est important de connaître toutes les sous-commandes de kubectl create et aussi savoir quand c’est plus rapide d’aller faire une recherche d’un manifeste prêt à l’emploi sur la doc officielle, et le copier/coller.

CKA : En plus des recommandations précédentes, il y a quelques astuces à avoir (que je connaissais déjà), comme ne pas oublier de sauvegarder dans un autre dossier tous les manifestes statiques présents dans /etc/kubernetes/manifests/ car il est facile de flinguer le cluster et perdre tous les points de la question. Il faut aussi savoir rapidement retrouver où sont stockés les logs des conteneurs avec containerd pour débuguer quand l’API server est KO, ne pas hésiter à redémarrer le kubelet pour gagner du temps en cas de crashloop backoff, savoir manipuler les données dans etcd avec etcdctl. Là encore, je suis vraiment sceptique sur l’intérêt au quotidien, sauf à gérer en prod des clusters créés avec kubeadm (ce que je ne fais plus depuis bien longtemps).

CKS : Il y a pas mal d’avis divergents sur l’intérêt de la CKS parmi ceux qui l’ont passée. Tout le monde est unanime pour dire qu’elle est dure (c’est vrai). C’est la plus exigeante, j’ai sué à grosses gouttes en la passant, et j’ai dû faire quelques révisions sur une partie des sujets que je ne connaissais pas. C’est aussi la seule où j’ai vraiment l’impression d’avoir appris des trucs utiles (chiffrement etcd, révisions/découvertes apparmor/seccomp). Un des points mis en avant comme négatif est qu’elle oblige à connaître un minimum des choses sur des projets tiers comme falco / trivy / cilium / istio, ce qui sort du cadre strict de Kubernetes et drift sur d’autres projets (qui ont leur propre certifs, d’ailleurs). À titre perso, je n’ai pas trouvé ça “choquant”, mais je comprends la gêne pour une certif officielle Kubernetes.

Conclusion / est-ce que je le referai ?

Ça dépend de la question. Je ne suis pas “CNCF ambassador” alors je ne vais pas me gêner pour dire ce que j’en pense.

Si c’est les KCNA/KCSA, c’est un grand NON. Elles ne servent strictement à rien.

Si la question c’est “est-ce que je repasserai les certifs CKx quand elles expireront”, c’est quasiment sûr que non.

Sauf à passer freelance / bosser dans une ESN (c’est pas du tout prévu) et que ça me soit utile (ça reste à prouver, à mon avis mon CV a plus de valeur), je ne vois pas d’avantage à les repasser, que des inconvénients. Franchement l’expérience “proctored exam” était trop pénible, et les KCNA/KCSA n’ont aucune valeur à mes yeux.

Si jamais c’est un exercice de pensée en mode “imaginons, on revient en 2024, est-ce que tu le refais”, la réponse est probablement “oui”, sous condition.

Je l’ai dit plus haut, c’est mon employeur qui m’a payé les certifs CKx, avec dans l’idée que moi “le vieux”, motive un peu les “jeunes” à qui les certifs étaient aussi payées, à les passer.

Et ça, c’était vraiment rigolo : le faire en groupe et “se tirer la bourre”. Ça a plutôt bien marché d’ailleurs, j’ai passé chaque certif en premier, mais ils ont fait de meilleurs scores que moi, au final (moi ça me fait rigoler, eux sont contents d’avoir mouché le “vieux”).

Donc entre le coût pris en charge d’un côté, et le côté collaboration / faire grandir l’équipe, ça valait le coût (jeu de mots, humour, haha).

Autres ressources

Si vous voulez aller plus loin, voici d’autres retours d’expérience et ressources utiles de la communauté française :

Comment bien foirer vos certifications Kubernetes CK{A,S} - Rémi Tech Notes
Notes de certification KCSA - Joseph Ligier
Tips & Tricks — Kubernetes Certifications “CKA — CKAD — CKS” - Jérôme Masson (Sphinxgaia)
Guide pour réussir l’examen de certification CKA
Certifications Kubernetes : CKA et CKAD - Mossroy
CK-X - simulateur des certifications Kubernetes - sailor-sh

Un an dans le nua.ge

Thu, 06 Oct 2022 22:00:00 +0200

C’est l’histoire d’un cloud

Vous vous en souvenez peut-être ?

L’an dernier, en novembre, un certain nombre de comptes techs twitter recevaient une box contenant des codes pour tester un tout nouveau fournisseur cloud, fièrement Français, du nom de nua.ge.

J’avais été un peu surpris de recevoir, quelques mois plus tôt, un message de la part d’Iris, pour me demander si je voulais bien tester avec quelques autres “happy few” ce tout nouveau service cloud.

Pour la petite histoire, c’était la toute première fois qu’on me proposait ce genre de choses. C’était aussi la toute première fois où je me suis fait qualifier “d’influenceuse tech”. Amusant.

J’ai attendu un peu (1 an) avant de faire un retour.

Buzz, ou bad buzz ?

Pourquoi attendre pour ce retour ?

D’abord, parce que beaucoup d’autres ont dégainé plus tôt. Je vous ai mis les liens, en fin d’article, de tous les articles de mes pairs que j’ai retrouvés sur le sujet.

Ensuite parce que je voulais voir dans quelle direction le service allait aller.

Beaucoup ont reproché à nua.ge (à l’époque) d’être un peu “pauvre” en fonctionnalités, surtout par rapport à son positionnement tarifaire. A priori ce n’est pas forcément vrai, nuage se situe plutôt dans la moyenne (cf l’étude de coud Mercato).

La société qui opère nua.ge Oxeva avait répondu à cette critique en disant qu’une roadmap était en cours d’élaboration et que les points les plus bloquants seraient rapidement adressés.

Premiers pas avec l’interface

La première chose que j’ai remarqué est que l’interface était effectivement assez simple. Le site web vante d’ailleurs un service “simple mais pas simpliste”.

L’onboarding était hyper efficace (un des meilleurs que j’ai vu). La page de création d’une nouvelle VM aussi.

On a globalement cinq menus:

un menu “espace de travail” dans lequel on a les machines du projet courant
un pour gérer ces fameux projets (en créer un nouveau, le supprimer)
un pour créer des utilisateurs (nouveau)
un pour le suivi de la consommation
un pour la facturation

Les deux derniers auraient pu être fusionnés je pense, je me trompe toujours et je les inverse…

A quelques détails près, c’est tout.

Alors qu’en est il, 11 mois après ?

Je vais être franc, j’ai eu à ma disposition 10000€ de crédit.

De quoi tester allègrement toutes les fonctionnalités et même héberger pas mal de trucs pendant un bon moment.

Au niveau de la stabilité du service, je n’ai rien à redire.

Au cours des 12 derniers mois, le service a subi de brèves coupures réseau (et encore, c’est surtout les autres utilisateurs qui l’ont remonté). Mon monitoring externe n’a pas repéré grand-chose.

Au niveau infrastructure, ça semble donc être du solide.

Cependant, au niveau fonctionnalités, je vais être obligé d’être d’accord avec mes pairs. Même 11 mois après, on a vite fait le tour… On a des VMs, des projets… et c’est tout.

Des défauts corrigés

La roadmap publique a été mise en ligne et il est possible de voter pour des fonctionnalités.

Ca avait été promis quasiment depuis le lancement : l’API publique et documentée a rapidement été mise en ligne et est disponible ici.

Au fil des mois, l’interface a elle aussi été améliorée. Possibilité de transférer des IPs publiques d’une machine à l’autre, ajout de disques plus gros pour les machines (500 Go si nécessaire au lieu de 100 par défaut).

Il est également possible d’avoir une gestion des utilisateurs avec une gestion des droits basique par projet que j’utilise beaucoup.

La gestion des groupes de sécurité (firewalling / flux réseau) ont été grandement améliorés. Au début on avait le choix qu’avec traffic web et traffic SSH, il y a maintenant plus d’options.

Mais d’autres toujours bien présents

Certains des points remontés dès le début sont malheureusement toujours absents. Stéphane Bortzmeyer avait reproché à nua.ge son absence d’IPv6, c’est toujours le cas. Je l’avais également remonté via le “chat”.

Le provider terraform (ou tout autre outil d’infrastructure as code) se fait toujours attendre. On a l’API mais c’est très “manuel”.

[Edit]Il existe un provider non officiel github.com/MKCG/terraform-provider-nuage. Son créateur m’a contacté pour me l’indiquer, ainsi que le fait qu’il n’avait pas l’intention de le maintenir. Cependant, comme il est open source, n’importe qui pourrait potentiellement le faire.

Plus grave, l’interface a plein de petites limitations très agaçantes (rarement, on peut les contourner par l’API).

Les projets

Il ne semble pas possible de modifier un projet existant. On doit le supprimer (et tout ce qu’il y a dedans) et en refaire un nouveau.

Toujours en parlant des projets, ils ont des quotas, fixés par défaut à 40 coeurs, 256 Go de RAM, 2 To de stockage et 20 IP publiques.

Je trouve cette fonctionnalité très utile ! Cependant, quel intérêt de les afficher dans l’UI au moment de la création du projet, s’il n’est possible de les modifier ? Les quotas sont donc immuables, à la hausse (admettons) comme à la baisse !

Les VMs

Encore plus grave, il n’est pas possible de modifier une machine virtuelle.

Dans l’interface, les seules actions possibles sont : allumer, éteindre, redémarrer. Impossible de changer sa taille en cours de route, même éteinte. Il faut la détruire et en refaire une autre. Vous avez intérêt à bien prévoir votre capacity planning…

J’ai dû réinstaller entièrement des serveurs elasticsearch trop gros à cause de ça et j’ai bien ragé. Je suis toujours en colère, je crois.

On aurait pu contourner le problème en ré-attachant les disques, sauf qu’ils ne sont pas détachables. Un disque appartient à une VM, point. Il est créé avec, détruit avec.

Cerise sur le gâteau, ça veut dire que ça compliquera aussi la réversibilité (pourtant un point capital dans le cloud…).

Enfin, c’est plus une problématique de poweruser / bidouilleur, mais il n’est pas possible de donner un nom “long” à une machine (mavm.example.org). C’est gênant, parce que la VM est ensuite déployée à l’aide de templates cloud-init et il est non trivial de changer le hostname en FQDN de manière pérenne.

En partie à cause de ça, j’ai été incapable d’installer Proxmox VE au dessus d’une installation Debian 11 fraîche (alors que j’avais réussi sur le IaaS de Scaleway).

Il manque pas mal de modules dans les Ubuntu 22.04 donc dès que j’en bootstrap une, je lance

sudo apt update && sudo apt upgrade -y && sudo apt install curl linux-image-generic-hwe-22.04 -y && sudo reboot

Conclusion

Ca fonctionne et j’en ai abondamment profité.

J’utilise nua.ge depuis quasiment 1 an pour héberger des serveurs pour plusieurs associations auxquelles je participe, et je ne peux pas dire que je suis insatisfait du service rendu pour ces besoins basiques.

Oui, une bonne partie des promesses initiales sont là : l’interface est hyper simple, le billing est limpide, l’infra semble solide.

Cependant, si je n’avais pas mes crédits gratuits, est ce que j’aurais choisi nua.ge pour héberger ces associations ?

Car une fois l’enthousiasme des milliers d’euros de coupons et du parrainage retombés, il ne restera plus que les clients payant leurs factures.

Cette punchline de David Legrand résonne toujours…

Sources additionnelles

Et si on testait le Clever Operator pour Kubernetes ?

Tue, 17 May 2022 10:00:00 +0000

Clever Operator

Il y a quelques mois, je suis tombé sur cet article de Clever Cloud qui disait avoir annonçait la sortie de l’Operator pour Kubernetes.

Nous avons commencé à travailler sur le Clever Operator suite aux retours de certains de nos clients utilisant k8s ou Openshift qui n’étaient pas vraiment satisfaits des solutions de gestion de base de données fournies par ces plateformes.

C’est pas un secret, j’ai beaucoup râlé sur les gens qui disent que Kubernetes c’est compliqué et/ou que ça apporte plus de problèmes que ça n’en résout (cf https://blog.zwindler.fr/2019/09/03/concerning-kubernetes-combien-de-problemes-ces-stacks-ont-generes/). On en a notamment parle avec Quentin ADAM ;-).

Mais ce que je ne disais pas clairement à cette époque, c’est que Kubernetes, c’est quand même plus simple quand il s’agit d’autonomiser les devs sur des workloads stateless.

Ou alors du stateful, mais pas trop violent : genre stockage de fichiers (Prometheus par exemple), voire fichiers partagés (avec un FS distribué, partagé entre plusieurs apps ou instances d’une même app).

Par contre, les bases de données, là, on rigole tout de suite beaucoup moins…

Attention, je ne dis pas que c’est impossible. Plein de gens le font, en prod (moi compris). Mais c’est tout de suite un autre niveau de complexité, car il faut gérer le cycle de vie de la base de données, les mises à jours, les pertes de noeuds proprement, etc.

Pour faciliter ça, il existe les “Opérateurs” dans Kubernetes, qui ont pour but d’ajouter toute une logique fonctionnelle pour gérer ça (comme celui pour MongoDB dont je parle dans cet article), mais c’est pas encore parfait.

Ajoutez à cela le fait que DBA, c’est un job “à part”, avec des compétences bien spécifiques et qui nécessite vraiment de savoir ce qu’on fait.

Du coup… j’aurais pu dire (en moins classe) :

Les DBs dans Kube, c’est ch**nt. Ca serait cool si quelqu’un dont c’est l’expertise pouvait gérer ça pour moi, en dehors de Kube.

Qui a dit “Clever Cloud” ?

Clever Operator

Ok, admettons qu’on ait un Kubernetes fonctionnel. On va plugger Clever Cloud dessus pour voir ce qu’on peut faire. Le billet sur le blog de Clever indique 2 manières de déployer l’operator (plot twist, il y en a une 3ème qui est mieux).

La première consiste à utiliser operatorhub.io, un site communautaire pour partager des opérateurs Kubernetes.

Pour utiliser cette méthode, il faut déployer le operator-lifecycle-manager, lui-même un opérateur, dans notre kubernetes. J’ai essayé et j’ai plein de critiques à faire sur ce tool.

Déjà, la doc nous demande de faire un curl | bash (déjà une hérésie en soit), ensuite, il se déploie sans prévenir sur mon contexte Kubernetes par défaut. Enfin, c’est pas bien clair ce qu’il faut faire pour le customiser (notamment pour ajouter nos credentials).

J’ai essayé 1h, j’ai laissé tomber, mais si vous avez l’habitude d’utiliser Operatorhub.io vous aurez peut être des infos que je n’ai pas.

La seconde méthode proposée est de déployer (ou de builder) soit même le container Docker dans notre cluster Kubernetes.

Vous pouvez le built à partir du code source sur Github ou utiliser notre image docker sur Docker Hub. Puis, configurez le. Ça se résume à paramétrer les variables d’environnement CLEVER_OPERATOR_*. Par exemple, vous devez créer un token pour vous connecter à l’API.

Je suis un poil sceptique sur le “ça se résume à” 😏.

Quand on va voir le code du clever operator (ici), on se rend tout de suite compte qu’il va falloir déployer beaucoup de ressources Kube et pas juste un container (~650 lignes de YAML).

En même temps c’est logique, il y a le fichier du Deployment, des Roles, plusieurs définitions de CRDs, bref…

DIY

Edit du 24/05 : depuis la rédaction de l’article, j’ai proposé une PR à Florentin (le dev de la feature chez Clever) pour ajouter une Helm Chart. Le principe est le même, on va devoir renseigner des valeurs dans values.yaml donc vous pouvez quand même dérouler l’article.

cd deployments/kubernetes/helm
helm install clever-operator -n clever-operator --create-namespace -f values.yaml .

Du coup, j’ai déjà spoilé la solution (qui est d’ailleurs mise en avant dans le README.md du dépot Github.com). On va déployer le YAML à la main.

On installe les CRDs :

kubectl apply -f https://raw.githubusercontent.com/CleverCloud/clever-operator/main/deployments/kubernetes/v1.21.0/10-custom-resource-definition.yaml
customresourcedefinition.apiextensions.k8s.io/postgresqls.api.clever-cloud.com configured
customresourcedefinition.apiextensions.k8s.io/redis.api.clever-cloud.com configured
customresourcedefinition.apiextensions.k8s.io/mysqls.api.clever-cloud.com configured
customresourcedefinition.apiextensions.k8s.io/mongodbs.api.clever-cloud.com configured
customresourcedefinition.apiextensions.k8s.io/pulsars.api.clever-cloud.com configured
customresourcedefinition.apiextensions.k8s.io/configproviders.api.clever-cloud.com configured
customresourcedefinition.apiextensions.k8s.io/elasticsearches.api.clever-cloud.com configured

kubectl api-resources --api-group=api.clever-cloud.com
 NAME SHORTNAMES APIVERSION NAMESPACED KIND
 mongodbs mo api.clever-cloud.com/v1 true MongoDb
 mysqls my api.clever-cloud.com/v1 true MySql
 postgresqls pg api.clever-cloud.com/v1 true PostgreSql
 pulsars pulse,pul api.clever-cloud.com/v1beta1 true Pulsar
 redis r api.clever-cloud.com/v1 true Redis

Si je peux me permettre ce commentaire, je trouve ça audacieux, ces shortnames 😱… Attention aux collisions avec d’autres CRDs 🤔.

Et ensuite on récupère et on va modifier le fichier du Deployment

curl -LO https://raw.githubusercontent.com/CleverCloud/clever-operator/main/deployments/kubernetes/v1.21.0/20-deployment.yaml

Préparer la configuration

Bon, à un moment donné, il va bien falloir que je connecte l’API clever cloud avec mon operator, notamment en renseignant les fameuses variables d’environnement CLEVER_OPERATOR_* dont parle l’article.

Si on regarde la tête de notre fichier 20-deployment.yaml, on remarque qu’il existe une ressource ConfigMap prévue pour renseigner les credentials (ligne 100).

---
apiVersion: v1
kind: ConfigMap
metadata:
namespace: clever-operator-system
name: clever-operator-configuration
data:
config.toml: |
[api]
token = ""
secret = ""
consumerKey = ""
consumerSecret = ""

Si vous êtes curieux (c’est mon cas), ce volume est ensuite appelé dans le Deployment

 volumes:
- name: config
configMap:
name: clever-operator-configuration
items:
- key: "config.toml"
path: "config.toml"

Puis monté dans la spec du template de container

 volumeMounts:
- name: config
mountPath: "/etc/clever-operator"
readOnly: true

Note : Idéalement, on voudra éviter de faire ça, dans la vraie vie. Les ConfigMaps (comme les Secrets) dans Kubernetes sont lisibles par beaucoup de monde (la seule différence pour les Secrets, c’est que les chaines de caractères sont base64ifiée. Si si, c’est dans le dico, “base64ifier”) et donc absolument pas adaptés pour la gestion de secrets. On pourrait aussi ajouter ces secrets comme variables d’environnement dans le Deployment (comme proposé dans la méthode 2 par l’article), mais c’est pire (on peut en débattre) encore niveau sécu. Idéalement, il faudra injecter ces valeurs avec un gestionnaire de secret tier, comme Vault par exemple.

Mais où on les trouve, ces valeurs à renseigner ?

Alors je n’avais jamais utilisé Clever Cloud avant, donc ça n’était pas super évident pour moi 😅.

On va d’abord devoir créer une organisation et récupérer son ID (en haut à droite de l’interface). Elle a la forme orga_xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx

Pour la partie consumerKey et consumerSecret, j’ai trouvé avec la documentation officielle. Dans mon organisation côté UI de Clever Cloud, on peut cliquer sur “Create… / an oauth consumer”

Pour la partie token et secret, je n’ai pas trouvé comment en créer un en console web et je n’ai pas trouvé dans la doc.

En bidouillant un peu (monkey testing), j’ai trouvé qu’on pouvait en récupérer en utilisant la CLI de clever cloud

curl -fsSL https://clever-tools.clever-cloud.com/gpg/cc-nexus-deb.public.gpg.key | gpg --dearmor -o /usr/share/keyrings/cc-nexus-deb.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/cc-nexus-deb.gpg] https://nexus.clever-cloud.com/repository/deb stable main" | tee -a /etc/apt/sources.list
sudo apt-get update
sudo apt-get install clever-tools

clever login
Opening https://console.clever-cloud.com/cli-oauth?cli_version=2.9.1&cli_token=... in your browser to log you in…
We're still waiting for the login process (in your browser) to be completed…
Login successful as Denis GERMAIN <...>

Une fenêtre de navigateur s’ouvre pour se loguer et magie magie, on a un token et un secret

CLEVER_TOKEN=aaa
CLEVER_SECRET=aaa

Tadaa !

Deployer l’opérateur

Tout est prêt, allons-y.

On peut apply le manifest et déployer le deployment

kubectl apply -f 20-deployment.yaml
namespace/clever-operator-system created
serviceaccount/clever-operator created
clusterrole.rbac.authorization.k8s.io/system:clever-operator created
clusterrolebinding.rbac.authorization.k8s.io/system:clever-operator created
poddisruptionbudget.policy/clever-operator created
networkpolicy.networking.k8s.io/clever-operator created
configmap/clever-operator-configuration created
deployment.apps/clever-operator created

Note: la dernière version de l’image Docker du Clever Operator a “un bug” du à une version trop ancienne de la GLIBC. Florentin de chez Clever est en discussion avec Redhat pour fix ça (`GLIBC_2.29’ not found).

~~Il “suffit” de prendre une version plus ancienne de l’image et ça remarche, en attendant un fix définitif.~~ (FIXED)

On teste tout ça

Normalement, là on est bons.

Dans la liste des bases (des add-ons dans la terminology Clever Cloud) supportées par ce operator, il y a donc :

ElasticSearch
MongoDb
MySql
PostgreSql
Pulsar
Redis

La documentation des CRDs est disponible ici et elle est bien faite.

Je ferai des tests plus poussés (déployer une vraie application) plus tard, mais déjà pour tester, j’ai pu lancer un mysql managée;

cat mysql.yml
---
apiVersion: api.clever-cloud.com/v1
kind: MySql
metadata:
namespace: default
name: mysql
spec:
organisation: orga_xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx
options:
version: 80
encryption: false
instance:
region: par
plan: dev
kubectl apply -f mysql.yml
mysql.api.clever-cloud.com/mysql created
kubectl get my
NAME AGE
mysql 14s

L’opérateur a également la gentillesse de nous créer un Secret avec les variables de connexion. C’est donc hyper simple de relier notre app à notre nouvelle DB :

kubectl get secret mysql-secrets -o yaml
apiVersion: v1
data:
 MYSQL_ADDON_DB: aaa=
 MYSQL_ADDON_HOST: aaa==
 MYSQL_ADDON_PASSWORD: aaa=
 MYSQL_ADDON_PORT: aaa==
 MYSQL_ADDON_URI: aaa==
 MYSQL_ADDON_USER: aaa==
 MYSQL_ADDON_VERSION: aaa
kind: Secret

kubectl run -it mysqlclient --image mysql /bin/bash
root@mysqlclient:/# mysql aaa --host aaa-mysql.services.clever-cloud.com --user aaa -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
[...]
mysql>

Conclusion

J’ai été très content de tester cet operator, et surtout de pouvoir échanger avec son développeur, Florentin DUBOIS, qui m’a aidé et à qui j’ai pu remonter quelques petits défauts de jeunesse de l’outil.

L’intégration entre Clever et Kubernetes marche vraiment bien, c’est fluide. La documentation des CRDs est bien faite, on est pas perdus. Enfin, la génération à la volée du Secret contenant les informations de connexion directement dans Kubernetes est vraiment une fonctionnalité bien pratique, puisqu’on voudra souvent monter directement les informations qu’il contient dans un Pod du même namespace.

~~De mon point de vue, il manque une Chart Helm, pour rentre le déploiement simple et flexible de l’opérateur, et sans trop spoiler ça devrait arriver bientôt ;-).~~ (FIXED)

A moi le pouvoir tout puissant des bases de données que je n’ai pas à gérer !

Retours sur Touraine Tech 2022

Mon, 24 Jan 2022 06:30:00 +0000

TNT 22, IRL

Vendredi j’étais à Touraine Tech !

Malgré le contexte sanitaire encore plus compliqué qu’en fin d’année dernière (…), cette édition a pu se dérouler en présentiel, au Polytech Tours, quasi normalement.

Bon… en vrai, côté orga, ça a du être bien galère, mais côté speakers / participants, tout était tellement smooth qu’on a rien vu. Bravo :)

TNT était l’occasion pour moi de faire mon talk “Dis papa ? C’est quoi un SRE ?” autrement qu’en visio et aussi de rencontrer pas mal de speakers (il y avait beaucoup de talks très sympas, je vous met le programme ici).

Keynote d’ouverture

La Keynote d’ouverture, présentée par Camille Justeau, a été consacrée à une réflexion sur l’écologie et la lowtech.

La conférence commence par relayer l’information que nous avons atteint une 5eme des 9 limites planétaires, selon un groupe de chercheurs.

En partant du principe qu’améliorer l’efficience des composants électroniques ne suffira pas à minimiser notre impact sur l’environnement, beaucoup des éléments nécessaires aux smartphones, serveurs informatiques, etc risquent de ne plus être disponibles. Il devient donc urgent de consommer mieux (à défaut de consommer moins).

C’est le principe de la lowtech, qui consiste à amener une réflexion sur ce dont on a vraiment besoin pour nos services numériques du quotidien.

Au delà de l’aspect purement écologique, il y a des réflexions intéressantes sur l’aspect “choix des équipements”. En effet, mettre en avant des composants durables, réparables, aux sources ouvertes, permet de pérenniser les matériels et donc limiter le gaspillage.

Utile

Durable

Accessible

Dis Père castor, raconte nous une histoire d’Ops

Slides de son talk (lien cassé)

Ce talk de David Aparicio, est une collection de postmortems et d’incidents de prod. Chaque exemple est raconté puis décortiqué par David, qui donne des clés pour éviter que cela vous arrive, ou a minima en réduire l’impact.

Pele mêle, je citerai :

faire des blameless postmortems
imposer de faire de meilleures docs, plus de runbooks, jouer des wheels of misfortune
mettre en place de workarounds quand le produit a vocation à disparaître très prochainement
rendre explicite les messages d’erreur
mettre en place de circuit breaker pour éviter les bootstorms

Dis papa ! C’est quoi un SRE ?

C’est mon talk ;-)

En attendant que la vidéo soit disponible je vous remet le lien vers l’article qui en parle

[Edit]La vidéo est ici[/Edit]

Would like to learn how manage your passwords like your code?

Dans cette session de 15 minutes, Sébastien nous a montré comment, chez OVHcloud, une partie des mots de passe sont générés, stockés et mis à jour de manière sécurisée à l’aide de passwordstore (ou pass).

Ce logiciel utilise GPG et est suffisamment simple et automatisable pour fiabiliser la gestion des secrets.

L’outil dispose d’un submodule dans Ansible ainsi que d’un operator dans Kube pour faciliter son usage.

Personnellement j’utilise plutôt Hashicorp Vault (mais c’est plus compliqué à utiliser) ou bien ansible-playbook.

Observabilité Zero to OpenTelemetry

Démo disponibles ici

Charles-Marie Ambrosetti et David Pequegnot nous ont fait un talk très sympathique d’introduction à l’observabilité, notamment grâce à OpenTelemetry.

Pas besoin d’un APM coûteux, toutes les briques open source sont à disposition ;-p.

Ils nous ont montrés qu’en injectant quelques libs mises à disposition par le produit, on était capable d’instrumenter le code et récupérer des traces, corrélables avec des logs et des métriques.

Le premier gros avantage d’OpenTelemetry est le nombre très important d’outils qu’il peut accepter, à la fois en entrée et en sortie.

Le second avantage est qu’il n’est pas nécessaire de réécrire du code (même si c’est possible). Pour certains langage il suffit d’ajouter une lib au démarrage (java) ou de changer de binaire (python).

On va donc pouvoir corréler sans effort grâce aux services déjà présent dans nos infras.

La démo a été faites avec le code de démo Spring “petclinic”, un serveur Prometheus et un serveur grafana avec Loki (pour visualiser les logs) et tempo (pour visualiser les traces).

Petit guide pratique pour commencer un design system

Par curiosité, je suis allé voir le talk de Cécile Freyd-Foucault sur les design systems.

N’ayant jamais travaillé avec des designers, je ne savais pas du tout à quoi m’attendre.

Elle a commencé par nous rappeler que nous utilisons souvent le “material design” de Google parce qu’il est disponible par défaut, mais qu’il est tout à fait possible de gérer son propre design system, moyennant quelques précautions.

Globalement, je n’ai pas compris tous les arguments (faire son propre design system permet de limiter le bus Factor ???), mais j’ai retrouvé beaucoup de similitudes avec mon métier et beaucoup de bonnes pratiques que je rabâche à longueur de journée.

Embarquez l’équipe dans les choix, soyez pédagogues, écrivez de la Doc, ne le faites pas pour la hype, pensez aux utilisateurs, directs et indirects, commencez par un seul élément (le plus utilisé pour avoir l’effet waouw), etc.

Bref, j’ai trouvé ça logique car je travaille comme ça moi aussi ;-)

GitPod : IDE as a service, ou comment ne pas acheter un MacBook Pro à 6000 € et être heureux avec une petite machine

MA GROSSE surprise de cette journée. Même si en vrai, en fait c’était prévisible, ce talk tourne dans toutes les confs et a de supers retours.

Mais même comme ça, j’étais pas prêt pour toutes les possibilités que cela allait m’ouvrir.

Grosso modo, Horacio et Philippe nous ont parlé de divers usecases dans lesquels ils avaient besoin d’environnements de développement plus ou moins complexes qui marchent “à tous les coups” et comment GitPod rempli parfaitement ce besoin.

Depuis un dépôt de code hébergé sur Github ou Gitlab (en ligne ou on-prem), on peut obtenir un environnement de développement complet ainsi qu’un IDE VScode (avec toutes les extensions et les fonctionnalité de prévisualisation), accessible depuis n’importe quel device depuis un navigateur web.

Et pour avoir vu les démos, c’est bluffant.

Il est possible de customiser les binaires/services disponibles dans la machine derrière l’IDE, voire même en lancer plusieurs via un docker compose et ainsi reproduire un environnement de développement complet depuis un navigateur.

Les possibilités ouvertes sont nombreuses et Horatio et Philippe nous donnent quelques exemples :

Faire des labs virtuels
Préparer rapidement des environnements de développement pour onboarder des nouveaux arrivants
Assister les contributeurs nouveaux à un projet open source en leur donnant un environnement prêt à utiliser
Avoir plusieurs onglets pour faciliter le travail sur plusieurs branches en simultanée

Je me vois déjà écrire le blog dessus avec Hugo, ou mes supports de conf avec marp, et je ne parle pas des cas d’usages pro que je lui réserve… [Edit]Je viens de faire mes premières modifs depuis Gitpod \o/[/Edit]

Vraiment une super découverte.

Keynote de fin

La keynote de fermeture a été réalisé par Damien de WeLoveDevs.

Damien nous a présenté, de manière humoristique, les résultats de son enquête annuelle “Ce que veulent les devs”.

C’était intéressant de voir ces chiffres (même si je commence à bien les connaître à force de consulter TOUTES les études qui sortent), et aussi un peu les messages qu’il a voulu faire passer (notamment sur le fait que beaucoup de gens qui se reconvertissent dans l’informatique ne trouvent pas de travail, malgré la pénurie).

Au delà des chiffres, Damien nous a partagé quelques livres à lire si on veut mieux comprendre l’entreprise.

J’ai aussi retenu les références suivantes (sur le savoir être) :

Encore merci aux orgas, c’était vraiment parfait.

[TNT 2022] Dis papa ? C’est quoi un SRE ?

Wed, 12 Jan 2022 06:30:00 +0000

Première conférence de 2022, IRL en plus :)

Après une grosse année 2021 avec plusieurs confs très sympas, pour grande partie en ligne, je reviens donc en janvier avec Touraine Tech 2022 (IRL, normalement). L’événement est (malheureusement ?) déjà sold out… Vous ne pourrez donc pas me rejoindre à la dernière minute.

Pour la petite histoire, la conférence se passe à Polytech Tours, où j’ai faillis faire ma formation d’ingénieur. Un petit clin d’oeil à mon (déjà lointain ?) passé d’étudiant donc ;-)

J’ai été retenu pour mon talk “Dis Papa, c’est quoi un SRE ?” que j’ai donné l’an dernier en ligne à Cloud Nord puis Cloud Est. J’ai pris vraiment beaucoup de plaisir avec ce talk mais j’ai aussi beaucoup discuté avec mes pairs à la suite de ce talk et j’ai beaucoup d’idée pour l’améliorer.

J’espère que cette version plaira à ceux qui peuvent venir et que j’aurais l’occasion de le donner ailleurs, histoire de déclencher encore d’autres discussions :-D.

Le pitch

Ces dernières années, vous avez certainement vu apparaître un nouveau terme dans les annonces d’emploi : SRE. Tout le monde en cherche ! Pourtant, bien malin celui qui est capable de décrire le poste d’une manière qui convienne à tout le monde…

Au delà de la définition qu’en donne Google, qu’est ce que ça signifie, être SRE ?

Quelles sont les missions et les compétences du « bon » SRE ?

Que faut il pour devenir SRE ? S’agit il d’un Dev ou plutôt d’un Ops ?

Tout le monde n’est pas Google ! Est ce que ce terme est devenu un fourre-tout marketing ou le rôle SRE répond-il a un vrai besoin ?

Dans ce talk, je vous donnerai donc mon avis ainsi que mon expérience sur ce nouveau (ou pas ?) métier.

Les slides

Comme à mon habitude, je met les slides à disposition ici pour que vous pouviez cliquer sur les liens en même temps que le talk :-)

[Cloud Est 2021] Dis papa ? C’est quoi un SRE ?

Mon, 18 Oct 2021 20:28:54 +0000

Non ce n’est pas un bug de la matrice : après le ch’Nord, l’Est 😅

Le 8 octobre, je vous ai présenté un nouveau talk à Cloud Nord, dans lequel je parle du métier de SRE (surtout de comment moi je le perçoit).

Si vous l’avez raté, pas de panique ! Vous avez donc une nouvelle chance de le voir, car j’ai été sélectionné pour le faire à Cloud Est ! Cette édition aura lieu les 21 et 22 Octobre 2021, en ligne, et les billets (gratuits) sont disponibles ici. (Il me manque encore Cloud Sud et Cloud Ouest 🙃)

Pendant ces deux jours, il y aura beaucoup de beau monde, je vous laisse regarder le programme, très alléchant. Mon talk est lui planifié le 21 à 11h.

Il donc s’agit d’un talk que j’ai écris suite à de multiples questions qui m’ont été posées (amis, connaissances sur les réseaux, etc) sur ce poste, différent d’une entreprise à l’autre ! J’en ai profité pour intégrer également quelques retours qui m’ont été fait à Cloud Nord donc il sera encore meilleur :-p.

Le pitch

Ces dernières années, vous avez certainement vu apparaître un nouveau terme dans les annonces d’emploi : SRE. Tout le monde en cherche ! Pourtant, bien malin celui qui est capable de décrire le poste d’une manière qui convienne à tout le monde…

Au delà de la définition qu’en donne Google, qu’est ce que ça signifie, être SRE ?

Quelles sont les missions et les compétences du « bon » SRE ?

Que faut il pour devenir SRE ? S’agit il d’un Dev ou plutôt d’un Ops ?

Tout le monde n’est pas Google ! Est ce que ce terme est devenu un fourre-tout marketing ou le rôle SRE répond-il a un vrai besoin ?

Dans ce talk, je vous donnerai donc mon avis ainsi que mon expérience sur ce nouveau (ou pas ?) métier.

Les slides

Comme à mon habitude, je met les slides à disposition ici pour que vous pouviez cliquer sur les liens en même temps que le talk :-)

[Cloud Nord 2021] Dis papa ? C’est quoi un SRE ?

Mon, 27 Sep 2021 06:55:00 +0000

Nouveau talk, où je parle de mon métier : SRE

Je serai de nouveau en ligne avec les copains nordistes pour vous parler (vous l’aurez deviné) du métier de SRE !

J’ai été sélectionné comme speaker pour l’édition 2021 de Cloud Nord, un événement 100% en ligne qui aura lieu les 7 et 8 octobre de cette année. La billetterie est dors et déjà disponible ici.

Il s’agit d’un nouveau talk que j’ai écris suite à de multiples questions qui m’ont été posées (amis, connaissances sur les réseaux, etc) sur ce poste, différent d’une entreprise à l’autre !

Il n’existe évidement pas de réponse universelle à la question « c’est quoi un SRE ? » !

Mais pour ne pas que SRE devienne un terme fourre-tout, je pense que raconter mon expérience peut aider à remettre un peu de concret dans ce métier inventé par Google et décliné dans nos entreprises.

Le pitch

Ces dernières années, vous avez certainement vu apparaître un nouveau terme dans les annonces d’emploi : SRE. Tout le monde en cherche ! Pourtant, bien malin celui qui est capable de décrire le poste d’une manière qui convienne à tout le monde…

Au delà de la définition qu’en donne Google, qu’est ce que ça signifie, être SRE ?

Quelles sont les missions et les compétences du « bon » SRE ?

Que faut il pour devenir SRE ? S’agit il d’un Dev ou plutôt d’un Ops ?

Tout le monde n’est pas Google ! Est ce que ce terme est devenu un fourre-tout marketing ou le rôle SRE répond-il a un vrai besoin ?

Dans ce talk, je vous donnerai donc mon avis ainsi que mon expérience sur ce nouveau (ou pas ?) métier.

Slides

Comme à mon habitude, je met les slides à disposition ici pour que vous pouviez cliquer sur les liens en même temps que le talk :-)

Import manuel de records DNS route53 avec Terraform

Mon, 20 Sep 2021 06:10:00 +0000

Terraform et l’Infrastructure as Code

Ce n’est pas la première fois que je parle de terraform, l’outil d’Infrastructure as Code particulièrement efficace dans les environnements cloud (mais pas que) de Hashicorp.

J’avais fait un petit « tour d’horizon » de l’outil quand il était encore en v0.10 (Hashicorp a passé terraform en v1.0 en juin), si vous avez besoin d’un petit rafraîchissement de mémoire ou que vous découvrez l’outil.

Pour la faire courte, l’intérêt de terraform (et de l’infrastructure as code) par rapport à l’automatisation plus classique est de passer dans un mode « déclaratif » où vous déclarez dans des manifests l’état souhaité de votre infrastructure plutôt que de dérouler un script qui fait les opérations unes à unes.

Vos manifests deviennent la « source de vérité », auditable, versionnable, absolue (pas de diff possible entre ce que vous pensez avoir déployé et le bidule modifié à la main hier que vous avez oublié).

Réconcilier l’existant avec l’infrastructure as code

Tout ça c’est super si jamais vous venez de commencer à travailler dans le cloud et que vous partez de 0.

Si vous avez déjà de l’existant, c’est plus compliqué puisque vous vous retrouvez avec une partie décrite dans votre dépôt Git et une autre partie « historique ».

Et même si on peut se dire que cette partie « historique » va finir par disparaitre au profit des nouveaux projets gérés par IaC, il existe une zone floue où on ne sait plus très bien si c’est géré à la main ou en IaC.

Du coup, autant en profiter quand on a le temps pour réintégrer le legacy dans l’IaC.

Route53, le DNS by AWS

Je suis donc arrivé dans un contexte technique où le DNS externe est géré par AWS depuis bien longtemps, et qu’on intègre progressivement les nouveaux records dans terraform. Cependant, j’avais besoin de modifier un record déjà existant (de type TXT) et je n’avais pas envie de le faire à la main.

Sachez donc qu’il existe pour une grande partie (tous ?) des providers terraform une commande terraform import qui permet comme son nom l’indique d’importer l’existant dans terraform.

Le souci est que cette import n’est réalisée que dans le « state » de terraform, pas la configuration elle même.

The current implementation of Terraform import can only import resources into the state. It does not generate configuration. A future version of Terraform will also generate configuration.

Vous allez donc devoir écrire le pavé HCL à la main.

D’un certain côté, c’est presque plus rassurant quand on y réfléchit, car ça permet de bien se poser la question de comment on souhaite découper nos projets, comment on veut construire l’IaC (avec des variables, avec des boucles, etc).

Récupérer les IDs uniques

L’idée ici va être de récupérer le record en donnant à terraform toutes les infos nécessaire pour qu’il retrouve celui qui nous intéresse. A la suite de terraform import, on doit lui donner les informations suivantes :

terraform import {resource_type}.{resource_name} {zone_id}_{record_name}_{record_type}

Dans mon cas, le resource_type était aws_route53_record, le resource_name mytxtrecord (le nom que je veux lui donner dans ma conf et mon state terraform). La zone ID dépend de votre compte AWS/route53, le record_name, c’est le nom du record (comme sur la console) et le record_type dans mon cas, un TXT mais ça aurait très bien pu être un A, un AAAA, un CNAME, etc.

terraform import aws_route53_record.mytxtrecord ABCDE1234567890_awesomeexample.org_TXT
aws_route53_record.mytxtrecord: Importing from ID "ABCDE1234567890_awesomeexample.org_TXT"...
aws_route53_record.mytxtrecord: Import prepared!
Prepared aws_route53_record for import

A l’issue de la commande, si tout s’est bien passé, vous devriez avoir un message qui indique le succès de l’opération et l’ajout du record dans le state de votre terraform. Il ne reste plus qu’à rédiger le pavé HCL pour votre IaC qui a cette tête là dans mon exemple :

resource "aws_route53_record" "mytxtrecord" {
zone_id = data.aws_route53_zone.awesomedomain.zone_id
name = "awesomeexample.org"
type = "TXT"
ttl = "60"
records = ["existingsuperimportantdata"]
}

On peut commiter ça, puis faire nos modifications comme d’habitude et en toute sécurité :-)

terraform plan
[...]
Terraform will perform the following actions:
# aws_route53_record.mytxtrecord will be updated in-place
~ resource "aws_route53_record" "mytxtrecord" {
fqdn = "awesomeexample.org"
id = "ABCDE1234567890_awesomeexample.org_TXT"
name = "awesomeexample.org"
~ records = [
+ "newtxtstring=veryimportantdata",
"existingsuperimportantdata",
]
~ ttl = 300 -> 60
type = "TXT"
zone_id = "ABCDE1234567890"
}
Plan: 0 to add, 1 to change, 0 to destroy.

cloud on Zwindler's Reflection

REX : Mon parcours vers le titre de Kubestronaut

Introduction

C’est quoi ces certifs déjà ??

Pourquoi Kubestronaut ??

La moula

Déroulé et difficulté

Aparté : PSI proctored exam

Aparté : killer.sh

Ce que je savais déjà vs ce j’ai appris

Conclusion / est-ce que je le referai ?

Autres ressources

Un an dans le nua.ge

C’est l’histoire d’un cloud

Buzz, ou bad buzz ?

Premiers pas avec l’interface

Alors qu’en est il, 11 mois après ?

Des défauts corrigés

Mais d’autres toujours bien présents

Les projets

Les VMs

Conclusion

Sources additionnelles

Et si on testait le Clever Operator pour Kubernetes ?

Clever Operator

Clever Operator

DIY

Préparer la configuration

Mais où on les trouve, ces valeurs à renseigner ?

Deployer l’opérateur

On teste tout ça

Conclusion

Retours sur Touraine Tech 2022

TNT 22, IRL

Keynote d’ouverture

Dis Père castor, raconte nous une histoire d’Ops

Dis papa ! C’est quoi un SRE ?

Would like to learn how manage your passwords like your code?

Observabilité Zero to OpenTelemetry

Petit guide pratique pour commencer un design system

GitPod : IDE as a service, ou comment ne pas acheter un MacBook Pro à 6000 € et être heureux avec une petite machine

Keynote de fin

[TNT 2022] Dis papa ? C’est quoi un SRE ?

Première conférence de 2022, IRL en plus :)

Le pitch

Les slides

[Cloud Est 2021] Dis papa ? C’est quoi un SRE ?

Non ce n’est pas un bug de la matrice : après le ch’Nord, l’Est 😅

Le pitch

Les slides

[Cloud Nord 2021] Dis papa ? C’est quoi un SRE ?

Nouveau talk, où je parle de mon métier : SRE

Le pitch

Slides

Import manuel de records DNS route53 avec Terraform

Terraform et l’Infrastructure as Code

Réconcilier l’existant avec l’infrastructure as code

Route53, le DNS by AWS

Récupérer les IDs uniques

Informations/sources additionnelles