Quels sont les news du cloud et du DevOps en ce mois d'octobre 2022 ?
Alors, la responsabilité des DevOps lors des cyberattacks,
l'état de l'art du DevOps en 2022, Linux et Rust, toujours,
c'est ce qu'on va aborder 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 mensuelle autour du cloud et du DevOps.
Et comme d'habitude, reste bien jusqu'à la fin,
on a des petits outils pour toi, on t'a découvert pas mal de choses.
Et avec moi pour en parler ce soir et pour parler d'actu,
j'ai René, bonsoir René.
C'est Christophe et bonjour à tous et à toutes.
Et j'ai aussi Erwan, bonsoir Erwan.
Bonsoir.
On va commencer par la traditionnelle rubrique du courrier des auditrices et auditeurs.
Et ce soir on a deux messages.
Alors j'aimerais vous lire tout d'abord le message de Sebast,
qui nous a laissé sur Actu DevOps de septembre sur Youtube en l'occurrence.
Alors il fait référence à l'épisode,
dans l'épisode, on m'a parlé d'astuces d'autres trucs sur Go et autres.
Et il nous dit merci pour l'astuce sur Go.
Lui aussi, il a des problèmes avec Python car ça commence à le limiter.
Et donc il va rajouter l'outil dont on parle,
qui est je crois apprendre le Go à l'époque,
et il va le rajouter dans ça tout douliste.
Alors du coup, j'ai déjà répondu à Sebast sur Youtube,
mais comme ça, il y aura une réponse plus générale à ce genre de messages-là.
Alors moi je trouve ça super cool,
parce que justement Actu DevOps s'est fait pour faire découvrir des choses aux gens.
C'est pour ça qu'en fait on fait ces postcasts de veille,
et qu'on se démène tous les, je sais plus combien on est tous les 8.
Je sais pas ce que vous en pensez, René et Arwan, sur ces petits messages-là.
Ouais, je trouve ça super positif en fait.
Parfois on reçoit aussi des petits messages sur Twitter,
en disant que l'épisode il a intéressé un petit peu du monde.
Ouais, quelque part pour la motivation je trouve c'est vraiment positif,
et ça donne envie de continuer.
Oui, moi je partage aussi cette enthousiasme, c'est cool.
En plus c'est un retour positif, c'est bien.
Et puis moi même je dis merci Radio DevOps,
parce que j'ai mis le training dans les choses que je dois faire et suivre.
Et du coup je le découvre grâce au podcast.
Oui, parce que tu étais pas là lors du leure-registrement je crois pour cet épisode-là.
Si, si j'étais là, et du coup je l'ai noté pendant l'enregistrement.
Bon bah c'est cool.
On a un autre message qui lui nous vient de la plateforme de questions,
je parlera de la plateforme de questions après,
qui nous a été laissé par Alexi qui a utilisé le pseudo Alexi Toujours Top.
Alors j'imagine que c'est pour nous dire que le podcast est toujours top.
Et il nous dit, pour le podcast je trouve que le générique de début et de fin
a un volume un peu trop fort par rapport au reste, en voiture c'est un peu gênant.
Alors, désolé Alexi, on va tenter de faire des efforts là-dessus,
justement avec Luna qui me rejoint sur le podcast.
Et sur tout un tas d'autres trucs.
Luna qui est ma nouvelle monteuse entre autres.
Que tu croiseras peut-être dans le prochain live des compagnons,
pour justement qu'elle vienne nous parler un petit peu de son métier,
de son alternance puisque je l'accueille en alternance sur la partie Community Management et autres.
Donc on va faire des efforts sur le volume sonore.
Justement on va éviter les pubs qui nous cassent les oreilles.
Alors bon, je sais pas ce que vous pensez de ça,
je sais pas si vous même ça vous déranger le fait que parfois
le générique est un peu plus fort que le reste.
C'est la technique des publicités là pour que ça reste bien en tête.
Exactement.
Bon, alors moi le message que j'ai à dire à toi qui nous écoute,
n'hésite pas surtout à nous dire ce que tu aimerais voir comme sujet à traiter dans les podcasts.
Justement, il y a une plateforme que tu trouves dans toutes les descriptions depuis le début.
Cette plateforme c'est question.compagnon-devops.fr.
Tu remplis ta question, ça nous envoie directement le message.
Moi je le reçois et ça me fait une liste de sujets à traiter.
Il y a des gens qui utilisent cette plateforme là pour nous envoyer des messages.
Mais c'est plus pour les suggestions.
Mais pourquoi pas?
Et surtout comme l'a dit Renée,
motive nous aussi en nous spammant de messages sur Apple Podcast.
Podcast addict, YouTube ou je ne sais quoi sur le forum aussi tu peux.
D'ailleurs des fois il faudrait que je prenne des messages du forum.
Mais c'est bien parce que ça nous aide à monter dans les recommandations.
Tu peux nous mettre cinq étoiles quand tu peux mettre cinq étoiles
ou tu peux nous mettre une étoile si jamais tu ne nous aimes pas.
Mais si tu ne nous aimes pas, t'es pas en train d'écouter cet épisode.
Enfin, j'espère.
Parce que sinon t'es vraiment maison.
Après ce qui peut être aussi intéressant,
je pense que si les auditeurs veulent donner aussi un peu des directions pour nous,
ça peut je pense aussi des fois nous aider à creuser plus certaines choses que d'autres.
Voilà je pense qu'il ne faut pas hésiter.
Exactement.
Alors Erwan, tu vas nous parler de responsabilité DevOps dans des événements tragiques.
Oui et on va faire référence du coup.
La cyberattaque qui a fait un peu parler d'elle récemment sur Kassubi, l'hôpital de Corbeille et Somme.
Donc on va vous parler de tout ça.
Bien sûr on aurait pu parler de plein d'autres choses,
mais si ce n'est pas assez plein de choses dans le monde de l'IT en général,
comme la super étude.
Alors je sais pas si vous l'avez vu, qui dit que 90% des équipes DevOps
aimeraient rajouter de l'IA pour être plus efficace au travail.
Je sais pas trop, qui sont ces 90% mais bon très bien.
Ou on aurait pu parler de la publicité dans la cli de Ubuntu quand vous faites un APT get update
qui est en train de déchirer Twitter au moment où nous enregistrons.
Mais donc on va parler de cette cyberattaque de l'hôpital de Corbeille et Somme.
Alors on va rappeler rapidement les faits, c'était dans la nuit du 20 au 21 août,
l'hôpital a suivi donc une attaque de type Rampsonware.
Donc pour ceux qui ne savent pas,
le Rampsonware c'est une attaque qui consiste à bloquer l'accès à des ressources
et à demander de l'argent pour de bloquer cet accès.
Typiquement les attaquants chiffrent par exemple votre base de données
et vous disent donne-moi des sous et je te donnerai la clé pour déchiffrer la base de données.
Ici on est dans le cas du logiciel Logbit qui a été utilisé contre l'hôpital de Corbeille et Somme
et qui est le nom aussi du collectif, je ne sais pas si on peut appeler ça vraiment un collectif,
mais du groupe de hackers qui est derrière l'attaque.
C'est un groupe qui a assez actif dernièrement, qui est connu depuis à peu près 2019
et qui avait fait un peu parler de lui récemment pour l'attaque du site de la Postmobile
qui avait été totalement donne pendant un donetime assez important suite à leur attaque.
Et donc du coup, qu'est-ce qui s'est passé ?
Comme convenu ils ont demandé des sous pour des blocs à l'accès
et ils ont mis un ultimatum pour dire si le 23 septembre vous ne faites rien,
on diffusera la data de vos clients, etc.
Bien entendu le 23 septembre, pardon, l'hôpital n'a pas payé,
de toute façon ils n'avaient pas le fameux million de dollars qui était demandé.
Et donc du coup le groupe de hackers a diffusé une archive de plus de 10 gigas
avec tout un tas de screenshots des data.
Et les data qui ont été diffusés, ça concerne aussi bien les passions,
que les partenaires ou que le personnel.
Donc c'est quand même assez varié.
Et bien entendu elles ont été authentifiées comme étant vraies.
Donc du coup c'est clairement pas du bluff.
Alors maintenant qu'on a dit tout ça, qu'est-ce qui va nous intéresser ?
Eh ben il faut savoir que récemment, j'ai plus la date, je pense que j'avais noté,
mais il y a une ou deux semaines,
il y a une association qui se nomme l'Union Nationale des Associations Citoyennes de Santé
qui a entamé des démarches pour engager la responsabilité de l'hôpital vis-à-vis de cet attaque.
Il faut savoir que légalement, se faire attaquer,
on peut pas se faire, légalement on peut pas être puni pour cet fait attaquer.
Déjà on se fait attaquer si en plus on dit que c'est de notre faute.
Par contre l'absence de réaction, d'accompagnement et de transparence,
ça c'est légalement répréhensible.
Et en l'occurrence dans le cas de l'hôpital,
même si on n'a pas les détails de l'action,
quoi que ce soit, ça a été quand même assez transparent.
Il y a eu pas mal de communication,
il y a des gens qui ont tout de suite des experts et tout qui ont été mobilisés,
donc on peut dire que en tout cas en termes de moyens, ils ont essayé de faire ce qu'il fallait.
Mais bon, donc il y a les démarches pour engager la responsabilité de l'hôpital sont lancées.
Quel que soit le résultat de cette procédure,
parce que ça en cours, donc du coup on ne sait pas trop ce qu'il en est.
L'affaire rappelle que les victimes d'un piratage peuvent malgré tout avoir une responsabilité juridique vis-à-vis des utilisateurs.
Donc ce n'est pas parce qu'on se fait attaquer,
que du coup on est,
enfin surtout quand on a des responsabilités de stockage de data comme un hôpital,
en fait on a une obligation de moyens en gros.
Et concrètement si cette obligation de moyens n'est pas vérifiée,
auditable de ce que vous voulez, on peut avoir des problèmes.
Et là où je veux en venir, et c'est là où la question ouverte va se poser,
c'est jusqu'où on remonte dans la chaîne de responsabilité là-dessus,
et qui va être responsable ?
Est-ce que c'est les grands chefs, est-ce que c'est les lits de l'équipe de l'infra,
est-ce que c'est justement le six admins qui est au bout de chaîne, etc.
La chaîne de responsabilité, elle n'est quand même pas si évidente que ça,
et puis il n'y a pas de, en tout cas je n'ai pas trouvé,
peut-être qu'il y en a mais je n'ai pas trouvé,
de juristes prédenses très évidentes sur le sujet.
Juste en cherchant un petit peu, j'ai vu qu'aux États-Unis,
alors bon, ce n'est pas chez nous mais bon, c'est quand même toujours bon à apprendre.
Aux États-Unis, il y avait l'ancien chef de la sécurité informatique chez Uber,
qui s'appelle Joseph Sullivan.
Il avait été poursuivi et condamné en 2016 pour avoir dissimulé une attaque informatique
qui a eu pour conséquence la divulgation de données de millions de personnes
d'utilisateurs de la plateforme.
Donc du coup, voilà, j'ouvre la question, est-ce que moi,
en tant que SRE, DevOps, whatever, parce que j'ai oublié de faire un APT Get Update
ou parce que je n'ai pas les outils qui vont bien pour faire l'update de mes services,
de mes serveurs, de mon hardware, de ce que vous voulez,
est-ce que je suis directement visé par ce genre de procédures
et est-ce que ma responsabilité, est-ce qu'en gros je peux finir en prison
parce que je n'ai pas mis à jour la dernière version du Docker Engine
ou des choses comme ça.
Je ne sais pas ce que vous en pensez, je ne sais pas ce que ça vous évoque
mais comme ce n'est pas non plus, il y a non d'un que ça,
que des associations suite à des attaques, en gros, demandent des comptes
sur les moyens qui ont été mis en place pour justement contrer les attaques.
Ça me semblait intéressant d'évoquer ça, sachant que l'hôpital, lui-même,
je pense qu'il risque pas grand chose parce qu'il va se retourner vers son prestataire
mais après, encore une fois, voilà, le prestataire, qu'est-ce qu'il risque
et surtout chez les prestataires dans cette chaîne de travail
qui est responsable, est-ce que c'est le chef, le lead, le mec en bout de chaîne, etc.
Je rajouterai pour finir que des attaques, il y en a tous les jours, tout le temps,
dès que vous avez une machine qui est sur Internet, qui est publiquée publiquement,
elle suit constamment attaquer, pinger, etc.
Il y a toujours des gens pour essayer de trouver quelque chose.
Donc se faire attaquer, c'est pas exceptionnel.
Maintenant, après, se faire percer, c'est malheureusement de moins en moins exceptionnel
mais on espère quand même que ça s'allait beaucoup moins.
Mais avec des attaques de cette envergure, ce genre de question,
ce genre de démarche judiciaire pourrait se multiplier
et donc je trouvais que c'était intéressant d'évoquer le sujet.
René, est-ce que tu as un avis sur la question
et est-ce que ça te fait peur maintenant de faire du run sur des machines ?
Raconte-nous.
C'est pour ça que je suis plus droit d'un run en fait.
Après, c'est compliqué parce que...
pas juriste en fait.
Donc je pense qu'il faut être extra...
enfin, assez prudent sur ce qu'on peut dire.
Je pense que peut-être le dépôt de plainte ici
est pour essayer de voir s'il n'y a pas eu une négligence
et à partir du moment, il n'y a pas spécialement de négligence
et que l'hôpital a suivi, je pense,
les recommandations en termes, les normes en termes de sécurité.
Voilà, je pense qu'il n'y aura peut-être pas de suite.
Après, j'imagine que c'est un peu comme...
enfin, l'hôpital est vu un peu comme une personne morale.
Je pense que s'il y a une procédure,
ce sera contre la personne morale et l'entreprise
et pas contre des individus, enfin, j'espère.
Après, je faisais quand même un sujet assez touchy
et je pense qu'il faut des gens qui connaissent le droit
pour vraiment savoir démêler un peu la pelote.
Est-ce que toi, Christophe, tu pensais plus sur le sujet,
je pense que ayant une entreprise,
tu es certainement plus au fait de n'aussi où.
Oui, j'ai plein de choses à dire.
Il y a plusieurs choses.
La première, je vais aborder la procédure judiciaire.
Quand tu lances une procédure judiciaire,
tu peux avoir plusieurs objectifs.
Le premier, ça peut être de demander réparation.
Ça peut être un premier objectif,
donc demander réparation financière,
faire évoluer les lois aussi, mais c'est moins le cas.
Ou, plus que je pense, au vu de ce qu'a dit Erwan,
obtenir des réponses.
Parce que si j'ai bien suivi Erwan,
il n'y a pas eu une transparence
et peut-être qu'elle n'est toujours pas là la transparence.
Et ouvrir un procès, c'est une manière pour obtenir des réponses
parce que les partis doivent apporter des réponses.
Donc, clairement, la transparence, via une procédure.
C'est fait régulièrement,
le fait de lancer des procédures judiciaires
pour obtenir des réponses
et pour avoir des réponses à certaines questions.
La deuxième chose que je voudrais apporter,
c'est la responsabilité pénale.
Et pas la responsabilité professionnelle,
la responsabilité pénale.
Si jamais quelqu'un, dans un cas comme ça,
il y a forcément quelqu'un qui va ou pas payer.
Si il y a une mise en cause d'une personne,
je ne sais pas comment ça se passe
dans les collectivités ou dans l'état.
En tout cas, quand t'es une entreprise,
il y a une personne qui est responsable,
c'est toujours la même, c'est le chef d'entreprise.
C'est-à-dire que ça ne redescend pas aux employés.
C'est l'employeur qui est responsable
et c'est lui qui prend tous les risques de pénaux.
Ça veut dire que toi, Erwan,
si tu fais une bêtise, que ton entreprise, elle...
C'est un exemple, évidemment, tu n'as pas fait de bêtises,
puisque c'est toi qui pose la question
si ton entreprise, elle est mise en cause
et qu'elle perd
et qu'il y a peut-être de la prison à faire.
Ce n'est pas toi qui va la faire,
c'est le directeur de l'entreprise.
Parce que c'est lui qui porte la responsabilité pénale
et pour la simple et bonne raison que c'est lui
qui porte le lien de subordination.
Comme toi, t'es subordonné à quelqu'un,
tu ne peux pas avoir la responsabilité pénalement,
je veux dire, dans une entreprise.
Le dernier truc, c'est...
Mais là, on sort du cadre du procès,
c'est la responsabilité professionnelle.
En effet, nous en tant que professionnel de la tech,
on a une responsabilité à bien faire les choses,
parce que ce n'est pas parce que tu ne vas pas faire de prison
que tu ne seras peut-être pas viré de ton entreprise,
parce que tu auras fait une boulette.
Ce n'est pas souhaitable, mais voilà.
Donc là, c'est à nous aussi de travailler ça,
de travailler nos compétences avec nos collègues
pour justement bien faire les choses.
Et le dernier truc que ça m'évoque, c'est...
Je suis désolé, je suis pas un nom monologue.
Le dernier truc que ça m'évoque, c'est le qui communique.
Qui prend l'initiative de communiquer.
Et ça, je pense qu'on l'a abordé dans l'épisode de podcast
où on a parlé des astreintes, il me semble,
et de la prod.
Je ne sais pas si on a parlé de ça, de la chaîne de communiquer.
C'est à dire qu'à un moment donné, nous, on est au courant
parce qu'on a des alertes, on remonte ça aux cellules de crise,
les cellules de crise remontent ça aux communicants,
les communicants font des blog posts, etc.
Ça va plus vite dans une start-up que dans une grande entreprise
méditationale.
Je ne sais pas si j'ai pu répondre à la question que tu te posais
ou si ça te paraît logique, ce que j'ai dit.
Ah si, si. Moi, j'avoue que je savais pas trop tout ça.
Donc, déjà, merci.
Et surtout, j'imaginais trop me retrouver en prison
parce que j'avais pas fait le upgrade qui allait bien
et partager ma cellule avec un mec qui a tué 3 personnes.
Ça aurait été chouette.
Après, par contre, si l'employé a fait vraiment du...
Je pense que c'est quand même des situations où tu peux ramasser,
mais si vraiment tu as fait du sabotage
ou tu as vraiment nu à l'entreprise, j'imagine.
Mais là, c'est l'entreprise qui se retourne vers toi.
C'est encore un autre sujet.
Et après, je ne suis pas non plus super connaisseur,
mais je crois qu'il y a des différences entre le droit criminal
et le droit criminel.
Donc, je pense que tu risqueras pas de te retrouver dans une cellule
où il y a quelqu'un qui a tué des gens,
mais peut-être que tu te retrouveras dans une cellule
où il y a des gens qui ont volé ou je ne sais quoi.
Si ça peut te rassurer, je ne sais pas.
Ah, je dormirais mieux ce soir.
C'est ouf.
Tu dormiras mieux ce soir.
Est-ce qu'on a d'autres choses à dire sur le sujet
ou est-ce qu'on embraye ?
On avance.
Allez, on va embrayer.
Alors, c'est moi qui embraye.
J'embraye et je vais vous parler du rapport
Accelerate State of Devots 2022.
Donc, ce rapport, il vient de sortir
et on apprend justement en 2021
que plus de 22 milliards d'enregistrements
ont été exposés en raison de piratages d'hiver.
On en a déjà largement parlé
dans ActuDeVots des épisodes précédents
et AirOne vient justement de nous en parler.
La sécurité
continue à être une priorité pour les organisations.
On vient juste de le voir.
Donc, l'équipe de recherche
et d'évaluation d'Evots,
le fameux Dora,
a décidé de se concentrer cette année
sur la sécurité de la chaîne d'approvisionnement logicielle.
Ici, vous savez, le fameux Pipeline CICD.
Alors, pour ceux du fond qui dorment près du radiateur,
au cours des 8 dernières années,
près de 33 000 professionnels
du monde entier ont participé à l'enquête
Accelerate State of Devots.
C'est la recherche la plus importante
et la plus ancienne de ce type.
On y apprend beaucoup de choses
sur l'état de l'art concernant le déploiement
mais aussi sur les performances opérationnelles
et organisationnelles.
Pour analyser la relation entre la sécurité
et le DevOps,
les chercheurs ont utilisé le fameux framework
Supply Chain Level of Security Artifact,
le SLSA,
ainsi que le Secure Software Development Framework,
le SSDF,
du NIST, N-I-S-T.
Oui, alors je dis fameux, mais j'ai appris l'existence en lisant la news.
Le premier constat étonnant,
et en effet c'est vraiment étonnant de le lire,
c'est une adoption assez large des pratiques de sécurité
de la majorité des personnes interrogées
déclarent, justement,
une adoption au moins partielle
de chaque pratique questionnée.
C'est-à-dire que dans toutes les questions
où on posait des questions sur les pratiques,
il y a une grande majorité des personnes qui disaient
« j'ai fait ça, j'ai fait ça, j'ai fait ça ».
Au moins partiellement.
Parmi toutes les pratiques promues par le SLSA
et le NIST-SSDF,
je ne vais pas y arriver,
l'utilisation de l'analyse statique de code dans un pipeline CI-CD
est la pratique la plus courante
et elle concerne 63% des personnes qui ont répondu.
D'autre part,
la préservation de l'historique du code et l'utilisation
de scripts de build sont également très bien étabillées
tandis que la signature des métadonnées
et la revue par deux personnes ont vraiment progressé.
Alors il y a un graphique, vous pouvez aller le voir
sur le site que je vous mets en description, qui met en place
tout un tas de pratiques et leur degré
de progression par rapport aux années précédentes.
Autre point surprenant, c'est que le principal facteur
prédictif des pratiques de sécurité logicielle d'une organisation
était d'ordre culturel et non technique.
Par exemple, on apprend que, comme c'est étonnant,
les cultures
ont fortes confiance et faibles blâmes
axées sur les performances plutôt que
que sur les organisations
où la confiance est partie en congé
et où les rapports humains sont basés sur le pouvoir
et les règles, ça marche mieux.
C'est pas comme si on répétait à chaque épisode.
Le résultat démontre que les équipes
se concentrent sur les pratiques de sécurité
ont aussi réduit l'épuisement des développeurs
je pense que ces développeurs sont en large
font partie des développeurs dans ce genre de rapport.
Les données indiquent aussi que la culture organisationnelle
les processus de développement moderne
tels que l'intégration continue
sont les principaux moteurs de la sécurité logicielle
et constituent le meilleur point de départ pour les organisations
qui cherchent à améliorer la sécurité de leur code.
Bingo, le dev secops, c'est juste du DevOps.
Donc, le rapport d'Aura valide mon point de vue
de plusieurs épisodes
comment dire, en avant.
Au moment où on enregistre ce podcast, il est sorti ce matin.
Donc, on apprend tout un tas d'autres trucs.
Je vous laisse aller lire le rapport plus en détail
parce que c'est super intéressant.
Et moi, justement, je voulais savoir ce que vous en pensiez.
Parce que, autant que créateur de contenu DevOps
c'est en effet une base de travail pour mes contenus
et aussi mes formations, mais est-ce que vous lisez
le rapport d'Aura à toutes les années ou pas ?
Je le confesse, non.
Je découvre un peu ce rapport.
Je ne suis pas ça de très près.
Moi non plus, j'en avais entendu parler
puisque tout ce qui tourne autour des méthodes
accélérées, c'est des choses qu'on m'avait pas mal poussées
dans mes précédentes expériences.
Mais par contre, je ne suis pas hyper assidu
sur le contenu du rapport que tu as de partager.
C'est pour ça que je vais en parler.
Parce que, je ne sais pas si vous avez l'impression
que c'est intéressant.
J'en parle régulièrement dans mes formations et dans mes cours
parce que dans ce rapport, on a des chiffres qui prouvent
mais vraiment, c'est chiffré.
C'est une étude scientifique, c'est chiffré qui prouve
que le DevOps est la mise en place des pratiques, des méthodes
et des outils, accélère les choses,
réduise le taux d'erreur, etc.
Ce n'est pas juste du blabla.
Ce rapport prouve bien que le DevOps
apporte quelque chose.
On parlera de la mort du DevOps dans un autre épisode.
J'ai bien envie d'en parler.
Apparemment, ça ne vous évoque pas plus de choses que ça.
Je vous propose qu'on passe à la suite.
Ce que j'ai envie de dire, c'est que
toi qui nous écoute dans ton podcast,
si tu lis ce genre de rapport ou que tu veux en venir en parler,
tu peux venir sur la communauté des compagnons du DevOps.
Tu peux t'inscrire, c'est gratuit. Tu viens, on est plein, on est déjà plus de 1000.
On discute entre nous, on s'entraide aussi.
Il y a des questions parfois, on répond.
C'est vraiment le lieu pour pouvoir échanger,
peut-être trouver un mentor, ou toi-même, si tu as envie de
passer tes connaissances à quelqu'un, tu peux trouver
des apprentis virtuels, on va dire,
dans cette communauté, puisque j'essaie de promouvoir
le compagnon âge, d'où le nom des compagnons du DevOps.
Alors, René, tu vas nous parler
de ton langage préféré, je crois.
En tout cas, c'est comme ça que je le perçois.
Oui, il y avait longtemps, quand même.
On n'avait pas parlé un petit peu de Linux et de Rust, il y a longtemps que je n'avais pas vu.
Oui, en fait, il y a quelques épisodes
où on a annoncé que Linux Torval avait donné son accord
pour expérimenter un petit peu la possibilité
de faire des drivers en Rust.
Aujourd'hui, c'est pour plus d'outfait une expérimentation,
parce que à l'heure actuelle, le noyau en cours de développement
et le noyau 6.1, on est sur les release candidate,
donc les futurs verts, on va dire,
ce qui va devenir la version finale du 6.1.
Un patch a été mergé
qui officialise le support
et toute la mécanique
pour pouvoir créer des drivers en Rust,
des compilés, etc.
On aura quelques liens
dans les notes de l'épisode là-dessus.
Donc voilà, ça va devenir effectif
à partir de très prochainement.
Donc ça, c'est plutôt une bonne nouvelle.
Et en lien avec cette news-là,
ce qui est assez intéressant,
c'est qu'il y a plusieurs personnes
qui ont travaillé sur un driver
pour Apple Silicon.
Donc toute la gamme de nouveaux Macs
à partir de Chiba RM.
Voilà, donc une distribution
qui s'appelle Assaï Linux, qui vise
à pouvoir utiliser Linux sur ce type de matériel.
Et donc, dans un premier temps,
ils se sont attachés à faire en sorte que
Linux tourne sur la plus-arme.
Et il restait encore un gros, gros morceau,
c'est le GPU.
Pendant, je pense à peu près 6 mois,
Apple fournit très peu de spécifications techniques.
Donc, ça tout se fait par Rivers Engineering.
Ils ont analysé le GPU pour voir comment il marchait.
Et il y a quelqu'un qui a fini par
développer un driver en Rust pour Apple Silicon.
Et ce driver est arrivé
à un niveau de maturité où il est capable
de faire fonctionner un environnement Linux
avec 2.3D de danse,
c'est-à-dire qu'on peut avoir un jeu qui fonctionne
avec l'accélération graphique,
avec l'accélération graphique, etc.
Bref, un niveau d'avancement assez
très correct,
compte-mû du fait que ça vient
de sortir il y a très peu de temps.
Et l'autre aspect intéressant, c'est que cette personne,
gros niveau, elle a fait 2 choses,
elle a fait des streams sur le sujet.
Alors, personnellement,
malheureusement, je n'ai pas le temps pour retroler
suivre et je pense que je ne suis pas forcément
câblé pour les suivre, mais ou du moins, pas forcément
assez de temps pour arriver à rentrer dedans.
Mais voilà, pour ceux qui veulent vraiment
se plonger, je pense que c'est des streams qui peuvent être intéressants,
mais clairement très techniques.
Et surtout, elle a fait un retour
d'expérience sur en fait
ce que ça lui a apporté de créer
ce driver en Rust alors que c'est tout nouveau.
Et le retour d'expérience, bon,
voilà, je vous laisserai aller lire plus en détail,
mais il est vraiment, globalement,
très positif en disant que ça lui a permis
d'éviter un certain homme d'écueil
et d'arriver assez rapidement à une solution
qui fonctionne et qui soit viable.
Donc voilà, c'était un petit peu, pour donner un petit éclairage
sur ce qui se passe et un petit peu les bénéfices
d'avoir un petit peu
la possibilité de créer des nouveaux drivers dans ce langage.
Voilà, je vous laisse réagir si vous soyez.
Oui alors je vais commencer, parce que en tant qu'ancien développeur,
je ne connais pas bien Rust.
Je pense peut-être que je me penche dessus pour voir la différence
de syntaxe entre le C et le Rust.
Je me pose une question, justement, que je ne connais pas bien Rust.
Le Rust, c'est un langage compilé, ou un langage interprété
via JVM. J'imagine que c'est compilé, parce que sinon ce sera...
Oui, pour faire du bas niveau en fait, à ce niveau-là,
c'est forcément compilé.
Et moi je me pose une question, parce qu'avec l'émergence du Go
et le Rust, pourquoi le Rust plus que le Go,
qu'est-ce qui fait que ça fait pencher la balance d'un côté et de l'autre,
est-ce que c'est des contraintes de licence de supporteur,
est-ce que c'est autre chose ?
Alors il y a une différence assez notable, c'est que Go utilise un garbage collector.
Donc il y a, on va dire, un système pour gérer la mémoire
et éviter des problèmes. Et Rust n'utilise pas de garbage collector,
il utilise d'une autre méthode, on va dire.
Et de ce fait-là, c'est parfois un peu plus...
Pour le très bas niveau, c'est un peu plus adapté.
Voilà, après, je pense que c'est une des raisons.
Après il y a d'autres raisons, c'est que vraiment,
Rust a été fait pour adresser des problèmes sur le bas niveau.
Et tout est adapté à pouvoir faire ça.
Et on va dire, on va dire,
et voilà, et aussi il y a un focus assez fort
pour essayer vraiment de garder un maximum de vitesse.
Voilà, on va dire, essayer de garder, avoir un peu un triptique
qui était assez difficilement conciliable, c'est-à-dire de la sécurité,
au niveau de la gestion de la mémoire, de la rapidité.
Et après, un autre avantage, c'est que c'est aussi
qu'on fait de la concurrence.
Voilà, ça aide aussi quand on fait des programmes multi-fredés
à éviter de se prendre les pieds dans le tapis et de se cracher.
J'imagine que Rust est plus développeur friendly que le C
parce que je me rappelle quand même avoir bien souffert
et j'en ai fait pendant plusieurs années du C.
J'avoue que...
Je suis pas sûr de ça, en fait.
C'est pas forcément...
Ah, t'es pas sûr.
Non, c'est pas sûr que ce soit forcément plus développeur friendly
en tant que tel parce qu'il y a une syntaxe qui est quand même assez...
Enfin, qu'il faut appréhender.
Mais par contre, la grosse différence, c'est que tu as...
Tu peux pas tirer une balle dans le pied.
En fait, en C, c'est très facile de faire une erreur.
Et l'erreur est humaine.
Donc voilà, c'est très facile de faire une erreur
et de rendre le programme complètement instable.
Et donc du coup, quand là, tu fais des parties carnelles,
si ça part, ça fait un panique.
Et puis ta machine a fait un bel écran...
Pas un écran bleu, mais a fait un beau carnell panique.
Alors que...
Oui, alors juste, je vais...
Je vais re-contextualiser pour les personnes qui nous écoutent
parce que toi et moi, je pense qu'on a cette expérience-là,
mais typiquement, moi, je faisais du temps réel
et le C est fait pour adresser des casse-bémoires particulières
et quand tu parles de carnelles paniques,
des fois, en fait, quand tu programmes
et que tu peux t'adresser directement
à des octènes-mémoires précis voire...
Tu peux taper à côté parce que tu as le droit,
parce que le système te le permet.
Tu peux aller taper dans les octènes-mémoires du système
et donc tu fais planter ton système
parce que tu vas écrire des informations
ou en théorie, tu devrais pas aller écrire.
Parce que tu as besoin de ça pour faire du temps réel
et pour faire des trucs ultra rapides, en fait.
Parce que c'est ça, en fait, dont on parle du système d'exploitation,
on parle de driver.
Les drivers, ça va écrire des données dans des mémoires
de cartes graphiques, de sondes, etc.
Donc je précise pour les néophytes,
je sais qu'il y en a beaucoup qui nous écoutent,
que même si ça fait longtemps que je ne sais pas faire de ces,
je me rappelle tout ça.
Vas-y, continue, René.
Non, je pense que tu as bien résumé
et voilà, en fait, c'est un langage qui est très...
qui est très puissant, en fait, le sénat.
On peut faire normalement de choses, mais voilà,
il y a des risques d'erreur
et voilà, c'est ce que Ross essaye d'éviter.
C'est toutes ces problématiques.
Il y a toute une état de classe d'erreurs comme ça,
les danglines pointeurs, les double-free,
parce que on peut, par exemple,
un truc classique, c'est en réserve de la mémoire,
on la libère et puis on pense qu'on a oublié
qu'on a libéré, on essaye de l'accéder de nouveau.
Voilà, on va chercher des données qui ne sont plus là
parce que ça a été libéré avant.
Du coup, ça fait un beau problème,
parce que les données qui vont se trouver à cet endroit-là,
ce n'est pas celles qui sont attendues
et du coup, ça va...
il va se passer quelque chose de pas très bien, probablement,
qui va probablement amener le carnel à planter.
Moi, je n'ai pas un avis très tranché sur le sujet.
Par contre, je reste admiratif du travail
que des mecs peuvent faire, justement,
sans avoir de respect,
juste en faisant du reverse engineering
et arriver à proposer des choses comme ça.
C'est juste démentiel.
J'arrive même pas à capter que
que ça aboutisse à quelque chose de bien.
C'est vraiment...
le travail qui est derrière est complètement dément.
Pour moi, c'est des extraterrestres,
les gens qui participent à ce genre de projet.
Je pense qu'on est un peu sur l'extra-terrestre,
sachant que...
dans les liens, vous pourrez suivre
un certain nombre de...
si vous suivez la personne sur Twitter,
elle a donné aussi le temps que ça lui a pris
de faire ce driver.
C'est relativement rapide.
C'est...
plusieurs...
on ne parle pas en année,
on parle plusieurs semaines.
C'est relativement rapide.
Le contenu de la difficulté de l'exercice.
Je vois que son Twitter,
c'est linaasai,
j'imagine que c'est une femme.
Je voyais sur sa chaîne YouTube,
mais c'est un personnage virtuel.
Je ne sais pas si c'est vraiment une femme.
Si c'est une femme, c'est cool.
Moi, ce qui...
ce qui m'interpelle,
ce qui me pose question en tant que créateur
de contenus libres,
comment est-ce que les développeurs du Noyau Linux
et ce genre de choses arrivent à vivre, en fait.
Parce que là, on parle de durée
et de temps de travail énorme.
À moins qu'ils soient comme moi, frilance,
et qu'ils arrivent à se vendre très bien à côté,
je ne vois pas trop comment tu arrives à dégager
autant de temps,
sauf si tu n'as plus de vie de famille,
plus de loisirs et que...
Moi, je reste admiratif sur...
Mais ça, ça fera peut-être l'objet
d'une discussion sur le financement du livre.
Après, clairement, je pense que...
ce genre de profil-là,
c'est quand même relativement rare.
Avec ces connaissances-là.
Et du coup, c'est des gens qui sont...
qui sont...
soient sponsorisés,
soit...
c'est à l'arrivée d'entreprises
qui les payent à faire ça.
Je veux dire, je pense.
Là, après,
malgré tout, quand on regarde les statistiques
sur le Noyau Linux,
il y a quand même une part de hobbyiste,
donc des gens qui ne sont pas affiliés
à des entreprises et potentiellement
complètement bénévole.
Eh ben, merci, Yovone, pour cette news.
Alors, c'est le Christophe du futur.
Je fais une petite interruption
de ce podcast
pour vous donner une nouvelle,
puisque en fait, j'ai été contacté
entre le moment de l'enregistrement
et le moment de sa sortie
par les organisateurs de Kubernetes
comme Utilise France.
Et donc, je voulais vous en parler
dans cet épisode d'Actu DevOps,
parce que c'est vraiment un sujet d'actu,
vous allez le voir.
Donc, les Kubernetes
comme Utilise 10 France auront lieu
le 7 mars 2023 à Paris
au sein du célèbre
centre George Pompidou.
Mais pourquoi je vous en parle aujourd'hui
et pas plus tard, c'est parce que, en fait,
aujourd'hui, je vais vous parler
du fameux
CFP,
Call for Papers
donc, ça veut juste dire,
en fait, on a besoin de vous
pour faire nos talks, s'il vous plaît,
envoyez-nous vos talks.
Donc, du coup,
les Kubernetes
comme Utilise 10 France
ont ouvert, justement,
la soumission au talk
et ils vont, justement,
le fermer
le 31 octobre.
Sauf que je leur ai dit que moi,
l'épisode d'Actu DevOps,
que tu es en train d'écouter,
serait publié, grosso modo,
le 27, je crois,
c'est ça, le 27 octobre,
et que ça, les 7 peu de temps.
Alors,
j'ai négocié avec eux et ils ont accepté
de repousser
la date de fin
de poste
des propositions de talk.
Vous pouvez, enfin, tu peux donc, si t'as envie
d'aller proposer un talk,
tu peux le faire jusqu'au 6 novembre 2022.
Alors, c'est quoi le format, en fait ?
Ils ont plusieurs formats de
présentation. Ils ont les conférences
de 45 minutes qui peuvent être présentées
par une ou deux personnes, les retours d'expérience
d'environ 30 minutes
sur la présentation d'un outil ou d'un framework
qui peuvent être présentées par une ou deux personnes.
Ce qu'ils appellent les lightning talk
en 10 minutes, qui est un format
très, très court sur un sujet très précis.
Et ils veulent aborder, évidemment,
les sujets du clone natif
et du DevOps. C'est pour ça que je t'en parle
parce que tu es dans un podcast
DevOps et cloud,
évidemment, clone natif.
Donc, les catégories sont
pour les thèmes
développement d'applications clone natif,
intégration continue
et déploiement continue, outillage et bonne pratique,
réseau,
sécurité, stockage, data,
machine learning
ou autre sujet type
crazy stuff. Alors, je ne sais pas ce qu'ils mettent
derrière crazy stuff, mais en tout cas,
ça, il mérite d'exister. Vous pouvez envoyer
des trucs complètement fous.
A priori, ils sont ouverts.
Ils donnent la priorité.
Donc, aux initiatives et projets locaux,
open source et ou communautaire.
Ils veulent pas de pitch marketing
ou commerciaux.
Ils veulent
des présentations
plutôt orientées par tâches
d'expertise et retour d'expérience.
Ils n'oublient pas
aussi la partie développement
avec des tools
qui ils aimeraient
lier au développement d'applications.
Ils veulent promouvoir
la diversité et les démarches vertueuses,
comme par exemple l'écologie, les démarches
RSE,
responsabilité sociale et environnementale,
etc.
Ils veulent faire la promotion
de la nouveauté et de l'originalité.
Ils encouragent les premières soumissions.
Donc, si c'est ton premier tool,
tu peux aller proposer
ton sujet.
Pour ça,
il n'y a rien de plus simple.
Tu vas sur le site Internet
cfp.kcdfr
mais de toute façon,
je mets le lien
dans le descriptif de l'épisode
comme d'habitude.
J'espère que tu pourras
participer et que
ce message t'encouragera
à proposer ton tool.
Je reparlerai probablement
des cassés des frances
au moment du lancement.
Voilà,
tu vas reprendre ton épisode,
il n'y a pas de soucis.
Tu peux rester jusqu'à la fin de l'épisode.
Alors, tu l'attendais
depuis le début de l'émission, c'est la fameuse section
des outils. C'est moi qui ai l'honneur
d'ouvrir le bal. Et je vais te parler
d'un dépôt
qui est le dépôt
de Bergman Harry,
qui est le DevOps Exercise.
Du coup, c'est un dépôt qui va te permettre
de retrouver tout un tas
d'exercices et de questions
qui vont pouvoir t'aider à apprendre
des techniques divers et variées
des DevOps et serreux.
Donc, tu as
tout un tas
de sujets comme dites en cible,
le shell scripting, le piton,
le cloud avec OpenStack,
Google Cloud Azure etc.
De la virtualisation.
C'est énorme, il y a tout un tas de trucs
et quand j'ai découvert ce dépôt, je me suis dit
mais ce dépôt est génial,
puisqu'il y a plus de
2477
exercices et questions
et il est tenu à jour, puisque
je vois que le dernier comitement, on enregistre
a eu lieu il y a 11 heures.
Donc, il est maintenu
il y a déjà plus de
31000 étoiles
et plus de 6000 forks
presque 7000, ça veut dire qu'en effet
il y a des gens qui l'ont forké, qui participent.
Je ne sais pas combien il y a
de contributeurs à ce dépôt-là, mais
ça doit être assez énorme.
Et j'ai trouvé, je me suis dit, que pour
t'apprendre à des divers techniques,
évidemment c'est tout en anglais, mais
c'est plutôt intéressant.
Un avis sur ce, est-ce que vous
connaissiez déjà ce dépôt-là ?
Non, moi je veux bien
dire qu'un petit mot, c'est
pas mal parce que
ce qui peut arriver c'est que
pas pour l'avoir vécu.
D'avoir
un test technique
pour un entretien
et j'avoue que
quand j'ai passé
ce test technique-là, je ne savais pas
trop sur quoi ça allait
porter.
Je pense que c'est vraiment la difficulté
au niveau du DevOps, ça peut être vraiment large.
Et c'est vrai que
je n'avais pas trop
pratiqué,
enfin, on voulait trouver un site
comme ça pour avoir un petit peu
le type d'exercice qu'on pouvait avoir et je pense que
ce serait plus...
éclairé un peu plus.
Je trouve que ça avait plutôt bien marché
mais voilà,
pour se préparer, je pense que c'est bien.
Je pense aussi.
Alors j'ai trouvé, il y a 114
contributeurs et contributrices, donc
il y en a beaucoup.
Je ne connaissais pas non plus,
je parcours là et
en plus le format, il est pas mal
parce que ce n'est pas des exercices oppressants.
Du coup,
c'est pas mal pour...
pour ces... enfin,
on a la réponse dès qu'on expand
la question et tout.
Et c'est plutôt bien fait.
Regardez deux, trois trucs et...
non, c'est une bonne...
En tout cas, ça doit être
pas mal pour soit se mettre un peu dans le bain
soit pour se dire, est-ce que j'ai les bases
rapidement d'un sujet
passé dessus, ça doit
rendre un peu plus confiant, donc c'est cool.
Donc non, c'est
une bonne découia.
Eh ben, tu as la parole, je t'en prie
garde là si tu veux nous parler
d'un langage que j'adore.
Ouais, ouais, ça m'a fait marrer.
Je suis tombé dessus parce que je cherchais
moi, je...
Alors c'est pas un outil.
C'est un ensemble de...
c'est une initiative qui regroupe
tout un tas de...
de petites librairies,
des librairies fonctions pour...
pour Bache, donc c'est pas ça que Christophe
est content et que d'autres
vont probablement criser.
Mais ce que... est-ce que pas mal, c'est que
donc ça s'appelle pure Bache Bible
et en gros,
il y a tout un tas de...
de cas d'usage où on vous dit, bon,
ben... habituellement,
à chaque fois, vous refaites des one-liners
qui sont pas hyper fiable,
vous refaites des petites fonctions
que vous redeveloppez pour chaque projet
que vous faites. Ben en fait, eux, ils proposent
déjà
des librairies pour manipuler
des strings
pour faire des opérations un peu complexes
etc etc. Et l'idée, c'est
juste, ben, de copier-coller
les trucs qui vous intéressent dans votre code
pour en profiter.
C'est... bon, je trouvais que c'était une bonne
initiative. Pareil,
c'est... c'est pas
des trucs de ouf, mais
par exemple, si vous voulez pas
avoir à vous prendre la tête
à trim les white spaces
d'un stream, ben
il y a une fonction qui fait ça
copie-colle, app-app
c'est réglé, vous l'appelez
et ça fera le job
et sans que vous ayez
à re-réfléchir à tous ces sujets. Donc
je sais pas, moi je trouvais que c'était...
c'était plutôt cool. Pareil, c'est bien présenté,
c'est que des trucs faciles,
c'est facile de contribuer aussi.
Ils sont demandeurs de contribution.
Donc, allez voir ça, pardon.
Et...
et j'imagine que toi, Christophe,
tu as probablement des petites choses
à rajouter dans la liste
des 12 milliards de...
parce qu'il y a vraiment un paquet
de choses proposées.
Alors, il y a des trucs que je trouve pas très...
pas très utiles, mais
il y a quand même un bon paquet de choses
qui sont sympas.
J'irais voir justement,
voir ce que je peux en tirer,
ce que je peux en faire, ce que je peux proposer.
René, ça t'évoque quelque chose ?
Ouais, ça a l'air...
ça a l'air pas mal.
Ouais, c'est bien parce que je pense,
j'ai parcouru rapidement, mais il y a plein de méthodes
qui te permettent de faire des choses
rapidement. Et si tu sais pas comment les faire
en bâche, mais que t'en as besoin dans un script,
tu vas aller récupérer ça et tu vas les copier.
J'ai vu des trucs que je suis pas très chou
avec eux, notamment
les short-run méthodes
pour faire des boucles.
Ça rend vite ton code églisible.
Mais bon, ça c'est...
typiquement quand j'étais développeur,
quand j'étais tout jeune, j'avais 20 ans,
j'adorais optimiser mon code
et faire le code le plus petit possible.
Et on m'a vite appris
qu'il fallait pas faire ça, et maintenant
à mon âge je comprends pourquoi, parce que
un code hyper optimisé, notamment en C,
pour ceux qui ont jamais fait de C,
tu peux faire des trucs vraiment églisibles en C,
juste quand tu le lis, tu comprends pas
ce qu'il se fait. Et donc
tu peux faire pareil en bas.
Écrivez du code
visible. Je connais.
Tu connais le C Obscur ?
Non, mais je pense que j'en ai fait.
C Obscur, en fait, c'est limite
une...
une voix où le but du jeu
c'est de rendre le truc le plus
compliqué possible en fait.
C'est un exercice, voilà,
le style en fait.
Non, moi j'en ai ça le plus simple possible.
J'ai retrouvé le comment je suis tombé dessus.
C'est parce que je cherchais à faire
un URL des codes
en one liner, quoi.
Et je ne jouais pas de façon hyper simple,
et c'est comme ça que je suis tombé
dessus. Donc allez voir,
il y a des trucs sympas.
Bon, Roder, tu veux nous parler de quelque chose
qui va m'aider, je pense, dans l'avenir ?
Oui, j'ai un petit outil
qui
a été proposé un moment
sur Twitter par
Akanoa,
quelqu'un qui fait des streams
justement
autour de Rust et plein d'autres choses.
Et là, je vous encourage
d'assuyer, parce que c'est aussi de très
bons articles.
Et en fait, c'est un outil
qui a été écrit par quelqu'un qui s'appelle
Florentin Dubois, qui est...
qui travaille pour Clévoir Cloud.
Et ça permet de...
de générer un change log dans
deux formats.
Format Markdown
et format
mail
pour pouvoir
envoyer...
on va dire HTML, voilà, HTML
mail pour l'envoyer vers
aux gens sur une mailing list, etc.
À partir
de des comites
Git. Donc en fait, il suffit
de pas... Il y a un fichier de paramétrage
pour décrire un petit peu le projet, etc.
Et après, si on respecte
euh...
le terme, euh...
les guides...
Les guides conventionnels peut-être ?
Ouais, conventionnels guides. Merci Christophe, voilà.
Donc il consiste à mettre un mot clé
si le commit c'est un feature,
si c'est un fix, si c'est de la doc,
si c'est... voilà. Donc si on respecte
cette convention là,
bah en fait, ça fait un joli
change log avec
les différentes sections et les
différents comites qui vont dedans. Donc
voilà, il y a...
il y a d'autres outils qui font ça, mais celui-là
est plutôt sympa.
Et euh... il est créé en reste aussi.
Oui, et je vois qu'il y a
un contributeur qu'on connaît bien
dedans, puisque... il y a 3
contributeurs, un robot, Florentin Du Bois
et un certain... René.
Oui, on va, j'ai fait
une petite euh...
Ouais, ça m'a intéressé et j'ai fait
voilà, j'ai fait une petite
maires request dessus, parce que
en fait,
nous étions des...
des...
des...
et voilà, j'ai...
il y avait un moyen de supprimer la
dépendance à NPM, donc ça reste plus
à limiter le nombre de dépendances, c'est
toujours intéressant. Et voilà,
j'ai proposé, puis bah...
j'ai eu la chance de ce que ce soit merdier.
Exact. Alors je ne peux que t'encourager
à utiliser les...
les... les comites conventionnelles
à... d'autres façons, quand moi je donne
des cours et je... j'apprends aux gens
à utiliser les guites conventionnelles, et
dans mon équipe, j'impose les guites...
les comites conventionnelles pour guites.
Pour justement pouvoir faire
ce genre de choses qu'on n'a pas encore mis en place, et ben
je pense que je vais tester
cet outil pour générer les change logs,
puisque on a quand même
maintenant pas mal de logiciels libres qu'on
maintient, et je pense que pour notre
collection en cible qui installe une host,
ce sera pas mal pour...
faire les change logs de manière automatique,
parce que pour l'instant c'est Arthur qui les crée
à la main. Merci, je peux en e...
Je peux rajouter un tout petit mot
pour... si vous voulez
voir des exemples
du change log que ça génère.
En fait je crois que... Clever Cloud
développe l'outil qui s'appelle Sousou
qui est un reverse proxy
voilà, avec...
qui peut... qui peut se reconfigurer
à chaud, etc.
Mais... et voilà, je crois qu'il génère le... le
change log de cet outil
avec... avec...
avec le... le outil dont on parle.

De toute façon l'intérêt c'est de le mettre dans une
intégration continue, qu'au moment où tu crées
un tag, pouf, tu as ton change log qui est
généré, j'imagine. Erwin, un truc à dire là-dessus ?
Non, je... je connaissais pas cet outil
et je charge des espéraments celui que...
que j'utilisais, qui...
qui se basait aussi sur les...
conventionnel...
comites, et je retrouve plus son nom.
Bah si tu le trouves d'ici la publication...
sans...
Ah ouais, bah c'est une... Ouais, si je le retrouve
je... je ferai... ferai suivre.
Oui, il y a des alternatives après, il y a pas...
ça c'est sûr. Et Erwin, tu vas nous parler
d'un repos que j'ai vu aussi apparaître
il y a pas longtemps ?
Ouais, et...
comme... comme c'est vrai que souvent
la... la documentation
pour...
qui tourne autour du...
du mouvement DevOps est...
très souvent en anglais, même s'il y a
beaucoup de...
de contributeurs français,
bah il y a...
Stéphane Robert là, qui a...
qui a créé un...
donc vous pouvez suivre d'ailleurs sur Flutter
il est... il est... plutôt actif.
Il a créé un...
un ripot justement pour centraliser
euh...
pas mal de ressources qui parlent
DevOps...
euh...
DevOps, donc du coup francophones.
Et euh...
et donc du coup, bah déjà on y retrouve
les compagnons du DevOps.
C'est bien.
Mais il y a plein de choses, il y a...
il y a des...
il y a des gens sur Twitter, enfin il y a
des comptes Twitter à suivre, il y a
des sites, il y a des blogs, il y a...
il y a... il y a... il y a... il y a molte choses.
Et euh... bah du coup je trouvais que c'était
une... vraiment c'est cool comme
initiative de faire ça. Et euh...
bah pour ceux qui... qui débutent et qui
se posent toujours la question de bah...
bah je commence, peut-être que ça ça peut être
une... une bonne porte d'entrée.
Donc euh... vous voulez
souligner l'initiative.
Oui oui, super initiative, euh...
après euh...
Stéphane, euh... il fait...
ouais il fait... voilà tout.
Il fait très active dans le mouvement et ce qui
fait une bonne qualité. Et donc
euh... ouais je pense que c'est vraiment
quelqu'un à suivre. Et dans l'occurrence
cette initiative elle est... elle est vraiment sympa.
Exactement, et bah je suis
aussi euh... Stéphane
sur LinkedIn et sur Twitter. En plus
c'est un compagnon qui passe de temps en
temps sur le forum. Donc
je te salue Stéphane.
Merci en tout cas pour cette initiative
parce que en effet ça permet de regrouper
un seul endroit et
euh... et bah les initiatives
divers et variées, puisqu'il y a beaucoup de choses
hein, sur... euh... some French
DevOps, euh... le lien est dans
la description. Vous retrouvez
beaucoup de choses. Beaucoup de...
contre Twitter...
de vidéos, de podcasts etc.
Et ben merci Erwan de nous
à l'avoir mis euh... parce que c'est vrai
que je l'ai vu popée cette semaine
et j'y ai pas pensé. Mais tiens pensé, c'est cool.
Et bien, je
tiens à te dire à toi, cher auditeur
ou auditrice qui nous écoute
que tu peux partager ce podcast
puisque un podcast
si tu ne le sais pas c'est très dur à faire découvrir
c'est pas comme une vidéo Youtube. Un podcast
il faut que tu l'envoies à quelqu'un. Il faut
que tu l'envoies par mail, que tu l'envoies
sur Twitter, sur LinkedIn, euh...
que tu l'écoutes avec d'autres personnes
euh... ou que tu envoies un petit
SMS avec le lien du podcast.
Ça nous aidera à le faire découvrir
euh... puisque le podcast
a une croissance certes euh...
organique qui est là
mais c'est pas forcément elle est pas
aussi importante que Youtube. Donc
je pense que le format audio
euh... a justement de l'avenir
donc n'hésite pas à partager le podcast
euh... je te rappelle aussi
que ce podcast est en licence libre
en créatif common by essa
tu peux le découper, l'utiliser
euh... dans tes propres
euh... vidéos, podcasts etc
si tu t'entais que tu nous crédites
et si tu nous envoies un petit
message en plus ça nous fera plaisir
euh... c'est les dernières choses
que j'avais à te dire et euh... du coup
je vais laisser les mots de la fin
à mes chers co-animateurs
et je vais commencer par renait
alors un petit mot de la fin
euh... bah je pourrais dire n'hésite pas
aussi à bah contribuer
à faire des tout comme Stéphane
voilà de proposer des choses
et je pense que ça a un double intérêt
ça permet de
de bah... de partager forcément
et des d'autres personnes mais aussi
parfois de bah... enrichir son
parfois son compte
et le quissouag et le club qui toque
mais voilà se faire un petit peu de
de promotion ça peut être intéressant
enfin on en a déjà parlé lors des
entretiens voilà et
ce sera le mot de la fin
souhaitant une... en espérant que vous avez bien
aimé cet épisode et rendez-vous
au prochain tout à fait
et enfin Erwan tu as le mot de la fin
de la fin ce sera calpain
c'est un beau calpain
spiral si tu écoutes ce podcast
et que tu n'es pas sur youtube tu peux aller
voir le calpain sur youtube tu verras
la vidéo j'en parle aussi parce que
c'est important parce que mine de rien
on peut se targuer d'être le seul
média qui à la fois est en
vidéo sur youtube et on podcast
puisque on a nos chers collègues
qui sont soit en vidéo, soit en podcast
mais pas les deux, nous on est un peu les deux
cocoréco
on fait ton ça ensemble
en tout cas merci à vous de eux et moi je te dis
à très bientôt
si tu as envie de discuter du mouvement
alors rejoins nous dans la communauté
des compagnons du DevOps
à bientôt
la balade aux diffusions des compagnons
du DevOps est produite par l'Hydra