Bonjour à tous et à toutes et bienvenue dans un nouveau numéro de DevOps.
Alors aujourd'hui, je suis accompagné par Mathieu.
Salut.
Tu as déjà eu dans un présentant podcast.
Je nous avais présenté ton offre CAS, donc de Kubernetes Service que tu avais chez ExoSkyle.
Aujourd'hui, on va parler de Bache, alors Bache, l'interprèteur de commande et plus
généralement en fait des scripts.
Et là, pour le coup, je te laisse te présenter.
En effet, j'étais déjà venu dans le podcast, donc merci encore pour cette nouvelle invitation.
Je m'appelle Mathieu Corbin.
J'ai travaillé comme administrateur système et ensuite comme développeur, mais appliqué
à de l'infra chez un cloud provider chez ExoSkyle pendant presque quatre ans.
Et c'est là, en effet, que...
Enfin, j'étais encore chez ExoSkyle quand j'étais intervenu la dernière fois.
Maintenant, je suis repassé à SRE, donc dans chez Konto, qui est une startup française.
Voilà pour la présentation.
Voilà, j'ai pas grand-fauze d'autres à dire, à part que je te vois un peu des deux côtés,
côté Dev.
Enfin, sans ma carrière, je ne veux pas soit Dev, selon mes envies, on va dire.
J'ai un peu la double casquette.
C'est cool, enfin, voilà.
C'est-à-dire quand même qu'il y a eu du changement depuis la dernière fois où tu es
interprète.
C'est ça, avec un poste différent aussi.
Je t'invite donc aujourd'hui pour parler en fait d'un sujet un peu d'actualité, alors
d'actualité.
C'est un peu bizarre de dire d'actualité quand on parle de Bache.
Mais t'as écrit donc il y a déjà presque deux ans, je crois, un article sur Bache que
tu vas pouvoir nous résumer.
Et il faut dire qu'il a été assez repris dernièrement avec des personnes qui l'ont
commenté et t'as même dû faire encore une réponse par rapport à ça.
Mais on va en discuter maintenant.
Et donc le format de ce podcast, ça va être vraiment d'être une réaction par rapport
à ce sujet, de voir donc ton opinion, ton avis, le comprendre peut-être un peu plus
et voir après ce qu'on peut en tirer, voir ce que tout le monde va pouvoir en comprendre.
Je te laisse peut-être résumer d'ailleurs à la base pourquoi t'as créé cet article.
Il y a quelques années.
En effet, j'ai fait mon premier article en décembre 2020 et je voulais aussi commencer
par ça parce que c'est parti d'un constat cet article.
Moi j'ai commencé ma carrière en grand groupe dans des missions en grand groupe où
tout était fait d'ailleurs en KSH.
Avec des scripts de plusieurs milliers, voire dizaines de milliers de lignes où vraiment
tout était fait.
Mais quand je dis tout, c'était tout.
Même il y avait un espèce de système d'innit maison en KSH.
Tous les scripts de déploiement étaient en KSH.
Il y avait encore de la X.
Donc voilà, c'était un contexte assez compliqué.
Et pour être honnête, c'était ingérable.
C'était vraiment ingérable, immatenable.
Ça plantait en permanence.
C'était des scripts en plus non versionnés avec un historique écrit en commentaire en
début de script.
Donc ça se passait un peu comme ça de personne en personne.
Et dans mon équipe, on essayait un peu de se débarrasser de ça et de moderniser vraiment
la stack.
On était la première équipe à parler de déploiement continu, un frascode ou des choses
comme ça parce qu'on avait beaucoup beaucoup beaucoup de problèmes avec le shell.
Donc là, je vais dire shell, on peut parler de shell et pas forcément que de bash.
C'est vraiment tout ce que je vais dire sur bash.
Pour moi, ça plie également KSH ou d'autres shell.
Mais voilà.
Il y a déjà ce constat là de faire de l'infra avec un gros coup de script.
Ça ne marchait pas.
Ce n'était pas ma table sur le long terme, on pourra revenir sur pourquoi.
Ensuite, j'ai évolué, j'ai changé d'entreprise, j'ai travaillé beaucoup sur de la CI CD.
J'ai travaillé en tant que SRE.
Il y a quelque chose vraiment constant pour moi que je vois en permanence, c'est quand
il y a du shell qui est un peu trop utilisé, c'est-à-dire des scripts trop longs ou avec
de la logique.
Donc quand la logique, ça va être des boucles, des conditions, de la logique peut-être
métier aussi.
Alors, ça peut être même côté infra, notre métier, c'est de déployer des choses.
Donc dès qu'il commence à avoir vraiment de la logique, etc., il y a des erreurs,
il y a des scripts qui plantent, c'est souvent des scripts avec une gestion d'erreur difficile,
des bugs subtils.
J'en ai encore eu un ce matin, bizarrement, quelqu'un qui avait oublié dans un script
de déploiement continu des espaces.
Vous savez, autour d'un comparaison Bache, autour de l'opérateur égal, parce qu'à
une comparaison en Bache, c'est une fonction, ça prend un certain nombre de paramètres.
Donc si vous collez, si vous enlevez des espaces entre une comparaison de chaîne, par exemple,
et le égal, ça plante.
Donc voilà, il y a vraiment cette consente au long de ma carrière où à chaque fois
qu'il y avait du shell utilisé, ça marche et mal.
Et d'ailleurs, je vais parler avec beaucoup de gens qui n'étaient pas forcément d'accord.
Et je me souviens d'ailleurs, une réflexion que j'avais faite à quelqu'un une fois,
je lui ai dit, je suis sûr, prends ta collection de scripts shell qui était sur GitHub, regarde
ton historique, je suis sûr que tu vas voir fix-up, fix-up, fix-up, fix-up, et c'était
le cas.
Je veux dire, c'est vraiment quelque chose que j'ai vu.
Et finalement, avec le temps, je me suis dit, mais moi, il y a un truc que je ne comprends
pas, c'est qu'aujourd'hui, finalement, nos scripts, déjà moi, je ne fais pas vraiment
une distinction sur le script des programmes, c'est que nos scripts, c'est des vrais programmes
au final qui ont besoin d'être maintenus comme des programmes classiques.
Je ne fais plus l'indistaction en disant, voilà, ça c'est un script, ça c'est un programme,
et ils ne vont pas avoir le même cycle de vie ou les mêmes outils pour les utiliser.
Pour moi, les deux, c'est des programmes.
Et pourquoi ne pas, et moi, je faisais beaucoup de devs, comme j'ai dit, je travaillais aussi
également tant que devs, je me disais, mais pourquoi on n'utilise pas les mêmes outils
que les développeurs pour faire nos scripts ? Pourquoi on ne s'inspire pas d'eux ? Et j'ai
l'impression que dans l'administration système, il y avait un peu cette chose de dire, les
développeurs, ils doivent faire des tests, il y en a marre des devs, c'est un truc classique,
si ça admine Grognon, il y en a marre des devs qui poussent des bugs, etc.
Mais par contre, alors pour les scripts internes, là, c'est open bar, il n'y a aucun problème
à y aller en mode YOLO, balancer des scripts fait à la rache sur un point de table en
prod, là, ça ne posait pas de problème.
Donc il y avait aussi un peu ce truc-là qui m'a gêné, et je me disais, mais voilà,
pourquoi on fait ça, surtout dans le monde d'aujourd'hui, on peut en reparler,
où finalement, ce n'est pas de l'humain qui pilote de l'infra, c'est des problèmes.
Et donc j'ai écrit ce premier article où je montrais certains points limitants de bâches,
selon moi, enfin je dis selon moi, mais au final, il y a des fausses, enfin, c'est de la
tech, donc c'est difficile de... ce n'est pas du mensonge, je veux dire, on va pouvoir revenir
sur ces points. Et en effet, l'article, il ressort de temps en temps, en fait,
et là il est ressorti récemment, donc j'en avais fait un deuxième pour clarifier certaines
choses. Et voilà, mais au final, cet article là-bas, c'est là, par un constat,
enfin deux constats, c'est plein d'erreurs dans les scripts bâches, et mais en fait,
pourquoi on fait du bâche ? Pourquoi on ne fait pas autre chose ? On fait du bâche parce que il y a
dix ans, on faisait du bâche, où il y a vingt ans, ou du KSH, je ne sais pas, il y a d'autres outils
aujourd'hui et d'autres philosophies, vous dites aussi de... pour écrire des programmes, je pense,
pour faire de l'administration système.
C'est vrai que là, je te rejoins complètement, il faut voir que, je le précise, j'ai fait des
invitations un peu plus larges pour avoir d'autres avis dessus, donc là il pourrait y avoir aussi
un droit de réponse ainsi qu'un veut. Malheureusement, on est deux personnes qui avons à peu près la même
opinion, parce que moi c'est vrai que dans mon expérience, je partage totalement l'expérience,
j'ai déjà été dans des compagnies où absolument toute la prod tournait avec un seul script shell,
je me suis dit que c'était du bâche, je pense que c'était du bâche quand même, toute la prod tournait
avec un script bâche, c'est à dire que c'était tous les programmes de la prod qui tournaient en
étant préfixés par ce wrapper, ce wrapper il n'était pas testé, il avait... alors on avait quand même
mis dans un guide, mais en fait il était dans un guide lié à un cookbook chef, c'est à dire qu'en
fait il suivait le cycle de vie d'un cookbook chef, il n'était pas du tout lié avec son propre
cycle de vie, donc il n'était pas testé, en fait il était juste... c'était un asset dans le
déploiement, alors qu'absolument toute la prod tournait sur, on n'avait pas de linting,
on n'avait pas de test dessus, on n'avait absolument rien, et c'est vrai que c'est un point qui revient
assez régulièrement quand on regarde les scripts shell, c'est qu'ils n'ont pas une qualité très
forte, et alors quand ils commencent à avoir une qualité très forte, tu l'as parlé de la gestion
d'erreur, mais moi je peux parler aussi de la gestion des entrées, de toutes les options qu'on
peut mettre dedans, etc. Tout est possible de faire, il faut voir que shell ou bash va être un
langage tournage complet, donc globalement on va pouvoir faire à peu près ce qu'on veut avec.
Le problème c'est que soit il est simple, et il est simpliste, il ne gère pas tous les cas,
et il va avoir beaucoup tendance à planter, soit il devient extrêmement verbeux, et il va tester
beaucoup de cas, et dans ces cas là il devient absolument illisible, et il devient même très
compliqué à faire évoluer de manière propre, et donc on arrive au constat que tu as dit,
c'est des fixups un peu tout le temps, un niveau de qualité qui est faible, et c'est assez dommage
parce que, et je pense que ça c'est un constat qu'on pourra avoir, c'est qu'on touche à de la
fonctionner, qu'un petit script qui fait un joli hello world sur une page web, on parle pas du
même niveau de qualité qu'un script javascript juste shiny, on parle vraiment de la prod,
c'est vraiment dommage d'un an, donc là j'ai donné juste un exemple parce que c'est vraiment celui
auquel je pense, et donc toi justement dans l'article est ce que tu donnais, parce qu'on est
il y a quoi par exemple comme choses qui sont limitantes pour toi quand on parle de bâche
et même de tous les chels en règle au général que tu listais ? Oui, on a déjà listé certains
finalement, certaines, la gestion d'erreur pour moi c'en est une, alors bien sûr on peut faire du set
etc pour stopper un script où il y a des erreurs, on peut faire, voilà, checker des statu codes,
des commandes qui sont appelées, etc, etc, mais on est très très loin d'une gestion d'erreur dans
un problème, comme dans un problème, désolé, comme dans un langage de programmation, voilà,
j'ai arrivé classique, que ce soit des stack-trace, des types, erreurs, etc, ça n'a rien à voir et
d'ailleurs il y a beaucoup de choses qui sont dures à expliquer, je voudrais juste revenir la
suite dans mes articles, c'est qu'en fait souvent je parle à des admin-sys de ça,
d'autres choses que je vais mentionner, en fait ils me disent oui mais non, mais je ne suis même
pas sûr qu'ils comprennent parce qu'en fait c'est des concepts souvent de dev, c'est-à-dire quand
je vais parler, voilà je parle de choses parfois des sys admin, mais sans avoir les notions de
développement de base pour comprendre ces choses-là, c'est compliqué de voir l'intérêt que ça en
fait, une gestion d'erreur, par exemple type P, un type Résulte, ou une gestion avec des exceptions,
des stack-trace, etc, etc, et ça c'est quelque chose de très commun, c'est à dire c'est en fait
un manque de connaissance pour moi et c'est dur quand il manque une connaissance de dire qu'est-ce
que ça m'a porté, parce qu'en fait je ne connais déjà pas c'est quoi le truc, le concept,
donc voilà, je voulais juste dire ça avant parce que je vais parler de beaucoup de concepts de dev
en effet et ces concepts-là, si en tant qu'OPS on les maîtrise pas, tant qu'administe on les
maîtrise pas, on ne peut pas comprendre leur intérêt et ça c'est un point très important.
C'est vrai que je voulais y aller après justement, et ça c'est que tu soulèves le point principal
en fait du pourquoi tes articles vont revenir et pourquoi on a cet attachement souvent à Dache,
c'est en effet que c'est très simple à prendre en main, mais en même temps va avoir énormément
de soucis ensuite et en effet si jamais on ne connaît pas ce qu'on peut faire d'autre,
c'est dur de l'imaginer en fait, on ne sait pas ce qu'on ne sait pas et on ne sait pas ce
qu'on ne connaît pas et en fait on a à peu près le même problème quand on a des gens qui font du
PHP et du Python, dans le sens où c'est le premier langage de programmation que les gens vont
accéder. C'est un langage extrêmement simple à prendre en main qui permet de faire beaucoup de
choses et en fait pour quelqu'un qui fait du Python au quotidien, c'est dur de lui dire qu'il peut
y avoir d'autres langages meilleurs sachant qu'il est déjà capable de tout faire avec du Python
et que globalement ça répond à tous ces problèmes actuels. Je pense qu'on a à peu près le même
problème avec les admin 6 qui font du Bache, c'est que depuis 20 ans en fait du Bache,
on est capable de faire absolument tout avec. C'est dur de l'imaginer qu'il puisse y avoir
autre chose qui le fait mieux. Soit ça veut dire qu'on s'est trompé depuis 20 ans, soit ça veut dire
qu'au final ça va être shiny et je vais y perdre trop de temps derrière à apprendre quelque chose
d'autre et je vais quasiment avoir un système de perte irrécuperable. C'est à dire si jamais je
passe à un nouveau système, à quel point je vais perdre la connaissance que j'ai déjà accumulée
avant parce qu'au final il faut voir que ces admin 6 qui font du Bache, c'est des gens qui connaissent
extrêmement bien Bache. Enfin en tout cas des petites subtilités du langage de faire des parsing
de ligne de commande avec du Bache, avec des get-ups etc. C'est un truc qui immonde,
mais quand on le connaît sans doute que ça va vite, en tout cas on le voit vite. Et on a même
aussi souvent ce problématique qui vient régulièrement qui est si j'ai besoin de Bache une
fois, pourquoi j'aurai à apprendre un autre langage alors qu'il faut que j'uniformise,
que je standardise et donc si je fais du Bache une fois, je vais faire du Bache tout le temps.
Et ça on le retrouve aussi dans d'autres écosystèmes.
Et je dirais aussi un truc, c'est qu'aujourd'hui ça va très vite. C'est à dire qu'il y a un peu
aussi un truc dans l'administration système que j'ai vu au cours de ma carrière et très souvent sur
les réseaux sociaux, c'est à dire que plus on utilise des trucs un peu bas niveau etc,
plus on est hardcore un peu. Ouais moi je suis tout au moins en Bache, je connais très bien le
Big Boss parce que voilà je fais des trucs super low level ou super tipeee admin 6 et dès qu'on
commence à parler un peu de choses un peu au niveau d'abstraction, de langage, de concept,
de programmation, de développeur, là on est vu comme un DevOps, ingénieur Yamel,
enfin moi je m'en prends régulièrement des comme ça, en gros on n'a pas de connaissance,
voilà parce qu'on n'est pas assez bas niveau pour eux. C'est à dire ça y est on est passé côté
Dev, on est limite chez l'ennemi, c'est à dire c'est un peu ça au final le truc, voilà maintenant
tu fais du Dev, tu es plus un vrai sassis admin, tu ne fais plus du Bache, attention il y a un peu
cette culture dans l'administration système que j'ai du mal à comprendre, c'est moi le plus hardcore
et c'est moi avec mes Script Shell etc qui un peu en mode héros, sauveur, voilà boum je sauve
la prod avec mon petit Script Shell écrit sur la pointe d'une table, c'est pas du tout ma vision
de l'administration système aujourd'hui, mais vraiment pas, et voilà, mais bon pour revenir
sur la question, voilà reviens peut-être, je sais pas pourquoi j'avais tout reviendra dessus,
justement peut-être pour enlever ça, pour bien montrer que quand on parle de Bache on le connaît
également et que c'est pas parce qu'on fait du Dev qu'on ne connaît plus nos prémices d'infrastructure,
qu'est-ce que toi tu vois comme problématique, que de problème avec Bache ? Alors la gestion
d'erreur que j'en ai parlé, c'est ça rien à voir avec une régition d'erreur typée etc avec
des stack tres avec des erreurs qui peuvent se gérer et même être détectées on va dire,
le fait d'oublier de gérer une erreur peut être détectée à la complication des choses comme ça
ou via des linters, donc ça c'est une première chose, ça va très vite de se tirer une malade
dans le pied en Bache sur ça je trouve, on peut également parler de la gestion on va dire de
tout le cycle de vie du programme, gestion de dépendance, de modularisation, de création de
librairie, de bibliothèque et de partage de ces bibliothèques via des outils comme je ne sais pas
ma vanne en java, enfin chaque langage finalement son outil de partage de librairie, en go ça va être
kit up mais bon voilà généralement la gestion des dépendances en go c'est pas d'ailleurs
extra mais bon c'est tout pour mieux que Bache mais je veux dire il y a ces notions vraiment de partage
et de qui est beaucoup plus simple à faire on va dire dans un langage de problémation voilà
n'importe lequel qu'en Bache pour moi ou en Bache pour partager quelque chose généralement c'est
j'ai des bibliothèques de fonction et je fais du source ou des choses comme ça mais on n'est pas du
tout sur pour moi une vraie gestion de dépendance donc ça ça va être également un point, ça
va être aussi sur un point important, ça va être le type h c'est un point important, ça limite
quand même beaucoup d'erreurs et c'est très intéressant d'avoir du type h dans un programme
et pour aller plus loin sur les structures de données également, notre quotidien c'est quand
vous travaillez avec des systèmes externes des API donc envoyer des requêtes généralement et
recevoir des réponses, travailler avec des figés de configuration, travailler avec de la donnée
en fait c'est ça un point important c'est on travaille vraiment avec de la donnée pour représenter
toutes sortes de choses et donc dans le langage de problémation on va utiliser quoi pour représenter
ces données on va utiliser des classes des structs c'est dépend du langage c'est pas les mêmes
concepts à chaque fois mais on a des représentations pour des outils pour représenter de la donnée de
manière fiable on va dire pour gérer son cycle de vie on va dire voir attacher les fonctions
à cette donnée pour pouvoir la modifier et ça en fait bâche est très mauvais à ça le
challenge général je veux dire les structures de données faire voilà faire un tableau en bâche
c'est déjà affreux alors un tableau en deux dimensions je ne parle pas mais là je ne veux
même pas parler de structures de données comme des haches mappoutes mais juste voilà représenter
mettons un pélode de requêtes htdp avec un user mettons on doit créer un utilisateur dans une
API et il a quoi comme c'est quoi son pélode c'est name par exemple voilà non prénom adresse
adresse qui est elle-même une structure de données avec ville rue etc etc représenté
ces jours ce genre de choses dans le langage c'est très compliqué en bâche alors que dans d'autres
langages c'est beaucoup plus simple et de manière et ça se fait de manière beaucoup plus fiable
donc la sérilisation des sérilisations que ce soit en jason en yaml ou se fait de manière
beaucoup plus simple bref on a beaucoup de choses qui arrivent qui sont qui sont amenées grâce à ça
et pour moi bâche aujourd'hui bah sur les systèmes au actuel ou finalement au trait de beaucoup de
données c'est pas du tout du tout pertinent et même voilà dès qu'on doit interagir avec une API
de faire de la validation d'input etc t'en parler c'est la galère en bâche quoi surtout le fait
que ce soit pas tippé ça n'aide pas non plus donc voilà j'ai d'autres points mais je sais pas si tu
veux réagir là dessus peut-être d'abord ou pas mais bah oui non mais c'est tout à fait raison c'est
le fait que bâche donc il faut un peu rappeler comment ça marche on est vraiment dans une
uniquement des strings des caractères qui sont passés de commande en commande c'est au final
vraiment ça à la base alors c'est un énorme intérêt c'est un énorme atout au quotidien c'est
que toutes les commandes parlent à peu près la même façon que n'importe quelle commande peut parler
avec n'importe quel autre ça a un énorme énorme avantage l'un de dans on n'a pas de notions
compliquées d'évolution toutes et strings et tout se passe en des strings mais en effet après on a le
drawback par rapport à ça qui est que si jamais votre commande rajoute une ligne de log au milieu
d'un string de données et ben vous avez pas de moyen de le savoir il n'y a pas il n'y a pas vraiment
de notion et en fait vous allez gérer cette ligne là comme n'importe quel autre et donc le problème
en fait qu'on va avoir d'embauche et c'est un peu le contrôle d'erreur que tu faisais ou le
contrôle de données et le contrôle d'erreur en fait les deux en même temps c'est que les problèmes
peuvent aller au carré quoi c'est à dire que un problème généré par une commande va se répéter
à celle d'ensuite à celle d'après et on va avoir un effet d'emballement parce qu'il n'y a pas
vraiment de contrôle par rapport à ça un contrôle vraiment de est ce que la donnée que j'ai
reçu est logique ou non et ça pour le coup en go on a moins problème là et c'est un truc qui a
été sans doute mis dès le début qui est que quasiment toutes les commandes renvoient une
erreur ou pas on a vraiment cette notion alors des gens qui aiment pas qui préféraient que ce soit
des stacktrace enfin des des des interruptions au niveau de la fonction mais voilà on a toujours
une erreur qui est renvoyée et on doit checker les erreurs en permanence et on voit vraiment la
différence entre les deux en fait la vraiment un langage qui a été basé sur le fait qu'il faut
checker les erreurs quasiment tout le temps la moitié du programme qu'on fait c'est du checking
d'erreur et de l'autre côté quelque chose qui est juste balance balance des des strings des strings
qui ne représentent rien c'est-à-dire c'est facile c'est vraiment des choses mais c'est de la dire
c'est pas encodé dans le langage voilà c'est pas de truc il n'y a pas de classe il n'y a pas de c'est
drôle c'est que je sais que j'avais discuté avec parmi les gens qui sont l'univers d'Otnet et
en fait PowerShell était un shell et toujours d'ailleurs je connais très mal des gens fans de
PowerShell qui connaissent très bien mais normalement le but de PowerShell c'est que justement toutes
les commandes renvoient des objets et donc tu peux avoir un mapping des objets et donc des commandes
qui vont chercher seulement un bout c'est vraiment en fait quelque chose où le pipe entre deux commandes
c'est un objet qui est renvoyé et plus uniquement une string
alors qu'en bas le rôle la gestion d'objets c'est JQ quoi ça va dire oui voilà c'est un JQ mais
en fait après le problème c'est en fait il faut donc que la commande gère Jason en fait ça veut
dire que vraiment la seule façon d'envoyer un objet complexe entre deux commandes c'est d'envoyer
du Jason sauf que en plus c'est drôle c'est que la plupart du temps les gens vont détester Jason
ou Yamel pour cette même problématique là en fait qui est mais c'est pas géré partout et
je rebondis également sur la gestion de dépendance que dont a parlé il faut voir que donc à la gestion
de dépendance du code donc une librairie une fonction bâche mais ce qu'il faut pas oublier
également et c'est un point essentiel c'est que la plupart des programmes bâche appellent des
fonctions qui sont elles-mêmes des dépendances externes qui sont liées à la distribution linux
en tout cas à l'écosystème dans lequel tourne le script si jamais vous appelez un cut que vous
appelez un enfin je sais pas quel commande en fait n'importe quel commande qui est appelé la plupart
du temps ça va être une commande qui est liée à l'écosystème et en fait en fonction de là où
vous vous trouvez vous n'aurez pas forcément le même comportement on a très souvent le problème
pour les gens qui font du du macOS parce que les commandes macOS n'ont pas exactement le même
comportement je crois que c'est les greps qui n'ont pas exactement le même problématique
enfin la même comportement enfin des fonctions quand même assez de base de corps utiles qui
sont pas exactement pareil et alors après ça va être pareil si on va sur des distributions avec des
des typiquement de l'embarquer ou des choses comme ça où on va avoir un certaine commande qui
ont vraiment un comportement extrêmement différent et le problème c'est que bâche masque ça
c'est à dire que la commande va se lancer elle va tourner mais en fait le comportement attendu
sera pas le bon et comme encore une fois on n'a pas de gestion d'erreur pas de gestion d'input et
ben le lien entre plusieurs fonctions n'est pas checker on peut avoir un truc qui explose qui
explose assez facilement c'est à dire que vraiment la commande ne reverra pas une erreur
elle ne reverra pas un code d'erreur donc même si on a mis un 7-X qu'on a décidé de bloquer
de bloquer l'exécution la commande peut très bien dire non mais moi c'est ok mais elle n'aura pas le
même comportement et d'ailleurs sur ça ça me rappelle vraiment l'époque où j'ai l'impression
que les quatre premières années de travail en tant qu'admin 6 je passais ma vie à corriger des
scripts d'init parce que c'était bah c'était l'enfer c'est voilà c'était des scripts shell et en
effet chaque distribute on travaille sur plusieurs distributions et chaque distribution ou des gens en
terme avait construit leur fameuse lpeur vous savez pour stocker les pidi dans des fichiers gérer
les accès concurrents c'est à ce truc là c'était mais l'enfer l'enfer l'enfer et en effet c'était
pas la même chose entre un redacte et mettons à nous bout de tout je sais pas quoi toutes ces
fonctions là pour gérer le site de vie du pro à mais savoir est ce que moi enfin c'est pidi et moi
j'avais accueilli le système d comme une libération que clairement à l'époque je me tais dit mais
c'est c'est juste trop bien quoi je veux dire on n'avait plus galéré le nombre d'erreurs en
prod avec des scripts des chats d'init moisie c'était un truc mais enfin c'est arrivé mais tout le
temps enfin bref c'est un autre sujet les systèmes dites mais bon voilà c'est un peu en lien aussi
oui oui parce qu'avant tu étais en bâche mais vas-y continue maintenant sur les autres points
sur les autres points bah on parle un peu d'outillage mais c'est aussi quelque chose que tu
avais mentionné les lineteurs les l'analyse statique de code même dans les idées etc et
l'outillage est aussi fourni grâce notamment au type h en en dessinant un engrâche fortement
typé on peut faire d'outillage intéressant parce qu'on a des types donc même le compilateur
ou des choses comme ça enfin le fait de voir vérifier des choses statiquement c'est très
intéressant c'est super intéressant et là on est vraiment ça peut être aussi des framores de
mocking des framores de test etc ce que souvent on me dit on peut faire des tests en bâche oui on
peut faire des tests en bâche mais les concepts de programmation comme les interfaces en go ou les
génériques dans d'autres dans j'ai dit dans toute l'angage mais maintenant c'est dans go aussi ou
le type h statique on va dire enfin le type h statique de manière générale ou même dans
les langages dynamiques on peut vraiment créer des jeux de test avec des mocs c'est-à-dire moquer
des composants dire des clients par exemple de manière assez simple et claire veut dire vraiment
cette notion de voilà de comment je vais tester mon programme comment je vais moquer des appels
externes comment je vais en faisant différentes appelations une implementation pour dire le
vrai code et une implementation pour le test même si c'est caché derrière une interface
bref toute cette logique là c'est des choses qu'on va pas trouver on va dire en bâche donc voilà il
y a l'outillage et aussi la façon de s'en servir notamment lors des tests je veux dire c'est
dur de parler de ça en fait c'est peut-être un peu confus parce qu'en fait il y a tellement de choses
qui manquent d'embâche sur sur des concepts de développement comme j'ai dit lié au dev que
c'est un peu voilà je m'embrouille un peu et qu'est ce qu'elle intérim de ses causes
interface là justement quand tu parles de mocking je vais donner je vais donner je vais donner
un peu je vais donner un peu je vais donner un peu j'ai récemment récemment duré du écrit
un script qui interagir avec humanities donc on doit c'est un truc qui devait modifier des ressources
dans cube donc faire des appels à piaille au final j'ai utilisé un client mais bon voilà il
laissait ça on fait des aillots et donc il y avait des aillots avec une petite logique et et donc je
veux pouvoir tester ce programme et moi j'ai pas envie en local d'avoir à démarrer un cluster cube
pour juste faire un stango un go test bah ce que j'ai fait c'est que j'ai utilisé donc le client
cube standard le client dynamique de la librairie officielle go pour humanities dans mon code et
dans mes tests et ben j'ai écrit un mock de ce client parce que ce client là en go c'est il est
derrière une interface donc c'est une voie on voit une interface comme une liste de fonctions attachées
à une struct et donc j'ai écrit une struct de moq où j'ai surchargé ses fonctions dans mon test
pour pouvoir envoyer certaines données en fonction de certaines conditions donc comme ça je peux
vraiment lancer mes tests sans avoir à démarrer tout un environnement local je travaille vraiment
en isolation et ça c'est quelque chose qui est super difficile je sais même pas c'est possible
en bas je veux dire de faire des parce que il n'y a pas de notion on va dire de de programmation
orientée objet ou de il n'y a pas de notion vraiment de type h ou d'interface ou de de
protocoles comme dans comme ça s'appelle dans certains langages il manque tous ces concepts
là en fait qui nous aide au quotidien à faire le design de notre programme c'est vrai que c'est
quelque chose qui est important que je n'ai pas mentionné mais de l'architecture logicielle
ça se fait pas comme ça il faut des outils pour le faire il faut il y a des concepts derrière
c'est pas qu'il n'y a pas en bas c'est à dire c'est un logiciel s'appuie sur ben voilà sur
des pratiques et sur des outils et donc sur je pourrais parler plein de choses programmation
fonctionnelle de gestion de des des d'état d'une truc de l'immutabilité ou non la il y a plein de
trucs qu'on pourrait dire qui sont pas d'embauche et et c'est des choses qui aident au quotidien pour
tout notamment je vais essayer de me faire un peu l'avocat du diable c'est on l'a pas c'est
disponible dans d'autres langages mais est ce qu'on en a besoin en fait est ce que vraiment
ces concepts là qui existent qui sont très bien est ce qu'on fait de l'administration
de systèmes est ce qu'on en a besoin ben c'est ce que je disais un peu au début c'est ce qu'on
fait de la qualité en fait pour moi c'est ça le point c'est à dire c'est pour moi oui on en a besoin
parce que comme je l'ai dit nos scripts c'est des programmes et on veut que nos programmes soient de
qualité tout simplement c'est pour moi c'est vraiment un affaire de qualité je veux mes programmes
soit mes scripts soit modularisé c'est à dire par exemple moi quand j'ai créé un script
mes tons en go je dois faire un appel à Kubernetes par exemple je vais faire un vrai client
Kubernetes dans un module qui va surger de faire ça que j'ai pouvoir moquer que je vais pouvoir
utiliser dans différents contextes si je dois faire un script qui fait du slack pareil j'ai créé
un module avec un client slack avec des actions un peu au niveau chaque module va avoir des métriques
c'est quelque chose qui est important aussi donc si je fais des aillots je vais avoir du monitoring
je vais avoir des logs avec un logger que je vais pouvoir passer entre mes composants mon logger va me
permettre de facilement savoir si quelqu'un niveau de verrosité je veux dans l'ensemble de mon programme
le format de sortie donc j'aisonne ou du texte brut classique etc bref c'est fiamment c'est si on
veut faire de la qualité il faut faire du développement il faut utiliser des méthodes
modernes de développement en fait c'est ça mon point et bâche n'est pas du tout dans ce mode là
c'est à dire c'est il n'y a pas les outils dans le langage pour faire ça c'est des concepts
qui sont complètement manquants mais c'est d'ailleurs pour ça qu'on ne va pas aucun
développeur dans son quotidien ne va faire du bâche personne ne fait du bâche pour faire des
programmes on va dire classique le bâche n'utilise que généralement que dans l'administration
système alors on pourra parler plus tard de quand est ce que moi j'utilise bâche mais dès
qu'on a un programme un peu sérieux avec de la logique et vraiment une envie de faire de la qualité
bah là bâche ne peut plus juste pas fonctionner parce qu'il n'y a pas ces concepts on ne peut pas
faire du vrai développement en bâche tout simplement il n'y a pas les outils et donc là tu parlais
donc de réutilisation de modules etc si jamais on fait justement un peu du one shot donc en fait
je vais aller un peu plus loin de ce que tu disais c'était que on a des concepts en bâche donc
on n'a pas ces notions de test etc ces notions de test on les a pour le cycle de vie de notre
applicatif c'est à dire que si jamais demain on rajoute des fonctionnalités qu'on corrige un bug on
veut être sûr qu'on n'en rajoute pas un autre donc en fait cette notion de test qu'on rajoute tu
parles de qualité la qualité elle s'améliore parce que notre logiciel on va pouvoir être
sûr de son fonctionnement en permanence on est sûr que quand on a fixé quelque chose on n'a pas
un problème un problème qui est réapparu et c'est ça en fait le point le point essentiel
quand on fait des programmes de prod on veut être sûr que ce programme continue de fonctionner
sans avoir besoin d'avoir une connaissance profonde de ce script parce que c'est le problème qui
vient qui vient souvent ensuite après c'est que les scripts bâche ne se ressemblent pas les uns
avec les autres on a en fait énormément de méthodes différentes pour pouvoir les écrire
je sais pas d'exemple l'apprécie mais la manière de pouvoir traiter des lignes de commande et de
pouvoir faire des cèdes enfin de pouvoir changer des strings c'est entre connaître la
santé du oak connecte la santé du cède utiliser des fonctions natives de bâche déjà on a des
des façons différentes de le faire c'est pas vraiment que dans les autres langages on n'a pas
ça c'est que au moins on peut s'assurer que la sortie sera toujours la même on peut s'assurer
que si jamais demain quelqu'un refactorise une fonction on va avoir toujours le même résultat
alors oui il existe il existe du bat ça il utilise des choses pour pouvoir le faire voilà il
utilise il existe des choses pour pouvoir le faire dans du bâche mais en fait c'est la notion
des cosyme dont tu parlais c'est qu'en fait quand on regarde de bâche en fait les cosyme est
très très faible si jamais on fait du lignes de or il n'y en a qu'un seul c'est chel check si tu veux
faire du test c'est bat et puis c'est à peu près tout quoi là où dans tous les autres langages
on a eu une évolution rapide des usages pourquoi parce que c'est beaucoup utilisé donc on a eu
plein de framorques de test qui sont apparus qui se sont remplacés qui ont été qui ont été refaits
là où dans bâche bah c'est très pauvre en fait d'où le fait que on va avoir après ce niveau de
qualité fait c'est pas qu'on peut pas avoir un niveau de qualité élevé avec bâche c'est juste
que ça va être beaucoup plus compliqué et donc toi dans ton cas c'est à quel moment tu
utilisais du bâche parce que là on a dit donc on avait de la réutilisation est ce que si tu fais
des scripts des oneshots c'est ça c'est ça on shot généralement c'est pour récupérer de l'information
c'est à dire c'est pas pour faire des actions c'est pour récupérer de la donnée si je besoin ça
m'arrive par exemple de devoir récupérer des ressources dans cube très rapidement pour
check un truc là je vais faire je vais même pas faire du bâche je vais faire un one liner ou peut-être
quelques lignes avec un cube cuttle moins au json pipe gq enfin je sais pas des trucs comme ça voilà
donc pour récupérer de la donnée et très rapidement voilà avec un petit coup de cède de haut
etc va dire sortir quelque chose ça marche assez bien mais c'est voilà c'est du one shot c'est pas
des choses que je vais utiliser tous les jours c'est à dire si je dois l'utiliser tous les jours je
vais tendance à le je pense que je vais le mettre dans un script dans un autre langage et
aussi c'est des choses que je ne peux pas partager du moment que je veux partager quelque
chose je vais pas le faire en bâche tu parles d'écosystèmes c'est quelque chose qui est très
important pour moi dans une entreprennage dans une entreprise mais même au niveau de l'open source
comme je l'ai dit au début la majorité des langages ont des systèmes de gestion de dépendance
et donc moi finalement quand je tous mes clients tous mes toutes les choses comme ça etc ben j'essaie
de les partager si j'écris un client pour faire du slack et ben je vais me dire ben tient
y a peut-être quelqu'un qui aura le même besoin un jour dans l'entreprise et ben donc je vais faire
je vais le mettre je vais faire une libre au final et je vais partager cette cette chose là au sein
de l'entreprise ou le mettre en open source etc et on construit comme ça un écosystème de la même
manière j'ai connu on l'a tous connu je pense des entreprises où les scripts shell chacun sa
petite collection de scripts shell en local non partagé et donc parce qu'il y a eu un besoin
un jour et ça n'a pas été mis en commun et pas de bol trois mois après il y a un autre collègue
qui avait ce besoin là et ben malheureusement le scre... ah oui je me rappelle que matieu il avait
fait ce truc avec un script shell il y a trois mois après mal à là il est en vacances bon bah
voilà tant pis donc il y a aussi cette notion de décosystème d'entreprise qui est important
pour moi et ça passe par des modules des libres on appelle ça comme on veut pour avoir des composants
au niveau que je peux ensuite consommer en tant que que personne qui va devoir développer des scripts
et ces modules peuvent être vraiment de qualité ça permet ça aussi on peut se dire chaque module va
avoir des logs des métriques des métriques corrects ce que souvent on me dit oui mais moi j'ai
je peux faire du time avec bas je sais pas quoi non mais moi je parle de métriques avec des labels
avec des histogrammes des counters etc etc donc un vrai système de métriques donc vraiment
partager ça et même au niveau des cielas moi c'est quelque chose qui est sur lequel j'ai
vraiment eu des très bons retours dans mon espace professionnel c'est de créer des cielas et
mises en commun on va dire et qu'en gros au lieu d'avoir 30 scripts dans 20 répons avoir des
cielas ou une cielas il va dire que tout monde a écrit par exemple en go avec des sous commandes
des tout ce qu'il faut au niveau de gestion des flags comme tu dis les validations des inputs
etc etc pour faire des actions sur la production c'est à dire avec un truc testé comme je disais
qui utilisent des modules qui sont qui sont qui sont bien identifiés correctement monitorées avec
des logs et comme ça n'importe qui peut également contribuer qu'on soit def qu'on soit hopc etc
bah si on fait du go par exemple n'importe quel def peut aller rajouter sa commande dans la danse
miscée l'ail ou publier une libre parce qu'il a eu un nouveau besoin donc maintenant il a besoin
d'interagir avec tel API bah boum je peux plus une libre et tout le monde tout le monde peut en
bénéficier donc il y a vraiment ça qui m'apporte aussi c'est de le partage et pas juste des scripts
qui sont mis dans un coin sans cohérence sans écosystème tu parles pas mal de go et on parle pas
mal de go quel est le lien que tu fais entre et est-ce que c'est juste un langage parmi plein d'autres
qui utilisent par les hype barbu à lunettes dans un coin ou est-ce que vraiment il y a un sens
ou est-ce que ça aurait pu être du java du notre gs quoi que ce soit alors les les différences
chaque langage des différences moi j'aime bien go pour faire des scripts parce que déjà c'est
c'est assez simple à prendre en main ça fournit l'écosystème est énorme en fait donc ça c'est
intéressant il y a vraiment un énorme écosystème on peut vraiment tout faire et beaucoup d'outils on
va dire de son écrit en go dans notre métier on va dire soit humanitis à tous les outils
hccorp enfin voilà il y a des tonnes d'outils qui sont écrit en go donc c'est intéressant de me
maîtriser c'est pas de langage parfait bien sûr il y a on peut dire des choses sur son type
système ou des choses comme ça mais c'est un langage où on est productif où les gens peuvent
facilement monter en compétence dessus et contribuer ça se déploie très bien ça fait un binaire
statique donc c'est très facile à distribuer sur des saveurs ou n'importe où et voilà donc c'est
bon pour utiliser d'autres langages c'est pas ce qui me dérangerait le plus tant qu'il y a vraiment
de la qualité après voilà je n'ai pas envie de passer dans le débat qu'elle est meilleure
langage j'utilise toujours le langage qu'il faut pour mon besoin c'est-à-dire que pour d'autres pour
d'autres cas je vais pas utiliser go mais pour de scripting je trouve que ça marche bien global
mango c'est voilà c'est ce que j'utilise moi aujourd'hui en effet ok non mais oui enfin je suis
d'accord avec toi et c'est c'est ce qui est bien avec avec go alors actuellement c'est que déjà
les logiques sous-jacentes de la std lib sont très très proches du système c'est très simple de
retrouver la fonction dont on a besoin le cisco l'ont en a besoin etc quand on fait vraiment du
pur système et on a un langage qui nous permet d'avoir quelque chose qui peut tourner en route
moi c'est ça souvent que je dis c'est que mon langage mon logiciel que j'ai fait avec du npm
que j'ai mis dans du nut js j'ai beaucoup de mal à le faire tourner en route je vais avoir beaucoup
de mal à lui donner les droits pour pouvoir le faire parce que l'abstraction est très élevée parce
qu'en fait on a des promesses on a des choses comme ça qui vont pas forcément être être validés dans
le cas de go on a vraiment un langage qui n'est pas objet ou en cas pas complètement objet en
tout cas on a des structures comme tu l'as dit un peu avant c'est pour ça que ça le rend assez
simple on va pas avoir des trucs ultra compliqués comme on fait en java avec de l'héritage multiple
et yolo yolo les classes étendues là on a quelque chose en fait qui est assez simple et quand on
fait des scripts et c'est marrant d'ailleurs tu te dis le mot script pour du go alors que je suis
sûr que la plupart des adminsis qui ont l'applicieux de faire du bash vont dire un programme on dire un
langage de programmation comme ça mais c'est vrai que pour faire un script la plupart des temps je
m'en trouve à faire ça c'est que j'appelle une fonction de go je regarde sa sortie c'est à dire
que je regarde le code d'erreur qui me renvoie je regarde si le code d'erreur est bon pas bon
si il est bon je continue avec la structure je l'envoie dans une autre fonction et en fait
je sais que là les trois quarts de mon programme ça va être des tests d'erreur c'est un if un
return un end un end du if et après une autre fonction que je vais appeler et en fait quand on
fait des scripts en go on a vraiment ça qui vient en permanence et c'est du bash plus plus pas
moi vraiment c'est comme ça que je vois la plupart du temps c'est du bash plus plus avec du contrôle
des entrées donc si jamais demain je mets un jour une librairie que la structure change et ben
j'ai une erreur de compilation c'est à dire que je le sais instantanément qu'il y a une changement
d'un changement de dépendance et je vais avoir un contrôle fin des erreurs avec une reprise avec un
arrêt et en fait je vais décider du comportement que je veux faire et je peux faire des juste même
faire des boucles de manière facile quoi parce qu'une boucle en bash une façon de base n'importe
quel outil de programmation un outil de programmation c'est un truc vraiment qui fait des boucles
c'est genre la moitié du d'un processeur sert à faire des boucles et des boucles avec avec un test
et ben c'est quelque chose de compliqué en bash et c'est vrai que moi j'ai dit script mais j'aurais
pu dire programme parce que comme je disais je fais pas je fais plus la distation entre les deux
parce que sinon il y a vraiment les gens pensent script truc à la rage programme truc de qualité
alors que non les deux devaient de qualité pour moi et moi j'étais en tout voire découpé
même mes scripts vraiment module déjà parce que j'essaye de comme je disais de réutiliser des
modules existants et surtout parce que un truc qui est important aussi c'est que les gens se rendent
parfois pas compte que même un script simple en fait ça peut être compliqué j'aime bien prendre
l'exemple du script de backup la script de backup c'est pas juste ouais je prends une donnée j'ai la
meilleure c'est bah comment je moniteur mon script comment je moniteur son temps d'exécution si je
dois faire plusieurs aillots ce qui arrive souvent chaque aillot je veux qu'elle soit monitorée par
exemple je veux savoir combien de temps ça me met pour faire le backup combien de temps ça me
met pour l'envoyer mettons sur s3 je veux des labels sur ces métriques je veux des logs et je veux
aussi bah vraiment peut-être si ça plan d'avoir de l'alerting donc balancer un évente un événement
dans un système de monitoring externe donc là je plus souvent des SDK si j'utilise sentry pour
réagir sur des erreurs qui est un outil que j'aime bien bah l'appareil je veux envoyer mon erreur à
sentry etc etc donc c'est des choses qu'on voit très très souvent dans le dev dire un dev
va avoir des métriques va avoir des tests va avoir des intégrations de sentry va avoir tout ça
c'est des astractions mais voilà dans l'op c'est des choses qui sont très rares et ça je comprends
comme je disais au début je comprends pas pourquoi pourquoi on s'impose pas la qualité qui ce que
les dev s'imposent en fait c'est tout simplement ça pourquoi nous en tant qu'ops on serait là à
se dire bah non nous ça ne nous concerne pas en fait de faire tout ça de faire de faire de
la générique logicielle en fait ça rend ça mon point c'est pourquoi on ferait pas ça là c'est
les critiques que t'as souvent parce que là on l'a un peu parlé au début et donc ton article est
souvent repris quels sont les principales critiques que tu entends parce que ça donc tu l'as expliqué
déjà dans tes articles qu'est ce qui va qu'est ce qui va qu'est ce qui va faire que on qu'est
ce sont les arguments en fait qu'on va t'opposer à faire ça déjà beaucoup d'incompréhension
ce qu'on me dit mais si je peux faire des tests en bâche je peux j'ai fait de la gestion des erreurs
en bâche je peux faire des métriques en bâche mais comme je dis il y a un manque de concept déjà
il y a un manque de concept de c'est quoi faire du développement en 2022 donc à partir de là
c'est dur d'expliquer enfin veut dire pour venir à la base faut expliquer bah voilà c'est quoi un type
c'est quoi un moque c'est quoi une métrique avec des labels enfin bref c'est des choses c'est quoi
l'intérêt d'un logheur global dans une application etc etc et ça faire ce travail là ça me
prend beaucoup de temps et beaucoup de gens en fait de refusent de le faire enfin de monter en
compétence sur ces sujets et en fait préfèrent rester dans leurs dans leurs opinions toutes tranchées
sur je peux le faire en bâche sans comprendre finalement toute la portée de ces de ces outils
et concept qu'on retrouve dans d'autres langages donc ça c'est mon premier problème l'autre problème
que je vois généralement bah j'en ai parlé au début c'est en gros c'est les ingénieurs d'aujourd'hui
enfin les admissives d'aujourd'hui ne savent plus rien faire ils ont trop d'abstraction ils savent que
faire du gammel et c'est où c'est des devs voilà c'est un truc comme dit soit t'es pas un admissiste
un devs c'est censé être une insulte je pense je sais pas moi je suis content de savoir développer
en effet parce que parce que c'est le quotidien d'un an enfin c'est une partie du travail d'un
admissiste aujourd'hui donc ça c'est une critique vraiment très classique les gens se pensent vraiment
comme j'ai dit très très intelligent de faire du bâche en fait c'est comme si comme si ces
personnes se disaient bah moi je fais des choses très très compliquées et je suis content de le
faire en fait c'est un peu enfin je comprends pas trop le truc c'est parce que c'est assez bas niveau
etc donc c'est censé être voilà ça donne du crédit social je sais pas c'est quoi le truc mais
il y a un peu c'est cet attachement à l'outil de on a toujours fait comme ça c'est des trucs que
les devs ne font pas et donc moi je suis pas un dev donc je fais ça ça c'est un truc que je vois très
très souvent ouais tout simplement sur sur le discord parce que oui on a un discord que vous
pouvez rejoindre n'importe quel moment et là on est en direct donc il y a des gens qui arrivent à
faire des des commentaires on nous dit aussi qu'un des arguments qui est donné parfois c'est le fait
qu'il y a peu de dépendance en vache c'est à dire qu'en fait ce qu'on a dit comme t'as l'heure
étant une non gestion de dépendance pour certains va être pris vous m'aider pris comme une comme
un argument en fait un argument qui est non mais j'ai besoin de rien installer bâcher sur toutes les
machines c'est simple j'ai pas besoin de c'est pas besoin d'un truc compliqué vraiment même
mettre un binaire c'est compliqué là je me mets mon fichier j'exécute ça tourne
ça c'est ça je comprends donc ça veut dire si notre but c'est quand même d'automatiser des
infras etc etc et de se fournir un service à des utilisateurs si on sait déjà pas déployer un
binaire sur des serveurs et gérer son cycle de vie comment on est géré sensé gérer le cycle de
vie de 10 100 000 applications qui sont poussées plusieurs fois par jour par les devs clairement
c'est là il faut partir déjà de la base et se dire pourquoi on sait pas faire ça et si on
sait pas faire ça on saura pas faire le reste de notre métier parce que c'est un pré-requis en fait
de savoir déployer des app et gérer leur cycle de vie déjà ouais mais là par exemple aussi un
exemple qu'on a c'est et c'est vrai que je suis intervenu en ss2z pendant un moment et en fait
on avait des scripts shell qui est vraiment des scripts shell magiques on les a nait chez le
client ça marchait chez sur l'open suce ça marchait sur du rhl ça marchait sur du debian etc on
arrivait vraiment avec le script shell magique et puis on faisait tourner et puis hop ça marchait
quoi en vrai toi au l'heure actuelle tu ferais ça comment en fait t'aurais eu quoi comme alors
j'ai connu ça aussi comme je dis en début carrière on avait plusieurs distrits on fait encore de la
x du ksf c'était super pénible alors déjà plusieurs choses c'est déjà je pense que dans
une entreprise c'est bien aussi d'avoir un peu de la standardisation sur comment sur au moins notre
distribution après on peut avoir plusieurs distributions mais aujourd'hui un langage comme
go même même d'autres langages en fait fournissent une abstraction au dessus de tout ça go compilent
très bien pour du bsd ou des choses comme ça alors bien sûr il peut avoir des différences si on
essaye de faire de choses pas de le bbf sur go sur fribsd oui ça marche moins bien que sur l'inux
c'est sûr ou pareil pour les conteneurs donc il y a des choses qui sont pas pareilles parce que le
kernel en dessous n'est pas le même mais tout l'intérêt des langages de programmation c'est quand
même de gérer ces choses là de manière transparente du java on peut le faire tourner partout du go
on peut le faire tourner partout du piton je suis pas un énorme je n'ai pas une énorme expérience
en piton mais j'ai jamais trop entendu de problèmes comme ça ou même sur du windows ou des choses
comme ça c'est on peut généralement lancer faire du piton donc après ouais c'est à la réunement
que je comprends pas tant que ça et surtout je dirais une autre chose également c'est que si
finalement ce que j'ai connu aussi ces connexions de script géant qui était lancé comme ça
etc c'est pas l'abstraction que je veux pour déployer mes applications aujourd'hui moi ce que
je veux c'est travailler avec des API travailler avec voilà des endroits faire de déclarer faire
d'infrastructure déclarative ou des choses comme ça j'ai pas envie d'avoir à déployer des
applications avec des contraintes spécifia ou c'est à moi de gérer finalement les contraintes
spécifiques de chaque distribute je veux une API et derrière c'est un programme qui va me gérer
ces spécificités et c'est à ça c'est aussi un truc important et des choses comme après ça va être
que sur Linux aussi on va me dire mais clairement c'est un des intérêts par exemple pour moi de
cumulatiste c'est que ça tourne un peu partout et donc forcément on a un peu moins d'adhérence on
va dire à comment ça tourne et moi je t'endrais plus sur ça que sur essayer de faire des script
batch qui tourne partout je préfère avoir créé une API qui tournera sur chaque distribute et
derrière ça m'appellera au pire des programmes spécifiques mais qui peuvent aussi être écrits
en piton en go ou je sais pas quoi je vois pas la bonne raison de faire du batch pour ça en
final qu'est ce qu'est ce que finalement même dans batch va faire tourner un conteneur sur bsd c'est
pas possible c'est pas parce qu'on fait du batch que d'un coup ça y est on a des c groupes des
choses comme ça donc finalement c'est quand même plus le carnel qui va jouer et au niveau de la
distribution ensuite ben là je pense que je vais plutôt au contraire essayer de maxraire via d'autres
outils pour pas avoir cette dépendance à une distribution mais je pense justement en fait ça
c'est quelque chose quand je reviens un peu sur mon expérience de pourquoi on avait ces scripts
batch elle là l'avantage qu'on avait et pourquoi on les avait en chel c'est que quand tu partais
avec t'habit et ton couteau pour aller installer un long software tu partais avec
ta collection de scripts sur clé usb en fait si jamais tu avais un problème et ben en fait
tu pouvais le fixer en temps réel alors que potentiellement si jamais demain j'en voyais un
consultant avec son script son petit go avec juste le binaire et que le binaire il me dit non
bah c'est non c'est peut-être ça aussi la peur la peur qui est derrière qui est mais comment
je vais faire si jamais si jamais ça marche pas qu'est ce que je vais faire si jamais mon binaire
ne fait pas ce que j'aimerais qu'il puisse faire alors moi je pense que c'est aussi une question
de responsabilité de qui finalement j'allais dire en fait on parle d'honor ship finalement là
fiamment sur qui gère ce binaire là et c'est vrai que moi je vois beaucoup de gens qui utilisent
batch en effet pour ça en mission d'ailleurs une personne qui me prisiquait présenter un projet où
ils faisaient du batch de cette manière là c'est pas vraiment et moi ma façon de travailler c'est
pas je me pointe dans un bureau je balance un cri de bâche je me barre et après la phrase dégrade
pendant trois ans jusqu'à ce que je revienne en mode sauveur enfin bref pour moi il y a vraiment
aussi une question de sur le long terme comment on travaille et ça c'est un truc qui est aussi
important parce que si dire si j'arrive avec mon script que je lance que ça marche pas et ben comment
je fais pour que ça marche bah je dois investiguer pourquoi ça marche pas je vais le corriger et
moi ce que je veux c'est que pour à lancer mon script tous les jours pour que ça marche je veux
pas avoir envie de le faire tous les deux ans ou des choses comme ça bref je veux pouvoir le faire
tout le temps tout le temps tout le temps le faire évoluer également parce que les infras évoluent
les besoins évoluent je veux que les gens puissent contribuer dessus et c'est ça pour moi l'important
et en effet on est ça on sort un peu du mode j'arrive je mets mon script je veux pas ou alors
moi ce que c'est je suis pas consultant aujourd'hui mais je préfère arriver dire bah aller on va
construire quelque chose ensemble que vous allez maîtriser ensuite je veux pas réveiller plus
jamais donc pour moi c'est il faut vraiment voir aussi l'impact de faire ce genre de faux c'est à
dire balancer du script bas chez partir sur le long terme sur un essai d'entreprise où finalement
plus personne à la maitrise parce que le truc est géré à coup de script lancé de temps en temps
et on sait plus trop ce qui se passe entre on sait pas si on a du drift on sait pas comment ça
marche au final et plus partir sur une approche long terme de gestion d'infrastructure et
je pense qu'auci il y a une autre solution en fait à ça qu'on a qu'on a vite compris c'est que
souvent ces scripts shell qu'on utilisait donc on l'appelait install.sh on l'enseille on priait
souvent ça marchait pas parce que bah on passait d'une DBN8 enfin une DBN6 et une DBN7 on passait
d'une RHEL je sais pas combien une autre version et donc on avait en effet des gestions d'épendance
qui n'était pas là typiquement une libre quelconque qui était pas installée qui était pas le même
nom de paquet qui avait évolué qui était plus à la bonne version qui faisait que ça marchait
pas etc. donc souvent même quand le script shell marche pas en fait c'est que derrière il y avait
un autre problème un peu plus important qui était même pas détecté forcément d'ailleurs le script
shell il finit ça il disait ok en fait il y avait la moitié des trucs qui marchaient pas et qui
avait été pas bien installé et tout en fait maintenant on a une solution pour gérer ça
bah c'est les conteneurs d'ailleurs en fait on a un conteneur on prend son application son
application on la met dans une jolie image de conteneurs on dit ça c'est ma version
labelisé qui marche quel que soit la distribution quel que soit le kernel ou la version du kernel
en tout cas la plupart du temps et et à la limite on a un script install point et ça c'est la seule
chose qui fait c'est docker run moindé moins moins restart always et puis et puis rouler je n'ai
pas en fait et donc en fait c'est peut-être pour ça qu'on a encore moins besoin de bâches qu'avant
parce qu'on a standardisé les écosystèmes on a standardisé un écosystème dans lequel
ça marche et dans lequel donc notre programme de lancement notre init notre whatever dessus ça
peut même mettre un petit script shell c'est pas forcément si jamais c'est juste lancer une
commande on a un entrepoint point et ça c'est tout à fait logique d'en avoir un mais il est
standardisé dans un écosystème précis il est testé et en fait on teste tu parles une mochette
chose comme ça en fait on va tester le conteneur avec son script shell en fait comme s'il faisait
partie du logiciel et donc d'un seul coup on a une autre une autre approche par rapport à ça c'est
vrai que ça c'est quelque chose qu'on avait pas à ce moment c'est à cette époque là pour ça que
shell par exemple logique parce que voilà logique bite et couteau le mid du sauveur le gars qui
qui sauve la prod qui se trouve le script qui arrive à se démerder qui importe qui importe le
qui importe les problèmes et c'est vrai que sans doute notre métier s'est construit avec ça il
s'est construit avec ses avec ses visions de cette personne qui connaît absolument toutes les options
possibles d'un hook et arrive à faire un way liner super bien sauf qu'en fait c'est pas forcément
ce dont on a besoin aujourd'hui on parle souvent des brian jerks bah là c'est un peu ça en fait
le problème c'est cette façon d'être trop brillant qui fait que ça masque les problèmes et en
fait même ça a empêché d'évoluer vers des solutions meilleures et en fait maintenant on a
juste une dette avec certains détesses qu'on parle de dette de dette technique etc là pour le coup
c'est clairement le cas on a une dette une dette qu'il faut se mettre à payer parce que on a en
bouché des gens trop brillants à un moment et ça c'est c'est paradoxal en fait dans un moment où
où les gens savent faire quoi en fait ils sont toujours les sauveurs avec leur script leur script
shell là où aujourd'hui ah bah n'importe quel demeuré peut lancer une installation parce que c'est
juste un appel à une à une épiaille oui et c'est ça le métier c'est tout le coup mais c'est ça
bah non mais c'est donc disponible à autre chose bah c'est ça je veux dire c'est du c'est du
autonome et qui sait pas gérer ces trucs ces trucs là clairement et ça c'est vrai que mais toi tu
parlais des conteneurs mais tu ne te rends pas des copains en disant ça parce que généralement les
gens à fond dans le bâche etc et qui me critiquent c'est des gens qui vont être aussi anti-conteneurs
anti souvent anti un frais à scone anti en gros c'est anti tout ce qui est sorti après 2005
c'est un peu moins en tout cas non mais c'est voilà c'est un peu mais c'est le cliché quoi c'est le
cliché et mais au final enfin moi je veux être honnête enfin ces gens là je les vois plus
faut dire dans mon monde ils sont peut-être ici ils sont peut-être encore dans les grands groupes
ou quand j'étais avant mais c'est tout c'est vraiment dire ok on troll sur twitter mais sinon
après dans la vraie vie qui travaille encore comme ça c'est très rare et c'est et c'est but aussi
là en fait pourquoi pourquoi ce podcast là c'est que je vois encore des jeunes sortis d'école
qui vont me sortir ces réflexes là qui ont encore le réflexe de se dire non mais voilà un script
shell je modifie trois quatre trucs hop c'est bon ça marche l'argument ça marche worked on my
machine quoi et c'est vraiment c'est vraiment un problème et je me dis justement voilà on peut dire
non mais il y a moyen de faire mieux il y a moyen de faire plus de qualité et clairement vous ne
perdrez pas votre job parce que vous avez fait un script en go qui marche mais non mais pas votre
job c'est mais c'est pas un peu comme tu dis c'est une question de mythes quand j'ai commencé ma
carrière c'était ça aussi je veux dire les le six admins qui gère la prod attention avec un p
majuscule voilà qui connaît qu'est toutes ces collections de scripts qui peut balancer à droite
à gauche qui qui est un peu voilà toujours un peu grognon un peu qui tire un peu la gueule
ouais les développeurs un machin qui veut le contrôle c'est ça aussi je veux contrôler en
fait je veux pas laisser la main aux autres je veux contrôler ma prod c'est ma prod c'est ça
souvent des choses que j'entendais c'est tout était construit avec ce le métier c'est construit
que ce mythe là et aujourd'hui bah ouais c'est un problème et moi pour moi d'ailleurs là c'est
un autre sujet aussi moi je l'ai vu le shadow it avec les devs qui disaient on a un ralbone en fait
du chie des six admins comme ça qui gère tout on peut rien faire on a la main sur rien on n'a pas
le droit d'utiliser l'init de l'init de la machine ou systemd parce qu'il faut utiliser le truc
interne en ksh des trucs de dingue à moi que je voyais et bah qu'est ce qu'on a fait tout
monde a fait du shadow it et tout le monde c'est fait les six admins là se sont fait bypass c'est
les mêmes qui vont pleurer aujourd'hui en disant et pourquoi tout le monde est parti chez le cloud
sur le cloud bah c'est sûr on va dire tout le monde pleurait en permanence mais tu voulais rien
faire pour fournir le service des utilisateurs bah oui bah tout le monde s'est barré tout
le monde est chez amazon et tout le monde est sur des attractions parce que pas parce que tu l'as
pas proposé tout simplement parce qu'il y avait ce mythe en interne de les six admins qui bloquait
tout et ça c'est des choses que je veux plus revoir clairement c'est vrai que là on digresse un
peu et c'est un énorme et clairement mais c'est la fin mais mais non c'est que vraiment bâche
arrive en fait dans un contexte dans un écosystème et il faut pas négliger cette notion d'écosystème
les gens qui font du chel font en effet sont dans un dans un mythe et dans des dans des logiques
différentes qui sont des logiques de contrôle de de de de de de de de de de de de de de gestion de
bout en bout et donc de la volonté de d'avoir des problèmes simples d'utiliser des outils simples
pour ne pas avoir besoin de les gérer de manière trop compliquée en fait c'est un peu ça le
chose la chose qui vient la chose qui vient avec et moi ce que je veux dire un peu un peu en conclusion
en tout cas moi de mon côté c'est c'est n'ayez pas peur enfin tester essayer n'ayez pas peur de
faire de la qualité n'ayez pas peur de faire des choses bien laissez-vous du temps pour aller à la
plage quoi enfin vraiment ne soyez pas en permanence à devoir à devoir gérer de la prod à 2h
du mat si jamais vous gérer de la prod à 2h du mat si jamais vous avez peur de déployer le vendredi
c'est qui un problème ce n'est pas normal il ne faut pas rester dans ce contexte là impression de
parler comme des gens qui ont été battus toute leur vie et qui reste dans ce contexte là ce n'est
pas vous la victime quoi enfin genre vraiment sortez en fin ce n'est pas vous ce n'est pas vous le
problème c'est vous la victime sortez en ça va bien se passer je pense que ma conclusion personnelle
par rapport à ça moi ma conclusion sur ce débat pour revenir vraiment sur sur bâche c'est si vous
avez réussi à prendre bâche vous aurez aucun problème à apprendre d'autres langages c'est pas
du tout impossible c'est ça même peut-être plus simple vous aurez des outils un compilateur
etc pour vous aider et apprenez les concepts du dev apprenez c'est quoi la programmation
fonctionnelle comment on fait de l'architecture logicielle comment on fait de la gestion d'erreur
comme c'est quoi comment je mets des métriques pertinentes des loges pertinents comment j'organise
mon code comment je publie des dépendances pour qu'elles soient ensuite réutilisées de manière
donc de manière assez générique comment je construis cet écosystème etc etc parce que
aujourd'hui le job de la mine 6 c'est ça aussi c'est du dev et donc finalement il faut résonner
comme des dev il faut travailler comme des dev quand on est sur ces sujets et pour moi ça c'est
vraiment le point le plus important et c'est des choses qui s'apprennent et qui sont pas du tout
impossible moi j'ai aucun problème vraiment aucun problème avec des gens de travailler avec des gens
qui font maîtrise pas forcément go etc les gens montent en compétence dessus il n'y a aucun
soucis et c'est pas perdu même voilà souvent les gens de dire bah comme tu disais ils vont dire bah
je connais bâche et je vais perdre cette cave je vais en gros j'ai passé dix ans à faire du bâche et
maintenant je dois plus en faire c'est pas perdu c'est toujours utile de connaître des choses
je suis sûr de connaître bâche et de connaître hock ou grep ou cède etc c'est pas c'est pas voilà
vous l'utiliserez peut-être encore mais bah vous arrêtez pas enfin allez essayer d'aller aussi
plus loin et pas juste rester sur les acquis moi peut-être que dans cinq ans je dirais bah moi je
fais plus du gauche autre chose et bah tant pis il y aurait quelque chose de mieux pour mon besoin
je sais pas de m'enfermer dans des techno parce qu'au final ce qui est important c'est les concepts
et voilà j'insiste là dessus ce qui est important c'est sur les concepts et donc apprenez les concepts
de l'ingénierie du visuel tout simplement alors moi je vais être même encore un peu plus timorec
toi par rapport à ça c'est je vais pas dire apprendre c'est vous apprendrez oui essayez
fait fait un petit script quand vous avez un besoin la prochaine fois que vous avez un bâche qui a
planté essayez de le réécrire en go un exemple que je donne bah le script shell dont j'ai parlé
au tout début à pouvoir faire le tronc le lien avec tout début du podcast ce script shell qui
s'appelait vera demi point sh je n'ai pas réécrivé régulièrement en fait je l'ai réécrit en go
en une demi journée ce script qui avait quasiment un an et demi deux ans de d'histoire je l'ai réécriée
en une demi journée et surtout je lui ai rajouté 60% de couverture de test alors que vraiment je suis
une merde en développement je ne croyais pas qu'il n'y a que les gens qui sont doués qui peuvent
en faire si j'ai réussi à faire du développement si j'ai réussi à faire des tests unitaires
vous serez capable de le faire vraiment j'insiste dessus ce n'est pas quelque chose qui est réservé
aux autres juste bah au début vous allez un peu en chier débule mais en fait vous allez quasiment
en chier moins que tout ce que vous avez appris pour faire du bâche c'est à dire que les concepts
vous allez retrouver vite vous allez voir qu'il y a des choses que vous avez mis du temps à prendre
en bâche que vous avez que je vous en avez galéré que vous allez faire beaucoup plus rapidement
cette fois ci en apprenant ce langage là et d'ailleurs sera encore plus rapide à votre
prochain langage ensuite chaque saut devient devient un peu moins dur en fait quand on l'a fait et
et vraiment essayez de le faire vous avez un petit script shell essayez de le recoder en go
juste pour voir juste pour voir comment vous pourriez faire en utilisant le plus de fonctions
natives pour avoir le moins de oui parce que si jamais vous faites du go et que vous appelez
vous appelez du shell en permanence avec des avec des execs vous avez raté mais essayez de le faire
voyez comment ça se passe voyez ce que vous avez à pouvoir vous apporter un point aussi dont
on n'a pas parlé c'est la vitesse d'exécution encore dans une autre boîte j'avais un script shell
qui tournait à chaque fois que la client se connectait il y avait un petit script shell qui
tournait pour générer un environnement de sftp voilà et en fait c'était le lend et mon site
io m'avait c'était lui qui avait codé ça en bâche pourtant il n'était pas du tout 96 et ça
m'était 18 secondes et ce qui me disait c'était bah non mais c'est pas possible d'améliorer ça
c'est que des appels systèmes c'est comme ça et ce sera jamais autrement j'ai recodé ce script
là en bâche j'ai recodé en go on est passé de 18 secondes d'exécution c'est à dire le client
était ing pendant 18 secondes et bah on est passé à 0,5 secondes ce qui est très lent pour un
programme en go mais en fait parce que derrière on avait là vraiment les appels systèmes il n'y
avait pas toute la notion d'interaction entre les commandes de temps de traitement etc etc on
avait vraiment quelque chose qui était rapide et voilà ça c'est un exemple concret que je
donne donc essayez quand vous avez la prochaine fois que vous avez un problème avec un script
bâche essayez de le recoder en go nous c'est le moi c'est vraiment la chose que je vais vous dire
de faire le essayez pas du un langage un peu exotique pour le faire essayez pas en ruste voilà
clairement fait un langage simple ça pourrait être même du piton à la limite mais essayez en go
quand même et vous allez voir que vous allez avoir des concepts qui vont apparaître et qui vont
vous aider au fur et à mesure moi c'est comme ça que ça s'est passé je pense que c'est passé comme
ça pour la plupart des gens en ingénieur et logiciel en design logiciel je suis très mauvais mais
voilà j'apprends et en entreprise et ben demander au dev tout simplement si vous n'avez personne dans
votre équipe côté côté ops qui maîtrise on va dire tous ces concepts de programmation de go
et c'est ou go ou autre un voilà et ben demander à vos dev de vous aider en fait et c'est ça qui
est intéressant et c'est ça pour moi le vrai dev ops quoi je veux dire c'est comme je disais on
repart d'écosystèmes mais moi je trouve ça génial quand des devs ben vont faire des merges
request et vont faire évoluer des scripts etc parce que tout le monde parle le même langage au
final c'est on utilise des outils communs et chacun revue ou l'autre veut dire parce que ok on n'est
pas exactement sur le même scope mais au final il y a des points qui se rejoignent et le développement
s'en est un tout à fait comme ça on apprend aussi quoi en entreprise alors après un point pas trop
aller dans un autre sens je l'ai vu dans certaines boîtes où c'est les devs et le langage des devs
qui a impacté la prod en fait dans cette logique là c'est à dire vous êtes pas non plus obligé
d'utiliser exactement l'outil que les devs utilisent pour faire du front web les outils du front web
sont très bien pour du front web c'est pas parce qu'il ya 14 devs dans votre boîte que vous êtes
obligé d'utiliser ce même langage pour faire vous la gestion de votre prod vos développeurs seront
capables de changer de langage pour faire des poule récoches chez vous parce que ils ont la
plupart du temps appris d'autres langages à un moment de leur de leur vie on a tous appris plusieurs
langages même juste notre langue maternelle et après des langages de programmation donc vous
serez capable d'en apprendre d'autres eux seront capables vous vous serez capable en tout cas
comme t'as parlé les concepts vous restez à peu près similaire les uns avec les autres et c'est
comme ça qu'on peut qu'on peut fonctionner en tout cas ce qu'il faut à la fin c'est avoir le bon
langage pour la bonne qualité attendue en tout cas et c'est ça en fait là où ça saurait si vous
avez réussi bon je sais pas si c'est un autre mot à dire là dessus est ce qu'il ya non ça
non non je pense que c'est à peu près tout ça fait là ça fait une heure je pense qu'on est
on est pas mal et j'ai vraiment rien à dire j'avais si d'un peu vraiment tout décrire dans
mes articles c'est vrai mais mais voilà j'espère que là ça clarifiera un peu certaines choses
et en rapportant aussi c'est on n'a pas on n'a pas d'animosité plus que ça du bâche c'est on
est passé par là comme on a dit avant comme on est passé par là on est capable de dire que ça
peut et que ça peut avancer bon par contre les gens qui voilà qui est un peu trop ventard et qui
considère que tous les gens qui font pas du bâche etc c'est des ingénieurs yamel cubanitis machin
enfin anti anti tout non ça ça par contre là moi je ne veux pas travailler avec ces personnes
voilà c'est ce que j'ai vu toujours du bien je vais t'honnête je peux imaginer bah non c'est
pas le cas j'ai un autre podcast de prévu sur sujet là qui arrivera normalement mi-juin sur
justement cette gestion des outils et cette gestion de la frilosité à avancer dans les outils
que l'on reviendra forcément sur ce qu'on a parlé là mais il y en aura un prochain sujet là-dessus
merci matieu merci à toi pour ce podcast là ça durerait même plus longtemps que ce que j'imaginais
sur un sujet comme celui ci je pensais pas qu'on tiendrait autant de temps donc je crois que ça
était intéressant pour vous de l'écouter et on se retrouve sur le discord pour que vous
trouverait en lien un peu partout sur notre site web il ya un lien d'invitation n'hésitez pas à nous
pinger en direct si vous voulez plus d'informations à en débattre à venir nous parler là-dessus ce
sera avec joie même si vous n'êtes pas d'accord c'est aussi intéressant là-dessus et puis on se
retrouve avec ceux qui sont déjà sur le discord maintenant pour faire un petit débrief après
ça voilà merci beaucoup et puis et puis une prochaine à la prochaine salut