Quand on commence Moisantaba, on se lance dans la première journée sans fumée.
Les premiers conseils de l'appli Taba Info Service, les premières difficultés,
et comment les surmonter, les premières économies qui s'affichent,
les premiers effets positifs sur sa santé,
et avec l'aide de l'appli Taba Info Service, le premier.
Non merci, j'ai arrêté.
Participer à Moisantaba, auparavant de vos chances de devenir ex-fumeur.
Pour être aidé, téléchargez l'appli question Taba Info Service.
Ceci est un message du ministère chargé de la santé,
de l'assurance maladie et de santé publique France.
Alors, si comme moi, tu as longtemps cherché des outils DevOps à mettre dans ton cube,
ce podcast va t'intéresser.
Au détour d'un post link, j'ai découvert DevOpsStack.io,
une stack DevOps pour Kubernetes avec les meilleurs outils libres et cloud natifs du milieu.
C'est aussi les outils que j'ai choisis, mais je spoil un petit peu.
Bienvenue sur Radio DevOps, la balade aux diffusions des compagnons du DevOps.
Si c'est la première fois que tu nous écoutes,
abonne-toi pour ne pas rater les futurs épisodes.
C'est parti !
Bonjour à toi chers compagnons, et bienvenue dans ce nouvel épisode d'Enaparté.
Aujourd'hui, j'ai le plaisir d'accueillir Raphael Pinçon,
et je ne te cache pas qu'on allant sur le site de DevOpsStack,
la première fois j'étais un peu perdu.
Et du coup, c'est pour ça que je l'ai invité dans ce podcast
pour qu'il nous parle un petit peu de ce projet.
Mais avant ça, je te rappelle que le podcast est publié en licence libre.
En CC, il y a ça, tu peux comprendre des bouts, le découper,
l'utiliser dans tes propres productions,
tu peux aussi le diffuser, le partager, ça nous fera plaisir.
Par contre, tu dois nous notifier et citer la sauce.
Et bienvenue à Raphael.
Merci.
Et justement, c'est le moment où je vais te demander de te présenter un petit peu,
de nous dire un petit peu ce que tu as fait dans ta vie, ce que tu fais,
et quel est ton rapport avec DevOpsStack.io ?
Oui, alors mon, on va dire mon background, c'est un gsystem.
J'ai, ça fait une quinzaine d'années que je suis dans le générique système.
Pas mal depuis une dizaine d'années de consultings,
on va dire au sens large, consultant cloud native,
ça va un petit peu de tout ce qui est
un peu pète vers deux coeurs, vers beaucoup,
beaucoup Bernet S ces dernières années.
Et puis aujourd'hui, je suis solution architecte.
Du coup, je vais te poser les petites questions rituelles que je pose
à tous mes invités, puisqu'on est sur un podcast DevOps.
Pour toi, c'est quoi la définition du DevOps ?
C'est compliqué, c'est pas simple à répondre.
Je crois qu'à chaque fois que je vais chez des clients,
qu'on en parle ou en conférence, on a toujours des débats sur ce que c'est,
prendre des exemples.
Bien sûr, on peut parler de collaboration, DevOps,
SQ, marketing, vente, etc.
On peut aller jusqu'à, voilà, c'est Chris Boytard,
je crois qu'il parle de startups,
l'idée d'avoir un peu un well card dedans,
parce que finalement, tout le monde est impliqué.
On peut parler d'automatisation, des outils d'infrasco,
de déploiement, des problématiques de spoff, etc.
Pour moi, je dirais de manière générale, pour moi,
c'est un ensemble de pratiques qui favorise la collaboration,
l'efficience dans l'IT et sa groupe, beaucoup de choses,
mais surtout pas que les outils.
Je crois qu'on est assez d'accord alors.
Et bien, comment toi, tu as rencontré le DevOps justement ?
Comment il est arrivé à toi dans ta vie ?
Moi, j'ai commencé ma carrière d'ingé-système sur du CF Engine,
donc un peu les débuts de l'infrascode open source.
Il y a une quinzaine d'années, donc c'est un peu là-dedans que je suis tombé.
Ça m'a amené vers Peupets,
et donc ça m'a amené vers ce milieu d'infrascode
qui était déjà beaucoup sur des pratiques, en tout cas les outils,
mais aussi tout ce qu'il y a autour.
Le CI CD est arrivé assez rapidement là-dedans aussi.
Et j'ai eu la chance assez rapidement
de ne retrouver au Config Management Camp à Ghent,
en Belgique, qui a lu en février tous les ans,
sauf cette année à cause du Covid.
Et où les fondateurs du mouvement DevOps,
entre autres, Patrick De Bois et Chris Boitart, vont régulièrement,
donc on les croise régulièrement là-bas.
Donc il y a toute une ambiance DevOps.
C'est un peu les mêmes personnes qui vont au Config Management Camp
et qui ont démarré les DevOps days.
C'est un peu là-dedans que je suis tombé là-dedans.
Oui, quand même.
Et du coup, est-ce que ça a vraiment changé quelque chose dans ta vie, le DevOps ?
Est-ce qu'il y a eu un avant et un après ?
Alors avant, j'avais des cheveux, maintenant j'en ai moins.
Sinon, ça me donne une distance critique vis-à-vis de mes propres pratiques.
C'est surtout ça, parce que l'outillage, les outils, etc., c'est une chose,
mais c'est plus revenir un peu au fondamentaux,
voilà des spoffes, tout ce qui est problématique de streamlining,
on va dire, à défaut d'avoir des meilleurs mots en français.
Des pratiques techniques, des pratiques humaines, organisationnelles.
C'est une exigence aussi, l'exigence d'automatisation,
l'exigence de traçabilité, de collaboration,
de remise en question régulière des choix qui,
des fois, paraissent évidentes.
Et puis après, on se dit, tiens, si je les remettais dans le scope,
un petit peu dans la visée des principes DevOps,
on se rend compte que des fois, des choix qui paraissent évidentes,
ne sont pas, que ce soit au niveau des choix humains ou des choix techniques,
et qui peuvent parfois être contre-productifs.
Pour moi, c'est un parcours, on n'est jamais arrivé.
Je ne vais pas dire que je suis expert DevOps,
même si ça fait 10 ans que j'en fais, parce qu'on en apprend tous les jours,
et que si on regarde autour de nous et qu'on est honnête,
on a même du mal à mettre en pratique ce qu'on croit.
C'est toujours un peu compliqué.
Exactement, on va rentrer dans le cœur du sujet,
le dur du dur, c'est pour quoi je t'ai invité quand même.
Je t'ai invité pour nous présenter un projet qui s'appelle DevOps Stack,
que j'ai découvert la semaine dernière.
Alors, je ne te cache pas que quand je suis allé sur la page du projet,
c'était un peu cryptique pour moi.
Peut-être que c'est lié à mon onglet un peu approximatif,
ou alors à une explication un peu foireuse.
Je ne sais pas, je laisse ça en suspens,
mais je n'ai pas tout de suite compris à quoi ça servait,
et en discutant sur le Post-Linked in,
que j'ai commencé à comprendre l'intérêt du projet.
Du coup, est-ce que tu peux nous le pitcher avec tes mots en deux minutes ?
Je vais essayer, c'est jamais simple,
et faire des pages pour expliquer les projets,
c'est jamais simple non plus.
Donc, on va situer un peu, il y a deux ans, on est en 2020,
je travaille chez Camp2Camp,
on dépasse plus en plus d'infras Kubernetes,
sur différents projets, sur différents cloud,
ils commencent à y avoir de la caisse, de l'EKS, de l'OpenShef, etc.
Et puis, on se rend compte que différentes équipes,
différentes équipes SRE,
ont des manières différentes de faire les choses.
On essaie de garder des choses un peu homogènes
pour que les équipes puissent communiquer entre elles,
pour que des gens puissent passer d'un projet à un autre,
et du coup, on se retrouve à copier du code Terraforme,
copier de l'ARGO CD, des trucs comme ça, un peu à droite à gauche,
et évidemment, ça diverge, ça ne marche pas trop.
Et donc là, on se dit, il faudrait faire un projet
qui centralise un petit peu ça, nos bonnes pratiques.
Donc, c'est bonnes pratiques au niveau du déploiement du Kubernetes,
bonnes pratiques au niveau des outils
qu'on va déployer sur le Kubernetes,
et puis un peu une manière standardisée de déployer tout ça.
Donc du coup, quitte à faire quelque chose,
autant que ce soit Open Source,
parce que chez Cam2Camp,
on avait cette culture un peu de tout faire en Open Source,
directement s'il n'y a pas de raison de ne pas le faire.
Et c'est comme ça que le projet est né.
Alors, si je résume ce que j'ai compris,
c'est finalement ce projet là, il va déployer ton Kubernetes,
puis il va rajouter des applications dedans
pour le rendre plus sûr avec de la mesure et des choses.
C'est ça ?
Oui, alors l'idée, en fait, c'est qu'on a un projet Terraform
et puis on lance ce projet,
ça nous installe le Kubernetes,
ça installe les applis de base,
et potentiellement, ça pourrait aussi installer des applis métiers
qui vont être déployés dessus.
C'est du tout en un.
Aussi, parce qu'on veut avoir, on y reviendra peut-être,
mais une approche un peu blue-green des upgrades de cluster,
et du coup, on ne veut avoir aucune tâche manuelle
quand on veut passer d'une version cluster à l'autre.
Donc tout doit être automatisé à partir d'un point d'entrée
qui va être Terraform pour nous.
Oui, ce qui se comprend.
Du coup, deuxième question, c'est le cas d'usage
auquel le projet répond,
parce que le maître en open source, c'est bien,
mais est-ce que vous avez pensé au cas d'usage des utilisateurs finaux ?
Est-ce que ça correspondrait au vôtre ?
Oui, alors nous, c'est vrai que le principe pour nous déjà,
c'était que ce soit un projet interne et qu'il soit utile en interne.
Après, on essaie toujours de penser un peu plus large
que ce soit suffisamment générique.
Je pense qu'une fois que le projet y prend,
il se générise, on va dire, au fur et à mesure des besoins
et puis au fur et à mesure des contributions qui peut y avoir.
Pour l'instant, il n'y en a pas ou très peu.
Donc pour nous, le cas d'usage, c'est vraiment j'arrive chez un client.
Je vais déployer un cluster.
Il y a d'autres outils qui permettent de faire ça,
mais il y a deux, trois points souvent qui ne correspondaient pas exactement.
Je ne sais pas, on pourra peut-être revenir là-dessus d'ailleurs
sur les autres outils qui arrivent un peu au même résultat.
Mais pour nous, c'est vraiment ça.
On arrive chez un client, on doit déployer un cluster,
déployer des applications dessus.
Et je pense qu'il y a beaucoup aujourd'hui pour en avoir parlé un petit peu.
Il y a beaucoup de boîtes qui ont ce besoin là et qui arrivent sur des outils
éventuellement assez similaires.
Oui, je vais te parler de pourquoi ça m'intéressait comme projet.
En fait, nous, on utilise les CubeManager de Scalway.
Moi, je viens de mon OpenShift.
Donc OpenShift, c'est bien parce que ça vient,
ça s'installe avec plein d'outils tiers comme la gestion des routes,
les certificats, la supervision, la centrisisation de logs,
toutes ces choses-là qui ne sont pas dans le Kubernetes natif.
Et du coup, quand moi je suis passé à CubeManager,
nous, on se posait des questions sur quel outil on allait déployer dans notre Cube
et comment on allait le déployer.
Et au bout d'un moment, on s'est aperçu que finalement,
il fallait utiliser ArcOCD pour installer des trucs.
Et puis, quand j'ai vu votre projet, je me suis dit,
mais en fait, c'est exactement ce qu'on veut faire.
Du coup, je dirais regarder plus dans le détail parce qu'on est encore au début
de notre Poc pour plein de services en ligne qu'on a.
Et donc ça, c'est un cas d'usage qu'on a nous.
C'est j'ai mon Cube, je l'installe et qu'est-ce que je rajoute dessus
pour qu'il soit exploitable facilement?
Donc ça, je pense que le projet répond à ça.
En gros, c'est ça.
Oui, sauf que pour l'instant, à l'heure où je parle, en tout cas,
ça installe également le cluster lui-même.
Mais ça, c'est éventuellement quelque chose qu'on a prévu de débriller.
Oui, justement, on va en parler de ça.
Donc, j'ai vu qu'il y avait aussi dans la documentation une partie sur le pipeline.
Est-ce que tu peux nous parler un petit peu de ce fonctionnement-là du pipeline?
Donc, comme tu l'as dit, c'est Terraform.
Alors moi, j'ai l'impression que Terraform lance l'agrégat Kubernetes.
Va installer quelques briques.
Et puis après, c'est Argo CD qui va installer les composants applicatifs tier
comme la supervision et autres.
Est-ce que tu peux rentrer un petit peu dans le détail?
Et puis aussi nous dire, parce que j'ai vu dans la doc, il y a des parties
sur Gitub Action et Gitlapse.
Si je ne suis pas allé gratter, mais comment ça s'interagit tout ça?
Oui, c'est exactement ça, en fait.
Donc, l'idée, effectivement, c'est qu'on va lancer Terraform.
Terraform, il va éventuellement installer le cluster.
Il va installer Argo CD une première fois avec Helm, parce qu'il faut bien
commencer quelque part.
Et puis ensuite, Argo CD va prendre la main, installer les différentes
applications, y compris s'installer lui-même en dernière étape, se finaliser,
en fait, histoire que tout soit géré en mode GitOps.
Après, en fait, on n'est pas obligés d'utiliser des pipelines.
On peut très bien lancer Terraform à la main.
Ça marche aussi.
L'idée, c'est qu'on essaye quand même d'avoir une approche GitOps pour
la traceabilité, pour faire du peer reviewing, etc.
Et du coup, l'idée, c'est que assez rapidement dans les projets,
on va mettre en place un pipeline.
Alors sur certains projets, c'est du GitLab.
Quand on a sur d'autres projets, c'est du GitHub Action.
Ça pourrait être autre chose.
On n'a pas aujourd'hui, on ne fournit pas du Jenkins, parce qu'on n'en a plus.
Mais ce n'est pas eu-slu qu'on en fournit si c'était nécessaire.
Et puis l'idée, c'est que, typiquement, sur du GitHub Action, sur du GitLab,
on peut simplement sourcer le yaml qu'on fournit.
Et puis on a directement les tâches qui vont faire typiquement
un Terraform plan dans une Merged Request,
et puis un Terraform plan quand on meurge, par exemple.
C'est la deuxième question que j'avais posée, mais du coup, t'as répondu.
On peut faire un include directement dans le GitLab CIag,
ce que vous fournissez.
Par contre, c'est relativement peu flexible, en tout cas à l'heure d'aujourd'hui.
Ça veut dire si on veut faire quelque chose de plus flexible
que ce qu'il fournit au niveau des pipelines.
Aujourd'hui, il faut copier le pipeline et puis l'ajuster.
Mais ça reste plus une facilité qu'une obligation moyenne.
Oui, en effet, parce que j'ai vu que vous aviez un seul fichier
et il y a tout été dedans et vous n'avez pas fait l'include à l'intérieur.
Mais ça, c'est un autre sujet, l'include dans les inclus.
Mais c'est quelque chose où il y a clairement moyen d'améliorer ça
et typiquement d'avoir aussi des tâches un petit peu mieux séparées
au niveau du pipeline.
Aujourd'hui, c'est, il me semble, c'est pas super propre
et c'est des améliorations qui peuvent arriver après.
Alors, j'ai vu que c'était compatible
avec les cubes manager de Azure et d'Amazon Web Services.
Alors, je n'ai pas trouvé Google Cloud.
J'ai vu aussi que c'était compatible avec 4S
et Kubernetes Indocker, le Kind.
Mais, d'après la Dock, ce n'est pas compatible.
En tout cas, ça ne laisse pas apparaître
que c'est compatible avec CubeVania ou avec d'autres solutions manager.
Je me posais la question, moi,
à petite personne, pourquoi ne pas commencer par CubeVania
et après les autres ?
Alors, tout simplement parce qu'on n'a pas eu le besoin
que Kamsukem, c'est une boîte de service.
Et du coup, on a fait là où il y avait le besoin
et là où il y avait du budget pour les clients.
Donc, on avait le besoin spécifiquement sur AWS,
donc KS pour certains clients,
sur AKS pour d'autres clients, donc Azure.
Et du coup, on a commencé par ces parties-là.
Maintenant, là, dans le refactoring qu'on est en train de faire
et qui peut-être au jour où la vidéo va être publiée
sera déjà stable, j'espère.
Dans le refactoring qu'on est en train de faire,
du coup, j'ai séparé un petit peu la partie ArgoCD du cœur.
Et du coup, ça paraît totalement possible de prendre un Cube,
on va dire Vanilla ou autre,
un Cube qui est déjà installé et d'installer ArgoCD
avec le module dessus et d'éployer le reste aussi.
Donc, pour nous, en fait, c'était une facilité d'embarquer tout,
Azure, AWS en particulier, K3S, il est arrivé
parce qu'on avait besoin de faire des tests, en fait, surtout.
On ne s'en sert pas pour de la prod.
Mais par contre, pour tester toutes les applis qu'on déploie dessus,
c'est quand même plus simple avec un K3S,
avec un EKS ou un AKS.
Et puis, K1 de le but, c'était de remplacer K3S
parce que K1 est quand même plus rapide.
On va peut-être garder les deux options à terme, je ne sais pas trop.
Alors moi, je viens de lui montrer l'openshift.
J'ai vu que c'était compatible openshift.
Je ne l'ai pas mis dans mes questions que je t'envoyais,
mais du coup, j'y pense.
Je suis assez surpris parce qu'openshift, il arrive avec,
comme je l'ai dit tout à l'heure, plein d'outils
qui font ce genre de choses, peut-être pas ArgoCD ou d'autres trucs.
Mais pourquoi l'encompatible avec openshift,
qui embarque déjà une petite AQLK ?
Ouais, c'est compliqué.
Je ne sais pas si on va le garder déjà,
mais c'était un peu un test.
Mais en plus, c'est assez compliqué
parce qu'openshift, il utilise Terraform pour s'installer,
OpenShift 4.
Mais il fournit un binaire qui est un installeur qui embarque Terraform.
Mais du coup, ce n'est pas utilisable sous forme de module Terraform.
On est obligé d'exécuter ce binaire.
Il y a pas mal d'impératifs,
il y a pas mal de séquenciel dans le mode d'installation.
Donc du coup, on a dû faire un peu des grailles dans Terraform
pour que ça fonctionne.
Mais disons, le but, c'était encore une fois la standardisation.
C'est-à-dire se dire qu'on aimerait avoir des stacks
qui soient le plus similaire possible entre les différents projets.
Et si on a un projet OpenShift,
on préférerait qu'il soit configuré exactement pareil
que les projets qu'on a sur UKS, AKS,
parce que ça facilite la collaboration entre les équipes.
Ça facilite les échanges de connaissance.
Du coup, vu que vous embarquez un ARGO CD,
la question suivante, c'est si j'utilise ça,
évidemment je peux fournir mes propres applications
à ARGO CD pour compléter ce que vous faites.
Mais, tu me vois venir,
est-ce que le projet envisage d'avoir,
comme moi, je suis un gros utilisateur d'encibes,
il y a des collections communautaires,
est-ce que vous envisagez d'avoir des applications communautaires
à mettre dans son cube justement ?
Oui, c'est une bonne question.
Alors jusqu'à maintenant,
là je parle sur les versions 0.Qui que je trouve,
on est sur les 0.50 de la DevOps stack,
qui était encore très monolithique, on va dire.
Ce qu'on a jusqu'à maintenant, c'est un paramètre extra-app,
c'est Extra Application Set sur le module de la DevOps stack,
qui permet de passer des définitions
d'applications supplémentaires et d'applications set supplémentaires.
C'est comme ça qu'on instantie nos applications métiers
à l'heure actuelle.
Maintenant, je vais empiéter un peu sur les questions suivantes.
On est en train de travailler sur la modularisation
qui va devenir normalement la V1 de la DevOps stack.
Et cette modularisation, elle permettra,
soit d'utiliser un module générique Application Set,
qui va permettre d'instancer de la même manière
qu'avec les Extra Application Set,
soit éventuellement même de faire des modules métiers,
on va dire, des modules supplémentaires
qui pourront être hébergés n'importe où, en fait.
Et ces modules, ça va être des mélanges de terraformes
et de chartes, ou en tout cas de terraformes et d'argot CD,
qui pourraient permettre d'installer des applications.
Et éventuellement, quand on installe une application,
on peut vouloir créer, je ne sais pas, un bug-cat S3,
par exemple, une base de données, un truc comme ça.
Et donc, les modules pour intégrer de la logique
purement infrastructure avec terraformes
et de la logique de déploiement Kubernetes
avec la partie Argo CD.
Oui, alors ce que...
Je ne connais pas bien cette partie-là d'argot CD,
mais je suppose que Argo CD peut être piloté par Terraformes,
d'après ce que tu dis,
ce qui fait que si on fournit un module avec du terraforme et de l'argot CD,
le terraforme va créer l'application dans Argo CD
et puis Argo CD va aller chercher l'application dans le dépôt, c'est ça ?
Oui, alors en fait, l'approche qu'on a eue jusqu'à maintenant,
c'était d'avoir...
On crée dans le chart Argo CD,
on peut passer des applications ou des applications
ou des applications 7 supplémentaires.
Je ne suis même pas sûr si on fait comme ça
ou si on crée simplement avec le provider Kubernetes, peut-être.
Maintenant, dans le refactoring modulaire,
on utilise un provider qui a été créé par Olivier Bouquilly,
donc un provider Argo CD qui utilise l'API d'Argo CD
en fait pour créer des applications.
Alors pour l'instant,
on ne peut pas créer les applications 7 de cette manière
parce qu'ils ne sont pas exposés dans l'API d'Argo CD,
mais ça doit venir normalement dans Argo CD 2.3,
si je ne me trompe pas, quelque chose comme ça, ça devrait arriver.
Donc l'idée, effectivement, c'est qu'on a un provider terraforme,
donc en go, natif,
qui va communiquer avec l'Argo CD
pour créer les applications, pour créer les projets, etc.
Du coup, on aura une modularité pour, comme tu dis,
créer des applications, créer notre cube.
Je fais y appeler ce podcast,
Cube Out of the Box, créer notre cube tout configuré.
Et puis après, on pourra même utiliser des modules
qu'on développe nous-mêmes pour déployer les applications
à l'intérieur du cube, grâce à Argo CD.
Exactement.
C'est super intéressant.
C'est ça l'idée.
C'est ça l'idée.
Et puis l'idée, c'est d'avoir un peu des interfaces standardisées
entre ces modules,
donc typiquement des interfaces d'authentification, par exemple,
où on passe une structure OIDC à tous les modules.
Cette structure OIDC, elle peut venir d'un module cognito,
si on veut faire du pur AWS, d'un module KeyClug,
d'un module DEC, etc.
Et puis le module, il va se configurer,
il va renvoyer une structure OIDC
qu'on peut passer à une application
pour qu'elle configure l'authentification dynamiquement.
C'est ça l'idée.
D'accord.
Pareil pour le monitoring, pareil pour le test.
C'est super intéressant.
C'est une partie que je connais moins, selon tu viens de parler.
Un jour, je pense que je vais m'y plonger,
mais j'ai déjà beaucoup de choses à faire.
Tu as répondu sur ma question, sur le changement d'implémentation.
J'ai vu sur le DEPO-Git qu'il y a une baisse des contributions depuis octobre.
Est-ce qu'on peut craindre un abandon du projet ou pas,
ou est-ce que c'est lié à des événements externes
de l'équipe disponibilité ?
Il y a plusieurs choses.
Déjà, la personne qui a créé le projet chez Cam2Camp,
Michael Canneve, est partie début octobre, fin septembre.
Donc, lui, il était très très actif sur le cœur,
et donc, du coup, il y a ses contributions au moins.
Ça a demandé un peu de réorganisation de notre côté
pour savoir qui allait reprendre, comment allait reprendre.
Maintenant, nous, on a des projets clients qui utilisent cet outil-là.
On n'a pas de version privée de la DevOps stack.
Donc, si on continue à le faire évoluer, c'est public,
et ça va continuer à évoluer,
parce que nous, on s'est engagé à l'utiliser en interne.
L'autre chose qui a réduit un petit peu les contributions ces derniers mois,
c'est le fait qu'on a commencé à penser à la V1,
et donc à cette modularisation pour avoir une approche plus explicite,
pour pouvoir interchanger les modules,
remplacer le module d'authentification, par exemple, par un autre module,
avoir des modules optionnels, etc.
Et donc, il y a eu pas mal de... comment ?
De refactoring et de repenser les choses.
Et donc, à l'heure actuelle, on a une branche V1
qui prend un petit peu plus de place que la branche Master.
Et c'est aussi pour ça qu'il y a moins de contributions sur Master à l'heure actuelle,
parce que tout ce qu'on fait entrer sur Master, il faudra le porter sur V1.
Donc, on est plus en train de penser à la suite que de faire évoluer l'actuelle.
D'accord, c'est parce que je voyais justement les comites qui se menusaient.
Et du coup, j'en viens à mon autre question.
Est-ce que vous avez déjà des contributeurs externes,
ou est-ce que vous en cherchez ?
Alors actuelle, il n'y en a pas.
À ma connaissance, en tout cas, je crois qu'il y a des gens qui l'ont forqué.
On a eu des questions.
Pour l'instant, il n'y a pas vraiment de contributeurs externes.
Je pense que s'engager sur la version telle qu'elle est aujourd'hui,
ou on enregistre, c'est pas forcément simple,
parce qu'on prépare la suivante.
Donc, sur la V1, je pense que ça va être assez intéressant.
Et je pense qu'on veut avoir une approche communautaire
et puis voir s'il y a des gens que ça intéresse, c'est clair.
Ça fait partie du jeu open source, et pour moi, c'est quelque chose d'important.
S'il y a des gens qui l'utilisent,
on a soit aussi une certaine standardisation
qui va au-delà de ce que nous on fait.
Je ne vais pas te cacher que moi aujourd'hui,
la stack qu'on a choisi pour partir dans QP
pour certains de nos projets ressemble beaucoup à celle que vous avez choisi,
puisque la plupart des outils sont ceux qu'on a choisi.
Et donc, on était partis pour créer des applications Argo CD.
Donc, si demain, plutôt que de créer mon propre projet dans mon coin,
j'ai envie de participer aux vôtres,
de fournir par exemple un provider pour aller sur Capsule,
Kubernetes Managé de chez SkaLway.
Comment je fais pour contribuer avec vous ?
Est-ce que je dois absolument passer par des poules request ?
Est-ce que on peut discuter au téléphone en vision,
parce que pour l'instant, il y a encore peu de monde ?
Comment vous faites l'onboarding des nouveaux contributeurs ?
Alors, les poules request, c'est clair, c'est bien.
On peut faire...
Moi, je n'ai pas de problème en soi à discuter,
je pense que mes collègues ne le auront pas non plus.
Après, il y a un canal qui existe qui est sur le Slack du CNCF,
sur le Slack Kubernetes.
Le canal s'appelle came to cam DevOps stack,
came to cam DevOps stack.
Il y a une centaine de personnes dessus.
À l'heure où on enregistre, il n'y a pas beaucoup de discussions,
mais on a réfléchi en interne à déporter pas mal de conversations
qu'on a chez came to cam sur ce canal-là,
au niveau implémentation, peut-être pour impliquer plus de monde.
Donc, il y a ce canal public, et c'est un moyen aussi de nous contacter.
Alors, du coup, je vais pousser mes questions,
parce que je vois qu'on a le temps encore un petit peu.
Et puis, du coup, j'ai plein de questions qui me viennent.
Est-ce que vous faites des tests, justement, dans le projet ?
Est-ce que vous avez des pipelines qui font tourner des tests ?
Et si oui, comment vous vous organisez ?
Alors, sur la V0, il y en a.
Sur la V1, il faut encore qu'on repense toute la partie test.
Il y a beaucoup de travail à faire à l'heure où on enregistre aujourd'hui.
Sur la V0, en fait, les tests, c'est des tests de déploiement principalement 4-3S,
pour l'instant, parce que c'est vrai que déployer sur autre chose,
c'est un peu plus compliqué.
Ça veut dire avoir des credentials dans GitHub ou ce genre de choses.
Donc principalement, les tests à l'heure actuelle, c'est déployer la stack,
vérifier qu'elle se déploie bien, que les applications sont bien synchronisées
dans Argo CD.
Et puis, il y a un test d'update également,
qui consiste à réappliquer terraformes et vérifier qu'on arrive
à mettre à jour la stack.
Alors, actuellement, ça se cantonne à ça.
Et ça fait partie des gros sujets attaqués,
effectivement, c'est comment tester.
De toute façon, c'est toujours un problème.
En tout ce qui est automatisation d'infrastructures,
les tests, c'est assez compliqué parce que ça demande d'interagir
avec l'infrastructure réellement et donc de provisionner les choses.
Et c'est toujours un peu complexe.
Ouais, à part les lineteurs, je pense qu'on peut avoir plein de lineteurs sur l'IML.
C'est vrai que les tests, c'est un peu dur.
Est-ce que vous avez intégré des solutions justement comme test-infra
ou service-pec ?
Pas encore.
On avait réfléchi à faire ce genre de choses.
Avec terraformes, ce n'est pas super simple,
je trouve d'intégrer des choses aussi parce que la DSL est assez haut niveau.
Et du coup, on peut difficilement faire des tests unitaires,
comme on peut faire en rubis avec Pepe, par exemple.
On est un peu coincé avec terraformes de ce côté-là.
Mais c'est clairement des choses où je pense qu'on est assez ouvert
à avoir des suggestions parce qu'il y a de quoi faire.
Bon, je vais suivre le projet de très près parce que nous,
ça nous intéresse.
De toute façon, nous en avons besoin aussi de ce genre de choses.
Parce qu'on ne l'a pas dit, peut-être qu'on peut parler de la stack un petit peu,
la stack classique que vous utilisez et que vous déployez.
Et c'est quoi ?
Alors la stack qu'on installe de manière standard,
c'est déjà un Kubernetes.
Par-dessus, son install Argo CD.
Donc ça, c'est les deux briques qui sont indiscutables.
On va dire sans ça, on ne fait rien dans la DevOps stack.
Et puis après, pour l'instant, en standard, ce qu'on installe,
c'est trafic comme ingress-controller,
certes manager pour la gestion des certificats,
l'acupromité au stack pour tout ce qui est monitoring.
On installe en règle générale, on met l'OK stack aussi
pour ce qui est de la gestion des logs avec Grafana,
parce que du coup, on déploie un Grafana sur le cluster.
On a une partie TANOS,
je ne sais pas si on l'utilise beaucoup pour l'instant,
pour tout ce qui est persistence des métriques.
Est-ce que j'oublie quelque chose ?
Sur la partie OIDC,
soit on utilise l'authentification qui est fournie avec le cloud,
donc Cognito sur AWS, Azure AD sur Azure, etc.
Soit on fournit un key clock,
typiquement quand on veut faire de l'exo scale, par exemple,
parce qu'il n'y a pas de solution OIDC à la règle.
Je crois qu'elle arrive.
Et puis, est-ce que j'oublie quelque chose ?
Oui, donc Prometheus, Grafana.
Je n'ai pas l'impression d'oublier quelque chose.
Après, avec la modularisation de la stack,
de plus en plus, on va avoir soit des modules qui vont remplacer.
Typiquement, une des choses qui m'a amené vers cette modularisation,
j'ai travaillé avec un client qui m'a dit,
oui, mais c'est bien gentil,
mais moi, déployer Prometheus Alert Manager Grafana dans mon cube,
ça ne m'intéresse pas.
On a un Elastic Cloud.
Donc, on voudrait le plugger à l'elastic cloud.
Et donc, on s'est dit,
tiens, si on avait une approche modulaire,
peut-être qu'on pourrait déployer à la place du module Prometheus Stack,
un module Elastic Cloud qui va configurer cluster
pour envoyer sur l'elastic cloud.
Ou se dire, c'est bien, on a déployé un key clock,
sauf qu'en réalité, on voulait plugger sur un free PA
et key clock, c'est un peu lourd pour ça.
Donc, si on avait un module DEX, ce serait peut-être un peu plus flexible.
Et donc, au fur et à mesure,
on va fournir des modules un peu de remplacement.
Ou des modules complètement optionnels,
c'est-à-dire que si on ne veut pas de Tano,
si on ne veut pas de Tano, si on ne veut pas de L'Oquistac,
on ne veut pas de L'Oquistac.
Il y aura, ce sera au niveau de la documentation des modules,
qu'on dirait, qu'en est-ce qu'il y a des dépendances
entre les modules,
il y aura peut-être des modules qui sont nécessaires pour en déployer d'autres.
D'accord.
Justement, pour choisir les applications,
vous vous basez sur quel critère, vous en interne,
enfin jusqu'à présent, vous vous êtes basé sur quel critère ?
On s'est basé sur ce que tout le monde utilise, on va dire.
En comment vient aussi beaucoup du monde d'OpenShift,
côté Kubernetes,
on va dire que la stack Prometheus, Grafana, c'était assez logique.
Je ne sais pas parce que quand même,
sauf si ça a changé depuis,
moi je viens d'OpenShift 3, OpenShift 3, c'était une sacke LK.
C'était du Kibana derrière.
C'est du Prometheus Kibana.
Mais il n'y avait pas de Grafana, il me semble.
Ah ouais, on avait tendance à mettre du Grafana un peu partout.
Mais ça ne semble plus logique de fournir une stack LK Prometheus Grafana,
c'est très bien intégré.
Après, ça a l'avantage d'être léger.
Donc du coup, si on déploie dans Cluster, ça fait sens.
Je pense qu'une stack élastique, ça a peut-être plus de sens
quand on veut avoir des métriques complètement externes au Cluster.
Et peut-être pour des gens qui voudront déployer beaucoup de Cluster,
se dire, tiens, je vais déployer une stack de munturines dans chaque Cluster,
c'est un petit peu lourd.
Et du coup, je pense qu'à terme, avoir cette option-là, c'est intéressant.
Pour l'instant, c'est surtout basé sur le fait qu'on avait choisi
cette éclat en interne, et donc c'est celle-là qu'on voulait standardiser dans nos projets.
Je pense que c'est une bonne stack.
Nous, on a fait des études et on est tombés sur les mêmes outils.
Donc je pense que...
Et puis on n'est pas les seuls, là, que tu dis, tout le monde fait pareil.
C'est clair.
C'est clair.
C'est quand même...
Enfin, je veux dire, Prometheus, c'est quand même quelque chose qui vient,
qui vient avec Kubernetes, on va dire.
C'est très, très lié à Kubernetes.
Alors tout à l'heure, tu as dit un truc qui m'a interpellé.
Je trouvais ça intéressant.
Je me dis, il faut que je lui pose la question.
Tu as dit, vous commencez par installer Argo CD,
qui installe les autres applications et qui finit par s'installer lui-même.
Ma question, c'est, pourquoi est-ce que Argo CD ne commence pas
par s'installer lui-même pour après installer les autres applications ?
Oui, il y a des problèmes de dépendance.
Et il y a des problèmes de dépendance soft, des problèmes de dépendance hard, on va dire.
Dépendance soft, c'est typiquement...
Ok, j'ai une application qui instantie des ingresses.
Il y a une dépendance soft sur le fait d'avoir un ingresse contrôleur à un moment donné.
Mais si on n'a pas l'ingresse contrôleur, c'est pas grave.
Les ingresses sont là, ils font rien.
Par contre, il y a des dépendances hard.
Des dépendances hard, c'est typiquement...
Si je veux installer mon Argo CD et qu'il soit monitoré,
je vais devoir instantier des services monitors en utilisant le Prometheus Opérateur.
Et ces services monitors, ils ne sont pas disponibles
tant que j'ai pas installé la stack Prometheus, qui va installer les CRD.
Et ça, il y a pas mal d'endroits où il y a ce genre de problématique là.
Des problèmes de poulet d'oeufs, on va dire, de dépendance circulaire,
qui font que mon Argo CD, au départ, je ne peux pas l'installer avec du monitoring
parce que je n'ai pas encore les CRD qui vont venir.
Alors soit il faut qu'on instantie tous les CRD du monde avant d'installer Argo CD,
mais c'est un peu moche.
Soit on est obligé de faire en plusieurs étapes.
On a cette même problématique qui arrive, pour l'instant, on n'a pas implémenté,
mais on a le même problème avec certes managers typiquement.
Pourquoi ? Parce que certes managers, de la même manière,
si on veut l'installer correctement, il a du service monitor,
donc il a besoin de la stack Prometheus.
Mais la stack Prometheus, pour bien fonctionner,
elle doit avoir des certificats valides, donc elle a besoin de certes managers.
Donc on est un peu à l'heure actuelle, à l'heure où je parle,
on est en train de se dire que sur la modularisation de la DevOps Stack,
on va avoir une logique où les modules auront deux points d'entrée,
un point d'entrée Bootstrap qui va installer l'application en mode minimaliste
avec Helm et un point d'entrée principal qui va finaliser l'installation avec Argo CD.
Pourquoi on a ces deux points d'entrée et pourquoi choisir Helm pour le Bootstrap,
en fait, simplement parce que ça peut nous permettre d'avoir
quelque chose qui va converger.
C'est toujours la problématique.
Comment on fait pour avoir une installation qui soit déclarative,
qui utilise un système avec un graph directionnel
et en même temps, l'installation, elle doit se passer avec des étapes séquentielles
et c'est toujours le problème avec tous les outils qu'on utilise.
Et l'intérêt, c'est que du coup, en passant par des charts Helm pour le Bootstrap,
on peut ignorer à la limite les valeurs qui viennent plus tard
dans les upplies suivants.
Du coup, Argo CD, quand il s'installe lui-même,
il va recycler sa propre instance où il va en créer une nouvelle
et puis il va jeter l'ancienne.
Argo CD, en fait, il retombe sur ses pattes.
C'est-à-dire que s'il y a un chart Helm qui a déployé Argo CD dans le namespace
Argo CD avec certaines valeurs, quand on va déclarer l'application,
il va se rendre compte qu'il va gérer le namespace.
En fait, il va se rendre compte qu'il y a déjà un déploiement Argo CD,
donc il va le remplacer.
D'accord.
On n'a pas parlé de stockage.
Est-ce que justement dans la stack, il y a un gestion de stockage type Migno ou pas ?
Alors, on a ça en option.
Ne serait-ce que pour 4.3s ou Kines, simplement, déjà pour tester.
Je suis en train de faire un module Migno pour ça,
qui du coup va être un module qui va déployer Migno,
qui va éventuellement instantier des trucs dans le cloud,
et qui va fournir une structure en retour avec des clés d'API Migno pour injecter dans les applications.
Maintenant, la logique qu'on essaye d'avoir depuis le départ,
c'est un choix d'implémentation un peu spécifique,
qui des fois nous limite, mais qui essaie de nous guider,
on va dire, c'est d'avoir des approches blu-grine.
Au niveau du cluster, je ne parle pas au niveau des applications.
Idéalement, on aimerait ne pas avoir à mettre à jour nos clusters Kubernetes.
Encore une fois, c'est un choix qu'on a fait,
parce que quand on met à jour un cluster Kubernetes,
ça veut dire qu'on fait une étape qui n'est pas réversible,
et du coup, si ça plante, on ne peut pas revenir en arrière, c'est un petit peu embêtant.
Donc jusqu'à maintenant, ce qu'on essaie de faire sur nos projets,
c'est que si on a besoin de changer de version de Kubernetes,
ou de version de la DevOps stack,
on déploie un deuxième cluster, donc si on a le green à l'heure actuelle,
on déploie un blue et ils y versent ça.
Ce deuxième cluster, une fois qu'il est prêt, on bascule le DNS
et on change complètement.
Donc, idéalement, ça veut dire que les applications elles-mêmes
doivent être state-less le plus possible,
c'est quand même une bonne pratique.
C'est-à-dire que tout ce qui est dans cluster,
idéalement, devrait être state-less.
Ça veut dire que dans une grande partie,
on essaie de s'interdire de faire des volumes dynamiques,
à part pour du cache.
Et si on doit avoir des données qui sont persistantes,
ce qu'on fait, c'est qu'elles sont en dehors de la DevOps stack
et on les passe en paramètres, en fait.
Donc, typiquement, je ne sais pas, la base de données des utilisateurs,
le YDC, par exemple, on peut dire que si je veux un YDC persistent,
une base d'utilisateur persistent, je vais le créer avec Terraform
dans mon projet Rassine, et je vais le passer en paramètres
et je vais le mettre en train à la DevOps stack
pour que entre mes cluster blue et green,
je retombe sur la même base d'utilisateur.
C'est super intéressant, mais du coup,
j'ai encore plein de questions avec ce qu'il vient de dire.
Je trouve le conseil assez intéressant.
Après, je me dis que ça doit être compliqué à mettre en place.
J'espère que c'est bien documenté,
parce que ce n'est pas facile,
ce que tu viens de décrire.
Non, c'est compliqué.
Et du coup, je me pose des questions,
parce que dans theCUBE, t'as quand même le TCD
qui a plein de trucs qui sont stockés dedans,
comment tu fais, tu translates aussi ta base de données,
fait envoyer le TCD dans ton nouveau club.
En théorie, on n'en a pas besoin.
Parce que qu'est-ce qu'il y a dedans ?
Il y a l'état des applications.
On s'en fiche un petit peu et on a de l'argot CD.
Si tout est bien fait et qu'on a des extra applications
ou des extra applications sets,
finalement, toutes les applications doivent se déployer
automatiquement sur le deuxième cluster.
Si les données sont dans une base de données externe
ou des trucs comme ça et qu'on a passé en paramètres,
il n'y a pas de raison que ça ne marche pas en soi.
Le téléscée est que ça va retomber sur ses pieds
et que tout ce qui est dans le TCD,
c'est un état transitoire, c'est du cash,
ce n'est pas des données persistantes qu'on a besoin de récupérer.
Parce que tout le thermo-guitop, c'est ça.
Et donc du coup, on va se réinstaller.
Les secrets vont se ré-recréer.
Si tu n'utilises pas une gestion de secret tiers, enfin...
Voilà. Typiquement, la gestion de secret,
pour nous, elle doit être en dehors du cluster.
Ça peut être un vault, ça peut être du SOPS,
ça peut être autre chose, mais on utilise pas mal SOPS
dans nos pipeline, donc le projet de Mozilla
qui permet de s'intégrer avec du chiffrage côté cloud.
Et ça nous permet, pardon,
effectivement que les clusters soient complètement staites-lesses.
Par contre, ça veut dire qu'on s'interdit
de créer des volumes qui doivent être persistants.
On a discuté pas mal de fois
d'intégrer Véléro dans la stack
et de pouvoir faciliter un peu la transition.
Il y a d'autres outils qui permettent de faciliter les transitions.
Pour moi, l'idée, enfin,
partir du principe qu'on va récupérer des choses
dans l'ETCD pour migrer à une nouvelle version du cluster,
c'est ouvrir la porte à pas mal de problèmes.
Ça veut pas dire qu'à un moment donné, on n'en aura pas besoin,
mais on préfère penser en se disant
qu'on va s'interdire de le faire si possible.
OK.
Alors, je sais pas trop...
Je vais garder cette idée pour une prochaine fois.
Par contre, j'ai une question à te poser.
Parce que tu as dit un truc qui m'a interpellé.
C'est avant que tu parles de Véléro.
Ah, puis, je ne l'ai pas d'auté.
Zut.
Zut, zut, zut.
Ça va être bien juste que l'on dire sur un truc.
Je te pose la question après.
Juste que l'on dire parce qu'on s'est posé pas mal la question
sur des projets un peu concurrents en hôtes.
Il y a le projet de...
de Vigeon, asurique, VSHN,
qui s'appelle SYN, S-Y-N,
qui est également basé sur Argo CD
et qui est basé sur...
enfin, qui...
L'idée aussi, c'est...
enfin, 1, 2, 3.
L'idée, c'est de démarrer des clusters Kubernetes
et d'intégrer Argo CD dedans,
mais de manière beaucoup plus centralisée,
avec une logique de précompilation
des manifeste,
avec un outil qui s'appelle...
enfin, c'est un tech Commodore,
c'est un tech un outil qui s'appelle Leutement.
Et puis, ils vont pas mal vers une logique aussi
basée sur Crossplane,
et Crossplane qui permet de faire de l'infrastructure
sous forme de ressources Kubernetes.
On s'est posé la question plusieurs fois
dans des web stacks d'utiliser Crossplane.
Et le problème de Crossplane,
c'est que toutes les données sont dans les TCD
et que du coup, ça nous interdisait
cette approche Bluegrine, en fait.
Ok. Je voulais te parler de Mosias Ops.
Donc nous, on est une équipe trop petite
pour utiliser...
pour utiliser administrer un Volt.
En tout cas, quand on fait du GitOps,
on chiffre nos...
on chiffre nos secrets dans Git,
parce qu'on n'a pas besoin de plus, en fait.
Pour info, on est 3,
et on a des tout petits projets, donc...
pour l'instant, on n'est pas encore... voilà.
Même à 25, en fonction des projets,
Volt, c'est compliqué de se dire comment on fait
quand on a des projets dans tous les sens.
Ouais, c'est ça.
Et donc nous, on chiffre avec Ansible Volt nos secrets,
et on voulait passer à Mosias Ops.
Et puis, en fait, on s'est aperçu que le projet
il a plus d'évolution depuis plusieurs mois.
Et que les mainteneurs sont aux abonnés absent,
qu'il y a des poules réquestes qui sont en attente.
Et je voulais avoir ton avis là-dessus.
Est-ce que, déjà, t'es au courant ?
Est-ce que... non ?
Je ne suis pas au courant.
Nous, on est passé par pas mal de choses, justement,
pour éviter des trucs un peu centralisés, complexes,
comme à Chicor Volt.
On a utilisé Gopas, en particulier, pendant pas mal de temps.
Continue à utiliser sur certaines choses.
Non, peut-être. On a utilisé du Yamel.
Et c'est vrai que Sop, s'il est pratique,
parce qu'il s'intègre dans pas mal de cloud pour ce genre de choses.
Il ne semble pas avoir vu passer d'un fou, en tout cas, en interne,
que le projet était plus maintenu.
Nous, on n'a pas rencontré particulièrement de problèmes avec ça.
Bah, s'il est stable, mais c'est vrai que ça fait...
depuis 2021, qu'il n'y a plus d'évolution.
Il n'y a plus de comites.
Donc, on se pose la question.
Il y avait même une issue qui demande si le projet est mort,
et les mainteneurs ne répondent pas.
Il y a deux semaines ou trois semaines,
il y a quelqu'un de Mosia qui a dit qu'il a l'air gardé.
Je vais me faire l'avocat du diable,
mais les mainteneurs de beaucoup de projets open source,
c'est les mêmes qui maintiennent à peu près
une cinquantaine de projets open source à côté.
C'est toujours les mêmes.
Et puis, c'est pas parce qu'ils répondent pas en six mois
qu'il y a personne derrière.
Mais, enfin, moi, je sais que je suis...
je plaide coupable d'avoir des issues sur certains projets
où on me demande si il s'est encore vivant,
et je n'ai pas répondu depuis trois mois.
Oui, mais là, c'est vrai qu'il y a plusieurs indices
qui nous ont fait dire qu'on va pas encore aller vers SOPS,
même si on a été prêt à y aller,
mais on va attendre.
Donc, c'est ce que je voulais être paré.
Et une dernière question, enfin, une avant-dernière question,
parce que je vois que l'automobile est super intéressant.
Est-ce que... parce que Argo CD permet quand même
de gérer plusieurs aggregats de Kubernetes.
Est-ce que vous avez pensé à ça,
ou est-ce que finalement, l'idée, c'est
qu'il y a un seul Argo CD par avec Kubernetes?
Alors, nous, on était partis sur l'idée d'avoir un Argo CD
par Kubernetes, c'est de gérer
uniquement le déploiement des applications dans le cluster.
Moi, ça m'est arrivé chez des clients
de monter un Argo CD qui géré plusieurs clusters.
Nous, on n'est pas dans cette logique-là,
parce que dans la plupart des projets qu'on a,
on a vraiment un cluster par projet,
voire par client, et du coup,
centraliser l'Argo CD,
ce serait centraliser la gestion des clients,
et il y a des clients pour qui c'est juste pas possible de faire ça.
Tout simplement.
Donc, pour l'instant, on est restés sur cette logique-là.
J'ai rien personnellement contre le fait d'utiliser
un Argo CD pour gérer des clusters distants.
Je vais tester, ça marche.
Pourquoi pas ?
Ça va se plus se rapprocher peut-être
pour le coup du projet SIN dont je parlais avant,
SIGCAN, Devis Jeanne,
qui me semble plus sur cette approche-là.
Je ne veux pas dire bêtis, il faudrait leur demander.
Il est libre ce projet ?
Si je le trouve, je mettrai les liens
dans les notes de l'épisode.
Du coup, je vais te poser ma dernière question
avant qu'on se laisse.
Est-ce que tu as un livre, un article,
ou une conférence à conseiller
à nos auditeurs et auditrices ?
Il faut être sur le sujet DevOps.
Quand je donne,
depuis des années, quand je donne des formations,
Pepe, Docker, Kubernetes,
souvent, il y a le sujet.
Je peux difficilement parler des outils,
sans parler de la logique qui va avec,
parce que ce serait dommage.
Pour moi, le bouquin que je conseille,
c'est THE GOAL de Eliah Gaudrat,
qui n'a rien à voir avec le mouvement DevOps,
puisqu'il prédate très largement,
il date des années 80.
Mais c'est le bouquin qui a inspiré
THE Phoenix Project.
C'est en gros une réécriture de THE GOAL
moderne.
Quand j'ai lu THE Phoenix Project,
je n'ai pas compris grand chose,
parce qu'il y avait trop de références à THE GOAL.
J'ai lu THE GOAL et j'ai dit, mais finalement,
il y avait tout dedans.
C'est les principes un peu qui ont amené
le mouvement Kanban, le mouvement
Toyota, etc.
Donc le mouvement DevOps est quand même
très largement inspiré.
Donc je conseille de lire ça.
Il y a même une version BD qui existe et qu'on trouve en ligne.
Écoute, merci.
J'essaierais de trouver ces livres et de les mettre
dans les notes aussi de l'épisode.
Je te remercie. En tout cas, c'était super intéressant.
J'espère qu'on parlera à nouveau
de ce projet-là
sur notre chaîne YouTube,
qui sait peut-être.
L'avenir nous le dira.
Et moi, je tiens à dire à toi, chers compagnons,
que si tu es envie d'approfondir
justement tes soft skills,
parce qu'on a parlé de hard skills, de compétences techniques,
mais si tu vas approfondir tes soft skills,
tu peux justement chercher
à obtenir un état d'esprit DevOps.
Si tu ne l'as pas déjà, avec ma formation
qui s'appelle DevOps Mindset, tu trouveras le lien
en description. Je te dis à très bientôt
pour une prochaine vidéo.
Si tu es envie de discuter du mouvement,
alors rejoins-nous dans la communauté
des compagnons du DevOps.
À bientôt.
La balade aux diffusions des compagnons du DevOps
est produite par l'IDRA.