Quels sont les nouvelles Claude et DevOps en ce mois d'août 2023 ?
On a un leak de clés API par milliers sur le Docker Hub, la mort du logiciel libre en Europe peut-être.
Le questionnaire de Stack Overflow on en parle chaque année et un successeur à rencible.
Tout ça c'est ce qu'on va voir aujourd'hui dans cet épisode de podcast.
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 Actu DevOps, ton émission de veille et Claude DevOps mensuelle.
Comme d'habitude, reste bien jusqu'à la fin pour découvrir notre sélection d'outils.
Et ce soir, j'ai avec moi pour parler d'actu, R1, bonsoir R1.
Bonsoir.
Et aussi, R1, bonsoir R1.
Bonsoir à toutes et tous.
Et si tu veux en connaître un peu plus sur chaque podcasteur, surtout sur R1 et R1,
tu peux aller écouter les podcasts d'entrevue que j'ai fait de chacun d'entre eux.
Et si tu veux en apprendre plus sur moi, il y en a aussi un pour moi.
Et tu suffis d'aller remonter dans le flux d'actualité des podcasts.
Et puis si tu es sur Youtube, tu vas sur la playlist en appartez, tu trouveras les podcasts.
Alors, on va commencer par le traditionnel courrier des auditrices et auditeurs.
Et aujourd'hui, c'est un auditeur qui m'a écrit un message sur le formulaire des questions.
Je parlerai après du formulaire des questions.
Alors, il me pose une question.
Donc, c'est quelqu'un qui envisage une alternance.
Il me demande si une alternance, en tant qu'ingénieur d'Evox, peut mener vers une carrière dans le cloud
et à terme mener vers un poste d'architect cloud.
Alors, si tu me suis depuis un moment, tu sais que je ne suis pas vraiment fan du terme d'ingénieur d'Evox.
Pour moi, on est ingénieur d'Evox.
Et puis, on fait le mouvement d'Evox dans notre manière de faire les choses.
Mais, passons.
Alors, pourquoi je dis ça ?
Parce qu'on ne dit pas ingénieur agile.
Donc, ingénieur d'Evox, c'est un peu pareil pour nous.
Pour être plus pragmatique, en fait,
ça dépend des cours que tu vas avoir dans l'école que tu vas choisir
et surtout l'entreprise dans laquelle tu vas aller
et qui va t'accueillir et surtout les travaux que tu vas faire.
Alors, j'imagine que, comme tu parles d'ingénieur, c'est un bac plus 5.
En vrai que général, en bac plus 5, on voit pas mal de choses dans les cours
puisque moi, je donne des cours justement à des bac plus 5.
Mais, tu ne vas pas pouvoir tout étudier pendant ton alternance.
Clairement, le cloud, ça me semble un peu juste.
Moi, je vois qu'on a un alternant de bac plus 3, bac plus 4.
Il ne va pas faire des tubes bac plus 5.
Mais, il voit tout ce qui est système, administration système, un peu de cloud.
Mais pas trop.
C'est-à-dire que pour l'instant, c'est encore nous qui gérons la partie cloud pur et dur,
les serveurs, les réseaux, etc.
De manière générale, pour être architecte cloud,
donc après évidemment, l'administrateur cloud,
puisqu'on fait administrateur, administrateur cloud, architecte cloud,
il va quand même falloir que tu aies de l'expérience,
mais à partir du moment où tu es ingénieur et tu as plusieurs années d'expérience,
perso, j'estime à 5, 6 ans d'expérience.
Si tu as vu pas mal de contexte de production,
tu vas pouvoir commencer à être architecte cloud.
Typiquement, c'est ce que j'envisage.
Je ne sais pas si René et Erwan, vous avez un avis là-dessus.
Si Erwan, je te laisse.
Un avis sur l'alternance, oui.
Je trouve que c'est toujours cool.
Effectivement, combiner un cursus technique,
donc un g, système, etc.
Avec une alternance,
c'est clairement une bonne option pour après,
pouvoir trouver des taffes et grandir en tant que futur architecte.
Donc ça, je pense qu'il n'y a pas de débat.
C'est quand même plutôt pas mal.
Après, effectivement,
je ne sais pas à quel point,
si tu veux vraiment travailler que dans le cloud,
ça va dépendre de ton alternance.
Ça va pas mal, comment dirais-je,
driver la suite des choses.
Si tu fais une alternance dans un truc qui ne fait que du berr métal,
il faudra rebondir un peu ailleurs
pour prétendre aller vers des postes d'architecte cloud.
Mais en tout cas, clairement, moi, je ne vois pas de contre-indication
à ce qui a été évoqué pour atteindre le graal
qui a été émis. Et toi, René ?
Oui, je suis d'accord. Je pense que c'est la bonne voie.
Il n'y a pas spécialement de problèmes. Après, ça dépend énormément de l'intérêt
qu'on y porte et du temps qu'on y consacre.
Si on est motivé, je pense qu'il n'y a pas vraiment de problèmes.
Après, ça peut même aller assez vite, je pense,
d'aller sur une venue architecte.
Si c'est ce qu'on veut faire,
si on est intéressé, je pense qu'il n'y a pas de problème particulier.
Je vais rajouter un dernier truc, parce que je me suis aperçu
que je ne trollais pas assez sur Windows, puisqu'on m'a proposé sur LinkedIn
un poste d'administrateur système Windows, si vous m'avez suivi
aujourd'hui sur LinkedIn. Si tu veux travailler dans le cloud,
évite absolument les entreprises qui travaillent
dans des contextes Windows. Parce que même s'il y a du
serveur Windows dans le cloud, c'est pas la grande majorité.
Je pense que René et Erwan seront d'accord avec moi. C'est de l'administration système Linux
du cloud basé sur Linux.
Les écosystèmes Linux vont plus te proposer des
alternatives pour passer au cloud.
Je ne sais pas si vous êtes d'accord avec ça, mais en tout cas, moi, c'est mon conseil.
Globalement, oui, je suis d'accord.
Après, je pense que les
personnes qui peuvent avoir des connaissances sur les environnements Windows,
c'est aussi un plus. Ça peut être utile, parce qu'il y a quand même
beaucoup d'entreprises où on retrouve un peu de tout.
Je pense que ce n'est pas forcément mal d'avoir
une expérience côté Microsoft, même si personnellement, je ne l'ai pas forcément.
Je ne pense pas que ça soit bloquant, mais effectivement, en termes de taf,
c'est clairement plus sur du Linux que tu trouveras.
Des opportunités
dans le cloud.
Tu peux nous laisser un message.
Tu as Apple Podcast.
Je sais qu'il y a plein de gens qui nous écoutent sur Apple Podcast.
Tu as aussi podcast addict.
Là, il y a déjà pas mal de messages.
Tu as le forum des compagnons de DevOps et tu as la plate-forme
pour poser une question.
Tu peux poser des questions.
Tu vas sur question.com, tu as des compagnons de DevOps.fr.
Tu peux poser une question. Ça arrive sur mon espace très low.
J'essaie de gérer les questions.
Souvent, c'est des idées pour des futurs épisodes de podcast,
soit solo, soit à plusieurs.
Alors, Erwin, tu vas nous parler de
Leak. Ça va devenir ta spécialité, je crois.
Malheureusement, notre actualité, souvent,
fait de ça.
C'est important de le rappeler pour qu'on soit toujours plus vigilant.
De quoi va-t-on parler?
On va parler de tout un tas de sujets autour de Leak.
Dans des conteneurs hébergés sur Docker Hub.
Alors, si vous êtes ici,
c'est inutile de rappeler que Docker fait partie de notre quotidien.
Pour développer, pour avoir des stacks complexes localement.
Pour la CI et même, bien sûr, pour de la production.
Les conteneurs de Docker, c'est vraiment un truc
qui aujourd'hui est pas mal répandu.
Et donc, du coup, dans cet optique-là,
il y a des chercheurs de l'École supérieure polytechnique de...
Alors, désolé, je ne vais pas forcément bien prononcer, mais de Renani, Westpally,
qui ont révélé que des milliers de conteneurs
d'images hébergés sur Docker Hub
stockaient des informations qui auraient dû
rester convaincées en ciel. Alors, déjà, pourquoi ils ont travaillé
sur Docker Hub ? Tout simplement parce que, pour ceux qui l'ignorent,
Docker Hub reste la registrie principale pour récupérer des
images Docker. Il me semble que c'est même la registrie
legacy et que du coup, l'étude
faite dessus permet d'être assez représentatif
de ce que font les gens. En tout cas, c'est ce que l'étude
met en avant. Et donc, le résultat, c'est qu'ils ont trouvés plein de choses.
Alors, quand on dit plein de choses, c'est quoi ? C'est qu'ils ont quand même contacté
à peu près 1800 développeurs qui ont retrouvé
via les comptes Docker Hub gravatars qui étaient associés aux
comptes sur Docker Hub via éventuellement même les informations
qui étaient dans l'image Docker avec des variables d'environnement. Ils regardent
comment était fait l'image.
Bien sûr, ils ont contacté tous ces gens avant de publier leur étude.
Pourquoi ? Parce que globalement,
leur étude a montré que
dans ces contenus, enfin dans ces images, pardon, je vais y arriver,
on trouvait des clés SSH, des clés
SSL, des APIQI pour des
services tiers, Twitter, Slack, GitLab, Gira, etc.
Et donc,
enfin, et donc tout ça, c'est pas bien de l'avoir dans des images,
d'autant plus quand ce sont des images qui sont publiques,
et donc récupérables par n'importe qui.
Et en termes de volume de ce qu'ils ont analysé,
de ce qu'ils ont analysé, on compte à environ
50 000 clés différentes et environ, enfin
50 000 clés privés SSH, pardon, et environ
3000 clés d'APIQI. Alors, le truc qui est assez rigolo,
c'est, et d'ailleurs c'est un peu ce qu'on peut
se demander quand l'il y est l'étude, c'est pourquoi il y a autant de clés SSH
et aussi peu entre guillemets de clés d'APIQI.
Tout simplement parce qu'il y a pas mal de personnes qui,
quand ils font leurs images de coeur,
en fait, ils ont besoin de cloner
des ressources qui sont privées ou des choses comme ça, donc du coup
lorsqu'ils font le build, pour se faciliter la vie,
ils copient une clé privée quelques temps,
ils font leur guide-clone ou je sais pas quoi,
qui m'ont installé les ressources privées, puis une fois qu'ils ont tout sur leur image,
ils effacent la, comment dirais-je, la clé.
Bon, bien entendu, suivant comment vous gérer les lailleurs, etc.
C'est pas ouf parce que ça veut dire qu'il y aura
un lailleurs avec cette information et donc
ce lailleurs avec cette information fait que ça peut être récupérable par n'importe qui.
Et donc voilà, globalement, il y a l'histoire. Et moi ce que je trouvais
à l'étude, elle est hyper longue, on va pas revenir là-dessus.
Ce que je retiens, c'est que, bon, bien entendu, les gars qu'on fait la recherche,
donc comme je dis, ils ont prévenu les gens
chez qui ils ont trouvé ça, et enfin
dans la mesure du possible, et pour leur dire
qu'ils avaient trouvé des choses pas ouf.
Et globalement, dans une bonne partie des réponses qu'ils ont reçues, c'est que
comme c'était des images dépréciées, ils ont pas fait attention, etc.
donc c'est des choses qu'on aurait jamais dû être soit publiées,
soit peu importe, ça aurait pas dû être là.
Et donc pour beaucoup, ils ont aussi
désactivé quand c'était nécessaire, enfin possible, pardon, les
clés d'appel. Et moi, quand j'ai lu
cet article, le truc auquel ça m'a fait penser, c'est du coup
cette histoire déjà de clés privés pour cloner
des ripos privés ou des choses comme ça,
ça me rappelle que quand vous faites un build
il y a des options qui vous permettent d'avoir
des informations privées juste le temps du build. Je pense à
l'option build arg quand vous faites votre build d'image de coeur
dans lequel vous pouvez passer des choses qui ne seront pas
infinées dans votre image de coeur. Donc ça c'est pratique.
Et puis pour la partie SSH, si vous avez votre agent qui
a tout ce qu'il faut, vous faites votre build avec le tir et tir
SSH et hop comme par magie, dans le build
vous avez accès à ce dernier et donc vous pouvez cloner
des choses privées. Et le truc que ça m'a rappelé
c'est qu'il y a aussi des outils, alors j'avoue que j'ai jamais trop mis ça
en place et j'aimerais bien avoir votre avis dessus. Mais comme
GeatLeaks qui justement est censé un peu repérer
donc via, enfin quand vous le mettez en pré-commit, bien sûr, si
une fois que c'est pouché sur GitHub, c'est perdu, on va dire,
mais en pré-commit qui permet de détecter
des secrets qui seraient écrit en dur
dans votre code, dans vos images ou whatever.
Et donc voilà voilà, donc René par exemple
est-ce que tout ça t'évoque quelque chose ? Est-ce que toi aussi tu as fait partie de ces gens
qui copiaient un peu pas proprement des secrets
dans les images ? Il faut jamais dire jamais tu sais
ça peut être pu m'arriver donc voilà
j'ai oublié. Et euh, ouais non je pense qu'il faut faire
attention, je pense que ce que tu disais, l'histoire des liers ça peut
être un peu visieux je pense
d'une même manière quand on pousse dans
Geat un secret, il faut faire le nécessaire pour refasser l'historique
bien sûr et pas juste refaire un commit derrière
Ouais, pas mal de choses à se méfier. Après ce que dis pas l'étude
c'est ce que ces secrets-là étaient plus ou moins
la proportion de validité de ces clés-là
par exemple des clés d'appliés, ça aurait été intéressant aussi d'avoir
une idée pour savoir si ce qui a été retrouvé était
à 80% en valide ou pas
ça va plus être intéressant
mais oui, globalement, voilà ce que tu disais
aussi, mettre en place des outils. Aujourd'hui je pense qu'il y a suffisamment de outils pour éviter de
commit des secrets, faire des audits des images, je pense qu'il y a
des outils qui doivent être capables de ressortir ce genre de
d'infos si on a pousché un secret quelconque
voilà
pas mieux
Je vais dire comme René
et comme toi Erwan, les hoocs
de pré-commit c'est bien. J'ai jamais testé
Geekleaks mais on en avait parlé. Je crois qu'on en avait parlé pour
l'épisode sur les secrets. En effet, utiliser
l'intégration continue pour scanner
le code et les images
ça peut être une bonne chose et dès qu'il y a un secret qui remonte
le révoquer. Une fois qu'il est
affiché, il est plus
sûr donc il faut le jeter et le remplacer
et en fait c'est mieux d'ailleurs de le révoquer que d'effacer l'historique
pour moi, parce que je considère que comme il est
sur une forge, il a liqué. Je ne saurais pas
quoi dire d'autre, à part ça. A part que ça m'étonne quand même
parce que typiquement, moi les clés c'est sache
je les mets plutôt dans mon intégration continue que dans mes images
de conteneurs mais bon peut-être que
je me trompe. Ah bah moi je ne veux pas
balancer mais j'ai travaillé dans une boîte où à un moment
il y avait quelques petites légertés
sur le sujet et c'était essentiellement lié au fait
que les personnes qui avaient mis ça en plage, je pense qu'ils n'étaient pas
hyper à l'aise avec les options de build
d'images de cœur et donc du coup ils avaient
dans leur image des clés ou des trucs
comme ça c'était pas...
le dérapage arrive vite, c'est ça que je veux dire
mais c'est ça, tirer et tirer c'est sache, les build arg
et normalement avec tout ça vous pouvez vous passer
de mettre des secrets ou que ce soit et
c'est propre. Alors de manière générale
j'ai tendance à dire qu'une image de conteneurs elle ne doit contenir
aucune variable, aucune donnée de ce type là
et que ça doit faire partie de l'environnement qui est injecté dans le
conteneur, c'est à dire que notre build il doit être complètement agnostique de toute
configuration, clés sache comprise, clés à pays etc.
donc si ça t'arrive de mettre une clés sache dans ton conteneur
c'est qu'il y a quelque chose qui doit mal se passer
quelque part dans la structure où tu es et il faut vous poser des questions
à ce moment là parce que si vous avez besoin de faire ça c'est qu'il y a un truc
qui ne va pas selon moi.
René, tu te vois oucher de la tête ? Oui oui, je suis d'accord.
Tu es d'accord. J'acquiète. Tu acquiète, parfait.
Et bien alors si on n'a rien à ajouter je vous propose qu'on passe à la
suite. Et donc la suite
on en a déjà parlé en 2022 c'est le questionnaire de Stack Overflow
donc le Stack Overflow Developer Surveil est sorti
depuis mai alors je sais on est en août au moment où ça sort mais c'est
toujours intéressant de s'y pocher surtout qu'on s'y est pas
intéressé ici. D'autres l'ont fait mais pas nous. Donc qu'est-ce qu'on y apprend
qui est intéressant pour nous, pour le cloud, pour le DevOps. Alors déjà
pour les personnes qui ne connaissent pas le questionnaire Stack Overflow c'est un questionnaire
en ligne qui a lieu toutes les années et qui est plutôt représentatif
parce que là il y avait 70 000 personnes, cette année il y a
89 000 personnes qui travaillent dans le monde du développement de logiciels
dans 185 pays. On peut dire que ça commence à faire du monde.
Comme en plus on a déjà parlé en 2022 sur
Actu DevOps on va pouvoir faire des comparaisons. Alors
la première chose c'est la partie apprentissage du code qui m'a intéressé
donc évidemment je te mets le lien du questionnaire tu peux
aller voir c'est vachement bien fait, tu peux aller visualiser plein de trucs. Donc là
je vais plutôt te parler chiffres et ce que je peux te dire
en podcast il y a des choses que je ne pourrai pas te dire. Au niveau de l'apprentissage
du code on apprend que les ressources en ligne
ça représente 80%.
Ce qui est en augmentation puisque la dernière
c'était que 70%. Donc ça veut dire qu'il y a quand même
8 personnes sur 10 qui utilisent des ressources en ligne pour apprendre
à coder. Ce qui veut dire que le travail qu'on fait
dans Actu DevOps, d'autres podcasts,
les vidéos etc les articles de blog c'est important parce qu'il y a beaucoup
de gens qui utilisent ça.
Et ce qui est important et ce qui est intéressant qui m'interpellait c'est que
les personnes de moins de 18 ans sont celles qui font le plus souvent
appel à des ressources en ligne. Ça veut dire
que c'est plutôt les jeunes qui utilisent le plus
les ressources en ligne. Ce qui paraît pas étonnant puisque
étant donné nos âges autour de ce podcast-là, quand on en était
jeune et qu'on apprenait en tout cas moi quand j'avais moins de 18 ans
j'avais pas accès à internet. Donc déjà ça c'est la base
c'est que internet n'était pas encore démocratisé je sais pas à R1
renait. Parmi ces ressources on a
90%
sont des docs en ligne et ça c'est en hausse. 82%
des personnes utilisent Stack Overflow
ça c'est en baisse, ça pourrait faire l'objet d'une autre actue
mais j'attends un peu parce qu'apparemment Stack Overflow
et on perd de vitesse depuis quelques mois. 77% des interrogés
utilisent des blogs ça c'est en hausse aussi et 60% des gens
utilisent des vidéos. Il n'est pas écrit podcast mais
les vidéos c'est en stagnation, on est à le même niveau a priori
d'utilisation.
Cette année il y a eu un focus fait sur la télégence artificielle
puisque tu l'auras vu on ne peut pas passer à côté de chat gpt et consort
cette année et ça c'est important.
Du coup, combien un focus qui est fait, je me suis
intéressé à ça aussi et il y a 70% des
personnes qui ont répondu utiliser ou prévoir d'utiliser
les outils d'intelligence artificielle dans leur processus de développement.
Et ceux qui apparaînent à coder
sont encore plus nombreux puisque
ils représentent 82% des personnes et à titre personnel
moi je donne des cours en école et pendant m'aîter
les étudiants, j'ai remarqué certains de mes élèves
qui utilisent chat gpt. Je ne sais pas encore ce que ça va donner
je verrai dans l'analyse de leur code si ça a donné des piss
surtout que j'ai vu à peu près quel groupe c'était
donc je suis assez curieux. Mais ce qui est intéressant c'est que
70% des personnes
il faut que j'y arrive. 77% des personnes
sont favorables ou très favorables aux outils d'IA pour le développement
les développeurs et
développeuses professionnelles sont plus susceptibles d'être
indifférents que ceux qui apprennent à coder. Ça veut dire que les personnes qui apprennent à coder
sont moins indifférents à l'intigence artificielle
que les personnes qui sont déjà professionnelles.
Il y a plein de choses intéressantes encore sur l'utilisation de l'IA mais je vous d'affaire
un panorama complet donc on va parler des métiers.
Au niveau des métiers, ce qui m'a surpris
c'est qu'elle fortobaisse dans la plupart des métiers. Et ça
je l'explique par le fait qu'il y a beaucoup plus de métiers que l'an dernier
qui sont cités. Parce que dans les métiers
des répondants il y a 33% des personnes qui font du
développement full stack c'est en baisse, 17% qui font du développement
back end c'est en baisse, 7% qui font du développement full stack c'est en baisse
et en 10ème position
on a 2% des personnes qui
spécialisent DevOps. C'est en baisse aussi.
Et comme je l'ai dit il y a beaucoup plus de métiers que l'an dernier, ce qui explique la baisse
de tous les métiers finalement. Alors qui sont
les personnes qui répondent à ce questionnaire là?
Donc au niveau géographie, il y a 21% des personnes
qui sont aux Etats-Unis, c'est en hausse par rapport à l'an dernier.
C'est le premier pays. Le deuxième pays c'est l'Allemagne qui est passé devant l'Inde.
L'Allemagne a 8%. Donc il y a quand même une chute. Parce que le premier est à 21%.
Le deuxième pays c'est l'Allemagne a 8%. Le troisième pays c'est l'Inde
a 6%. Et Cochorico, nous sommes en 6ème position
position stagnante par rapport à l'an dernier avec 3%
des répondants. Donc 3% des personnes qui ont répondu
sont en France. En France mais pas francophone.
C'est dommage, on n'a pas cette notion de locution.
Ça pourrait être intéressant. Il y a 37% des personnes qui répondent
qui ont entre 25 et 34 ans et c'est la majorité en fait quand on voit la courbisage
c'est là où il y a le plus de personnes. Au niveau de l'environnement
de travail, comme on sort quand même
de période de confinement il y a quelques années
en 2022 on était tout juste sorti du confinement
depuis un an. Je me suis intéressé à ça aussi. Donc il y a 42%
des personnes qui sont dans un milieu de travail hybride. Ça veut dire
en partie en remote et en partie en présentiel. Donc ça c'est stagnant.
Par contre il y a une baisse du nombre de personnes en full remote
à 41% et une augmentation des personnes
en présentiel à 16%. Ça veut dire qu'il y a
plus de personnes qui travaillent en présentiel qui répondent aux questionnaires
ou alors que les gens reviennent dans les bureaux.
Je ne sais pas comment l'analyser autrement que comme ça.
Il faudra voir sur la durée l'année prochaine qu'est-ce qu'il y en a.
Alors au niveau des techno vous allez me demander quels sont
les techno les plus populaires. Alors évidemment
indétonable le premier JavaScript avec 63%.
Je passe sur le deuxième. Python est en troisième position. Alors JavaScript
pour info est en baisse. Par rapport à l'an dernier.
Python est en troisième position avec
49% et lui il est en hausse.
Et ce qui m'intéresse aussi c'est d'avoir des
techno comme le bash. Le bash est en 6e position avec 32%
et il est en hausse aussi. C'est à dire qu'il y a plus de monde
encore qui font du bash et je sais que ça va faire plaisir à Mathieu.
Mathieu si tu nous écoutes c'est pour toi. Et quelque chose qui va faire plaisir
à René c'est que Rust reste le langage le plus admiré.
En plus des langages les plus populaires ils ont fait un truc genre
admirer désirer qui est vachement bien. Visuellement c'est très
chouette de regarder ça mais par contre en podcast ça passe pas. Par contre
ce que j'ai pu remarquer c'est que Rust est le plus admiré à 85%
des répondants qui admire ce langage de programmation.
Qu'est ce qu'on met derrière le terme admirer ? Je te laisse aller voir le questionnaire.
Comme je te le disais justement il y a un énorme
travail qui a été fait sur la visualisation des techno.
Et pas que les désirer etc. Il y a vraiment
des arcs de cercle avec les gens qui passent d'une techno
à l'autre. C'est vraiment super intéressant.
C'est très compliqué à retranscrire en podcast donc va voir le
questionnaire. Enfin on va parler de l'expérience de développement
avec les processus, les outils etc.
Parce que là dedans on a notamment les développeurs
professionnels qui déclarent à 72% avoir
une intégration continu et un déploiement continu et ça c'est bien ça nous plaît
à Radio DevOps parce que ça veut dire qu'il y a plus de la majorité
des personnes qui ont ces techno là. Ils ont aussi
pour 60% des tests automatisés
et du DevOps disponibles dans l'organisation. Alors
moi je me pose quand même une question sur les personnes
qui font du déploiement continu et qui n'ont pas de tests automatisés.
Je sais que ça existe mais je m'interroge toujours sur pourquoi ils font ça.
Et enfin
les outils d'observabilité, supervision etc.
Donc ça a progressé puisque aujourd'hui il y a 39%
des répondants qui estiment avoir des outils d'observabilité
contre 37% l'an dernier. Donc évidemment
c'est un panorama un peu biaisé que je vous fais mais
est-ce que vous aviez déjà regardé le questionnaire Stack Overflow, est-ce que vous le regardez
chaque année tous les deux et quelles sont vos impressions sur ces chiffres
là ? Rene, puisque c'est toi qui m'as suggéré
de parler justement de questionner Stack Overflow.
Moi ce qui m'intéresse c'est que c'est la 8e année consécutive
que raste et non comme tu l'as dit, les plus admirés et plus désirés.
Voilà, ça c'était...
Après Fosmefieb c'est quand même, comme on l'a vu il y a beaucoup de
c'est le premier pays c'est les US donc ça
biaise peut-être un petit peu les résultats. Mais ouais
c'est toujours intéressant d'avoir une idée un petit peu de
qu'est-ce qui est utilisé, qu'est-ce que les gens préfèrent,
qu'est-ce qu'ils font. Donc ouais non c'est un... enfin comme
tout sondage c'est intéressant de
regarder un petit peu pour voir un petit peu qu'est-ce qui est populaire, qu'est-ce qu'il est
ou pas et puis un petit peu la tendance parfois
de où vont les métiers quoi.
Merci et toi Erwan alors.
Moi déjà je suis outré de voir que
Pearl est aussi bas. C'est au niveau
d'Elyxir, c'est entre Elyxir et Scala.
Donc toute
mon initiation au développement
est pas en fumée quand je vois pas ça. Mais non moi
je reste toujours hyper surpris que Bache
soit CEO. C'est bon
va être très bien et je suis
encore plus surpris de voir que c'est Rust le plus admiré entre guillemets.
Quand je pense que j'ai passé un après-midi
à faire un exercice et j'ai trouvé que c'était l'enfer
mais bon je trolle.
Mais non en fait ce que je trouve intéressant c'est que ça donne
même si c'est quand même
très particulier comme sondage ça donne quand même des tendances
et il y a des tendances
il y a des tendances qui sont intéressantes
ne serait-ce que sur le remote
et le présentiel. C'est
quelque chose
en tout cas que moi j'avais constaté à gauche à droite
et ça me fait un biais de confirmation
mais ça semble aller aussi dans ce sens-là
J'ai l'impression
que le go est un peu plus élevé par rapport à l'année précédente
et
moi j'ai le sentiment que c'est plutôt bien
Mais non en vrai
il y a plein de petites infos
qui sont intéressantes
et
même s'il ne faut pas prendre ça comme évangile
et surtout pas se dire
parce que
parce que PowerShell est de vango
il faut tout faire en PowerShell
ça ne doit pas
être un peu plus grand
mais c'est intéressant pour avoir une idée
des compétences globales que les gens
voire des trucs communs
je trouve que c'est toujours intéressant
à parcourir
et effectivement il y a des stats sur la CI-CD
sur les tests et tout qui sont toujours
assez croustillantes à regarder
parce que déjà on se dit qu'il y a pire ailleurs
que ce qu'on connaît
mais non
moi je trouve que c'est bien pour avoir
une petite photo de ce qui se passe
et mine de rien, c'est à Coverflow
il y a presque 90 000 participants
donc ça commence à être
assez significatif comme truc
toujours intéressant à lire
et puis rendez-vous l'année prochaine
pour voir s'il est tendance de se confier
en effet 89 000 participants
et moi je vois que le C par lequel j'ai commencé
est quand même dans les 10 premiers
moi ça m'étonne pas que je sois aussi haut
parce que mine de rien c'est facile à apprendre
et on en a de partout et on parle de l'intégration continue
il y en a beaucoup dans l'intégration continue parce que dès que tu veux faire un truc
lancer plusieurs commandes
ou plusieurs scripts qui sont développés dans d'autres langages
tu passes par le Bache et puis de toute façon
si tu veux interfacer plusieurs commandes
tu fais du Bache et c'est très facile
de faire du Bache pour des petits trucs
ça m'étonne pas alors je n'ai pas parlé des bases
de données mais la première base de données est PostgreSQL
la deuxième MySQL je n'ai pas parlé des plateformes Cloud
évidemment la première plateforme Cloud
tu l'auras compris c'est Amazon Web Services
il y a beaucoup de choses à apprendre
justement dans ces questions et si on veut en faire le tour
on pourrait y passer des heures donc c'est pour ça
qu'aucore une fois je t'encourage à aller voir
tout ça
alors si tu apprécies justement le podcast
tout ce qu'on raconte et tout le travail
qu'on fait aussi sur la chaîne Youtube
si tu l'aimes, si tu veux t'assurer qu'on continue
à produire justement ce podcast et ce contenu
le meilleur moyen c'est de nous aider en nous soutenant
soit en faisant un petit don, tu peux aller sur la plateforme
de don LibèreAPE, tu trouveras un lien sur le site internet
compagnons-devops.fr
tu peux aussi et ça nous aidera
à partager le podcast puisque faire connaître un podcast
c'est très dur, sur Youtube c'est plus facile
mais un podcast c'est plus dur donc le prendre
l'envoyer par mail à tes collègues
si il y a un épisode qui t'intéresse tu peux y aller
et puis aussi je te rappelle que le podcast est en licence libre
tu peux le réutiliser dans tes propres contenus
alors, Ronnet tu vas parler d'un truc
qui m'a intrigué quand on a préparé l'émission
je me suis dit tiens, il y a un truc qui se passe
oui alors c'est
une initiative européenne, enfin c'est peut-être plus
qu'une initiative parce que
du jeu c'est de faire quelque chose qui s'appelle le cyber resilient act
alors
c'est assez donc il y a beaucoup de choses donc
je vous encourage à aller voir les liens
si ça vous intéresse je vais essayer de résumer
un petit peu ce que j'en ai compris sachant
que je suis loin d'être un expert sur ces genres de sujets
donc voilà si je dis des bêtises ou non vous ne voulez pas trop
donc en fait l'idée à la base je pense qu'elle est assez
intéressante parce que c'est d'essayer d'améliorer
la sécurité des logiciels qui seront utilisés
en Europe
et donc de mettre en place tout un tas de dispositifs
à la fois techniques et administratifs pour gérer
plus potentielle faille etc
et remonter à des instances
alors c'est pas très clair quels sont ces instances
probablement quelque chose au niveau de l'Europe
mais on ne sait pas trop ça reste assez flou pour le moment
mais voilà c'est l'idée c'est quand même d'essayer d'améliorer la sécurité
sauf que malheureusement
un des soucis c'est que ça
je pense que ça a été très très
orienté ou du moins avec pas mal
pour le logiciel propriétaire et il y a beaucoup
de soucis
et notamment on a le Conseil National du logiciel libre
qui a mis un billet
en disant qu'il y a un certain nombre de problématiques
avec le logiciel open source et des sociétés
qui font
de l'open source
enfin qui travaillent avec des logiciels open source
et donc notamment
ce surcoût entre guillemets
toutes ces dispositifs
administratifs et techniques en plus
ils estiment que ça va représenter jusqu'à 30%
en plus de coûts pour les sociétés
qui sont souvent pour la plupart de petites sociétés
des PME donc ça c'est un premier problème
potentiellement au niveau économique
pas toutes les sociétés seront à même de supporter
cette augmentation là
et il y a aussi tout un tas de problèmes avec les logiciels
open source parce que les logiciels open source
ont une clause
entre guillemets non responsabilité donc c'est
un peu le use at your own risk donc il n'y a rien de garantie
et donc ça
ça cause un certain nombre de problèmes avec ce décret
là parce que
parce que
voilà il va falloir certainement
rajouter enfin qui va s'occuper
pour les sociétés qui utilisent
ce type de logiciel qu'est ce qu'il va falloir faire
donc des cours en plus comment ça va se passer
donc il y a des choses qui ont été quand même un peu prises en compte
notamment le fait que
les activités à but non lucratif
sont exantées en fait
entre guillemets de ces obligations là
d'avoir plus de contrôle etc
mais ce qui est considéré à but non lucratif
c'est des logiciels pour lesquels il n'y a aucun
contributeur soit professionnel
enfin ou du moins rémunéré
donc du coup on va dire qu'il y a énormément de projets
open source
ou des personnes peuvent travailler de manière professionnelle
dessus et contribuer, à partir de ce moment là
le projet n'est plus considéré totalement comme
un logiciel
à but non lucratif
et donc entrer dans
cette fameuse procédure pour rajouter du contrôle etc
donc voilà ça pose tout un tas de soucis
à ce niveau là
il y a aussi
une autre
il y a un autre lien qui vient de la fondation à page
où il y a des choses qui ne sont pas très carré notamment le fait que
c'est pas très clair mais
il est demandé en fait que les logiciels qui soient utilisés ne doivent pas
contenir de vulnérabilité alors avec
peut-être un peu d'ignuance mais globalement
quelque chose qui est impossible
à réaliser
donc bref
je vous laisserai voir les articles
pour creuser tous les problèmes qui ont là dessus mais en tout cas
les gens concernés par le logiciel libre
émettent
des fortes
doutes
voire réformer un petit peu
pour essayer de mieux prendre en compte
les logiciels open source
et c'est en cours
mais voilà ça avance
quand même au niveau des instances européennes
et je pense qu'il faut être assez vigilant sur
ce qui risque de se passer avec ce truc là
parce que potentiellement
je pense que ça peut avoir un énorme impact
notamment il faut savoir qu'en Europe
le logiciel libre c'est plutôt une force
ça représente quand même
des revenus non négligeables
et ça serait un peu dommage de se tirer une balle dans le pied
et de rendre
le travail des entreprises qui se travaillent
dans ce domaine là encore plus difficile que ça n'est
avec une équation
économique qui n'est pas toujours facile à trouver et qui là
deviendrait encore plus difficile
c'est un peu ce que j'en ai compris
encore une fois je suis loin d'être un spécialiste du sujet donc
je vous conseille d'aller voir si le sujet vous intéresse
et ben voilà Christophe peut-être que toi
tu as regardé un petit peu et
je pense que notamment
de part tes activités tu serais concerné par ce genre de choses
et voilà si tu étais un petit peu au courant
ou pas et ben je te laisse réagir
et ben non je n'ai pas regardé j'aurais peut-être dû en fait avant
les missions regarder
ça m'inquiète en effet je vais aller regarder de plus près
surtout que je parcours le texte
du conseil national du logiciel libre
et je vois pas de notion de taille d'entreprise
souvent dans ce genre de texte
quand on a une tolérance sur les petites entreprises
là il n'y a rien
ça ressemble quand même très fortement à quelque chose
qui émane d'un lobby du logiciel propriétaire
je pense qu'il y a quelque chose de cet ordre là
derrière puisque il y a beaucoup de choses qui viennent des logiciels propriétaires
pour empêcher le logiciel libre justement
de pouvoir prendre des parts de marché parce que comme tu le disais en Europe
il y a beaucoup
on utilise beaucoup de logiciels libres et en France
notamment on est le pays européen qui utilise le plus des logiciels libres
je sais pas si c'est le chiffre d'affaires
qui est le plus élevé en Europe mais en tout cas en France
on est l'un des pionniers du logiciel libre
c'est d'ailleurs on pourrait parler
de la relation entre Richard Stallman
et la devise française qui lui a donné
cette idée là mais bon
ça m'inquiète je vais les regarder quand même
ce que je ne sais pas c'est qui
va devoir modifier les logiciels
est-ce que c'est les éditeurs
quand il y a des éditeurs identifiés
je pense à GitLab c'est plus facile
mais quand il y a des éditeurs non identifiés qui sont des personnes
comment est-ce que tu fais
quand c'est des groupes de personnes
comment tu vas les forcer est-ce que c'est les entreprises
qui utilisent les logiciels libres qui vont devoir faire des choses
ça reste encore flou pour moi
R1, oui, ce que j'en comprend c'est que c'est le
partenaire du client
qui va être plus ou moins responsable d'assurer
un certain suivi
des failles etc
potentiellement les corriger ou les faire corriger
bref à mon avis beaucoup plus de boulot
que ce qui est aujourd'hui nécessaire
parce que si tu prends ne serait-ce que l'exemple de Linux
qui a un consortium
l'Europe va aller voir le consortium Linux
et lui dire bah voilà faut faire ci faut faire ça
ou est-ce que c'est les acteurs européens qui vont faire
des pools request ou des mergers request auprès de Linux
pour dire bah voilà nous notre
moi ce que j'ai compris c'est que sur les gros projets open source
autour du monde en termes techniques
je pense que c'est bon c'est couvert parce que sur les gros projets il y a déjà
toute la structure avec les failles
qui sont reportées, le nom de disclosure etc
toute la gestion tout ça c'est fait, ce qui va manquer potentiellement
peut-être c'est le reporting parce que ce que j'en comprend c'est qu'il y a
un reportage potentiellement reporting en plus à l'Europe
voilà après
donc je pense que ces gros projets c'est peut-être pas eux qui risquent d'avoir le plus de mal
c'est plutôt les projets un peu plus
petits qui de librairie par exemple
qu'on va utiliser, qui bah là comment ça va se passer
tu vas utiliser la librairie qui va être responsable de ça
si il y a des problèmes ça va être toi qui va être responsable en premier lieu au lieu de
que ce soit les gens qui ont fait la libre enfin moi c'est pas très clair
et enfin voilà ça mérite d'être creusé je pense
ça a l'air
dans ce que t'as expliqué
j'ai l'impression qu'il y a rien qui va
c'est... au début tu te dis ok pourquoi pas
mais en fait l'application elle est atroce
enfin en tout cas ce que tu as évoqué pour
appliquer je vois pas comment ça peut marcher
bah en fait aujourd'hui ça te donne l'idée que c'est des
politiciens en fait qui ont des technocrates
qui ont pris le truc, qui ont voulu faire un truc en se disant
on va faire un truc... enfin moi je vais pas aller blâmer je pense qu'il y a peut-être une
bonne volonté d'avancer mais soit comme
Christophe l'a dit ils ont été conseillés par des gens
qui ont plutôt une vision propriétaire et ils ont complètement
enfin je pense occulté une grosse partie de
tout l'écosystème du logiciel open source et libre
et voilà ça fait un peu peur parce que ce
traité il avance et un moment peut-être
qu'il y aura une mise en application qui
reste d'être assez pénible
puis il y a un logiciel sans potentiel vulnérabilité
et puis sans bug et puis
voilà mettez-moi un paquet et ça sera bien
merci
alors en tout cas nous on a des tout petits projets
libres où souvent il y a un ou deux contributeurs chez nous
faire qu'on se pose la question qu'est-ce qu'on fait
on va pas... enfin clairement si on doit rajouter
à 30% de trucs juste en fait on va
arrêter parce que on pourra pas
les maintenir, on les utilisera chez nous
mais on les rendra plus vibres, enfin je vois que ça
pour les tout petits projets qui sont utilisés par peu de
personnes, pas typiquement je pense à notre collection
en cible pour installer Configure Yunos
elle est un peu utilisée mais pas tant que ça
bah si demain on doit faire des trucs comme ça
si on doit rajouter 30% de R&D en plus pour ça
bah juste on va la supprimer dans cible Galaxy
puis voilà mais je vois pas trop...
enfin je vois pas trop d'alternatives
je vais les voir du coup cette histoire
après je pense qu'une des problématiques aussi c'est que
comme pas mal de trucs européens ça reste
encore assez flou quoi tu vois
il y a des choses qui sont et du coup
je pense que ça laisse un petit peu part à l'interprétation
à la fois des fois nous on a peut-être une
interprétation un peu on dit ou là ça craint
enfin on les gens autour du logiciel Open Source Libre se disent ou là
ça a l'air pas cool
bon après voilà je pense qu'il faut peut-être que ça se précise un peu
et ce sera pas aussi catastrophique que ça en a l'air
mais c'est quand même à suivre et
il faut être assez vigilant sur le sujet je pense
c'est peut-être alors comme tout ça émane de la commission européenne
mais c'est peut-être à nous d'aller interpeller nos députés
européens pour leur faire comprendre
qu'il faut pas laisser passer ça
ou alors qu'il faut la mander et très fortement
parce que là ça se passe pas
à l'Assemblée nationale ça se passe vraiment au niveau de l'Europe
et après ça va revenir à l'Assemblée nationale
parce qu'il y a les règles et les lois de chaque pays
les décrets d'applications je sais pas comment ça marche mais bon
il y a un truc à faire
si vous avez des idées je suis preneur mais sinon
on passe à la suite
vivement que ça finisse comme le projet Gaia
il faudrait qu'on entère le projet Gaia d'ailleurs
tu m'y fais penser
bon très cher auditeur il faut que tu saches que la
news que tu veux entendre elle m'a été piqué
parce qu'il était pas au courant mais en tout cas c'est celle dont je voulais parler
et du coup Erwan m'a gris la priorité parce qu'il l'a mis
dans nos notes avant moi
donc Erwan je t'en prie à toi l'honneur
déjà navrai désolé
donc oui on va parler de nanotique
très cher à Christophe et à beaucoup de gens dans la communauté
des DevOps
qui est Antibel en fait c'est tout frais
le 25 juillet il y a
Michael Dehan qui est en chef là si je prononce bien aussi
désolé qui est juste
l'un des créateurs d'Antibel
il a fait un poste sur son blog
où il parle de justement en gros
quoi faire après pour
l'automatisation et ce qu'il faut garder à l'esprit
et donc pour vous éviter de lire cet article
on va vous faire un petit résumé
alors je vais pas rappeler ce qu'est Antibel
mais si jamais il y a des gens qui ne connaissent pas
c'est un outil
qui va vous permettre d'automatiser
le déploiement de configuration
le déploiement de conteneurs, de services
voir d'exécution de tâches et en fait
un peu ce que vous voulez
c'est fait en piton et ça je crois que c'est la date de 2012
un truc comme ça
donc dans son article il revient
un petit peu sur les succès
d'Antibel et les chiffres je vais les citer
parce qu'ils sont assez intéressants, il dit
que Antibel rapporte en gros 600 millions par an
de dollars, c'est pas mal
et que dans les boîtes du fortune
5onrod, il y a
en gros
quasi toutes les boîtes de
ce fortune 5onrod
utilisent Antibel à plus ou moins
à plus ou moins grande échelle
donc il met en avant le succès qui lui pense
est essentiellement dû à l'approche
agentelesse puisque ça repose sur SSH
vous n'avez pas besoin d'installer des agents spécifiques
sur les machines que vous souhaitez gérer avec Antibel
et aussi au fait qu'il estime
que c'est un outil qui a été fait pour ceux qui n'ont pas forcément
de compétences de dev puisque tout passe
par du Yamel, on parle même de Yamel engineer
avec
avec peu ou prou
de codes en soi
on parle plus de description
de tâches ou autres
et ce qui est donc très loin
de concurrents
Antibel tel que peut-être pour ceux
qui en ont déjà fait
donc Antibel c'est bien, c'est cool
mais pour faire des choses vraiment
à grande échelle, il rappelle
que ça peut avoir quelques limites entre autres
et c'est en partie de ce fait
qui pense qu'il y a de la place pour d'autres outils
qui ne dit pas qu'il va enterrer Antibel
ou quoi que soit, de toute façon, ça a été racheté par Redat
donc ça ne sera pas enterré
mais il pense que
pour aller sur des archis encore plus ébrides
encore plus importants en termes de volumes
d'autres outils
seront peut-être plus idouane
et en effet Antibel c'est très bien
mais pour ceux qui ont déjà géré des infras
un petit peu fat avec
arrive très vite le côté de
Antibel c'est lent
donc c'est très discutable, il y a plein de sujets autour de ça
mais globalement c'est le constat qui est fait
et donc autour de tout ça
de toutes ces réflexions
il propose de se lancer dans un nouveau projet
pour faire en gros Antibel
mais le Antibel d'après
il n'y a pas encore de nom qui a été
apposé au projet
et c'est en Rust
qu'il a décidé de le faire
l'explication de pourquoi Rust, elle est assez intéressante
il dit texto dans son article
parce que c'est plus beau que le go
donc chacun fera
son propre
son propre avis sur cette remarque
ça ressemble en effet un peu à un dogme
mais en tout cas oui, l'idée c'est d'aller
vers ce genre de langage
pour faire des binaire facilement exportables etc
où il n'y aura pas besoin d'un
rickoyermont.txt qu'on met à jour régulièrement
pour, comment dire,
faire fonctionner votre stack Antibel
donc voilà en partie
pourquoi le choix
d'aller sur du Rust et puis aussi parce que
le Rust permet, moi je ne suis pas un expert
mais ça permet
c'est bien mieux designé pour faire
justement du SSH à grande échelle
sur plein de machines en parallèle
de façon plus visiblement
plus optimale. Mais par contre
ce qu'ils souhaitent faire malgré cette refonte
c'est de garder quand même des choses qui sont assez propres
donc il veut toujours quelque chose de très simple
donc garder ce côté
et Yamel Engineia
il veut toujours se baser sur SSH
alors j'imagine que ça ne veut pas dire
que tout est fermé pour potentiellement des agents
mais en tout cas le fait d'avoir une approche à Jean Tless
reste quelque chose d'important à ses yeux et gardé en tête
il souhaite être en mesure de supporter
la quasi totalité des playbooks actuel
donc il donne un chiffre de 90-95%
je ne sais pas trop sur quoi il se base mais
il souhaite en gros que ce soit rétro compatible avec
que vos playbooks en CibleSoir soient trop compatibles
avec Loutique et en cours de développement
et que ça aille même jusqu'au support des modules pitons
puisqu'ils prévoient un espèce de
de wrapeur histoire que
déjà que la communauté qui a créé énormément de modules
pour un Cible ne doit pas tout refaire en rust
et
donc du coup permettre
d'être une adoption plus simple
pour ne pas perdre tout ce qui a déjà été fait
dans les choses qui sont évoquées
vraiment de façon très vague
mais bon qu'il faut garder en tête, il parle d'intégration
aussi avec Terrafant
bien sûr
il veut que ça soit toujours full open source
et donc cette annonce qui date
il n'y a pas longtemps, du 25 juillet
a fait beaucoup beaucoup parler depuis
puisqu'il y a plein de gens qui disent que c'est la fin
d'un Cible, d'autres qui disent que non de toute façon
un Cible est trop implanté
pour disparaître rapidement
d'autres qui attendent avec impatience
ce genre d'outils pour aller plus loin sur leurs infras
qui sont hyper fat avec des inventaires et des playbooks
qui mettent trop de temps, enfin des inventaires très fat
et des playbooks qui mettent trop de temps à s'exécuter
moi je suis assez curieux de voir ce que ça donne
c'est clairement un projet à suivre
et donc du coup Christophe, vu que je t'ai coupé l'herbe sous le pied
qu'est-ce que tu as pensé de cette nouvelle ?
alors ce qu'il faut savoir c'est que depuis
l'article de blog a été amendé
et donc on connaît le nom du projet qui s'appelle JetPortch
et il y a déjà un site internet qui s'appelle JetPortch.com
où on peut voir pas mal de choses
puisque c'est une documentation d'un outil qui n'existe pas
encore mais qui ressemble très très très fortement
à un Cible
le fait que ce soit compatible
à annoncer à 90-95%
d'ailleurs quand on lit rapidement
la doc on comprend que c'est clairement très compatible
enfin la manière d'écrire le code est compatible
ce qu'il y a derrière peut-être moins mais en tout cas
ça veut dire que Jet va pouvoir intégrer des playbooks
potentiellement écrits pour un Cible
et exécuter son moteur derrière
typiquement ça me fait penser à un truc
une approche qu'on a dans les langages
qui sont interprétés
qui est, tu as une virtual machine
qui va interpréter ton code et derrière
le code de la JVM
alors JVM c'est parce que pour sa Java
mais le code de ta, pas du truc qui va interpréter ton code
peut être complètement différent
notamment dans l'écosystème Node il y en a plusieurs
il y a Node, Dino, Fire, y en a tout à
et je me demande si c'est pas
une approche comme ça
qui Michael veut apporter
avec un moteur d'exécution plus rapide
peut-être plus simple
alors on perd au passage le fameux
FQCM
le full qualifié de
FQDN, le full qualifié de domain name
qui est la nouvelle manière d'écrire
les noms des modules avec community.machin
c'est un truc pour un package
ce qui a été introduit dans EnCible
il y a quelques années pour séparer
EnCible de tout ce qui est
package et module communautaire
là on revient à la perte d'avant
où c'est juste le module shell
le module APT, le module machin
moi je suis très curieux d'essayer
par contre il y a un truc je n'ai pas compris
en quoi c'est problématique d'avoir un
Recoyarmont-Poyamel ou un EnCible Recoyarmont-Poyamel
parce que pour moi c'est essentiel
et c'est l'un des avantages de l'outil
je ne parlais pas de ça
je parlais du Recoyarmont.txt
en Python qui peut être un peu
fastidieux à maintenir
et tout, bien sûr faites des EnCibles Recoyarmont
tout ça c'est important
faites même un Recoyarmont-Poyamel.txt
pour être environnement Python pour jouer EnCible
mais c'est vrai que si tu as un binaire plutôt que ça
recréer c'est quand même plus
plus confortable, t'es rafforme t'es content
de juste avoir le téléchargé
mais dans t'es rafforme tu as des provider et en EnCible
tu as parfois des dépendances avec d'autres modules PIP
c'est vrai que nous on utilise PIP EnV
je sais qu'il y en a plein qui utilisent Poetry
pour faire des environnements virtuels
fait des environnements virtuels si tu utilises EnCible
que tu utilises Poetry, EnV ou PIP EnV
c'est important
mais en effet pour avoir un binaire go tu pourras utiliser d'autres outils comme
STF peut-être à terme
mais j'ai déjà beaucoup de trop parler je vais passer la parole à René
non j'ai pas forcément
grand chose à ajouter, moi je suis juste un peu
surpris
qu'il crée un nouveau projet complètement alors que
ça semble comme vous le dites plus tôt peut-être
plus une refonte du moteur qui serait nécessaire
et pourquoi pas forcément refonte le moteur d'EnCible
après j'imagine qu'il pense qu'il va avoir plus de liberté
en faisant un projet annex
j'imagine que c'est la raison
voilà je suis dit
il y a juste un truc où je n'étais pas totalement d'accord
c'est quand il a dit qu'il n'avait pas forcément besoin
de notion de programmation pour faire d'EnCible
je suis pas complètement d'accord
parce qu'il y a quand même
moi je trouve que dans EnCible on retrouve pas mal de notions
de langage de probation dans la manière structurelle
et le code etc et on s'aperçoit assez vite
qu'il y a plutôt des bonnes pratiques qui ressemblent
à ce qu'il se fait en code et que si tu ne le fais pas
tu as des modules d'assez moins qualité
donc voilà je suis pas convaincu par en tout cas
cet argument là
après ce que je pourrais juste dire pour la raison du choix de Rust
je pense que les articles sont peut-être un petit peu
réducteurs de ce qu'il a pu dire ce qui souvent se dit
c'est que Rust est très expressive c'est à dire qu'il a un système
de typage qui permet de définir les choses
je sais pas comment dire de manière très
complète je sais pas comment dire ça mais
voilà je pense que c'est un des atouts
du langage
et que c'est aussi en termes de rapidité d'exécution
c'est plutôt pas mal
et bah nous verrons ça
c'est un projet à suivre en tout cas
alors je vais profiter avant de passer
aux outils de te parler un peu de mon collectif de frilance
j'en parle pas assez
ce podcast il est produit par Lidra
c'est le Lidra qui paye pour enregistrer le podcast
les outils etc
c'est donc un des éléments
qu'on veut se faire connaître et je t'en parle aujourd'hui
non pas parce qu'on cherche du TAF mais parce que Lidra c'est un collectif
d'indépendants qui est ouvert
et tu peux rejoindre Lidra si tu en as envie
si tu es frilance tu peux si t'as envie de créer du commun
dans un collectif de DevOps si tu partages
les valeurs de logiciels libres si aussi
tu es intéressé par la souveraineté numérique
même si c'est pas essentiel
tu peux avoir envie de rejoindre un collectif et rejoindre un collectif
ça a plusieurs avantages
ça te permet de répondre à des projets plus importants
que ce à quoi tu pourras répondre tout seul
typiquement dans notre collectif
on est 3 frilances plus 2 alternants
et on répond à plusieurs projets
où on est parfois 2 parfois 3
pour rejoindre Lidra
ça nécessite de devenir salarié de notre CAE
et aussi les technos qu'on met en avant
et qu'on a tous en commun c'est plutôt en cible
les conteneurs, terraformes, guite lapsiailles
un peu moins Kubernetes mais quand même
c'est juste parce que je te dis
les technos qui viennent à moi
ce pourquoi on vient me chercher sur les réseaux sociaux
l'avantage d'être au collectif aussi c'est ça
c'est qu'on peut se passer des missions entre nous
et donc on renforce le collectif comme ça
donc si tu as envie de rejoindre un collectif
puisque mon t-shirt c'est bien indiqué Lidra
tu peux m'écrire sur les réseaux sociaux
et on en discutera et tu rencontreras les autres
et puis la phase d'intégration
elle prend son temps parce qu'on désire connaître
les gens pour créer justement un noyau dur de frilance
bon maintenant on va parler des outils
parce que c'est la section que tout le monde adore
l'automatisation, la tech et les outils
donc Roné tu vas nous parler d'un premier outil
oui c'est un petit outil qui a été créé en reste justement
et qui est une alternative ADF
donc Ormic est plutôt sympa
à l'affichage, il est assez clair
et assez joli, ce que j'ai trouvé intéressant
c'est qu'il fait aussi une sortie JSON
donc on peut changer ça aussi pour avoir une JSON
et donc récupérer tout aussi on a besoin de récupérer
quel est l'espace sur un file système Dispo etc
très facile à parser avec du JQ derrière
ou avec n'importe quel parser JSON
et voilà je trouvais ce outil sympa
et voilà c'est pour ça qu'il est mentionné
moi je n'utilise plus ADF depuis longtemps
sur mes machines depuis que j'ai découvert ADFC
mais en effet disque a l'air vraiment super bien
notamment dans un contexte où on en parlait tout à l'heure de Bache
ou tu veux faire des petits scripts avec
tu veux regarder des trucs sur ta machine
et bien avec une sortie JSON et JQ comme tu le dis
il y a même j'ai noté un truc intéressant
tu as une notion de filtre, tu peux sortir les files système
qui prennent plus par exemple de 20 Giga
enfin des trucs comme ça, j'imagine qu'il y a plein de filtres
possibles dedans
Erwin tu connaissais ce outil là justement ?
non je ne connaissais pas
pour moi c'est mandatorique
les outils comme ça
enfin que les outils aient une sortie en JSON
c'est vraiment, ça change
c'est tellement pratique
jusqu'à diser René pour récupérer des informations précises
sans avoir à faire des réglages de l'enfer
qui seront de toute façon fausse au bout d'un moment
et rien que pour ça je pense que c'est un outil intéressant
à tester
en effet
moi je vais parler d'un autre outil
pour le coup c'est pas un outil qui s'installe justement
et c'est ça l'intérêt, c'est distrocy
on a vu apparaître sur les réseaux sociaux il y a quelques temps
quelques semaines je dirais
potentiellement maximum 2 mois
distrocy qui est un site qui permet de tester
des distributions Linux dans notre navigateur
ça veut dire que ça va encore plus loin que la fameuse live distribution
ça permet de tester une distribution
sans l'installer sur notre machine
même sans bouter notre machine
si jamais on hésite entre plusieurs distributions
ce qui est le cas le plus classique à mon avis
si on veut tester des trucs on va sur distrocy
on choisit sa distribution
il a instancé une machine
parce que j'imagine qu'il y a des VM là derrière
et puis on peut le tester
moi j'en ai testé quelques-unes et c'est vraiment intéressant
j'imagine René que t'en avais entendu parler
oui j'en ai entendu parler j'ai même essayé
ouais c'est sympa
je crois qu'il y a par contre pas de BSD
donc peut-être ça va venir
mais c'est un chouette projet
je suis très déçu de pas voir
la distribution à Namontana Linux
disponible sur le site
et sinon je trouve que ça retire tout le charme
d'installer une distribution pour la première fois
et de pas arriver à faire ce qu'on veut avec
mais ça a l'air d'être un beau projet
pour moi c'est l'étape d'avant
c'est l'étape où tu choisis la distribution qui a l'air de te plaire
puis tu télécharges le live cd pour l'essayer sur ta machine
pour voir si ça marche bien
puis après tu l'installer tu galères
pour moi c'est ça
pour répondre à René mais est-ce que BSD
y a une distribution Linux ou est-ce que c'est un Unix BSD ?
c'est un Unix
voilà donc comme là distro 6
concentre sur Linux c'est peut-être le truc
oui peut-être
ah bah Erwan tu as un outil à nous présenter
oui c'est vraiment un tout petit outil
mais que je trouve assez pratique
qui s'appelle dive
qui vous permet en fait d'explorer
les couches
enfin les layers par moment
de vos images
de vos images d'occur
et en fait ce que je trouve assez intéressant c'est que
souvent
les cas d'usage typiques c'est
vous voulez voir quels sont
après chaque layer
quels sont les répertoires les plus gros
qui ont le plus grossi
et ça dive va vous le mettre en évidence
assez vrai donc vous allez comprendre par exemple
qu'après un run d'une action
vous avez oublié de cliner
je sais pas le cache de package qui a été téléchargé
ou quoi que ce soit
donc ça c'est quand même assez pratique
et puis de la même façon ça va vous indiquer
dans les nouveaux fichiers
qu'ont été rajoutés
dans chaque layer
et donc encore une fois ça c'est assez pratique
quand vous êtes sur des images un peu complexes
ou quand vous êtes sur des images qui dépendent d'autres images etc
et que vous n'avez pas forcément
tout l'historique de ce qui s'est passé
c'est un bon moyen pour explorer un petit peu
tout ce qui s'y passe
voir la taille des images et tout
un lancer c'est hyper simple
c'est une image docker un lancer
où il faut donner accès
dans laquelle il faut monter un endroit spécifique
le soket du docker engine et c'est parti
et vous avez rien à faire
ça va avoir accès à toutes les images
que vous avez auquel le docker engine a accès
donc voilà je sais pas si vous connaissez
mais moi je trouve ça très pratique
et je m'en suis reservi il n'y a pas très longtemps
et du coup c'est comme ça que j'ai pensé à le mettre ici
et ben tu as bien fait
moi je le connaissais parce que j'étais déjà tombé dessus
mais je ne l'ai jamais testé
c'est de ma faute que tu as dit couche
parce que avec mon côté un peu francophone
j'ai traduit ton layer en couche
puisque j'ai bien parlé de couche d'oignons
quand je parle des conteneurs
et donc c'est évidemment un outil essentiel
quand on veut optimiser les images de conteneurs
parce qu'une image elle peut vite, très vite, trop vite grossir
moi j'ai déjà vu des images d'applications
qui faisaient plus vieux en giga
et je peux dire que si tu génères une image
toutes les heures par exemple
à chaque fois que t'as tes développeurs qui pouchent
et ben ton rejet de conteneurs
il va vite, très vite grossir et prendre du poids
donc pour optimiser tout ça, d'aveu me semble essentiel
Erone tu connaissais d'aveu
non mais ça a l'air cool
histoire d'aller trouver où est-ce qu'on a mis nos API key dans l'anime h?
par exemple ça peut être intéressant
Erone c'est toi qui finis le balle des outils
avec un petit outil apparemment
ouais c'est même plus un site web en fait
alors c'est un petit peu hors sujet peut-être par rapport à ce qu'on fait d'habitude
mais comme c'est vraiment un super truc
j'ai voulu absolument parler
il y a assez peu de temps je me suis mis à bricoler un tout petit peu d'embarquée
une petite carte basée sur un chip
qui est fait par Expressif
qui est une société chinoise
et donc jusqu'à maintenant Expressif ils avaient des ESP
alors des processeurs qui s'appellent ESP32
ou ESP8266
et en fait ça c'était un peu des types
on va dire propriétaires en termes d'espressif
et ils ont une nouvelle gamme basée sur du risque 5
et voilà et puis ils ont fait pas mal de boulot aussi pour qu'on puisse les programmer en Rust
alors bien sûr on peut les programmer en C ou en autre chose
mais voilà moi ce qui m'intéressait c'était d'avoir un petit peu programmé
un de ces types basé sur risque 5 et en Rust
et donc j'ai acheté une petite carte, ça ne coûte pas très cher
et j'ai expérimenté, j'ai fait mes trucs
et en fait Wokui c'est un site que je connaissais depuis pas mal de temps
et en fait pour les gens qui veulent s'initier par exemple
la programmation embarquée, des choses comme ça
voire la IoT quelque part
c'est en fait une plateforme en ligne qui permet quasiment de tout faire
sans acheter le moindre hardware
c'est à dire que ce que j'ai fait entre guillemets
avec un bout de matériel physique
voilà pour tester on peut le faire complètement de manière virtuelle à travers le site
et donc ça permet de valider des montages
avec des composants un petit peu classiques qu'on peut retrouver
donc on fait le câblage entre guillemets
on réalise le câblage virtuellement
sur la plateforme en connectant les différents éléments
et ensuite on injecte le code
donc jusqu'à maintenant ça pouvait se faire
qu'avec le C, c'est plus ou plus, éventuellement peut-être un peu de Python aussi
micro Python
mais ils ont rajouté le support de Rust
et ils ont rajouté entre guillemets l'émulation de ces nouveaux chips basé sur RISQ 5
et donc moi je pense vraiment que c'est un supersite
pour découvrir, pas à la peine d'acheter du matériel
bien sûr ça a des limitations
c'est pas aussi rapide que du vrai hardware
il y a certainement des petits corners caisses
mais je pense que pour s'initier, pour voir comment ça fonctionne
c'est vraiment un supersite
donc voilà je voulais absolument en parler
et voilà je sais pas si vous connaissiez
ou si ça fait partie d'un petit peu des choses qui vous intéressent
mais voilà si c'est le cas je pense que je vous encourage à les voir
moi je viens de regarder
je connaissais absolument pas
et je suis impressionné
c'est hyper bien foutu leur truc
et je regarde un petit peu le code de certaines démo
il faut s'accrocher à son slip quand même
il y a le truc qui fait des espèces de tunnels de matrice en diodes là
putain pour afficher ce truc là
regarder le code ça va vous faire plaisir
on parlait dans le cible juste avant
c'est autre chose
c'est marrant parce que ce code là
je sais pas ce que c'est
parce que c'est du point INO ou LNO
ça ressemble à du C pour moi
bref je connaissais pas
ça va me rappeler mes débuts
parce que moi je viens de l'embarquer mais du temps réel
on faisait de l'assembleur et du C sur des machines et des drivers
mais j'avoue que c'est pas ce qui me passionne en ce moment
en ce moment c'est plus le barc éthique qu'autre chose
parce que avec mon poste de créateur de contenu
c'est plutôt ça qui me drive en ce moment que l'embarquer
mais merci en tout cas je trouve que pour la pédagogie
moi à chaque fois que je vois ces trucs là
je trouve que c'est vraiment super
parce que tu as un navigateur
donc ça veut dire que potentiellement
sur une tablette ou même un smartphone
qu'on a presque tous aujourd'hui
tu peux commencer à apprendre un petit peu à coder
parce qu'il y a ça aussi derrière
il y a à simuler des projets de code
et c'est souvent des algorithmes
alors tu parlais Erwin de celui là
qui était un peu complexe
mais finalement il est pas si long que ça
le code il fait 200 lignes
200 lignes quand tu as commencé à apprendre à coder
c'est quelque chose que tu vas vite atteindre
donc pour moi ça fait partie des outils
que j'aurais bien aimé avoir quand j'étais plus jeune
une des forces aussi c'est que les gens partagent leur circuit
et leur montage et leur code
et du coup ça permet de
parfois de choper des morceaux
c'est à dire qu'à une nuit il a connecté
tel composant j'ai le même cas
donc tu peux aller voir et récupérer le blog qui t'intéresse
et franchement c'est pas moi
moi je trouve ça vraiment en ce site
il y a un gros boulot je pense au niveau de l'émulation
pour élimuler
je pense que c'est même écrit en JavaScript
je sais qu'il y a un émulateur pour les plateformes AVR
donc tout ce qui est Arduino
qui a été fait en JavaScript
je sais pas après pour les autres
mais ouais c'est vraiment sympa
alors en plus du cas d'usage d'apprentissage
je me demande dans quelle mesure ça peut être un outil
pour faire de la recherche et de développement
parce que du coup
finalement t'as pas besoin d'avoir les trucs sous la main
et tu peux faire des tests
avec des composants que t'as pas
pour voir si ce que t'as en tête ça peut être concluant
et puis après acheter les trucs pour faire physiquement de la R&D
alors je me demande dans quelle mesure ça peut être un outil

ouais je pense que...
alors tu peux faire ce genre de choses mais ça reste limité
parce qu'il y a quand même pas une liste de composants
pour l'instant qui est immense
et tu ne trouveras pas tout
mais ça permet déjà de faire...
je pense par exemple si tu veux expliquer un petit peu
pas peut-être au lycée, dans des lycées
ou des choses comme ça
ou un petit peu d'informatique embarquée
je pense que c'est génial parce que du coup
t'as pas besoin d'avoir du matériel
ce qui coûte quand même relativement cher
donc c'est plutôt pas mal
et alors petite touche notre nostalgie
je viens de tomber sur le jeu Simon pour Arduino
donc pour ceux qui ont mon âge
ça se vend encore à ma belle fille, elle a un Simon
pour ceux qui ne connaissent pas Simon
c'est un arc de cercle avec 4 couleurs
et ça fait des séquences et il faut les reproduire
c'est très bien comme jeu
bref je crois qu'on a fait le tour
de ça
donc moi je peux te rappeler
à toi, chers auditeurs, si tu apprécies cet épisode
tu peux nous rejoindre dans la communauté des compagnons du DevOps
tu peux discuter avec nous, avec les autres podcasteurs aussi
qui sont pas là aujourd'hui mais en tout cas c'est le lieu
où tu peux échanger, faire découvrir
des choses, y compris des outils
parce qu'il y a aussi des gens qui partagent des outils
ou qui ont des problématiques et qui les posent
donc viens t'inscrire
on est déjà plus de 1500, je sais plus combien on est au dernier comptage
mais on est nombreux
si d'ailleurs tu suis l'épisode en podcast
et si tu ne le sais pas je fais des lives réguliers
où je parle de la communauté, de son évolution
et de toute l'arrière sale
de comment ça se passe
je vais laisser comme d'habitude le mot de la fin
à mes co-animateurs et pour ne pas
surprendre rien je vais commencer par R1
et ben le mot de la fin sera
je le récupère
Syllo
parce que c'est un truc le DevOps combat
et que c'est une très bonne trilogie, lisez là
oui c'est pour ceux qui ne voient pas
la vidéo, c'est un bouquin
que vient de nous montrer R1
et René tu as le mot de la fin de la fin ?
le mot de la fin de la fin, très classique
j'espère que cet épisode vous intéressera
et que je vous retenerai en rendez-vous
pour un prochain épisode
et voilà bientôt