C'est d'abord une culture. Quand on est en DevOps, on prend tout le monde.
DevOps et agile font effectivement partie de la même famille.
Sa virtualisation applicative, c'est très bien.
Aujourd'hui, ça nous prend 10 minutes et un café.
Ce n'est ni être dev, ni être DevOps. C'est avant toute la communication.
Ce mouvement DevOps, c'est tout simplement drivé par la communauté et endorsé par les entreprises.
J'ai adopté une démarche DevOps.
Le développement agile, on a accéléré des poignements.
Ça amène une clarté sur le travail de...
Être dans une démarche d'amélioration contient votre trou face à des...
Ça, oui, naturellement ensemble, ça donne des résultats contrêts.
L'objectif individuel, ça s'atteint, alors que l'une ambition, ça se partage.
Bonjour à tous et à toutes. J'espère que vous allez bien.
Aujourd'hui, on fait un numéro d'actu.
Donc, le premier de son genre.
J'espère que vous serez un peu indulgent et que vous allez aimer ce format.
N'hésitez pas, de toute façon, à commenter, à prévoir, à écouter.
Le but est donc de revenir sur les actualités qui se sont passées durant les deux dernières semaines.
Celles que j'ai pu voir.
Le but étant d'être assez rapide,
déjà que vous ayez une idée de ce qui s'est passé,
si jamais vous avez pu ne pas avoir certaines actues,
mais également de pouvoir un peu commenter ça.
Donc, comment ça se passe ?
On a un répositori GitHub qui s'appelle donc pct slash actu,
dans lequel vous pouvez ouvrir différentes issues
qui vont être toutes les actualités dont vous aimeriez qu'on parle.
Aujourd'hui, on a sélectionné 4 pour la partie DevOps.
Et donc, le but, ça va être de passer une dizaine de minutes ensemble
à discuter de ces actualités.
Vous pouvez rejoindre également le Discord.
On est en live aujourd'hui pour faire cette partie-là.
Et voilà.
N'hésitez pas à venir pour pouvoir commenter en direct,
si vous le souhaitez,
ou même juste pour écouter en direct,
et pour participer également.
Donc aujourd'hui,
je vais d'abord revenir sur une première actualité
que vous avez sans doute dû passer,
qui était ensuite au Covid,
c'était une conférence qui s'est passée complètement en ligne,
c'est le GitHub Satellite.
Durant cet événement,
il y a pas mal de choses,
pas mal d'annonces qui ont été assez cool.
Donc, des annonces des fois très spécialisées sur GitHub.
Personnellement, j'en ai sélectionné 3
qui m'ont paru à être assez intéressantes.
La première, c'est déjà VS Code directement intégré dans GitHub.
Ça paraît un peu rien comme actualité,
mais en fait, ça a beaucoup d'impact, je trouve.
La première impact,
c'est déjà de se dire qu'on est vraiment au moment du regroupement
entre GitHub et Microsoft.
On rappelle, initialement,
que GitHub avait créé le projet Atom d'un IDE
qui se rapproche d'un sublimetex en utilisant Chrome
et toute la machine avec Chrome.
D'ailleurs, dans ce cadre-là, ils ont utilisé pas mal d'électrons,
qui est aussi un projet qui était fait par GitHub à la base.
Donc, ils ont fait Atom.
Microsoft trouvait peut-être le code pas assez bien à son goût,
et c'est dit, on va créer VS Code.
Maintenant que GitHub a parti à un VS Code,
on voit qu'il y a un rapprochement,
donc Atom est venu par un burn-down et c'est toujours un projet open-source.
Déjà, on peut continuer de travailler dessus,
mais on voit que VS Code est devenu vraiment un projet extrêmement important.
Ce qui a annoncé dans le projet durant cette conférence,
c'est l'intégration en ligne de VS Code.
Plus besoin d'installer le projet,
plus besoin d'installer le logiciel,
vous pouvez directement avoir accès à tout un environnement de développement en ligne,
sans avoir besoin d'installer quoi que ce soit.
Quels peuvent être les intérêts à ça ?
Alors déjà, ça peut avoir un intérêt pour les gens qui ne sont pas forcément très techniques.
Ça m'arrive de travailler avec des gens qui sont plutôt partis business, on appelle ça.
Ce qui ne sont pas forcément des gens qui ne peuvent pas contribuer au lire du code,
si le code est bien structuré, ça peut être assez simple à faire.
Le problème, c'est que installer toute la machine ria,
installer Xcode par exemple si on est sur Mac,
si tu avais après tous les logiciels, tout le runtime pour faire les tests, etc.
ça peut devenir très complexe.
Là, ici, on a quelque chose pour permettre un non-bording des gens très rapidement.
Ça peut également permettre tout simplement d'avoir de pouvoir travailler à distance.
Si jamais vous avez un problème extrêmement urgent à régler,
ou si vous avez besoin de travailler sur un ordinateur qui n'est pas le vote,
vous avez accès à une instance à distance.
Et ça, c'est vraiment pas mal dans le cycle de développement qui est possible.
Un autre intérêt, et là on se rapproche encore plus du DevOps,
c'est que potentiellement cet environnement en ligne
est un environnement préconfiguré avec tous les outils dont vous avez besoin.
Plus besoin d'avoir à se soucier de quelle est la version d'NPM disponible
dans le système de paquet de votre distribution,
ou quel est celui qui est installé sur le PC des développeurs.
On pourrait très bien voir demain un environnement assez unifié,
très similaire à un environnement de 6 high directement en ligne.
Et donc avec une intégration totale,
avoir cette notion d'un projet complètement hébergé en ligne
dans un environnement offline,
et en fait quelque chose qui pourrait potentiellement demain
changer notre façon de travailler.
Bien sûr, à l'heure actuelle je ne peux pas vous le garantir
et je ne sais pas ce qui va se passer demain,
mais c'est quelque chose qui pourrait arriver.
Au final, et c'est là encore, vous c'est le plus tinct,
c'est que c'est l'aboutissement de beaucoup de choix techniques
qui ont été faits dans VS Code.
On l'a vu avec par exemple le travail avec WSL.
Ça permet d'avoir WSL pour le Windows Subsystem Linux.
Ça permet d'avoir un écosystème Linux au sein d'une machine Windows.
Le problème, c'est comment on y accèle.
On ne va pas lancer nos applications à l'intérieur de ce système-là,
puis après d'avoir un X, etc.
Ça devient très compliqué de lancer des applications graphiques
dans ce subsystem.
Dans VS Code, ils ont réussi à résoudre le problème
avec un système de clients serveurs.
D'avoir d'un côté le serveur sur la partie Linux,
donc comme ça toutes les commandes sont exécutées dedans,
tous les tests, tout le code est hébergé dedans,
avec tous les outils qui vont bien,
et la partie fronte qui est dans la partie Windows
avec toutes les interactions possibles dedans.
Là, on a un peu la même chose,
sauf qu'on a un navigateur qui est le client
et le serveur en dessous qui tourne dans une instance type Linux.
Et donc, c'est vraiment des choix
depuis le début qui maintenant commencent à se concrétiser
avec cet assemblage Microsoft GitHub
qui est de plus en plus important.
Et on va même y revenir,
parce qu'il y a encore une autre annonce,
ou en tout cas un autre projet
qui va encore plus dans cette dimension-là.
Une autre annonce que j'ai pu voir dans le GitHub Satellite,
c'est les GitHub Discussion.
Alors pour l'instant, on n'a pas...
En tout cas, je n'ai pas réussi à trouver beaucoup d'informations dessus,
mais globalement, ce que ça va permettre,
ça va permettre au lieu de devoir créer un projet Slack par projet,
de devoir inviter tout le monde dedans, etc.
d'avoir une complication à créer une communauté.
Là, par exemple, vous voyez, on est sur Discord,
mais parce qu'en même temps,
on n'est pas un projet GitHub à part entière,
on est vraiment un podcast.
Mais le but des GitHub Discussion,
ça va être vraiment de créer un peu ce que GitHub a essayé de faire,
c'est-à-dire un environnement
où on va pouvoir discuter de manière plus informelle,
pas obligée de rédiger de manière très longue les issues.
Mais de se dire, voilà,
créer une communauté plus synchrone
que ne sont les issues GitHub.
Et c'est plutôt pas mal, en fait.
Ce n'est pas forcément une révolution,
mais c'est quelque chose d'assez cool.
D'autres choses aussi qui ont été annoncées,
c'est plus pour la sécurité,
c'est des scans de vulnérabilité au niveau du code.
Je pense que on a tous peut-être une fois dû se tromper
et mettre des variables d'environnement qu'on ne devait pas.
Alors il existe des bouts déjà qui tournent.
Si jamais vous avez déjà arrivé de mettre une clé AWS
dans un compte GitHub public,
vous savez que instantanément,
vous recevez des emails avec des bouts qui vous disent
« Attention, vous avez mis une clé dans votre guide.
»
Et même si vous l'écraser,
ce commit-là n'oubliez pas
qu'il est toujours potentiellement disponible.
Donc juste faire un push-force ne suffit pas à le supprimer.
Et donc le conseil, c'est enlever cette clé-là,
en tout cas révoquer cette clé le plus vite possible.
Mais là, le but de voilà,
c'est d'avoir tous ces outils de sécurité
en amont dans notre code.
C'est des choses que d'autres bouts pouvaient proposer.
Là, c'est quelque chose qui est directement nativement dedans.
Donc ils ont même créé un langage
pour requêter le code,
ce qui s'appelle codeQL.
Donc je n'ai pas beaucoup plus d'informations
pour le moment dessus.
Mais c'est quelque chose à regarder.
C'est quelque chose qui peut être vraiment sympa.
Et sans doute,
l'avantage, c'est que c'est quelque chose
qui va pouvoir arriver aussi
sur toutes les autres logiciels.
Je pense à GitLab par exemple,
qui avait déjà ce genre de fonctionnalité existante.
C'est vraiment cool.
On va pouvoir en fait avoir une sécurité
directement au niveau du code,
d'avoir une qualité de sécurité du code,
potentiellement demain.
Et voilà,
c'est quelque chose qui peut être très cool
dans les projets open source, mais pas que,
parce que bien sûr,
GitLab peut être utilisé
dans autre chose que des projets open source.
Un autre lien qui m'a été envoyé
et qui me paraît être assez intéressant
dans cette démarche justement
de fusion entre Microsoft
et GitHub,
c'est un convertisseur
de pipeline Azure DevOps
en GitHub Actions.
Parce que tous les annonces
qui ont été faites de GitHub
tournent pas mal autour des GitHub Actions.
J'en ai pas trop parlé là,
mais il y a eu pas mal d'annonces
autour de GitHub Action.
Et ça devient vraiment le nerf
de ce que peut faire,
de ce que là où veut aller GitHub.
Et au final,
ça devenait un peu redondant
avec les Azure DevOps,
les pipeline Azure DevOps.
Et donc là, Azure a créé
un outil de conversion
qui vous permet de passer de l'un à l'autre.
Alors pour l'instant,
c'est complètement optique.
Vous pouvez le faire,
ça vous permet vraiment
d'un côté,
vous mettez le yaml Azure DevOps
et de l'autre côté,
ça vous le transforme en GitHub Action.
Pour l'instant,
il n'est pas prévu en tout cas
pas à annoncer
de supprimer les Azure DevOps pipeline.
Mais,
on voit qu'il y a une tentative
de réunir les deux
dans un tour, en fait.
Et c'est plutôt pas mal,
en fait, comme logique,
sachant que les GitHub Action
sont en fait quelque chose de ultra puissant.
Je pense qu'il faudra qu'on fasse
un numéro de DevOps là-dessus
parce que c'est vraiment
très sympa.
Et là, par exemple,
tout ce,
tout ce parti actu
est entièrement géré
avec des GitHub Action.
C'est-à-dire que toute la partie projet,
toute la partie
de gestion des liens
que vous pouvez envoyer,
en forme d'issues,
sont traités avec des GitHub Action.
On ne traite pas du code,
mais juste des issues.
Mais GitHub Action permet de le faire.
Donc, on a comme ça
une réunion
où on peut automatiser
des choses qui ne sont pas que du code
directement et de manière
en fait très simple
avec un partage
des ressources assez faciles.
Vraiment,
très sympa les GitHub Action.
Et donc là,
on voit
une tentative de merge
entre les Azure DevOps Pipeline
et les GitHub Action.
Donc, wait and see, je pense,
et c'est quelque chose
qui peut être
vraiment pas mal à regarder
dans le futur.
Une autre actue.
Alors là, pour le coup,
rien à voir,
alors vraiment rien à voir du tout.
J'ai vu un projet
passé en fait
qui s'appelle Aidan SCM.
Alors c'est un projet de Facebook,
pour le coup.
Je vois que les news
sont très orientés
gaffam,
mais
il faut se dire
que c'est des gens qui font
pas mal de projets.
Pourquoi j'ai sélectionné
ce projet en particulier ?
C'est pas vraiment une actue,
en fait.
C'est vraiment un projet
qui existait déjà.
C'est sur GitHub,
c'est dans l'organisation
Facebook Experimental.
Et alors pourquoi ?
Parce qu'en fait,
Aidan SCM,
c'est un outil
pour gérer les monoripaux.
En fait, c'est 3 composants.
Donc on a
l'Aidan CLI,
qui est en fait
la partie cliente
qui permet donc
de gérer
les interactions
avec Aidan SCM.
On a Mononoke,
qui est la partie
serveur de Aidan SCM,
qui est en fait
une sorte de,
enfin,
vraiment celle
qui fait tourner Aidan SCM.
Et enfin,
on a Aidan FS,
qui est un système
de
virtual file system,
un système
de fichiers virtuels
pour permettre
de gérer
les larges ripots,
les
repository guides,
monoripaux,
extrêmement larges.
Alors,
si vous avez déjà
un peu regardé
comment fait
Google en interne,
ils ont à peu près
la même chose
pour gérer
leur énorme monoripaux.
Et bien là,
en fait,
c'est pas un open source,
mais là,
c'est une sorte
de projet un peu similaire
pour permettre
de gérer
de très,
très larges monoripaux.
Pour ne pas
avoir besoin,
en permanence,
de devoir télécharger
des dizaines de
méga
toutes les
heures
ou toutes les
toutes les journées
juste pour pouvoir
faire un push.
C'est un peu ça le but.
Pourquoi j'ai sélectionné ça ?
Parce que,
au final,
on voit que très souvent,
les monoripaux
sont vus comme étant
une solution simple
pour gérer
du code.
Et c'est souvent
l'argument qui est donné.
Et en fait,
on voit que
pas tant que ça,

en tout cas,
ça dépend de l'échelle.
C'est-à-dire que là,
où le monoripau peut être
efficace à l'échelle
d'une petite équipe,
une équipe,
surtout en fait
de gens très unis,
fort ou très homogène
dans les stacks techniques
qu'ils utilisent,
très vite,
quand on commence
à avoir des projets
qui grossissent
ou des équipes
qui grossissent également
avec beaucoup d'interactions
qui sont faites
avec beaucoup de push,
avec beaucoup de code
créés,
là,
d'un coup,
on peut voir des limitations.
Et donc,
en fait,
on voit que là,
où normalement,
on avait créé le monoripau
pour essayer de ne pas avoir
besoin de trop tooling,
de dire,
« Regardez, c'est simple
de faire à la fois
un comit dans ma librairie
et dans mon code.
J'ai pas besoin
de beaucoup d'outillage.
»
En fait,
on s'aperçoit qu'à une certaine
échelle,
on est obligé de recréer
l'outillage.
Donc,
je trouvais ça assez marrant
d'avoir ça,
de voir que le monoripau
a aussi ses limitations
et qu'on a également
besoin d'outillage.
En fait,
on avait créé le monoripau
pour s'enlever des problématiques
qui en fait
arrivent à un moment
donné.
Donc,
j'arrive pas à connaître
ce moment-là.
En fait,
sans doute,
le chemin est un peu
entre les deux.
Il faut voir
en fonction des projets.
Ceux qui me suivent un peu
sur Twitter savent
que j'ai ma préférence.
C'est-à-dire que
si jamais c'est...
mon avis est plutôt de faire
du multi-ripau,
c'est-à-dire d'utiliser
toutes les primitives
de guides de manière simple
et pas les dossiers
d'anguites
et de séparer proprement
les ripositories
avec leur propre rythmie,
leur propre cycle de vie,
leur propre CIAI,
plutôt que de tout merger
au sein d'un même outil
qui est en fait complexif
et énormément
tous les pipelines de CIAI, etc.
avec tout dedans
qui peuvent s'entroméler,
s'entrecroiser
et s'entrover à avoir
beaucoup d'issues
ou pas forcément
bien liées.
Et si jamais vous avez besoin
de lier
des issues entre elles,
potentiellement
de le faire autrement.
Donc voilà,
peut-être que c'est
un manque d'outillage,
par contre,
pour le multi-ripau
qui existe.
Et ça,
c'est sans doute le cas.
On a vraiment
un manque d'outillage
dans le multi-ripau.
Mais, voilà,
ma préférence va plutôt
par là.
Je préfère le faire
manuellement
à la limite
mais garder cette belle
logique déclarative
des projets.
Même si ça peut
demander un peu
de temps manuel.

Je pense que je ferai bientôt
d'ailleurs dans mon autre podcast
qui s'appelle
Suprastructure,
qui est un podcast
pour le coût
beaucoup plus personnel
ou je peux un peu plus
troller.
Je parlerai
de la surautomatisation
et
de ce besoin
qu'on a des fois
de vouloir automatiser
des choses que,
même si elles sont faites
manuellement,
ne sont pas très graves.
Voilà.
Je vais digresser un peu.
Et, enfin,
la dernière
la dernière actue
que j'ai sélectionnée
de
ces deux dernières semaines,
c'est en fait
un exploit
que,
si jamais vous avez
solde,
vous avez solde stack,
vous avez forcément
entendu parler,
voire même,
je ne l'espère pas
mais peut-être subi.
Donc, c'est un exploit
de solde stack
qui est extrêmement violent.
Puisqu'en fait,
si jamais
un de vos ports
de votre serveur
était exposé publiquement,
même avec
des logiques d'authentification,
etc.
En fait,
en utilisant un exploit
bien précis,
les attaquants pouvaient
avoir accès
à votre master
et donc
à tous vos mignons,
tous vos neux,
tous vos neux réseaux,
tous vos neux qui faisaient
tourner du code.
L'exploit, en fait,
a été très, très vite
utilisé
avec des
gens qui ont commencé
à faire des mineurs
de Bitcoin.
Et donc, en fait,
très, très vite,
tous vos neux
se sont retrouvés
à être
infectés
par des mineurs de Bitcoin.
Et donc, j'ai pu
croiser des gens
sur Twitter
qui avaient des soldes
cette dernière semaine
et se sont retrouvés
à avoir toutes leurs
infrastructures
complètement hackées.
Donc, on peut se dire
qu'il y avait juste
à patcher
le solde server.
En effet,
ça a patché la faille
mais en fait,
tous les exploits
qui avaient été faits
ont réussi
à se répliquer un peu partout
et en fait,
on vraiment
complètement blootait
tous vos neux
si jamais vous aviez ça.
Donc,
en fait, j'ai sélectionné
cette news
parce qu'elle permet
de voir vraiment
que cette logique d'automatisation
en fait
a vraiment
son petit revers
de la médaille
qui est en fait
que les exploits
ou tous les problèmes
arrivent en cascade
à une vitesse grand V.
C'est-à-dire que
avoir accès
à ce neu central d'automatisation
peut permettre
d'avoir un exploit
extrêmement rapide
sur tous les
sur tous les neux
de votre server
et de votre cluster.
Donc,
peut-être que tout centralisé
n'est pas forcément
une bonne idée
d'ouvrir
tous les ports également
même si c'est sécurisé
et surtout
d'avoir
d'y penser,
de savoir
qu'à un moment,
shit's happen
et que votre neu central
peut être touché.
Et voilà,
j'espère que ceux
qui ont eu
cet exploit à gérer
ont pu dormir un peu,
n'ont pas eu trop de données
qui ont liqué,
ont pu
cégréguer le problème.
C'est ça aussi le problème
quand on est
victime d'un exploit.
C'est à quel moment
on a vraiment réussi
à complètement contourner
le problème
et de
être sûr que nos machines
sont entièrement nettoyées
et qu'il ne reste pas
un exploit dans un coin
qui va pouvoir se réveiller
et reprendre le contrôle
de nos machines.
Donc,
j'espère que
ça va bien.
J'espère que tous ceux
qui ont un salt disponible
ont bien checké
qu'ils n'ont pas été
victimes de cet exploit.
Faites attention à ça.
Et voilà.
Voilà un peu
pour les quelques news
devops
que j'ai eus.
Comme j'ai pu le dire,
on va essayer de faire ça
tous les deux semaines.
N'hésitez pas,
si vous voyez des news
à venir les reporter
dans les issues
du repo
GitHub
p7t.t.s.
Vous pourrez les mettre
directement dans la catégorie
soit DevOps,
soit Kubernetes,
parce que dans une semaine,
je vais essayer de faire
un nouveau numéro
aussi sur Kubernetes,
qui sera pour le coup
dans le podcast
d'AntonCube.
N'hésitez pas à le rejoindre
si jamais
vous avez envie.
Et voilà.
Donc, voilà pour les petites actues.
Partagez-les,
partagez les futurs actues
dont vous aimeriez qu'on parle.
Aujourd'hui, j'étais tout seul,
mais j'espère bien
que la prochaine fois,
il y aura deux de personnes.
C'est forcément
un premier essai aujourd'hui.
Donc, n'hésitez pas même
si vous voulez participer.
Je pense que si jamais
vous postez une actualité,
je vous demanderai
si vous voulez
si vous voulez y participer,
même juste sur cette actue
ou sur les autres.
Ce serait avec grand plaisir.
Et voilà.
Merci à tous.
Bon, écoute.
Et bon,
des confinements,
parce que je pense que
si quand vous allez
écouter ce podcast,
on sera déjà déconfinés,
ce qu'à je l'espère.
Et voilà.