Alors vous qui cherchez une bonne protection, je peux vous prêter mon armure.
La Gladiatus.
C'est sympa, mais c'est pas un peu grand pour un enfant de quatre ans ?
Oui, mais il va bien grandir, non ?
Oui.

Une seule protection pour tous, c'est du passé.
Chez Aysio Mutuelle, les garanties sont adaptées aux besoins de chacun, à toutes les situations familiales,
et certaines médecines complémentaires peuvent être prises en charge.
Aysio Mutuelle, c'est ça la Mutuelle d'aujourd'hui.
Rendez-vous en agence au suraysio.fr pour découvrir nos offres promotionnelles.
Alors, quand on fait du code d'infrastructure, on peut soit tout refaire soi-même,
soit utiliser du code libre mis à disposition par d'autres personnes sur Internet.
Alors justement, aujourd'hui, on va se pencher sur la gestion de la configuration,
en particulier avec Ansible,
et on va se demander s'il vaut mieux utiliser des modules ou des playbooks publics,
ou alors redevelopper des ressources personnelles nous-mêmes.
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 !
Bienvenue à toi, chers compagnons,
dans Radio DevOps,
ton émission de vulgarisation Cloud et DevOps mensuelle.
Alors tu l'auras compris à l'introduction.
Aujourd'hui, on va parler d'Ancible, mais pas seulement,
parce que notre réflexion et notre discussion,
elle reste valable sur tout un tas d'outils,
et notamment les outils d'infrastructure Ascode et de configuration Management,
dont on va parler aujourd'hui.
Alors on va s'appuyer pour certains d'entre nous beaucoup sur Ansible,
parce qu'on est beaucoup à connaître Ansible ici,
mais ça reste valable pour absolument tout.
Pour parler de ce sujet-là avec moi,
j'ai Nicolas, bonsoir Nicolas.
Salut tout le monde.
J'ai aussi René, bonsoir René.
Bonsoir à toutes et tous.
Et enfin, Damir, bonsoir Damir.
Salutation.
Et on va commencer à se poser la première question
de pourquoi est-ce qu'on voudrait réutiliser des modules
des librairies, des playbooks publics,
puisque dans Ansible on utilise le terme playbook,
ou tout un tas d'autres choses qui soient déjà publiées sur Internet,
qui sont souvent libres.
Est-ce que l'un d'entre vous veut commencer cette partie-là
et nous dire pourquoi est-ce que lui-même
utilise des parties libres sur Internet ?
Je peux commencer.
Donc globalement, moi ce que je fais depuis quelque temps,
c'est pour tout ce qui ne concerne pas le métier directement de ma boîte,
donc l'hébergement de notre solution, des choses comme ça,
mais plus l'hébergement d'un CMS pour le site institutionnel,
un blog, des composants un petit peu métier,
mais qui ne sont pas directement liés à notre valeur ajoutée.
Si ça existe sur étagère, que je suis capable de le mettre en place
en un quart d'heure et que je vais repasser
une demi-heure par ci par là à le maintenir,
tant qu'à faire, autant le réutiliser.
Par contre, c'est comme une librairie open source
que je vais utiliser, je vais regarder qu'est-ce que ça va m'apporter,
combien de temps je vais mettre pour l'intégrer
et est-ce que le truc est maintenu, est-ce que le code est lisible,
est-ce que si c'est abandonné, il faut que je puisse le reprendre
et si je peux le faire directement moi-même en 3-4 lignes de code,
je vais plutôt avoir tendance à le réutiliser moi-même
et sinon, c'est Erwan qui s'était exprimé par rapport à ça
avant moi qu'on avait préparé l'épisode, mais qui ne peut pas être là.
Lui, ce qui regarde aussi, c'est toute l'activité sur le Pau,
les issues, les updates, est-ce que les issues sont bien corrigés dans les temps, etc.
Mais aussi, il y a des tests de CIA pour vérifier que tout fonctionne.
Par exemple, si on parle d'Ontibol, est-ce que ça marche bien
dans X version d'Ontibol avec X version de Python
sur des systèmes d'exploitation différents, etc.
et vérifier que ça supporte bien différents systèmes d'exploitation
comme de la Ubuntu, de la Red Hat.
C'est là où moi, je mets un petit bémol par rapport à ça,
c'est quand ça en supporte un petit peu trop
et que quand on commence à les regarder dans le code,
que c'est vraiment trop compliqué et que ça paraît un petit peu tordu
la manière dont c'est fait, c'est là où moi, je me pose la question
de réécrire tout ça moi-même.
Et toi, Christophe, tu gères comment ça, par exemple, sur Frogit ?
Avant de parler vraiment de Frogit, je voudrais juste parler de mes cours,
parce que je donne des cours dans Cible, justement.
Et moi, je conseille à mes étudiants de démarrer tout de suite
en utilisant ce qu'on appelle des rôles dans Cible, donc du code libre
pour la simple et bonne raison, et je crois que Damir va être peut-être
dans mon sens, déjà ça va leur permettre d'être autonome plus rapidement
puisqu'ils vont se baser sur du code qui est écrit par d'autres.
Mais je leur dis toujours à chaque fois, attention,
en plus de dire tout ce que t'as dit pour aller choisir vos rôles,
lisez le rôle pour vous imprégner en fait de comment est-ce que en Cible,
ça se comporte, comment est-ce qu'on écrit du Cible,
allez voir ce que d'autres font, et comme ça, vous allez pouvoir apprendre
plus facilement, parce que mon cours, il est vraiment court,
donc je ne peux pas rentrer dans tous les détails et toutes les bonnes pratiques.
Si je peux remonder juste là-dessus, moi, j'ai un peu la main.
Je suis d'accord avec l'approche, après, c'est vrai que je pense,
ça a quand même d'abord essayé de les pousser à maximum
à faire des choses toute la chaîne, pour qu'ils comprennent bien
les embranchements, entre guillemets.
Mais autrement, au niveau de l'apprentissage, entre guillemets,
il y a quelque chose qui est très vrai, il faut vraiment
qui prennent le temps de lire et de comprendre ce qui a été fait.
Et ça, c'est quelque chose qui est quand même important
et qui est malheureusement pas souvent fait,
en tout cas pas assez fait sérieusement.
Donc, c'est un exercice qu'il faut s'habituer.
Exactement. Et du coup, pour rapprocher la question sur comment on fait pour Frogit,
bah écoute, on fait un peu des deux.
On utilise des briques déjà faites.
En fait, chez Lidra, on a identifié tout un tas de briques
qui nous permettent de configurer des serveurs comme on le veut,
sans avoir à redevelopper des choses.
Donc, on utilise ces rôles là, qu'on maintient un jour
dans un chidre quaihermont.
Et pour Frogit en lui-même, on utilise un rôle
justement qui installe GitLab, mais on l'a complété
avec tout un tas d'autres choses.
Et on est en train justement de se demander
si on ne va pas nous-mêmes développer notre rôle,
parce qu'on atteint les limites des choses.
Et ça, je pense qu'on en parlera dans la deuxième partie de l'émission.
Mais grosso modo, tout ce qui est déjà fait sur Internet,
nous on le réutilise,
Git a justement participé à l'évolution de ces briques libres.
Parce que la question en fait, nous on est tout petit,
on est trois techs,
et du coup on ne peut pas se permettre de maintenir
tout un tas d'outils nous-mêmes.
Je pense que c'est la bonne démarche.
Après, c'est un peu comme une librairie.
Après, plus il va avoir de contributeurs,
mieux ce sera.
Et en fait, c'est vraiment ce qu'on cherche à avoir.
En fait, c'est de simplifier la vie,
et essayer de partir sur un code qui est déjà éprouvé,
testé et fiable.
Oui, c'est ça.
Et puis le fait de participer à du code existant,
surtout si il convient à notre cas,
ça renforce en plus le code qui est déjà utilisable.
Je suis assez d'accord avec Nicolas quand il dit
que quand il y a plusieurs distributions un peu différentes,
parfois les installations, elles sont vraiment hyper spécifiques à chaque fois.
Là, c'est vrai que ça devient problématique,
mais bon, nous on a toujours la même base.
Donc on a identifié nos rôles sur Ansible.
Donc on va utiliser ces rôles-là.
Après, il y a aussi un truc à prendre en compte.
Moi, je sais que quand je faisais de l'Antibole,
j'utilisais beaucoup les rôles de Jeff Garling,
parce que ces rôles sont vraiment excellents.
Je crois qu'il a même fait un bouquin.
Et en fait, c'est quant à des contributeurs comme ça,
alors ça peut être un contributeur personnel comme Jeff,
mais aussi certaines organisations.
Il y a des trucs du style Linux Server,
ou en fait, ils vont maintenir des rôles
et tout va être construit de la même manière.
Et du coup, c'est très facile à maintenir.
S'il y a toute une équipe derrière,
c'est plus simple pour avoir de la fluidité,
parce qu'il y a des montées de versions,
il y a des évolutions dans les produits.
Il faut prendre tout ça en compte.
Et s'il y a plusieurs personnes à contribuer,
ou une seule personne,
mais qui est très veloce dans le sein de mise à jour,
parce qu'elle a vraiment une expertise dessus,
c'est foncé à utiliser ces bricks déjà toutes faites,
parce que vous allez gagner énormément de temps
et refaire ça vous-même,
vous allez prendre un temps fou.
Donc l'intérêt de l'Open Source,
c'est aussi de pouvoir réutiliser des bricks
et quand elles ne vous conviennent pas,
potentiellement ils contribuent.
Et d'ailleurs, contribuer aux bricks déjà existantes,
vous apprendrez énormément sur le produit aussi.
Oui, surtout quand on parle des bricks standard et communes,
typiquement gérés légitisateurs,
gérés du SSH et ce genre de choses,
c'est des trucs qui sont faits partout.
Et donc redevelopper quelque chose,
ce n'est pas forcément nécessaire,
parce que les outils qui sont déjà à disposition
font très bien les choses.
Par contre, nous, ce qu'on fait,
c'est que grâce aux variables, notamment dans cible,
on peut modifier les comportements des rôles,
et c'est ça qu'on fait justement.
Vous avez un autre truc à dire justement
sur pourquoi est-ce qu'on pourrait utiliser
des modules ou des playbooks publics ?
Pour être honnête,
à l'inverse de je pense, le panel ici,
je pense à pas spécialement,
on n'utilise énormément,
on utilise de temps en temps,
beaucoup plus peut-être sur du cube,
mais moins on va dire que la moyenne
de l'équipe actuellement dans le podcast.
On en parlera justement dans la deuxième partie.
Il y a un autre truc,
à pas négliger non plus,
c'est que si on vous demande d'installer un composant
que vous ne maîtrisez pas forcément,
en général, les configurations par défauts
sont assez bien foutues pour partir directement en prod.
Donc par exemple sur du NGINX,
vous aurez les haideurs de prods qui seront désactivés
par défaut,
vous aurez le nombre de workers, etc.
qui seront correctement gérés.
Et ça, c'est pas négligeable en termes de gain de temps aussi,
parce que non seulement vous allez installer
votre produit rapidement,
mais en plus vous l'aurez configuré correctement
pour être prêt plus rapidement à partir en prod.
Exactement.
Une bonne source d'inspiration,
si on veut même sans les utiliser,
créer ces propres modules la soi,
c'est vrai que c'est bien de s'inspirer aussi de ce qui est fait,
ça peut donner des idées,
et puis souvent les gens qui en font beaucoup,
je pense qu'ils ont des bonnes pratiques,
c'est bien de les suivre.
Tu me fais une transition parfaite
sur pourquoi est-ce qu'on pourrait créer des bricks lib,
puisqu'on a parlé d'utiliser,
mais avant de parler à pourquoi est-ce qu'on devrait redevler
pour un usage interne,
je voudrais qu'on parle un petit peu de
pourquoi est-ce qu'on irait nous créer des bricks de ces outils-là,
et notamment je vais vous apporter un témoignage,
et puis après je laisserai la parole à la Damir.
Je vais vous parler de la collection en cible
Why You Know Us, qu'on développe chez Lydra,
puisqu'on a découvert Why You Know Us,
il n'y a pas si longtemps que ça,
il y a deux ans je dirais,
on a commencé à l'utiliser un petit peu,
et on s'est posé la question évidemment
en mode DevOps,
comment on fait pour l'installer et le configurer,
et ce qu'on peut le faire avec un cible,
on a étudié un petit peu les rôles
qui étaient à disposition sur internet,
mais on s'est aperçu que déjà,
tous partaient d'un seul et unique rôle,
ils n'étaient pas forcément maintenus,
ils n'étaient parfois pas irrespectés parfois pas
les bonnes pratiques que nous,
on a édicté en bonne pratique,
celle que nous, on suit,
et du coup on s'est posé la question,
est-ce qu'on ne refraie pas nous-même un rôle,
et on a décidé d'en faire un,
parce qu'on voulait développer un service basé sur You Know Us,
et on a fini par maintenir une collection complète,
donc une collection dans un cible,
c'est un ensemble de rôles,
parce qu'on a étendu le comportement de You Know Us,
au plus loin du plus loin,
on a ajouté des choses par rapport au fonctionnement de You Know Us,
et là on va rajouter encore plein de trucs.
Donc ça c'est un truc,
c'est un thémoménaux,
c'est si vous-même vous créez des briques
qui à l'origine sont libres,
mais qui ne conviennent pas forcément,
et que ça peut être en effet utilisable par d'autres,
pourquoi ne le pas rendre libre,
puisque nous c'est notre objectif,
c'est de rendre libre les choses,
même si on a une partie de notre business
qui utilise cette collection-là,
nous ce qu'on va vendre à nos clients,
évidemment c'est le service et la gestion
qui est tout autour de cette collection,
parce que si on prend la collection et qu'on installe You Know Us,
et qu'on le configure,
ce n'est pas suffisant,
il y a toute la partie d'administration,
infogérance, etc.
Et je laisse la parole à Damir.
Du coup je remonte là-dessus,
pourquoi avoir créé une nouvelle collection,
plutôt que vous avez peut-être essayé de voir
avec ceux qui existaient déjà
pour leur proposer des refactos, des évolutions,
Alors oui, on a proposé au tout début
de participer à l'évolution des rôles existants,
sauf qu'en fait les personnes ne répondaient pas vraiment,
on avait vu que les projets étaient parfois abandonnés,
on a contacté d'autres personnes
qui étaient en voie d'abandon de leurs projets,
donc celles qui nous ont répondu nous ont dit
« reprenez le code, il n'y a pas de soucis,
il n'y a pas de problème ».
Et on a fait une collection après,
parce qu'en fait on s'est aperçu que notre rôle
n'était pas assez modulaire,
et on a rajouté des trucs qui n'étaient pas prévus
par les autres rôles,
notamment tout ce qui est parti backup
qui n'était pas prévu dans Unhost,
on a rajouté un rôle, etc.
les rôles de configuration des applications
et autres.
Et du coup en fait,
il s'avère qu'aujourd'hui notre collection
est la plus utilisée sur Unhost
dans SIDGalaxy.
Donc c'est que en fait,
les rôles existants ne suffisaient pas vraiment
et n'étaient pas mains de plus.
C'est aussi pour ça qu'on a décidé de partir
dans la création d'une autre.
Ok, je pense que c'est intéressant de préciser
pour les lecteurs vu qu'on parlait
de participer à l'open source.
Du coup,
moi,
il y a une des raisons que je vois aussi,
ça peut être quand on est une très petite équipe
ou quand on est une équipe
qui n'a pas forcément toutes les compétences
sur un domaine,
ça peut être intéressant
de créer des projets,
de les partager en open source
pour bénéficier un peu de l'expertise
de la communauté, on va dire,
et pouvoir avoir un peu des retours
sur ce qu'on fait
pour s'améliorer et pour améliorer
son code, quel qu'il soit.
Après, faire attention, parce que c'est quelque chose qui est pas
magique
en attendant, c'est des fois à croire
qu'on met dans l'open source plein de contributions.
La réalité, c'est qu'on va rester assis derrière
son bureau à attendre, on n'en aura pas.
Donc, c'est pas du tout certain,
mais ça peut être un axe aussi
dans certains cas, ou des cas un peu précis
où il n'y a pas beaucoup de projets qui existent
pour, du coup, améliorer les choses.
Après aussi, je pense que
c'est partager la maintenance,
si le projet prend, effectivement,
après ça, c'est...
quelque part, si ton projet
n'est pas en vue,
c'est un moyen d'avoir des contributions
et de partager la maintenance,
et de potentiellement aussi des temps.
Et puis, il y a un aspect aussi un peu...
je pense que c'est un peu aussi un peu ça,
dans ton cas, Christophe, c'est un peu un côté
marketing, tu montres un peu ce que tu sais faire,
ça fait un peu parler, etc.
Après, ça reste modeste,
mais bon, c'est...
c'est mieux que rien.
Je vais rebondir tout de suite,
parce que c'est clairement ça
qu'il y a un côté marketing
de montrer ce que nous, on sait faire
par du code.
Et justement, là,
je prévois de faire quelques vidéos,
justement, autour de ça, pour parler d'un site de Yunos
aussi, pour faire découvrir Yunos,
et comment est-ce qu'on peut l'utiliser dans le cadre
d'une entreprise DevOps.
Parce que je sais qu'il y a pas mal d'entreprises
qui utilisent Yunos comme base
de services en ligne,
et ça peut être une solution.
Et justement, développer
des briques libres, c'est...
une des voies, c'est montrer ce qu'on sait faire
pour obtenir de futurs clients
qui viennent, parce qu'ils ont vu
qu'on savait faire ça.
Je vais rebondir aussi sur l'animation
de la communauté, parce que c'est très vrai.
Une communauté libre, ça s'anime,
nous, on a encore n'était des
tout nos vices, hein.
On n'a pas de contributeurs
extérieurs.
Mais aussi, parce qu'il y a très certainement
très peu encore de personnes qui utilisent
cette solution-là.
Mais je pense que c'est la plupart des
mainteneurs libres, non pas vraiment
de...
contributeurs externes.
A part si ta solution est vraiment utilisée
par beaucoup de monde, type Kubernetes
ou ces gros projets-là,
je pense que t'as des contributions
externes, mais sinon,
c'est très dur d'avoir des contributions
externes, et tu fais pas
forcément du libre pour en avoir.
Je pense que tu fais surtout du libre
pour partager à la communauté
et aider la communauté de manière
globale, en fait.
C'est justement ce que je voulais ajouter.
C'est aussi une des manières de contribuer
à la open source, de montrer le bon exemple
et se rendre compte que,
finalement, en mettant
une partie des compétences en externe,
on vient pas forcément de tout vous pitié.
Effectivement, sur un malentendu, on peut avoir
des retours. Donc, je ne sais pas, tiens, moi,
je l'ai utilisé, j'ai eu tel problème.
Ça va vous éviter d'avoir le problème de votre côté.
C'est, tiens, moi, j'aurais fait comme si,
j'aurais fait comme ça. Bon, bon,
quoi pas. Si vous allez voir
sur mon GitHub, vous verrez
que j'ai mis en open source
des trucs sur Chef, des trucs sur Ansible
et des trucs sur Salstack.
J'ai eu zéro contribution,
mais au moins, j'essaye de jouer le jeu.
Par contre,
ce que ça m'a apporté, c'est que
j'ai des éditeurs de boutins qui m'ont contacté
pour faire des rélectures techniques.
Donc, j'avais fait une nib
pour faire du Proxmox.
Et en fait, ils m'ont contacté
parce qu'ils cherchaient un rélecteur
technique sur la partie Proxmox.
Et en fait,
ça, ça va vous apporter énormément
parce que vous vous faites
connaître sur une techno un petit peu
particulière. Ce qui est
de marrant, c'est que j'ai été identifié
comme un expert de Proxmox, alors que j'en avais pas
forcément l'impression.
Mais du coup, j'ai eu l'occasion
de relire un boutin. Et quand vous avez
l'occasion de relire un boutin en preview,
ça vous oblige
de lire puisqu'on vous paie pour.
Et en plus, vous apprenez énormément
de choses et du coup, vous
progresser d'une autre manière
et potentiellement, vous avez
pouvoir améliorer ce que vous avez mis en open source
après avoir appris des choses.
Pour compléter tout ça, on parlait du côté un peu plus
commercial ou en tout cas mis en avant
personnel. Il y a aussi pour des entreprises
le recrutement fait que
typiquement, donner des
exemples basiques ou des choses
sur lesquelles se reposer. Il y a des étudiants
quand ils vont chercher un peu de la aide soin de
tarte ou comment débuter, ils vont tomber
dessus, ça va les aider et ils vont retenir
positivement de mon entreprise. Donc c'est
aussi quelque chose qui se fait
aujourd'hui.
Oui, et puis
tout à l'heure on parlait
marketing, mais ce que tu dis, Niko, c'est la preuve
sociale, c'est prouver qu'on sait faire
quelque chose et en attendant ça a oublié
mais finalement on n'est pas
tant que ça à produire
du code public
et c'est pas anodin
en fait de mettre à disposition son code
même si c'est à personne. Parce que
comme le dit Damir, typiquement, moi quand je recrute
des gens, je leur demande le lien
vers leur repo, github ou githla
pour aller voir quel est leur code. Et souvent
je ne m'aperçois qu'ils n'en ont pas.
Et donc même participer
un logiciel libre si petit soit
il, identifier
des comites et dire, bah celui-là c'est moi qui les
fais, ça permet au en effet
recruteur de pouvoir nous recruter.
Après ça, il faut se méfier des
approches là parce que je fais beaucoup
de cas où les gens n'avaient pas le droit de comites sur
des repo publics ou des choses comme ça.
Ce qui est aussi un autre
problématique, ils ne sont pas forcément
surtout quand tu débutes, tu n'es pas
forcément le plus grand, non, tu ne peux pas
forcément décider de changer d'entreprise
juste pour une raison comme ça, si tout le reste
va, même après, remarque. Donc du coup
je me, j'avoue que moi je fais un peu
attention à ce genre de entre guillemets
raccourcis, pour le coup,
sur les profits publics.
Mais quand il y a des choses, tu peux
voir que la personne a contribué et que
ses contributions sont pertinentes,
intéressantes, etc. Donc c'est un plus.
C'est ça, c'est un plus, mais ça sera
jamais un moins.
C'est comme, en fait, je le mets, comme
dans toutes les activités qu'on compte un
temps perso. Moi, je voyais mon blog
à donner des cons, c'est plus sur le temps
pro, mais avoir un blog, faire des
contributions, des choses comme ça, pour moi, je le mets un peu
à part. C'est pas
quelque chose que je contré comme un moins, si il y en a pas.

Et pour donner un exemple,
dans ma boîte, on est en train de recruter
un développeur front, pour maintenir
la partie open source du
développement, bah c'est, on dit
aux gens, bah va voir le code, il est
là, donc et puis c'est ça qui va
faire que tu maintiennes. Donc si
t'as des reproches à faire, bah viens chez
nous, tu pourras faire tout ce que tu veux.
On a fait
exactement la même chose quand on a recruté
notre alternant en front, on lui a dit, bah
va voir notre projet, il est public, dis-moi
ce que tu en penses. Ça nous a permis
de lancer la discussion, justement,
à ce sujet-là.
Est-ce que vous avez d'autres choses à dire
sur le pourquoi est-ce qu'on pourrait créer
des big clips ou est-ce qu'on passe à la suite?
Bon, et bien, je vous propose alors
de passer la suite, mais avant de passer
à la suite, j'ai un petit appel à l'action
à faire, puisque suite
à la publication de mon antisèche
guide, je me suis dit que j'allais
en créer une autre et donc j'ai écrit
une antisèche en cible,
puisqu'on parle d'en cible ce soir, ça me permet
de glisser en fait ce petit mot. Donc si tu veux
avoir cet antisèche en cible
et me faire des retours sur celle-ci,
eh bah le lien est en description, tu peux
cliquer et tu pourras obtenir l'antisèche
en cible. Maintenant on va se poser la question
de pourquoi finalement on va
redevelopper des choses qui ont déjà été
développées par d'autres et pourquoi on va les garder
en interne dans notre entreprise.
Puisqu'on a abordé l'aspect
libéré, mais là on va parler
de le garder en interne dans notre entreprise
et c'est Nicolas qui va ouvrir le bal.
Oui, mais en fait, ça rejoint
un petit peu ce que je disais tout à l'heure
par rapport au choix. C'est
à vouloir prendre quelque chose d'un petit
peu trop générique, ça va pas répondre
à 100% de vos besoins et finalement
bah vous allez, si vous essayez
de faire rentrer
votre projet, votre manière de
l'installer dans un truc
public, vous allez essayer
de le faire rentrer au chausse-pied, vous allez
y passer 6 mois et
finalement vous auriez peut-être été beaucoup
plus vite à tout refaire vous-même.
Alors c'est vrai qu'il faut quand même
bien maîtriser le
l'outil avant de commencer à faire
des choses comme ça, mais c'est
ce qui va vous permettre de gagner
du temps sur du long terme, parce que
votre base de code sera quand même plus simple
à lire puisque ça va faire exactement
la manière dont vous l'installer
et ça va pas forcément gérer toutes
les autres distributions, donc c'était
aussi ce que je disais tout à l'heure par rapport
au nombre de distributions. Si vous en avez
qu'une, ça sert à rien de gérer
les 50 autres puisque
vous vous installez un point d'aide, vous installez
un point RPM, mais vous installez que ça
et tous les fichiers de configuration
c'est les vôtres, donc
la partie hyper modulaire que vous pouvez
avoir ailleurs, vous vous en avez pas besoin.
Par contre vous vous avez d'autres contraintes
et des fois les rajouter
dans des trucs un petit peu
à côté, bah
des fois ça fait perdre du temps.
Alors après
ça n'empêche pas de regarder ce qui a été
fait à côté pour s'en inspirer
plus ou moins fortement, alors
j'ai bien dit inspirer et pas copier
coller du code parce que
c'est de la propriété intellectuelle
et c'est pas très
c'est pas très cool pour ceux qui le gèrent
mais
des fois ça va vous permettre
de gagner du temps sur votre
métier.
Ne copiez pas le code et pas le fait
et vous demandez à Liya qui est dans votre
IDE de copier elle le code qu'elle a
trouvé publiquement.
Vous avez le droit de copier coller à partir de stack
overflow mais pas à partir de github, c'est pas bien.
Et après il y a un autre truc
aussi et c'est marrant parce que
avec Arwan on a vraiment la même
vision par rapport à tous ces trucs
là, c'est
avant de
copier un truc aussi
de l'extérieur, c'est pour éviter
d'avoir un truc qui disparaît
d'avoir
des choses qui sont modifiées
en fait il faut bien faire en sorte que
ça soit disponible sur le repository
interne, donc moi je fais beaucoup
sur les images de coeur par exemple
parce que c'est une certaine manière d'avoir de la gestion
de conf, je suis totalement
indépendant et quand je faisais
de l'antibole c'est pareil
les rôles, je les clonais en local
sur mes repositories
je les maintenais dans
un repository de privé parce que
des fois ça disparaît
des repos publics
et vous êtes le bec dans l'eau parce que
tout fonctionne sur un truc
qui existait
à l'extérieur et du jour au lendemain
vous pouvez plus l'utiliser, donc ça c'est pas très sympa
c'est quand vous faites des trucs open source
vous les laissez en ligne, si vous voulez plus
les maintenir vous pouvez le dire
mais c'est pas sympa
de laisser les copains le bec dans l'eau
et donc
je précise qu'il y a une possibilité
dans les dépôts de code c'est d'archiver le projet
ce qui le met en lecture seule
et ça dit explicitement
ce projet est le plus maintenu
mais il est encore à disposition
mais le supprime pas
parce que c'est pas sympa pour ceux qui l'utilisent
l'open source c'est ça aussi
on ne supprime rien
comme dans dit on ne modifie pas l'historique
et quand on publie un truc en open source
on ne l'enlève pas
et donc pour résumer
si c'est vraiment notre métier
qu'on installe un composant
si on revend du poste gréSQL
à la service
c'est pas quelque chose qu'on va mettre à disposition
parce que c'est aussi
là où on a toute
toute notre valeur ajoutée
donc on va
faire en sorte que ça colle vraiment à ce qu'on veut faire
et on va pas forcément vouloir le mettre
à disposition de tout le monde
je suis parfaitement d'accord avec ça
je vais profiter
je prends la parole puis après je laisserai
d'amir intervenir ou renais
nous sur Froguit on a vraiment
cette...
c'est à dire qu'on a pris des rôles
publics mais par contre il y a tout un tas
truc qui est notre coeur business
comment est-ce qu'on fait de tourner notre GitLab
comment est-ce qu'on la configure etc
ça c'est pas du tout dans les rôles publics
c'est dans nos propres playbooks et on garde
en interne et parfois même il y a des gens qui nous demandent
comment est-ce que vous faites
est-ce que vous voulez partager
ou on a un autre sas aussi qui déploie d'une exploit
tu n'es à notre manière
on nous le demande on dit bah non non
ça c'est secret professionnel
on a tout un tas de trucs publics
mais si vraiment vous voulez
bah vous venez chez nous en fait
tout simplement vous venez chez nous
vous prenez le service ou alors
on s'entend
sur une session de propriété intellectuelle
mais bon c'est encore un autre sujet
moi j'ai une question
à poser à Nicolas et peut-être aux autres
parce que cette histoire de dépôt interne
ça m'intéresse
parce que je ne l'ai jamais fait
est-ce que justement vous utilisez des
dépôts privés
et vous prenez le code
de ces dépôts privés
avec en cible ou d'autres
ou est-ce que vous utilisez encore
les dépôts publics et vous avez les dépôts privés
uniquement au cas où
moi
majoritairement ce que je fais
c'est que je clone les dépôts publics
en privé
j'utilise le privé et régulièrement
je regarde si le repository public a bougé
je le réintègre
je vérifie ce que ça casse dans mon infra
parce que bah comme je lance régulièrement
si je fais un dry run normalement
il y a zéro modification
si il y a des modifications je regarde
si c'est bon je pousse dans le repository privé
mais ma base c'est toujours le repository privé
parce que
c'est aussi une manière
de bien gérer le truc
de pas se manger
de pas se prendre les pieds dans le tapis
lors d'un applai malheureux
parce que
au bout d'un moment ce qu'on va vouloir aussi
c'est que toutes les nuits
en face des applaies automatiques
sans se poser la question de dans quel état et l'infra
c'est elle doit être comme ça
donc on applique toutes les nuits
et on écrase les configurations
qui ont été modifiées d'une manière ou d'une autre
si on utilise un truc public
on prend le risque qui est une régression
une manière de un changement de fichier de configuration
des fois on redémarre
des services on a envie que ça soit fait
certaines heures
si ils ont modifié un commentaire
dans le fichier
que ça a remodifié et qu'on redémarre le service
c'est un petit peu dommage
tu utilises vraiment
guide comme un proxy en fait
un proxy de rôle ou de dépendance
après j'ai dit guide
parce que c'est ma manière de sauvegarder
mais s'il y a d'autres trucs
par exemple je parlais de docker tout à l'heure c'est la même chose
j'ai une registrie privée
j'utilise non seulement je versionne
dans guide mais en plus
je pousse ça dans ma registrie privée
et finalement pour tout ce qui est
binaire autre
on pourrait raisonner de la même manière
si on fait du rust
du go du machin
pourquoi aller chercher les trucs à l'extérieur
et pas le reconstruire soi-même
Damir tu veux compléter
oui du coup
dans mon cas actuel
on n'a pas
de choses publiques de mémoire
ou peu en tout cas la majorité c'est sur des repo
privées qui sont accessibles
en transverse au client
après
ça vient aussi du fait qu'on a des choses qui pour l'instant
sont ultra ultra spécifiques
avec des outils extrax sont très spécifiques
donc
ça serait compliqué de le partager
sans
que ce soit incompréhensible en fait
et sans contexte donc il n'y a pas forcément d'intérêt
c'est peut-être quelque chose qu'on étudiera
et c'est ce qu'on voudrait étudier je pense
de ce qu'on avait discuté
quand on refraie un refacto global
voir si on peut découper des bouts pour les mettre
en public
mais si c'est... on veut pas en fait
de mon point de vue et de ce que je comprends
où on est d'une vision
on veut pas mettre en public pour mettre en public
si on met en public c'est qu'il faut que ce soit vraiment réutilisable
il faut pas que ce soit juste en mode
ouf j'ai changé ma permissé en public regardez je fais de l'open source
c'est pas le but
donc du coup
ça va avec tous les contraintes qu'est derrière la doc etc
ce qui fait
que pour l'instant c'est pas trop le cas
et du coup si je peux...
je peux juste compléter
on en parlait tout à l'heure parce que nous on a l'expérience là-dessus
en effet
nous en maintenant
cette collection en cible
ça nous pousse à nous poser
des questions sur l'usage que va en faire la communauté
et on écrit des trucs
qu'on n'aurait pas écrit nous
si on l'avait fait pour notre propre usage interne
et ça nous force
à écrire des choses génériques
comme tu le dis
si c'est trop adapté à un contexte particulier
ça n'a aucun intérêt de le rendre public
voilà
ça n'a aucun intérêt mais il y a beaucoup plus de limiter
je veux dire
ça sera moins réutilisé
ça sera peut-être plus utilisé pour des gens
pour piocher des bout de code
ou comprendre une logique réellement réutilisée en un bloc
autrement
comme on disait
il y a un fait
que les rôles
les choses génériques
plus on va vouloir
les variabiliser
plus ça va durer
à s'approprier
je prends un exemple très simple
qui n'est pas de l'ancible
mais c'est beaucoup plus parlant
ça va être tout ce qui est charte-helme
des fois des choses assez basiques
que je veux utiliser
je vais mettre en place sur du cube
je vois la charte-helme, un fichier de value qui fait 3 km
je vois des conditions go dans tous les sens
en got template c'est très bien
sauf que ça devient très vite imbitable
et on en finit par faire que des générations en local
avec m template pour essayer de debug
on perd plus de temps qu'on en gagne
et dans les cas là je préfère
faire un peu
réinventer la roue entre guillemets
sachant que c'est pas non plus énormément de choses à faire en général
mais je préfère repartir d'une charte 0
quitte à aller voir
si je me plante pas sur des implems
et m'inspirer de la logique etc
mais je vais pas
je vais rarement réutiliser totalement
à part des cas un peu précis comme l'ingresse
etc mais pour des produits
un peu plus purs par exemple qui cloque
je préférerais redémarrer mon truc
de mon côté surtout que je le connais un peu
et on a nos ripos interne
mais on va préférer par-dessus de côté pour éviter cette complexité
complexité qui va nous impacter
pas que pour la mise en place, qu'on gagne du temps
à mettre en place avec des briques libres
mais à contrario
si demain j'ai une brique libre
j'ai besoin de la faire évoluer etc
parce que j'ai un besoin
il va falloir en fait
contribuer
il y a deux solutions, la solution un peu brutale
et la solution un peu plus propre
la solution un peu plus brutale c'est de forquer en privé
ou en public et mettre juste
ce qu'on veut ajouter
ça c'est la solution un peu bourrine
parce qu'au final elle partit pas au projet d'origine
soit il y a la solution un peu plus propre
si j'ose dire qui est de proposer
cette modification au projet d'origine
avec potentiellement des discussions, des échanges etc
et potentiellement si il y a un refus
qui a quand même un côté certain là-dessus
ce qui peut prendre du temps et ce qui peut être
un peu compliqué dans certains contextes
ça c'est quelque chose que j'ai déjà vu
poser problème en tout cas aux personnes
et qui expliquait
le passage en interne
et en général
moi ce qui me rebut souvent
c'est la complexité, typiquement on parle d'Ancibelle
moi on a beaucoup de clients
mais on a un parc ultra homogène
avec en très très très très grande majorité du débian
si demain je dois me taper des playbook
en Decibelle
ou j'ai que des rôles
il y a 5 fois le nombre de tasse pour être sûr que ça tourne
sur toutes les machines et toutes les OS
ça me rajoute de la complexité
ça me rajoute du temps de debug
pas grand chose
donc des fois je préfère un peu
moi vraiment les briques libres je les vois dans 2 cas
le premier cas c'est qu'on ne connaît pas la technone
on a besoin de la mettre en place
on va monter en compétence après
j'aurais tendance à partir là dessus
et encore souvent ça devient une excuse
pour ne pas chercher à comprendre comment ça marche
donc faut un peu l'utiliser
mais il faut pas que ça soit une excuse
le deuxième cas c'est
pour expérimenter rapidement des choses
pour faire un Poc etc
et après se l'approprier ou l'adapter
mais pour le coup
à long terme
j'ai rarement eu des cas, on était très grand gagnant
à part si ça devient un produit qu'on publie nous
pour d'autres choses
auquel cas la c'est devient un peu plus
intéressant
globalement voilà mes petits
points
il y a un truc aussi
que je vais ajouter
par rapport à la réflexion
que j'ai et c'est vrai qu'on en a pas parlé
avant mais moi ça fait
un peu plus de 10 ans
ça a bien tout fait en disant que je travaille
dans des sociétés qui développent des logiciels
open source et dont le business model
c'est vendre l'hébergement de ces solutions
open source
et en fait si je fais le choix
de gérer moi-même
les rôles etc
pour déployer la solution
c'est pas dans mon intérêt
financier, c'est pas dans l'intérêt business
de la boîte de mettre ces composants critiques
en open source
parce que c'est grâce à ça aussi qu'on gagne de l'argent
donc c'est
pour tout ce qui est
c'est pour les sites vitrines
et ainsi de suite où c'est des parties
qui sont pas dans le core business
de la boîte, contribuer
dessus les utiliser
ça me pose aucun problème
par contre simplifier la vie
des utilisateurs qui vont prendre ma solution
open source et l'utiliser en interne
là bizarrement je suis beaucoup moins chaud
parce que bizarrement j'aime bien mon travail
et je veux le garder
du coup je fais en sorte de
garder cette maîtrise là dessus
après il ne faut pas
ça renvoie une connaissance un peu plus large
qui est le business de l'open source
aujourd'hui c'est quelque chose qui est ultra
ultra complexe
disons que c'est
pas tant je pense la complexité qui pose problème
c'est juste que le modèle est totalement différent
que le business classique et ça demande
à penser on va dire son fonctionnement
de cette manière là et c'est pas tout le temps possible
surtout quand des choses ou un business
sont déjà en place donc effectivement
ça peut être aussi
un gros frein et je dirais même
comme je disais tout à l'heure et j'insiste là dessus
parce que je vois trop souvent le cas
faire de l'open source c'est pas juste
publier quelque chose c'est d'assurer la maintenance
ça va être assurer
du coup le support, les réponses
dans étiqués etc et le nom
de fois parce que quand je pars de zéro
je vais quand même chercher s'il y a déjà des choses qui existent
ne serait-ce que pour voir si j'ai loupé
quelque chose dans l'install ou dans la logique
au moins relire un peu le code
sans
un grand troll entre guillemets
60 à 80% du temps
les projets ont
soit c'est des très gros projets
qui sont des top projets etc
soit ce sont des projets qui n'ont jamais vraiment eu
de contribution externe
des projets qui n'ont jamais vraiment eu
de grosses mises à jour et qui sont des fois
plus à jour parfois il y a des comites
qui datent il y a plus de 2-3 ans
et dans les cas là
moi ça m'inquiète en fait et c'est là aussi
un problème c'est qu'on a pas la maîtrise
du cycle de vie en fait quand le projet
est à l'extérieur
on sait pas s'il est le mainteneur va partir
ou pas alors il y a des mainteneurs qui font très bien
leur entre guillemets travail
entre guillemets quelque chose qui disent
j'ai plus le temps de m'en occuper donc si vous voulez le reprendre
tant mieux si vous voulez pas le reprendre tant pis
mais le projet est plus maintenu mais il y a aussi beaucoup de cas
où les personnes ont juste laissé le projet dans un coin
et ça ne charge pas et pour moi dans ces cas là
moi
on oublique l'open source aussi
c'est gérer en fait tout ça gérer
ce fonctionnement
c'est mis à jour c'est pas juste publié
quelque chose de dire c'est publié j'ai fini je fais mon taf
d'ailleurs
de l'autre côté pour les entreprises qui utilisent des briques libres
si vous pouvez pas aider au développement
pensez à aider sur de la doc
pensez à aider avec des donations financières
potentiellement pensez aussi à ces choses là
qui peuvent aider justement les
projets communs
à un peu s'améliorer et surtout à se maintenir
dans le temps parce que c'est pas simple
comme disait Nicolas notamment avec
la partie on va dire financière
et model économique
je pars un peu dans tous les sens je vois
c'est pas gentil de critiquer mais
contribue tout mes ripos open source
après ça m'est souvent plus sérieusement
ça m'est arrivé 2-3 fois
que les gens viennent me dire ah bah tiens
là j'ai une issue et je leur dis
bah écoute j'ai plus le temps de travailler dessus
fort que le mais le dans ton coin
le seul truc que je te demande c'est de me citer
dans les crédits du truc à l'origine
mais si ça permet de faire aux gens de gagner du temps
sur le bout de strap du truc
moi je dis tant mieux et je considère
que l'open source c'est ça aussi
c'est faire grandir la
masse de trucs qu'on peut faire
et tu réutilises un truc
ça te fait gagner du temps
bah t'essayes de contribuer dessus
soit en l'utilisant et en rapportant
des problèmes et si ça
si ça n'est pas maintenu
et que tu as les compétences
fort que le discute avec les gens
moi je pense que la plupart des contributeurs
enfin des mainteneurs d'origine
quand ils ont créé le produit et qu'ils n'ont
plus le temps de le maintenir si tu leur demandes
je pense qu'ils seront très heureux de te transférer
le repo pour qu'ils puissent
maintenir sa chaise
d'ailleurs il préfère on ça plutôt que de voir
le projet péréclité et tomber
tomber et ne pas être maintenu
voilà
c'est une bonne manière aussi de
des fois on cherche un projet à faire
ou des gens qui veulent s'impliquer
c'est parfois une bonne solution
de reprendre le projet de quelqu'un
et je voulais juste
ajouter quand même quelque chose
côté par exemple en tibol galaxy
une des difficultés
enfin ça c'est plus une expérience perso
c'est qu'il y a souvent énormément de choix
et je trouve que c'est ça
qui est
difficile en fait c'est qu'on a
énormément de choix donc il faut passer beaucoup de temps
à choisir
le projet
éventuellement qu'on veut utiliser
et si c'est un besoin basique
c'est vrai que c'est pas forcément peut-être
une bonne pratique mais on a tendance
parfois à se dire bon ce que je veux faire
c'est basique je vais le refaire j'irai aussi vite
voilà je pense que c'est ça c'est
une difficulté et puis l'autre
difficulté un peu d'expérience de ça
c'est que parfois on veut juste effectivement
faire un truc un peu petit assez basique
et on se retrouve en face de rôle qui sont
beaucoup plus complexes
beaucoup plus complets et voilà ça c'est
peut-être un peu le côté
qui fait que ça freine un peu la
réutilisation
pour ce genre de briques
exactement et d'ailleurs
juste
quand on cible
à créer les collections
je pense qu'on redate
à créer les collections je pense qu'il a fait
un bon choix parce que ça je pense
va permettre de
faire maissir les rôles et des rôles
qui faisaient tout et n'importe quoi vont devenir
des petits rôles dans des collections qui font plus
de choses
je laisse la parole à Nicolas
oui c'est vrai que ce que disait René
moi ça m'est arrivé tu veux juste installer
un njignix un redis ou je sais pas
quoi dans une configuration hyper basique
et en fait comme s'agère
40 distribs
c'est la gif, les setup, les machins
et en fait l'exécution te prend
5 minutes alors que si tu l'avais
écrit tout à même c'était plié en moins
de 2 minutes
exactement d'ailleurs
nous c'est ce qu'on a fait en fait on a
séparé complètement l'installation
de la configuration
de Yunost et de la configuration
des applications parce que Yunost
permet d'avoir des applications
donc on a fait plusieurs rôles
et on a séparé aussi le backup donc ce qui nous
permet de lancer les rôles quand on veut
et de faire ce qu'on veut sur les rôles et de pas
avoir tout dans un seul gros rôle qui fait le café
et ça aussi
c'est un autre truc qui peut être envisagé
alors je sais plus si
dans un cible on peut le faire de manière
aussi fine mais moi côté
sale stack ce que je fais de plus en plus
c'est j'importe un rôle existant
je le surcharge de mon côté
parce que j'ai quelques
rôles qui sont que je prends
en open source c'est pas critique
c'est pas les trucs de mon
métier donc encore une fois j'essaye
de prendre des trucs qui existent sur étagère
pour gagner du temps par contre
j'ai des petits trucs spécifiques à mon installation
et des fois on peut surcharger
et quand c'est un rôle qui s'exécute rapidement
prenez le
et puis si c'est pas possible
de juste le surcharger
en réutilisant
je crois que c'est le fait d'importer
un rôle dans un cible
on peut rajouter des triggers
sur certaines actions
et si c'est pas possible
copier, coller les actions
dans votre truc comme ça ça sera
plus simple et plus rapide
je sais pas si c'est possible
de surcharger un rôle honnêtement
on peut faire des tâches
après avant mais je sais pas si
ça peut être possible
quand je dis surcharger
je veux écrire un
de fichier de configuration à moi
et je veux que le service soit redémarré
après que ce fichier a été modifié
ou créé ok donc tu complètes le rôle
en faisant tes propres tâches
en effet c'est largement possible de faire ça
avec un cible
je l'avais fait à l'époque mais
je sais plus dans quelle manière
c'est possible
après je pense qu'il faut aussi un peu se méfier
parce qu'il y a peut-être un vieil aussi
quand on le fait soi-même on croit toujours qu'on va aller plus vite
et ça je pense qu'il faut quand même
mettre un peu méfiant parce que des fois ça prend
souvent plus de temps qu'on imagine
et puis souvent on loupe
aussi des cas
un petit peu à la marge etc
donc
voilà
d'ailleurs ça me fait penser qu'on n'en a pas parlé
de ça du retour sur investissement
et donc je pense qu'à mettre dans la balance
développer ses propres rôles
ou utiliser des rôles
qui existent déjà comme le dire René
on doit mettre dans la balance
le temps de développement qu'on pourrait estimer
et est-ce que c'est un bon retour
sur investissement de le faire nous-mêmes
ou d'utiliser un truc et le tuner un petit peu
comme l'a dit Nicolas et ça c'est des questions
à se poser avant de commencer
je pense que c'est un deuxième biais
c'est le biais du noten 20 dire
c'est-à-dire qu'on aime bien faire son truc à soi
parce que quand tu fais ton truc à toi
c'est quelque part plus
c'est ton truc
tu sais comment ça va marcher
tu n'as pas besoin de te... tu l'as pensé
et voilà t'es pas obligé de rentrer dans le code
de quelqu'un d'autre qui est souvent plus difficile
donc voilà je pense que ça
c'est un biais quelque part
qui peut être un peu trompeur pas toujours
mais du coup
tu as le problème à un verre
parce que quand tu as une personne qui arrive dans l'équipe
si c'est des rôles open source
qui ont déjà été utilisés ailleurs
si il y a les a déjà utilisés
enfin ou la fille
on réutilise
toute la même manière et pas
font des opérationnels
moi comme je refais tout moi même
les gens ils arrivent et bah tu te prends un mur
parce qu'il y a énormément de codes à lire
avant de comprendre quoi que ce soit
alors je pense
non mais juste
personnellement je n'ai jamais
jamais eu le cas en réveillant des projets
on va dire livres que ce soit en decibel
ou plus terraformes
j'ai jamais eu le cas où je suis tombé sur une boîte
qui a eu de serres un truc que j'ai déjà déjà déjà dans une autre boîte
qui soit publique
ça pour le coup je pense que c'est
le pourcentage de chance et quand même assez faible
mais d'un autre côté
moi souvent ce que j'ai c'est
je prends un code public
que ce soit truc ou autre
bah même si je veux gagner le temps
en ne récrivant pas
le temps que je lise comment ça a été fait
que je le comprenne surtout s'il n'y a pas de doc
ou je dois comprendre l'intention avec le code
c'est très chronophage aussi je pense
que dans tous les cas c'est très compliqué de
en fait justement ce choix
de savoir qu'est ce qui est le plus rentable entre
partir de zéro ou partir sur un truc existant
c'est pas quelque chose qui est simple
il y a énormément de paramètres à prendre en compte
que soit si le projet est encore maintenu ou pas
à quel point il est encore maintenu
l'insur... mon de moi
l'insécurité par rapport à cette maintenance
c'est ce que ça va continuer est ce que
il y a un mainteneur dans son coin qui fait tout seul
est ce qu'il y a une équipe d'une dizaine de personnes
qui bossent dessus il y a plein de choses comme ça qui sont
à se poser la complexité
le fait que bah reprendre
ça peut être chronophage aussi comme tu disais renais
il faut tester tous les cas etc
et je pense que faire cette balance en fait
c'est assez complexe dans certains cas
on peut pas la faire précisément
on peut aussi parler
de comment
on crée un nouveau rôle
moi j'ai un
un pote à moi qui me demandait
mais tiens bah comment est ce que tu fais
on a pris un cas concret on a pris un produit
et en fait
quand c'est quelque chose que je connais un minimum
je regarde la doc
et en fait j'écris directement le rôle
et je réécris ça dans
l'outil de gestion de conf
que ce soit de l'antibole du cell stack
peu importe tu réécris au fur et à mesure
et en fait à la fin si ça fonctionne
tu peux le réinstaller autant de fois que tu veux
sur autant de serveurs que tu veux
après sur un produit qu'on connaît pas
on peut vouloir l'installer
à la main en notant les commandes
dans un fichier pour pouvoir
le reproduire plus rapidement après
et si on se rend compte que
la masse de boulot à faire est pas si énorme
bah ça vaut peut-être le coup de le transposer
dans un rôle on peut aussi
essayer un rôle on prend
une machine toute neuve dans un coin
en plus avec le cloud
maintenant on peut faire du crash
un destroy
on bootstrap une nouvelle VM
on lance le rôle dessus
on se rend compte que c'est rapide
ça fonctionne à peu près comme on veut
et ben hop on y va on l'utilise
c'est je pense qu'il faut aussi
avoir une petite phase d'exploration
pour regarder quelle est la complexité
du rôle à quel point je peux l'utiliser
combien de temps ça me prendrait
pour le réécrire et ainsi de suite
je vais rembondir
sur ce que t'as dit parce que
moi c'est ce que je conseille
à tous les membres de mon équipe
quand on
quand on doit faire quelque chose
quand on doit automatiser quelque chose
qui n'a encore jamais été fait
on part pas directement comme tu l'as dit
dans l'écriture
on le fait manuellement pour bien comprendre
les enjeux, les commandes etc
on le fait une première fois
une fois qu'on est au point sur ce qu'on a fait
on automatise
je trouve à titre personnel que c'est la méthode
la plus rapide pour
développer des rôles d'infrascodes
c'est de tester d'abord
d'automatiser ensuite
trop souvent au début de ma carrière
j'ai écrit les trucs
je voyais que ça ne marchait pas
j'ai modifié mon code et tout et alors qu'en fait
maintenant je le fais à la main
j'ai trouvé la bonne solution
et j'automatise que j'ai fait à la main
je pense que ça dépend du produit
et ça dépend de l'expertise que tu as sur la solution
si tu maîtrises en decibel
tu ne vas pas forcément mettre beaucoup plus de temps
pour le faire parce que
si c'est installer un package, créer un fichier
de configuration et s'assurer que le service
est up au démarrage
tout le monde sait faire ça en decibel
si tu commences à voir des trucs
un petit peu compliqués, aller chercher une adresse IP
d'un service pour aller le mettre
dans un autre etc
là oui ça c'est clairement, il faut le faire à la main
mais encore une fois c'est
une réflexion à avoir un petit peu
en amont avant de se lancer
la tête dans le guidon
et de se prendre le mur
à la fin
c'est évaluer combien de temps
vous allez mettre pour l'écrire
et vous gagnerais du temps sur du long terme
je voulais juste ajouter un tout petit truc
c'est par rapport à ce que je fais
c'est ça que tu voulais dire tout à l'heure Nicolas
mais le fait aussi quand même peut-être
faire attention à ça quand on écrit
son propre playbook etc
on le fait pour soi
et je pensais
c'est ce que tu voulais dire
c'est que quand il y a des nouveaux qui vont arriver
faut faire attention à pas prendre trop de raccourcis
parce que quand on le fait pour soi on sait
ce qu'on a voulu faire etc
et quand il y a des nouveaux qui vont venir
peut-être exploiter ce truc-là
il faut quand même
garder un niveau de
commentaire etc
de bonne pratique pour que
pour que les gens puissent
comprendre ce qu'on a voulu faire
on réfléchit pas tous de la même manière
et du coup parfois ça peut être
difficile de reprendre parfois
l'importance de la doc dans les cas-là
c'est de commenter
de compléter avec l'intention le code
qui ne le retranscrit pas tout le temps
exactement
tu peux avoir malheureusement
quand tu le fais pour toi
un peu se raccourcir de se dire
ouais bah je sais ce que j'ai voulu faire
bon très très bon après tu vas peut-être pleurer
mais voilà faut faire un peu attention
je pense à ça quand on refait
quelque chose d'être sûr qu'on le fait
avec un niveau de qualité
similaire à ce qu'on aurait pu reprendre
mais ça pour moi c'est du coup
même en interne
c'est bien d'avoir une definition of
down de rôle et de choses comme ça
qui dit que les choses sont
par exemple le projet est fini quand tout est explicité
y compris du coup
les cas un peu complexes etc
et bah merci
oui on revient juste un peu
ce que je disais c'est que souvent on sous-estime
qu'on fait soi-même un petit peu le temps que ça va prendre
oui ça c'est vrai par contre
les deux choses que tu as dit sont vraies
et pas que dans le code
d'infrastructure c'est vrai dans le code
de manière générale
et je vous dirais plus
c'est
rajouter aussi des tests
type test infra etc
et si possible dans une CIA
parce que ça va vous faire gagner
énormément de temps sur du long terme
et surtout si vous travaillez
à plusieurs mots aujourd'hui je suis tout seul
dans mon infra bah vous
comme le disait René je le fais pour moi
donc je sais que le jour où
une personne va rentrer dans l'entreprise
pour travailler avec moi
il va y avoir une certaine inertie pour rentrer
dans après d'expériences
je sais que ça peut se faire assez rapidement
parce que je suis
premier à râler
sur ce que j'ai fait il y a 6 mois
quand c'est pas intelligible donc du coup
je m'arrange toujours pour que ça soit lisible
mais bon des fois on est dans le rush
donc
et d'ailleurs on a prévu
de faire un prochain podcast
un jour sur les tests d'infrastructure
on attend pour le faire
mais ça arrivera un jour ou l'autre
est ce que vous avez des
des choses à ajouter
ou je passe à la conclusion
de cet épisode
non ça me paraît bon
et ben on va passer
à la conclusion de cet épisode
donc comme tu l'auras compris
maintenir des logiciels libres
ça demande du temps et des moyens
créer du contenu libre
ça demande aussi du temps et des moyens
donc si tu apprécies le podcast
et si tu veux qui continue
à venir
à t'apprendre des choses
et ben tu peux nous soutenir
grâce à un don si tu peux
sur soutenir.compagnons-devops.fr
ça nous aidera
à payer les infrastructures, les outils qu'on
utilise et ça nous permettra
de continuer à faire des épisodes de podcast
encore longtemps en tout cas
je l'espère et
moi je vais me tourner vers mes co-animateurs
et leur laisser le mot de la fin
et cette fois-ci je vais commencer par Damir
ben du coup
si vous utilisez de l'open source
ou des produits partagés
n'oubliez pas de contribuer aussi
Nicolas
un petit mot
je vais piquer l'idée de Damir
sur la documentation
et je vais rajouter les tests
si vous faites des trucs en interne
n'oubliez pas que vous êtes vos premiers clients
et René
tu as l'honneur, la signe honneur
d'avoir le mot de la fin de la fin
je ne sais plus quoi dire maintenant
je vais vous souhaiter une bonne écoute aux auditeurs
et à bientôt pour un prochain podcast