Bonjour à tous et à toutes et bienvenue dans un nouveau numéro de DevOps.
Alors aujourd'hui, nous allons parler Fosdem 2022,
qui s'est tenu en remote cette année.
Tous les ans d'habitude, il est à Bruxelles.
Mais bon, cette année, impossible d'organiser avec bien sûr le Covid.
Et on va parler spécifiquement d'une conférence.
C'est assez cool parce que j'ai avec moi celui qui a fait le talk.
Et je vais laisser se présenter.
Salut.
Salut.
Bah du coup, c'est Mathieu.
Et puis je suis super content d'être avec vous aujourd'hui
pour parler du Fosdem, du talk de Platkar et un peu de ce qu'il y a autour.
Et est-ce que tu peux te présenter un peu plus ton expérience
peut-être pour que les gens puissent mieux te connaître?
Alors, oui, bien sûr.
Du coup, je suis ingénieur avec Microsoft depuis un an.
J'ai travaillé un an et demi en tant que DevOps aussi
dans une entreprise française.
Et puis, j'aime beaucoup Psycho-Open Source,
contribuer à des projets, participer à des discussions, etc.
autour de Open Source, ça, c'est vraiment un truc qui me motive.
Et je suis aussi au bénévole dans une association
qui s'appelle l'ingénieur sans frontières
et où je donne justement du temps
et puis les compétences que j'ai acquises au gré des années
à cette association, donc en partie au sein de l'équipe informatique
d'ingénieurs sans frontières.
C'est super.
Si on parle, on va d'abord parler un peu du Fosdem.
Donc, toi, cette année, t'es speaker.
Donc, c'est vraiment quelque chose d'un peu...
C'est un peu différent quand on participe seulement
en tant que...
que visiteur dedans.
Comment t'as trouvé cette édition cette année?
C'est une édition un peu spéciale, comme je disais,
donc Henri Maude, comme l'année dernière, d'ailleurs.
Oui, bah écoute, pour moi, c'était une première.
C'était mon premier Fosdem en tant que speaker
et en tant que participant de manière générale.
Donc, j'ai déjà trouvé l'édition Henri Maude super cool.
Donc, j'ai que hâte de voir en présentiel,
qu'est-ce que ça va donner.
J'ai eu beaucoup d'échos sur ces conférences-là
en termes d'orbiance, de qualité des talks, etc.
Donc, ça va être super cool.
Je pense que ça se prend présentiel.
Mais en tout cas, Henri Maude, c'était vachement bien organisé.
Donc, Kudos à toute l'équipe de bénévole qui est derrière,
parce que tout était prévu, en fait,
pour que ce soit en remote.
Et donc, il n'y avait aucun moment où ça ne marchait pas trop, etc.
Sauf pour mon talk, mais peut-être qu'on passera là-dessus.
Mais voilà, c'était vraiment Kudos à eux,
parce que tu as au moins 700 talks qui sont présentés en deux jours.
Et là, en fait, c'était tout bien géré avec Matrix en base pour discuter.
Et donc, les talks qui étaient diffusés comme ça,
tu avais vraiment une sensation assez agréable d'être pas comme en live.
Mais voilà, c'était vachement bien fait.
Donc voilà.
Oh, cool.
Alors moi, on le disait un peu en off avant,
mais c'est vrai que normalement le Fosdem,
c'est un endroit où je vais depuis 2009 ou 2010,
à peu près tous les ans.
C'est un peu le rendez-vous de tous les gens de la tête,
où je retrouve des anciens collègues,
toutes les boîtes où je suis passé.
Et c'est vrai que j'ai un peu de mal avec les conférences en ligne.
Et donc, cette année, je n'y ai pas du tout participé,
aussi parce que j'étais au ski, il faut le dire.
Mais donc, je n'ai pas participé aux conférences
et non pas non plus à la tienne.
Donc voilà, je suis un novice pour rapport à ton talk.
Et donc, je vais pouvoir être un peu le candid
quand tu vas nous présenter un peu ce que tu as selon ta parlée.
Déjà, pour revenir un peu,
tu as dit que tu avais travaillé sur Flatcar.
Là, à l'heure actuelle,
si je résume un peu de ce que j'ai pu voir,
donc on avait la société qui s'appelait Kingfork,
qui est une société allemande qui travaillait
donc dans tout le milieu de l'open source,
qui a été racheté, finalement, assez récemment
à l'échelle de la Tech par Microsoft.
Comment toi, t'as connu, et on a eu aussi Alban,
il faut que je le dise,
qui dans un numéro dans ton cube,
est venu nous présenter un spectre gadget,
donc qui est un outil de debug autour de Kubernetes,
qui utilise de l'IBPF, etc.
Allez voir, allez écouter cet épisode.
Je fais du cross-média, du cross-podcast.
C'est professionnel, ça, c'est classe.
C'est ça exactement.
Peut-être le lien dans la description.
Allez vas-y, je dis ça comme n'importe quel YouTuber.
Mais donc voilà, on a déjà eu des gens Kingfork,
Alban qui est venu.
Toi, qu'est-ce que tu peux nous en dire,
là-dedans, déjà sur la boîte, parce que c'est vrai,
enfin, moi en tout cas, c'est une entreprise
que je regarde depuis pas mal de temps,
qui est vraiment très cool.
Comment ça se passe, Kingfork,
Flatcar, et même le rachat par Microsoft ?
Ouais, donc, du coup, ce qui est assez drôle,
en fait, c'est que ça va faire deux ans,
deux ans et demi, j'avais uploadé une vidéo
sur YouTube où justement, je présentais Flatcar.
Donc c'était assez rigolo, où je parlais, voilà,
comment déployer un OEF Flatcar,
et puis installer certains trucs dessus.
Et du coup, c'était marrant,
puis j'avais fait cette vidéo bien avant
de rejoindre Kingfork, bien avant de contribuer
à Flatcar, etc.
Et du coup, je trouve c'est marrant,
cette petite détail de temporalité
que je présentais en fait Flatcar,
et maintenant je suis amené à travailler avec,
à contribuer dessus, dans moi.
Et Kingfork, c'est une boîte,
une petite trentaine d'employés,
quand ça a été racheté.
Et en fait, ce qui est assez intéressant,
c'est une entreprise qui résout des problèmes,
qui va se poser sur des problèmes
et se positionner là-dessus,
avec une expertise Linux,
une expertise Kubernetes,
et donc c'est assez intéressant de travailler
avec tous les profils qui sont au sein de cette entreprise,
parce que, ben, t'en apprends tous les jours.
Je pense que j'ai jamais autant utilisé
l'expression, tout d'ailleurs, learned,
depuis que je suis avec eux.
Et voilà, donc plus spécifiquement,
moi je suis dans l'équipe Flatcar,
donc on est 5, 6 personnes, voilà,
à travailler sur le système d'exploitation,
en tant que corps-mainteneur,
et évidemment, on travaille avec la communauté
pour améliorer Flatcar,
proposer des adjours,
et aussi, on va avoir des nouvelles fonctionnalités
sur le système d'exploitation.
Peut-être que je peux présenter rapidement
Flatcar, qu'est-ce que c'est ?
Flatcar, c'est...
c'est plus connu
d'anciennement sous le nom de CoreOS,
donc je vois que t'as un super t-shirt en plus,
on peut pas le voir, mais dommage.
Donc, en fait, qu'il y avait CoreOS,
qui est un système d'exploitation dédié
pour faire rouler du conteneur,
donc ça soit des grosses charges avec des clusters,
ou simplement un conteneur docker,
si t'as envie de faire tourner ton bloc dessus.
Et Flatcar, en fait, c'est simplement un fork,
et ça a devenu le nouveau CoreOS,
une fois CoreOS, donc c'était acquis par Redat,
il y avait eu tout ce débat là,
autour du système d'exploitation,
qu'est-ce qu'il va devenir, etc.
Et donc Flatcar, en fait, c'est issu,
c'est simplement un fork,
qui est maintenant devenu le nouveau
système d'exploitation,
qui est communiste à Ibane,
qui reprend tous les mécanismes de CoreOS,
et en fait, on a encore pas mal d'héritage de CoreOS
au sein de Flatcar,
et c'est assez intéressant quand on parcourt
l'historique Geet,
ou les différents répositorie,
de retrouver des mensonges CoreOS,
ou de retrouver des comites
d'anciens développeurs de CoreOS.
Donc voilà, Flatcar, c'est un système d'exploitation
qui est dédié pour faire rouler du conteneur,
et je me l'avais même dit une fois
dans un meet-up, j'ai trouvé ça intéressant,
c'est plus qu'un conteneur OS,
c'est un Kubernetes OS,
et je trouvais ça assez cool,
c'est vraiment un OS que tu vas utiliser
pour supporter ta charge de conteneur.
Pour ceux qui s'intéressent,
c'est basé sur du Gen2,
donc un autre, une distro Linux.
C'est pour ça aussi que j'aime bien
travailler avec Flatcar, parce que je suis
grand fan de la distro Gen2,
et une des particularités de Gen2,
c'est que tu vas compiler
tous tes packages, donc en fait,
tu ne vas pas récupérer des packages d'un répaul,
tu sais comment dire, tu vas juste récupérer
des espèces de fichiers
qui détaillent comment compiler un package,
et ce qui est assez intéressant,
c'est que tu as accès à toutes les options de compilations
des différents logiciels
que tu installes, et en fait,
ce qui est assez intéressant avec ça,
c'est que tu vas pouvoir désactiver
les options de compilations dont tu n'as pas besoin,
des supports dont tu n'as pas besoin pour un logiciel X ou Y,
et l'objectif, c'est d'avoir
une surface d'attaque qui est minimale
pour le système d'exploitation, parce que tu vas
uniquement livrer dans le système d'exploitation
les logiciels dont tu as besoin, et compiler
avec les options dont tu as besoin, et rien de super plus.
Et puis, une autre
particularité de
cette distro, c'est qu'il n'y a pas de package manager.
Donc en fait, tu ne peux pas
installer avec APT Get,
avec Pacman, avec Yume,
tu ne peux pas installer de package
une fois que tu as distro et déployé,
une fois que ton OS est déployé.
Donc ça, c'est assez intéressant, c'est un peu
contratuitif au départ quand tu commences
à jouer avec, parce que tu dis
vraiment, il y a un moment où t'as le outil
ou t'as le outil, comment est-ce que je peux
l'installer ? Et là, du coup,
c'est la responsabilité
des mainteneurs et de la communauté
de proposer des nouveaux packages,
de les mettre à jour,
de suivre tous les correctifs de sécurité
qui a à faire, pour pouvoir
proposer la meilleure expérience
utilisateur. Donc après, tu as des mécanismes
qui te permettent d'installer
des logiciels au bout de la machine.
Mais voilà, tu n'as pas de package manager,
et en fait l'objectif, c'est de diminuer
ce qu'on appelle le drift.
Je sais pas comment pour dire, en pensant
les cas entre
l'OS que tu installes et l'OS
qui va être mis à jour, à chaque fois.
Donc en fait, l'objectif, c'est d'oublier
que tu as un signe d'exploitation
et que tu utilises juste pour déployer
ta charge de confinière dessus.
Et voilà, je pose la question.
Oui, non, c'est pas moi, je vais pouvoir
raconter un peu aussi mon histoire par rapport à ça.
Donc moi, j'ai commencé à utiliser CoreOS
en 2014-2015
justement pour du Kubernetes à l'époque.
Donc on est vraiment dans des versions très récentes.
CoreOS qui était, enfin c'est assez drôle,
c'est d'ailleurs un fork de ChromeOS.
Donc c'est ChromeOS
qui se base sur Gantu pour son aspect build.
Mais en fait, c'est un ChromeOS
sans Chrome et avec Docker en plus.
Si jamais on résume
avec du systemd.
Donc à l'époque, c'était pas vraiment
un système qui était fait pour Kubernetes.
C'était fait pour faire du conteneur.
Ils avaient même développé un système
dédistribué qui s'appelle Fleet.
Rien à voir avec le Ransher Fleet
d'aujourd'hui, mais c'était un
système dédistribué pour avoir
des units de système dé
qui vont pouvoir tourner sur plusieurs noeuds à la fois.
Et en effet, oui, voilà, c'est un système
immutable, ou immuable.
Ça dépend si on veut faire du franglais
ou pas.
Et en effet, tout ça, c'est possible
uniquement parce qu'on a des
conteneurs. Parce qu'en fait,
la base, le socle, lui, est complètement immutable.
Pas de package manager, mais en fait,
derrière, comme on peut faire tourner
des conteneurs, on peut avoir accès à
ce qu'on veut. Ce qui fait qu'après, on peut
avoir des trucs assez cool, la base de Toolbox
qui avait été aussi créée par CoreOS
pour faire en sorte d'avoir
tous les outils du TCP dump,
des choses comme ça, dont on va avoir besoin
pour débugger nos workload.
Et donc nous, on avait fait
déjà à l'époque, donc en 2015,
on avait fait du CoreOS
Bar Metal, plus
du Kubernetes au-dessus
sponné via Flit. C'était un peu ça le but.
Et après, à l'intérieur du Kubernetes, on met
l'open stack. C'est une stack
classique dont j'ai parlé assez souvent,
mais qui était assez cool
l'un de dans. Et gros, gros
avantage de ce système, donc
Sandrift, c'est-à-dire qu'on va
limiter l'effet snowflake,
l'effet fleconneige.
C'est le système de
release par Channel,
qui est complètement érité
de Chrome et de toute l'expérience
de Google là-dessus du déboulement
qui est donc d'avoir des Channel
enquelles on s'abonne, Stable, Beta,
Edge,
qui vont permettre d'avoir des...
Il n'y a plus le Edge.
Donc c'est Alpha, Beta, Stable et
LTS.
Ouais, donc c'est ce qui correspond à
la même chose quand on l'utilise,
mais ce qui est vraiment cool
l'un de dans.
Sachant que,
point intéressant, donc le protocole
qui est utilisé derrière, c'est OMA
pour les mises à jour, on peut
avoir son propre système
de release, soi-même, qui
est un système en fait, à la mi-chemin
entre la release et l'asset management
où on va pouvoir comme ça avoir la
vision de son parc et des mises à jour
de son parc. Avant, il y avait Core Roller
qui était le logiciel fait par CoreOS
pour pouvoir gérer ça. Et maintenant, vous avez
un logiciel qui s'appelle
Nébraska.
Exactement, Nébraska sur le Cajet.
Quelques contributions maintenant.
Ouais, c'est cool.
Voilà, des contributions de merde
pour l'instant, mais bon,
ça me gavait à le builder, donc souvent
j'ai refait le système de build, comme d'hab
quand j'arrive sur un projet. Mais voilà,
un système que j'utilise, et alors ça on pourra
en discuter à la fin dans le next.
Mais voilà, voilà un peu pour
tout l'écosystème dont on a parlé là-dedans.
T'as pas trop parlé du
rachat par un Microsoft si jamais
on... voilà comment ça se place
pour vous en interne, parce que c'est...
Alors, ça c'est
assez intéressant
comme point. Du coup, pour l'instant
nous, ça n'a pas changé grand-chose. Donc ça
c'est assez intéressant.
Voilà, Flacar reste
comme UnityDriven.
Il n'y a pas d'influence
pour l'instant de la part de Microsoft
sur Flacar. Et donc voilà, donc ça c'est
assez intéressant parce que nous
l'équipe Flacar, on n'est pas impactés là-dessus.
Alors évidemment, maintenant tu vas voir
la collaboration qui va se faire avec Microsoft
pour travailler avec eux sur
des sujets autres, des diverses variés.
Donc toujours dans... bien sûr dans l'écosystème
Linux Cloud.
Mais voilà, de notre côté
Saint-KidVolk, ça n'a pas changé grand-chose
et ça c'est vraiment intéressant.
Quand t'avais rachat d'entreprise, t'as toujours peur
en fait qu'il y ait
des divergences qui se font
au sein de l'entreprise rachet.
En fait là, pas du tout. C'était assez naturellement.
Voilà, pas de grand changement.
Donc ça c'est cool.
Et puis moi je suis content
d'en vrai, vraiment que l'aspect
de Flacar soit préservé, conservé
et que ça continue dans ce chemin là.
Donc c'est... voilà.
Google a
son container OS.
Azure, enfin
Amazon a, je ne sais plus comment il s'appelle
mais à peu près pareil.
container OS.
Bottle Rocket, je crois.
Ouais, c'est ça. Donc pour utiliser
Fire Rocket.
Oui, c'est ça.
Firecracker.
Et je ne sais plus si Azure en a un.
Est-ce que justement Flacar
pourrait devenir le container OS
d'Azure ou pour Acad?
Alors Azure
de leur côté, ils ont
Marineur.
T'as peut-être entendu parler de fait.
Donc voilà, c'est
l'équivalent container optimized OS
au niveau d'Azure. Donc ça c'est dédié
Azure pour faire rouler du container
workload sur Azure. Flacar c'est
agnostique. Donc tu peux faire rouler du Flacar
sur du bare métal, tu peux faire rouler du Flacar
sur Amazon, sur Google,
sur KVM si tu as envie.
Enfin tu peux vraiment un peu faire rouler
partout et c'est quelque chose qui continue
qui va continuer à être préservé.
Dans tous nos tests
on teste ces plateformes
justement. Donc
les différents cloud private provider
par nom et puis le bare métal.
Donc pour l'instant Flacar, ça reste
comme une des arrivées, et cloud agnostique.
D'accord mais ça aurait pu devenir
justement la base de Azure
d'AKS. A quelques mois après
à mon avis avant Marineur,
enfin avec un rachat 2 ans avant
c'était ça devenait un an avant peut-être.
Ça aurait pu
voilà, il faut voir après
les conditions à ce moment-là
parce que effectivement
ça aurait pu devenir le de facto
l'OS utilisée sur Azure.
Mais sûrement que
le souhait de garder ce côté
communautaire et le souhait de garder ça
agnostique aurait peut-être
empêché justement que ça soit, ça
devienne le système d'exploitation
pour Azure. D'accord.
Et donc
de combien la parlé, t'as fait un talk là-dessus
donc en lien avec Flacar puisque c'est ce que tu fais
au quotidien. Est-ce que tu peux nous en dire
plus justement sur talk de quoi t'as parlé
et puis même un petit résumé dedans ?
Ouais, avec plaisir.
Donc
ce talk-là c'était vraiment dédié
sur les tests.
Alors en fait, comme tu l'as dit toi-même
c'est un système de release
par Channel, donc Alpha, Beta, Stable.
Alpha étant
tout ce qui est nouveau, qui est chippé
donc
des nouvelles fonctionnalités, des nouveaux packages etc.
ça passe par Alpha qui est validé par Beta
qui est validé pour les arrives en Stable.
Bien évidemment, avant chaque release
de chacune de ces channels
de ces channels, on va tester
le système d'exploitation. Donc qu'est-ce que ça veut dire
tester ? Ça veut pas dire on boot un 2
on regarde si ils boot et puis voilà
on chip. Donc là il y a vraiment
toute une batterie de test
qui sont roulées, des tests automatisés
bien sûr. Et en fait
on va tester, bah voilà, est-ce que
Docker ça fonctionne bien ?
Est-ce que l'ASLinux ça fonctionne bien ?
Est-ce que voilà
on essaie en fait de
couvrir un maximum de
cas d'utilisation de scénarios pour pouvoir tester
le système d'exploitation et identifier
d'éventuelles régressions, d'éventuelles bugs
ça nous a permis de
d'identifier, j'en pense j'avais fait une migration
d'OpenSSL, enfin une migration in update
d'OpenSSL sur OpenSSL3
et en fait cette suite de tests
nous a permis d'identifier
une régression du côté
d'OpenSSL. Donc ça c'était assez intéressant
parce que non seulement ça teste l'OS, mais du coup
ça teste aussi les paquets
qui vont avec et donc ça permet aussi, voilà, toujours
d'être dans ce petit communautaire
de pouvoir faire remonter des problèmes upstream
avec la suite de tests flatkya.
Donc c'est tout le classe
qui est vraiment dédié là-dessus, sur
qu'est-ce que c'est un test ? Comment est-ce qu'on teste
flatkya ? Comment ça s'intègre
dans le process de release
de flatkya ?
Et puis voilà comment c'est fait. Donc en fait
c'est un framework
qui est utilisé, donc c'est un framework
qui est fait en go, qui est développé en go
donc tous les tests sont développés
en go et en fait voilà
c'est simplement
grossièrement, ton framework
qui va s'occuper de déployer une instance
que ce soit sur un cloud provider, que ce soit localement
avec QMU
déployer cette instance, la provisionner
avec du ignition
et donc ça c'est pour faire
la provisioning initiale
et donc ensuite tu vas faire rouler tes tests
que toi tu vas écrire, en exemple
faire un Docteur Don
Alpine Sleep Infinity
et puis tu vas t'assurer
que tu as plein de conteneurs avec Alpine
qui roule et qui fait un Sleep Infinity
et donc c'est ce genre de tests
qu'on roule, donc tu en as des simples
comme celui que j'ai mentionné et tu en as
un peu plus complexe qui se rapproche
plus à ce qu'on appelle du test d'intégration
où tu vas réellement déployer
un cluster Kubernetes dans
ton scénario test
et tu vas déployer des potes dessus
tu vas regarder avec différents CMI
du Cilium, du Flannel, du Calico
et tu vas regarder que tout fonctionne bien
et donc ça ça te permet en fait
tu peux pas tout couvrir évidemment
mais ça te permet en fait d'avoir une idée
de oui ça fonctionne bien
et il n'y a pas de régression là dessus
et on ne risque pas de péter quelque chose en déployant ça
donc voilà le talk est...
Les tests que vous avez rajoutés justement
ils sont toujours en fonction
de problèmes que vous avez eus
parce que justement
cette couverture de test vous allez la faire
au fur et à mesure, genre vous avez un problème
vous rajoutez un test, ça va être comment
la volonté de rajouter un test particulier
Alors l'objectif
c'est d'augmenter bien évidemment
la couverture de flat-card
ce qui est compliqué c'est qu'on n'est pas
en mesure de donner un indicateur
c'est compliqué de dire 80% de l'OS
est décelé parce que vu que c'est un OS
tu fais ce que tu veux avec
tu ne peux pas tout couvrir
donc comme tu l'as dit il y a 2 cas de figure
soit on a un bug utilisateur à client
un utilisateur pardon
qui fait remonter un problème, ça ne marche pas
c'est ça, et on essaie d'identifier
si on voit que c'est un problème
de notre côté on va rajouter
un test pour éviter de la régression
et sinon
bâtir simplement
fonctionnellement ou des initiatives qui sont prises
bâtir ce parti là elle n'est pas testée
écrivons des tests là-dessus
puis faisons les rouler
donc voilà, tu as 2 cas de figure
soit il y a un incident qui est relevé par la communauté
soit tu as voilà
quelqu'un qui a
un demande en anglais
qui va te dire bah ouais, ça serait bien d'avoir un test
là-dessus
ça prend combien de temps à peu près là
à l'heure école de faire tourner tous vos tests
on va essayer d'enlever un peu la partie spawn cloud
parce qu'elle peut être un peu
mais à peu près ça va être combien à l'heure école
de jouer ces tests
alors si tu roules les tests
sur une bonne machine
localement
on va dire que tu les roules en parallèle
donc faut que tu aies une bonne machine
dans notre série ça prend
30, 40 minutes
à peu près, à rouler tous les tests
mais comme tu l'as dit très bien
sur d'autres providers
ça va prendre 10 heures par exemple
sur Equinix Metal parce que là
c'est du arme qu'on va tester
et tu as aussi le temps de provisioning qui est beaucoup plus lent
parce que c'est du Pixiboot
donc en fait là tu rajoutes beaucoup plus de temps
et c'est un sujet sur lequel on travaille
justement d'être en mesure de diminuer
le temps que prennent
l'exécution de la totalité des tests
parce que on va en rajouter encore des tests
donc en fait si ça prend 50 heures
à rouler tous les tests, c'est pas agréable
et puis ça impacte aussi
forcément le process de release
parce que tu vas le rallonger
parce que tu dois attendre que tes tests
t'es fini pour décider de la réalise
là alors quel est le framore que vous utilisez en Go ?
c'est un framore qui existe déjà
vous utilisez du Go Test
c'est plus le nom d'un des framores
qui sert à faire des tests comme ça
c'est quelque chose de maison
héritage de CoreOS
une fois de plus on retrouve
des héritages à quelques endroits
ça s'appelle Kola
qui fait partie d'une toolbox
qui s'appelle Mental
et Mental en fait c'est un ensemble d'outils
qui vont te permettre
d'oublier des images de plate-car
sur un object storage
de créer différents assets
autour de plate-car
et en fait
Kola c'est un framore
qui est en Go
qui essaie d'imprimter un petit peu la philosophie du framore
que le testing
de Go
de base
mais c'est quelque chose qui est maison
qui utilisait encore pas FEDERAC
CoreOS de leur côté
et auquel on contribue
tous les jours
c'est cool
et justement je vous en dis directement là-dessus
les rapports avec
FEDERAC
comment ça se passe
parce que si jamais on résume un peu
CoreOS
qui était l'entreprise du même nom
enfin l'OS et l'entreprise du même nom
a été acheté par Gredat
qui lui-même a été acheté par IBM
c'est vrai
et puis des gens de CoreOS qui avaient
sur un panneau
0 jours depuis la dernière acquisition
où ils avaient des compteurs comme ça
où ils se faisaient racheter
en l'espace d'un an ils se ont fait racheter deux fois
donc ça a pas mal changé
et donc on avait
historiquement donc
Gredat qui bien sûr fait toujours
à sa sauce avait le projet Atomic
qui était donc un OS
pareil pour conteneurs
mais qui utilisaient
TRI-FS
c'était vraiment
leur base sous-jacente
qui adore
visiblement
puisqu'ils utilisent aussi
sur
l'équivalent de SNAP
mais version Gredat flat pack
qu'ils utilisent aussi cette technologie
donc c'est TRI-FS
mais je me
ne le serai pas l'un de dents
et donc après mais qui avait vraiment
assez mauvaise réputation Atomic
et en fait on a eu
l'espèce de CoreOS Washing
où Atomic a
mergé un peu avec CoreOS
et est devenu ce nouveau Fedora CoreOS
quelles sont les rapports que vous avez avec eux
comment ça se passe
c'est assez intéressant
parce que dans les deux cas
c'est très communautaire
donc en fait on est amenés à discuter ensemble
sur certains sujets
j'ai par exemple en tête le sujet
Ignition
tout à l'heure j'ai parlé un petit peu de ça
donc c'est un outil qui permet de provisioner
ton instance Flatcar
au moment du bout
donc en fait ça te permet d'installer
des binaires si tu peux récupérer
ça te permet de créer des fichiers
sur ton système d'exploitation
un écart en tête laudinite
voilà
et en fait Flatcar
a une espèce de petite dette technologique
à ce niveau là
c'est qu'on est sur Ignition qui est assez vieux
qui maximum supporte la config v2
alors que maintenant
c'est la normalité
c'est v3
donc en fait là
toujours dans cette optique Flatcar de préserver
d'éviter d'impacter le moins possible
les utilisateurs en introduisant des breaking changes
ce qu'on a décidé de faire c'est de
upgrade Ignition
et de supporter et la version 3 et la version 2
alors que Fedora CoreOS
et Ignition supportent exclusivement la version 3
et ne supportent pas la version 2
donc ça c'est assez intéressant parce que du coup
on a été amené à travailler avec les développeurs
de Ignition donc du côté
Redat pour échanger un petit peu
autour de ça la faisabilité du projet
donc évidemment c'est toujours open source
donc c'est via des issues ou via des pro-request
donc on a des très bons termes avec eux
et c'est assez intéressant
de continuer en fait à maintenir ça
parce que au final ce qu'on veut c'est
fédérer
une communauté d'utilisateurs autour de ces systèmes d'exploitation
et on voit pas ça comme des compétiteurs
mais on voit plus ça
dans le monde open source et on donne le choix
aux utilisateurs de pouvoir choisir
quel sont leurs systèmes d'exploitation
donc ça passe aussi par une collaboration
avec les mainteneurs d'aussi différents systèmes
Est-ce que tu sais d'ailleurs
si ils avaient un talk au Fosdem
j'ai pas vu
de Fedora CoreOS
ou
de talk
relative à ça
je pourrais pas dire mais de même moi en diagonale
j'ai pas vu de
parce que historiquement
CoreOS a toujours été présent au Fosdem
moi personnellement la première fois que vous m'avez vu en physique
c'est justement au Fosdem 2015
où on est allé les voir
parce que février 2015
on va les voir en leur disant
on a l'idée de mettre du Kubernetes
sur
donc on veut mettre
OpenSack sur Kubernetes
donc on allait voir les gars de CoreOS
qui étaient à ce moment là
les gars les plus
les plus à l'aise sur les conteneurs
et ils nous ont un peu regardé
mais nous on met du Kubernetes dans OpenSack
mais jamais l'inverse
ils étaient présents
ils avaient un stand
ils avaient pas mal de talk
qu'ils ont pu faire
je pense qu'ils ont été vraiment intéressés
par l'idée et la question que tu leur as
oui, puisqu'ils ont fait Stackarnetest un an après
donc après, un an après
on avait Austin
donc c'était assez drôle
moi je suis parti de Claude Watt
à ce moment là
mais j'en connaissais qui était allé chez Austin
à l'OpenStack Summit d'Austin
et qui m'a envoyé des messages en direct
en me disant les gars ils sont en main stage
la keynote c'est CoreOS
qui présente Stackarnetest
leur stack Kubernetes
pour installer
de l'OpenStack
donc voilà, c'était assez drôle
mais après c'était vraiment quelque chose qui était dans l'air du temps
en fait et à l'heure actuelle
on a vraiment des technologies
qui sont vraiment dans l'air du temps
et qui se font un peu partout
de manière assez artisanale
et qui à un moment, c'est comme Kubernetes dans Kubernetes
ce système d'installer
des clusters Kubernetes
tout le monde utilise cette solution là
et personne l'Open Source
parce que je sais pas pourquoi d'ailleurs
mais c'était dans l'air du temps
mais c'est pour ça que je voulais savoir
s'ils avaient toujours ce côté communautaire
chez CoreOS via 2 rachats
qui peuvent être vraiment destructeurs
en termes de culture
et c'est ce que je te disais tout à l'heure
c'est que le rachat à Microsoft quitte vol
justement je suis content parce que c'est un préservé
un peu la culture de quitte vol
et cet engouement pour résoudre des problèmes
être communotif first
donc voilà
et donc seulement là vous aviez donc plusieurs
j'ai vu que vous aviez 5 talks au Fosemann cette année
donc les néo CoreOS
à dire ceux qui trustent l'un d'entre nous
mais tant mieux c'est vraiment
fait du bon boulot
c'était quoi à peu près les talks que vous aviez
alors on avait un talk
pour parler un petit peu de
tout ce qui est sécurité
un peu au niveau de ton système d'exploitation
donc c'était pas forcément dédié flat-card
c'était illustré avec des exemples de flat-card
c'était
parler de SELinux, de sec comp,
de audit, enfin tous les petits
systèmes et les outils d'écosystème
pour qu'ils vont permettre de sécuriser
un petit peu ton système d'exploitation
pour faire rouler du conteneur
il y avait...
C'est important de le dire, c'est qu'on a des outils
quand on dit les conteneurs c'est pas sécurisé
il faut voir qu'on a des outils à l'intérieur du kernel
qui permettent de sécuriser
les conteneurs, c'est pas Yolo
Yolo j'ai accès à toutes les fonctionnalités du kernel
même si la couche
de ces groupes se fait rouer
on a encore d'autres outils
derrière si ils ont bien été configurés
qui sont là pour
mitiger les problèmes
C'est pas Yolo j'ai accès à tout
en permanence, comme souvent
certains le croient
sur des conteneurs
C'est important de le rappeler
J'ai déjà vu ça en entreprise
où des personnes vont être un peu
réticentes à l'idée de déployer du conteneur
parce que non c'est pas sécurisé
c'est pas Yolo comme tu dis
Et même d'ailleurs ça peut même plus sécuriser que la plupart des systèmes
où on fait tourner
une vieille unit de système D
sans trop
d'isolation par rapport à ça
le conteneur permet justement d'avoir
encore plus d'isolation parce que au moins
le système sait où doit tourner
le
système, enfin où doit tourner
tout le workflow
donc on a vraiment quelque chose
qui peut être plus sécurisé
je mets un peu parce que
c'est tout un sujet
justement cette isolation
mais c'est possible
on va parler de choses
C'est possible et tu le dis très bien
c'est tout un sujet, c'est très complexe
l'environnement et je pense que ça
nécessiterait, il y a des conférences dédiées
là-dessus justement sur la partie sécurité
parce que t'as plein d'outils qui existent
plein de frameworks
de solutions
pour sécuriser un peu ton environnement
et du coup c'est pour ça qu'il y a bien un truc là-dessus
qui était juste de reparler un petit peu
les solutions un peu standard qui existent
Linux pour sécuriser
un peu et apporter un petit peu de sécurité
autour de ça
donc c'était un peu une nouvelle vue ou introduction
autour des outils
il y avait aussi un truc sur
Flatcar comment
contribuer à Flatcar
c'est à dire comment bider
une image Flatcar localement
donc Flatcar met à disposition un SDK
et en fait avec ce SDK tu vas pouvoir
étendre le système d'exploitation en rajoutant
des packages, en mettant un jour
des packages
en mettant des nouvelles fonctionnalités
de la configuration
et en fait tu vas pouvoir bider localement
ton image et puis tu vas pouvoir après le plo
de la tester
c'est un truc là-dessus
comment est-ce que tu peux contribuer à Flatcar
ça c'est cool, c'est même plus que contribuer
je peux avoir ma propre image de manière facile
sans avoir besoin de forquer tout le système
parce que je sais que
autre expérience avec CoreOS
chez Criteo on a essayé de faire un projet
qui s'appelait Coco, Kubernetes
on CoreOS
et voilà
c'était bon voilà on avait même
les déguisements etc
et un des problèmes qu'on a eu
à un moment alors c'était sur
sur la couche
d'authentification, SSSD
ou quelque chose comme ça où il y avait des options
de compilation qui n'était pas forcément bien
en tout cas nous dans notre cas, lien avec le DNS
je ne me souviens plus
il faudrait que j'aille voir l'issue que j'avais fait
c'était toujours DNS
il y avait un lien avec l'AD
le DNS
c'était pour avoir
l'authentification
quand on se connectait sur un CoreOS
de pouvoir avoir l'authentification via l'AD
de pouvoir récupérer la clé SSH
donc que la clé SSH soit dans l'AD
et que également on arrive
à avoir le champ pour savoir quelle est l'image
de conteneur qu'on va abouter quand la personne
se connecte, donc ça veut dire d'être directement
dans un toolbox, directement par une image
que la personne pouvait configurer
et on avait un problème dans notre cas
et on avait essayé de faire une contribution
et je crois que ma contribution avait fait péter le build
pendant quelques semaines
et d'autre côté ça me fait
penser à ça, c'est dans notre cas
localement, dans notre contexte
ça marchait plutôt bien
mais c'est vrai que rebuilder entièrement tout le système
en plus on était en hackathon à ce moment-là
c'était un enfer
on n'avait pas vraiment le temps donc on avait essayé de faire notre rue
moi j'avais vu le problème, j'avais commencé à faire un patch
en disant le patch il devrait marcher
mais en gros j'avais pas la capacité de pouvoir le tester
et donc là ce que tu me dis c'est que maintenant
on peut avoir un système en gros de
layering, c'est à dire gérite de tout
flatcard et je rajoute mon petit patch
exactement
et donc en fait
flatcard on va dire qu'il y a 3
répos importants
pour build des flatcards donc t'as
CoreOS Overlay, Portage Sable
et ce qui est, donc ça c'est le nom des 3
Répaulitub et en fait
si tu veux commencer à t'amuser
à bidouiller un petit peu, ça va être
simplement prendre l'état de ces 3 branches
à une version précise ou à la version
main et ensuite
avec le SDK, tu vas juste rouler 2 commandes
ça va builder les packages
et build the image
et le tout, le tout total ça te prend
40 minutes peut-être
au total pour builder une image et avoir
une ISO qui est disponible sur ton système d'exploitation
que tu peux tester
donc tu vas vraiment hériter de
ce qui est existant en prod et ensuite
tu vas rajouter si t'as un patch
si t'as un paquet de gérajouté
ou une modification à faire donc ça c'est assez intéressant
parce que ça te permet simplement de pouvoir
t'amuser avec
soit si tu veux contribuer
faire quelque chose upstream
soit si tu as envie
t'as vraiment des besoins propres à toi
qui ne sont pas nécessairement
en mesure d'être mis upstream
parce que ça ne intéresserait pas tout le monde
tu vas pouvoir le faire localement
ou pas
un module à compiler
un module à compiler
quelque chose comme ça
je connais que certains ont des sécurité qui ne sont pas fait par Sudo
ils ont besoin de carnell
de module propriétaire
à rajouter dans leur carnell
potentiellement ça peut servir
pour la petite histoire
sur le chat communautaire
t'avais même une personne qui avait réussi
je crois à installer tout la suite
ils sont 11 sur flatcard
je ne sais pas pourquoi ils en avaient besoin
mais tu es super intéressé
tu avais coulé le module carnell
installé et coupadé
donc les drivers
la couche logicielle aussi
ça c'était intéressant
mais on a aidé à faire ça
mais là tu vois c'est pas quelque chose que tu vas être en mesure de mettre upstream
parce que ça ne t'intéresse personne
d'avoir du X11
qui tourne sur flatcard
question là
c'est un petit sujet
c'est une lubie personnelle
est-ce que vous avez
comme intention de passer
à des architectures x86-64
un peu plus récentes
donc il y a eu une des compositions
en x86-64 normal
la v2, la v3 et la v4
qui à chaque fois rajoutent des instructions différentes
c'est une grande discussion
dans ARCH par exemple
de passer soit tout le monde en v2
donc avoir des instructions qui n'ont pas 15 ans
mais qui n'ont non 10
et est-ce que vous avez l'intention
d'avoir plus que du x86
mais du x86-64
un peu plus récent
donc avec potentiellement
des paquets compilés
avec des instructions
un peu plus que celle de
l'atlant 64 de 2000
alors ça j'ai aucune idée
pour être honnête
ce que tu peux faire c'est ouvrir une issue
sur youtube à l'époque flatcard
mais j'essaye de visualiser
un petit peu à quel niveau
ça interesse
au niveau du carnet et au niveau
au niveau de toute ta couche
à l'heure actuelle la plupart des distributions
sont extrêmement pessimistes
elles build du x86-64
tel que ça a été formalisé par les premiers atlants
de 64, c'est les mêmes instructions qu'il y a dedans
ce qui fait que si tu as des nouvelles instructions
à SSE, si jamais tu as du AVX
alors encore pire de la AVX 512
le compilateur
ne compilera jamais avec ça
c'est à dire que le compilateur GCC est configuré
pour une architecture extrêmement vieille
et en gros ce qui a été créé il y a pas longtemps
c'est qu'ils ont créé des
micro architectures
je crois que c'est le nom qui a été donné
et de dire on va décomposer le x86-64
donc le legacy x86-64
on va faire v2
qui rajoute des instructions sse1
et sse2
et ensuite on a
les instructions x86-64 v3
qui rajoutent encore des instructions sse
et le v4 qui rajoute je crois les AVX
256 et 512
512 je suis même pas sûr
mais en gros ça
pour permettre demain de pouvoir
builder des distributions
qui soient beaucoup plus rapides on parle beaucoup de greenitie
alors actuellement il faut voir que
il peut y avoir des différences de build très importante
l'un de dents
et de se dire d'avoir tout mon système
donc aussi bien le kernel mais également toute la stack
autour qui soit buildé
avec une architecture donc en fait potentiellement
je pourrais aller chercher mon flatcat
et dire je vois un flatcat
compatible avec telle version
des processeurs telle version
et me dire que comme ça j'ai
un build un peu plus
donc si je comprends bien
alors du coup c'est une option
que tu vas passer à gcc et il faut que ton hardware
le supporte aussi
exactement et donc potentiellement en fait il faut que tu connaisses
l'architecture de tes processeurs
est-ce que c'est du nea lm est-ce que c'est du skylake
etc. dans les architectures
intel et qui vont permettre de dire comme ça
et l'avantage c'est qu'on a un peu standardisé
on n'a pas juste fait des architectures que pour
une intel mais on a standardisé
pour dire comme ça on peut savoir même chez AMD
intel ou n'importe qui qui ferait du x86
ce que ce serait donc voilà
c'est juste une question personnelle parce que voilà
j'aime bien les petites optimisations comme ça de genre de choses
et quand on est dans des
des infrastructures un peu des kernels
un peu immutable comme ça
distribution immutable ça pourrait être assez cool
d'avoir vraiment en plus
d'être dédié conteneur c'est d'être en plus dédié
performance
et je sais que notamment clear le projet
clear linux est très en pointe
là-dessus puisque justement porté par intel
ou pour le coup ils ont toutes les instructions
de complication les plus batards possible
d'activer pour pouvoir
permettre ce type
d'usage. Et bah écoute c'est super intéressant
je regarderai
pour toi ça te rajoute des tests
ça te rajoute x test
étant potentiellement un bug de
compilation d'une optimisation gcc
ouais du coup
je pense qu'on a
les options de configuration par défaut
j'ai cc plus quelques custom
je pense par dessus mais voilà on n'a pas encore exploré
cette voilà donc c'est assez intéressant
avec que tu aimes de ça sur la table
ouais et arch notamment là maintenant
à commencer à se dire que peut-être ils allaient passer
par défaut à la v2
on se disant bah la v2 c'est
des processeurs qui ont 10 ans
normalement notre système
ne marchera pas sur des choses beaucoup plus vieux
que ça. C'est notamment
une idée
qui en vogue là dessus
de passer l'instant ou alors d'avoir du multi-arch
ça veut dire d'avoir du v1 et du v3
notamment.
Ouais c'est intéressant surtout si ça s'inscrit comme tu disais
dans la démarche un peu grinaïti
ça fait l'entièrement du sens
je pense que t'avais peut-être
des applications de sécurité aussi
il peut être plus intéressant si je sais pas si ça vaut
en jeu. Un peu
tu utilises des instructions mais pas tant que ça
c'est vraiment au niveau de l'architecture
lindent qui est utilisée
non sur les prébletiques de sécurité ça va vraiment
être plutôt les options
de mitigation que tu vas mettre dans ton gcc
de
un peu random testac
pour faire en sorte de pas, enfin voilà toutes les options
de sécurité que tu vas pouvoir mettre dans les options de compilation
lindent mais en fait
souvent c'est compliqué pour les distributions généralistes
du type d'Ebian etc de le mettre
parce que quand elles le mettent elles le mettent d'un seul coup pour des milliers
de paquets en même temps
et donc c'est extrêmement compliqué pour elles de
le mettre en place
là où dans une distribution
qui fait à la fin 200-300 méga
ça doit être à peu près ça le flat-k
enfin en terme de nombre de logiciels
d'avoir une stack beaucoup plus réduite
ça peut déjà être pas mal. Après il y a tout un sujet
malheureusement sur les conteneurs où
je peux pas dire
je veux un conteneur de type x7664v2
c'est à dire tout le
multi-arch
il ne supporte pas encore la micro-architecture
moi j'aimerais que mon processeur
par exemple il dise voilà je suis combative v4
bah si j'ai un conteneur v4 je le prends
sinon je prends un v3, sinon je prends un v2
sinon je prends x8664
enfin AMD64 comme on l'appelle souvent
comme ça
malheureusement il n'y a pas encore cette stack là
donc ça c'est encore un autre sujet dans les conteneurs
alors que ce serait extrêmement
adapté pour ça d'avoir exactement le conteneur
compilé avec les bonnes options
et qui peut faire des différences
très importants dans certains cas
vraiment
c'est sur certains load
sur certains workload
notamment tous ceux qui font du machine learning
tout de suite la différence
quand on commence à utiliser
les bonnes instructions de matrice
et de virgule float en tout
ok ouais vachement intéressant tout
ça m'a élevé un tout
ouais ça c'est
ma petite lubie perso que j'essaye de faire
mais c'est des choses que j'aimerais
que j'aimerais que ce soit un peu plus pris en compte
ouais c'est ça
j'en parle là dans devops
tout le monde saura que ça existe
qu'on peut optimiser son logiciel
avec des options de compilation
et qu'il peut avoir un impact
au final c'est important
ok donc voilà
et donc ouais on disait donc
cette partie sécurité
la partie contribution est-ce que tu souviens d'autres talks
ouais il y avait un talk
sur tout ce qu'il a parti
il y a aussi immulabilité
slash imutabilité comme il y a dit
donc justement
qu'est-ce que c'est flatcar à ce niveau là
comment s'est géré au niveau
du système d'exploitation
donc en fait je parlais d'oestri pour
le raccord west
c'est pas tri fs comme j'ai dit c'est oestri en effet
flatcar c'est un modèle
différent c'est du ab partitioning
donc c'est vraiment
le système d'exploitation qui est installé
sur une partition donc tout le slash usr
qui est installé là et quand t'as une update
qui est fait bah c'est écrit sur
une partition B et ensuite tu switch
au bout de A à B
donc ça te permet voilà d'abord de pouvoir rollback
si t'as mis à jour
ici à création un petit problème
et ça te permet toujours de conserver
en fait la n-1 sur ton disque
alors que oestri
oestri on a quelque chose où en fait on a un différentiel
qui est fait en fonction
c'est presque du guide scaricature
c'est un comédit
et puis
t'as cette approche là qui est vachement intéressante aussi
d'ailleurs il y a eu des questions
sur pendant ce talk
là ou
quel est le mieux en fait est-ce que le mieux c'est de faire
du ab partitioning est-ce que c'est de faire du oestri
t'as même avec B2FS
tu peux faire aussi des choses comme ça
et donc t'avais une question qui était avec
Kai donc la personne qui a donné le talk
qui a répondu bah il y a de l'aventure
t'as pas de choix miraculeux
t'as toujours les avantages inconvénients de l'un
et de l'autre donc
donc je vous invite à aller voir ce talk qui était assez intéressant
sachant qu'il y a des solutions
aussi même qui sont un peu
encore différentes
puisque en fait la plupart de temps l'avantage de oestris
c'est qu'on va pouvoir télécharger que le différentiel
c'est surtout pour délanger les... c'est incrémentale
voilà on a un incrémentale
on a le gel
cacink qui a été fait par l'enart poltring
qui permet de
faire en fait en gros je te donne un fichier distant
je te donne un fichier local
et en fait quand je vais aller télécharger le fichier distant
je vais télécharger que la différence
et il s'est le faire même sur des os
et ça c'est un truc je crois qu'il y avait
une issue dans le repo core os maintenant
pour justement utiliser cacink pour en fait
créer la partition B en utilisant
la partition A
et donc en fait en permanence tu vas les télécharger que le différentiel
donc même si le blob est extrêmement grand
mais qu'il y a juste un fichier qui change
en fait il va recréer la partition B
en utilisant seulement le diff
de la partie... du distant
en utilisant la partition A
et donc on a en fait un espèce de mélange entre
les deux qui permet d'avoir un système simple
donc auditable assez facilement plus que
au estri qui est une énorme usinagase
tout en gardant
un peu ce système de différentiel
assez simple et donc cacink
fait ça c'est son but lindant
et il marche aussi avec
des fichiers... des fichieros
donc vraiment tu peux lui donner
d'un côté la partition A
et de l'autre côté un binaire
et il fera tout seul le différentiel binaire
à l'intérieur
en comprenant voilà
c'est aussi possible d'avoir ça mais ça c'est dans le processus
de réalise du côté
du côté de la distribution
Bah au niveau de
SystemD tu as aussi SystemD6Ext
qui commence à faire un peu du bruit
à cette égoula donc ça aussi flatcard
il y a une issue qui est ouverte sur le repository
pour voir justement si on pourrait hériter
ce mécanisme non pas pour remplacer le
partition A B mais pouvoir te permettre
d'étendre un peu ce caractère
yutable du système d'exploitation
si tu veux faire rouler ton propre
container on time, si tu veux
faire rouler une version différente de docker
que celle qui est chipée
pour l'instant avec flatcard tu as des mécanismes
qui te permettent de contourner ça mais c'est
des mécanismes home made on va dire
donc l'intérêt d'utiliser le SystemD6Ext
c'est justement pour parier à ça et puis utiliser
des trucs upstream des techniques
que tout le monde utilise
et l'emerger à flatcard
ça aussi c'est des choses qui sont
en cours
on regarde comment est-ce qu'on pourrait
intégrer ça et comme d'habitude c'est public
si vous avez envie de participer
à la discussion n'hésitez pas
et d'ailleurs là vous parlez de docker
vous utilisez toujours, vous avez encore le
démon docker dans flatcard ou est-ce que vous êtes passé
à du container D ou un autre CRI
alors du coup
tu vas avoir container D
qui est chipée donc t'as ça
et avec
le système que je te parlais
Torx c'est en fait
toutes tes images de docker
toutes tes commandes de docker sont passées
d'abord par Torx
et en fait qui va te permettre d'utiliser
l'installation qui va bien
l'image qui va bien
puisqu'en fait on donne un moyen de customiser
ton docker
ton démon etc
au moment du boot de l'instance
avec Torx mais c'est un système qui est home made
et qu'on aimerait remplacer
dans le futur par système
d'assist texte
pour l'instant c'est ça
et ça nous permet de
pouvoir chipper du podman
par exemple pour l'instant qui n'est pas chippé avec flatcard
et beaucoup d'utilisateurs souhaitent la boire
moi aussi personnellement
mais pour l'instant c'est
une stack classique
est-ce qu'il y avait un autre talk
?
il y avait un autre talk
sur tout le système de mise à jour
en fait de flatcard
comment ça marche donc là on a
parlé un petit peu du système de release
alpha, beta, stable
comment l'auto update fonctionne
parce que finalement
en fait flatcard par défaut
se subdate tout seul
donc tu vas le déployer et lui il va
pinger un serveur public dont tu as parlé
de tout à l'heure au Nebraska
pour voir s'il y a le update à faire
et s'il y a une update à faire
récupérer le nouveau payload
et puis l'écrire dans la partie
sur B et reboutter tout seul
et donc tout ça c'est customisable
c'est configurable bien évidemment
et tout ce talk là est autour de ça
vous avez toujours loxmas ou pas qui
justement fait...
loxmas continue à tourner
je continue à faire des redis de temps en temps
sur ça
et on est en train
actuellement de faire un prof de concept
de loxmas plus
fleetlock
je sais pas si t'entends du pareil de fleetlock
mais tu parlais tout à l'heure
de la paix de roi coroès
comment ça se passait les relations avec eux
fleetlock c'est quelque chose qui est utilisé
du côté de faite de roi coroès
c'est un protocole qu'ils ont défini
et qui permet justement de gérer
des updates de flottes
de nœuds qui sont déployés
et on est en train de faire
une prof de concept de fleetlock plus loxmas
pour pouvoir
de nouveau rejoindre
les autres qui font
toujours ce côté-là
communautaire
pour rappel, loxmas fleetlock
quand on a une nouvelle mise à jour
imaginons qu'il y a une mise à jour qui soit disponible
on a 200 nœuds, on n'a pas envie que les 200 nœuds
se reboutent d'un seul coup
même si dans le protocole, au niveau du negrascar
on peut faire un stroking
potentiellement si jamais on utilise
votre hippo communautaire
posé en siennement si nos 200 nœuds saut dans le premier batch
200 nœuds reboutent quasiment
instantanément, enfin dans la période de refresh
ce qui peut être un problème
clairement et donc loxmas va permettre
de loquer et de dire
je veux que dans mon cluster il n'y ait que 2 nœuds
qui puissent se mettre à jour, 2, 3, xnœud
qui puissent se mettre à jour en même temps
et donc chacun prend un lock
et attend et donc en gros tant que le update
n'est pas fini, le lock n'est pas
réalise qui fait que une autre machine ne peut pas se mettre à jour
et en fait du coup
loxmas, tu as la p'tite
avec le fameux système de lock
qui fonctionne et puis tu vas aussi pouvoir
dire définir des plages horaires
pour tes visages au jour de nœud
si tu veux que ça t'arrange, que tes nœuds
ils soient obéités à minuit
le mercredi ou des choses comme ça
et en fait le problème
avec ce système de lock comme tu l'as dit
c'est que tu dois l'acquérir et en fait
toute la partie gestion du lock
c'est avec un nœud
et de CD qui roule derrière
et en fait l'intérêt d'utiliser flip lock
c'est que tu vas pouvoir t'affranchir de cette limitation technique
et avoir vraiment ce que tu veux
pour te filer un lock ou pas
donc je suis caricatured mais tu pourrais presque
détenir le lock
avec un petit serveur web
que tu aurais fait toi même que stop
et puis approuver manuellement un reboot de nœud
si tu as envie de faire ça
mais tu as plus de CD qui tourne derrière
ça va être vraiment avec l'implémentation
de flip lock, tant que c'est compatible
ça va, tant que ça implémente
le protocole flip lock, ça va, tu vas pouvoir
utiliser n'importe quel serveur en back
donc voilà, ça c'est un truc
il y a une poudre request qui est ouverte par quelqu'un de la communauté
pour l'instant, c'est quelque chose qu'on suit
pour faire une preuve de concept avec ça
Ok, parce que je me souviens plus
si je l'avais mis en place à l'époque
mais je me souviens qu'il y avait un opérateur
CoreOS à l'époque qui permettait justement
de gérer ça mais directement depuis Kubernetes
et donc en fait il va y avoir comme ça
une...
Du coup, tu parles peut-être
typhoon qui ont un opérateur
qui implémente flip lock
donc si tu as déjà joué avec flip lock c'est sûrement celui-là
que tu as utilisé
et sinon, le flatcard Linux
update opérateur, je crois, flio
Il a devait être ça
C'est flio, c'est l'implémentation de Loctimus
en opérateur C'est ça, qui permet
comme ça d'avoir une gestion
et justement à l'heure actuelle
vous restez donc un container OS
parce que vous pouvez faire tourner n'importe quel container
vous n'êtes pas encore un Kubernetes OS
comme peut-être Talos
est-ce qu'il y a un but
ou un but d'un moment, est-ce qu'en gros
vous avez souvent des usages hors Kubernetes
de votre flatcard dans ce que vous parliez ?
De l'expérience que j'ai vu pour l'instant
c'est essentiellement du Kubernetes
quand on a des issues
qui sont ouvertes
Je pense que lui on peut dire
que flatcard c'est du Kubernetes OS
parce que majoritairement
des use cases ça va être ça qui tourne
c'est d'ailleurs pour ça que dans les tests
on focus un petit peu sur des brésilés cluster
parce que c'est ce qui nous permet
en plus de tester le plus de fonctionnalités de flatcard
parce que quand tu déploies un cluster
tu entendas que tu as toutes les technologies sous la sonde
qui sont mobilisées dans ton test
donc sur le container runtime
que ce soit s-o-liniux
que ce soit la partie réseau etc
donc ça c'est assez intéressant
de dire ça
mais c'est vrai que voilà
tu n'as pas les outils qui sont chipés
donc tu n'as pas Qtcl qui est chipé
avec le site d'exploitation
donc tout ça c'est des choses que tu dois installer
au moment du provisioning avec Initio
et donc justement
tu as parlé de Initio Nv3
j'ai rarement utilisé Ignition
parce qu'en fait quand j'ai fini
la partie historique bare metal
chez les acteurs où j'étais
Ignition venait d'arriver et servait surtout
pour la partie provisioning des disques
c'était surtout son usage
à ce moment là donc on avait un mix Ignition
Ignition Cloud Init
est-ce qu'il y a une volonté
d'avoir justement une configuration
Ignition Nv3
d'avoir justement cette partie
je te donne une configuration QBADM
je te donne une configuration de qu'est-ce que
doit ressembler mon neu
quel est le master
contrôle plane que je dois rejoindre
est-ce qu'il y a cette volonté là
d'avoir encore plus cette facilitation
peut-être pour être plus intégré
avec la machine API
ça sera intéressant de voir
directement avec le upstream Ignition
pour bien de voir un petit peu
qu'est-ce qu'il fait de nouveau
pour l'instant je ne crois pas qu'il y ait
juste une solution magique
qui permet justement de donner du config
et ça join comme il faut
mais ce qu'on va utiliser
par exemple si tu veux déployer un cluster
tu vas simplement récupérer tes binaires
tu vas passer ta configuration en dur
ça va l'écrire sur le disque
ça va être en deux temps
si tu as un master, un contrôleur et un worker
ça va être en deux temps pour récupérer le token
c'est bon, c'est une installation classique
on va dire
et c'est comme ça que c'est roulé dans les tests
pour l'instant c'est un gros fichier
Ignition qui va t'installer
les binaires qui vont blâts
créer les fichiers, les services system d'air
qui vont blâts aussi
parce qu'avec Ignition tu vas pouvoir
définir des services system d'air
avec des dropping ou directement en dur
donc ça c'est aussi intéressant parce que
au final après t'arrives sur un système
qui est presque entièrement administré
par des services system d'air
ça c'est cool
et Ignition si je me souviens
on est sur une passe unique
on ne repasse pas à chaque fois
c'est vraiment fait pour la phase de provisioning
pure de l'OS
c'est initial et c'est fait
Air Liboot
avant même que le système
est totalement bouté
c'est là que c'est fait
ça roule une fois, tu peux forcer
à ce qu'il roule une seconde fois
si on a réellement envie
en ajoutant
un kernel command line
mais c'est pas prévu pour la différence
de Clutinete qui va rouler à chaque fois
si je ne m'abuse il va rouler à chaque fois
à chaque bout d'instance Ignition ça roule une fois
pour tout type
d'accord et donc gros on est vraiment dans du logic
COW
si on a envie de changer quelque chose on la pète
et on la règle
et voilà une fois de plus pour diminuer le drift
etc. donc là tu arrives
tu provises une fois et ça ne marche pas
ou tu as besoin de modifier quelque chose
tu repart de zéro, tu reverses une nouvelle configuration
et tu en déploies une instance
alors actuellement les plus grosses installations
enfin ce qu'elles sont les plus grosses installations
de Flatcar que vous connaissez
les plus gros utilisateurs
peut-être pas forcément les noms si vous ne pouvez pas donner
mais la taille, la charge, la taille d'équipe
qui le gère
j'ai pas en tête mais on avait fait
un petit sondage
alors je vais tout aller voir
mais je pense que ça doit être
en moyenne ça doit être
30, 40 nœuds qui sont déployés peut-être
mais j'ai pas de
je vais
voir
peut-être que je vais trouver quelque chose là-dessus
ok donc pour répondre à ta question
99% des utilisateurs Flatcar
ont reporté qu'ils roulaient du Kubernetes
ok
je me demande ce que font les 20h à les 20%
qui restent mais
du conteneur classique
ouais
et puis
je me suis fait qu'il y avait une stat
peut-être
c'est globalement ça
l'ordre d'idée toi en tout cas quand tu...
alors actuellement c'est pour les 30, 40 nœuds
pour un cluster
enfin la plupart de vos utilisateurs on va dire
voilà donc c'est entre 10 et 100
en moyenne
ça se verra
t'as quelqu'un qui a répondu plus
de 1000
donc je vais t'intéresser de voir l'infra
après
c'est ça l'intérêt de l'imitable
c'est que
voilà ça c'est pareil
à peu près pareil le temps de tester un nouveau matos
qui arrive et de savoir est-ce que ça passe bien dessus
et tester une nouvelle release quoi
sachant que si jamais on commence à avoir pas mal de monde
justement on peut s'abonner à des channels
beta et y avoir quelque chose
de plus chaosant
c'est quelque chose qu'on recommande
justement dans ton infras
d'avoir quelques channels beta
parce que ça fait partie aussi
de tout le release process
d'avoir du feedback de la communauté
des utilisateurs
si t'as un nœud qui pète
genre dernièrement on a eu une petite blague
qui était assez intéressante
ça a été ouvert au vendredi sur comme problème
Syllium qui crashait
en fait au démarrage
de l'instance
à cause d'un bug fix
dans un kernel LTS
donc c'était vraiment intéressant
parce que du coup ça remet en cause
qu'est-ce qui est chippé
avec des kernels LTS
donc normalement c'est censé être que du CVE
des collectifs de sécurité
et en fait là du coup t'avais un bug fix
qui était lié à une autre feature
qui était sur le monde après ces issu de dévêtements
et du coup c'était intéressant parce que au final
c'est arrivé en stable
et du coup tu dis c'est juste d'amuser un jour kernel
c'est du stable y avait aucune nouvelle fonctionnalité
et hop ça a pété Syllium
et grave mais ça veut dire que Syllium
n'a pas détecté avant et n'avait pas lui-même
son processus de test
sur les versions
sur le nouveau kernel
en théorie ça aurait dû être ça en fait
à l'arrière
mais du coup la viturée c'est cool
et du coup
ce qui est assez intéressant une fois de plus
c'est que là tout le...
ce qui s'est passé ensuite c'est qu'il y a une construction
une construction au niveau de Syllium qui a été faite
pour pâcher Syllium
pour que ça fonctionne correctement
et tu as aussi un test case
qui a été rajouté à Flakar
pour l'instant Syllium est testé
mais c'était pas cette fonctionnalité de Syllium
c'était du IPsec
donc c'était cette partie là qui était cassée
et du coup ça on l'a rajouté aussi en batterie test
pour éviter des bons...
pour identifier l'éventuel agression
bon future
c'est plutôt cool
je sais pas si tu as avec quelque chose d'autre
rajouter que tu verrais
là sur le...
même sur le FOSDEM même en règle générale
est-ce qu'il y avait des confs que tu as vus ?
oui je suis allé
du coup j'étais...
comme je dis je suis dans une assaut avec ingénieur sans frontières
et du coup
on est très intéressés aussi dans l'équipe informatique
de tout ce qui se fait en open source
au niveau communauté avec ça
donc on a regardé en fait que le FOSDEM ensemble
on s'est ouvert un chat et puis
on discutait
j'allais aller voir telle conférence
donc c'était assez intéressant
plus souvent c'est un petit apéro pour
relater nos histoires du FOSDEM
donc moi j'ai joué le jeu aussi d'aller voir
d'autres talk qui m'intéressaient bien
je suis allé voir un talk sur Java
premier talk du FOSDEM
si en fait j'étais qu'est-ce qu'il y a de nouveau
dans l'écosystème Java
la fonctionnalité du langage
bon bref c'était assez intéressant
Java c'est pas un langage que je fais tous les jours
et je n'ai pas trop l'occasion de voir
mais je suis curieux de voir ce qui se faisait
de nouveau
j'allais voir un talk aussi sur
NemoMobile
qui est un système d'exploitation libre
pour les téléphones
donc ça c'était aussi intéressant avec
une petite démo, montrer un petit peu l'état de la
chose, comment ça fonctionne, comment contribuer
donc ça c'était assez intéressant
depuis j'aime bien en fait que la partie
librice était autour de ça sur la téléphonie
et puis plus là j'ai vu aussi
je crois que c'est tout
quelque chose sur Antibole
ah oui Antibole à Ra
donc là ça c'était
je crois que c'était une personne de redat
qui a fait talk
et ça c'était assez intéressant
sur la fonctionnalité d'Antibole
ou une fonctionnalité R-Plugging Antibole
qui permet en fait de collecter foot-a-log
au moment de l'exécution d'Antibole pour les balancer
dans une base de données derrière
et ensuite pouvoir naviguer
récupérer un historique, identifier tout ce qu'il y a
en paye, tout ce qu'il y a en héros
tout ce qui est en succès
c'est vraiment juste
rendre persistent les logs antiboles
pour pouvoir ensuite naviguer à travers
c'était assez cool, l'outil était assez sympa
c'est une implementation en Django
derrière donc c'était assez gaude
voir ça
live et puis je vois
la problématique au tout était assez intéressante
parce que la personne expliquait que
des fois dans leur CIA
ils avaient plus de 50.000 lignes
de logs
donc quand il y avait un truc qui passait pas au niveau antibole
il fallait monter tout le traspac
pour voir
où est-ce que c'était pété
il montrait comment les Antiboles
à travers, ils arrivaient
à pallier à ça et pouvoir naviguer rapidement
dans des logs pour pouvoir identifier les problèmes
c'est vrai
tu as parlé de tout l'aspect libre-iste
qu'on a dans le Fosdame
c'est quelque chose qui est extrêmement présent
et extrêmement
surtout quand on y est pour le coup
c'est la foire au libre-iste
à fond
pour ça que je t'encourage
dès que tu peux y aller
ça a l'air vraiment unique
en plus
ça a l'air super convivial
tu discutes de tech
en buvant une bière
ça a l'air vraiment cool comme événement
et je pense que s'il est aussi connu
et célèbre en Europe
dans le monde, je pense que c'est aussi pour ce côté là
libre-iste et puis très bonne ambulance
de l'événement
tu penses que c'est pas le genre d'événement où tu te prends la tête
non, c'est toujours un endroit
où tu trouves des choses très spéciales
les seules problèmes que tu peux avoir
c'est chez pas l'année où par exemple
Facebook avait sponsorisé
la track piton
et où ça avait un peu fait jazzer
parce que c'est Facebook, parce que c'est pas bien
et parce que c'est pas libre
ça plus c'est pas libre
enfin voilà, c'est les seules choses
les seules grosses événements que tu peux avoir
et ça fait plus bien
je pense pas que tu manques de verre
mais tu as un côté aussi sympa
comme tu disais
que tu as les standards
des speakers et machins
donc je me souviens
tu avais Coroeste
j'avais vu à l'époque que tu avais du club
tu avais
Gen2 aussi qui était là
je pense que ça t'apporte une proximité avec les développeurs
pour pouvoir aller poser des questions etc
ça c'est cool
mais t'as même encore d'autres choses
alors je crois que le nom c'est ReactOS
ou quelque chose comme ça mais qu'il y a un OS
que je vois depuis que je faisais
donc ça a beaucoup plus de 10 ans
où les gars réimplémentent entièrement tout le kernel windows
donc c'est pas un Wine
c'est pas un name model
une couche de compatibilité par rapport au kernel Linux
c'est que les gars réimplémentent le kernel windows
voilà ils sont chauds
et ils ont une table
je me suis toujours demandé
qui sait qu'il avait la motivation
pour bosser sur des sujets comme ça
mais gars
t'as même encore des choses encore plus perchées
donc il y a une petite roue un peu plus loin
enfin un pavillon
qui est le plus petit pavillon d'autre tous
qui est un peu caché
où tu vas pouvoir avoir les projets à IoT
tu vas avoir des gens qui vont créer des
cubesats par exemple en open source
qui ont une espèce d'agence spatiale
donc c'est des italiens qui ont ça
une université italienne qui ont créé une agence spatiale libre
en fait pour créer des cubesats en open source
et avoir tous les plans
alors il crée pas de fusée
parce que d'ailleurs j'en ai demandé pourquoi ils avaient commencé
c'est une réclamitation je pense
alors tu pourrais le faire le problème c'est que
le logiciel de guidage d'une fusée
il ressemble quand même beaucoup à celui d'un missile
ah
et donc bah
voilà c'est pour ça qu'il y a pas
de logiciel de guidage open source
d'une fusée
parce que
parce que voilà
ouais ça pourrait être tombé
dans des mains de personnes malintentionnées
voilà après je me dis si jamais t'es une personne malintentionnée
tu arrives à récupérer du code
d'une façon ou d'une autre
avec la bonne personne
et normalement tu arrives à récupérer quelque chose
dans un pays qui a déjà diffusé
mais voilà en tout cas
intéressant et puis justement
c'est les gens super passionnés
donc même si toi
tu t'intéresses un peu de loin à la chose
par exemple tu parles juste en de réactores
et bah les mecs ils vont te donner
cette passion et cet énergie
et du coup toi ça va t'intéresser et ça aussi
c'est beau ce genre d'échange que tu peux voir dans
ce genre de conférences
Exactement et point important
les tools là bas
sont extrêmement techniques
et
avec une propension
à vraiment mettre en avant
les contributeurs, les gens qui soient les contributeurs
en projet et soient même les créateurs du projet
mais en tout cas
si jamais vous avez peur de parler
si jamais vous vous sentez pas bien
par rapport aux autres trucs qui existent
franchement aller voir un truc du FOSDEM il y en a plein
on se sent que c'est pas des gens
qui aiment parler mais qui aiment partager
ce qu'ils aiment faire et donc c'est quelque chose
d'extrêmement bien
Et ça je trouve ça beau quoi
parce que au final c'est le propre ingénieur
ou même la personne technique
c'est de partager en fait
ce que tu as appris, partager du feedback, faire du retour
d'expérience et voilà
t'as pas besoin d'être super allé
sur scène pour partager les choses
ou t'as pas besoin d'avoir le sujet
trending du moment pour le partager
en fait si c'est quelque chose que tu as appris
et que tu dis que ça peut être intéressant de le partager
FOSDEM c'est bon on voit quoi
Voilà, enfin si c'est open source
toujours on va toujours
rappeler ça mais voilà
c'est un grand sujet les conférences
en ce moment
Mais voilà en tout cas
voilà sur le FOSDEM
ce qui est assez cool
donc n'hésitez pas à venir l'année prochaine
on va espérer que ce soit en physique
parce que vraiment la moitié de l'est
enfin les trois quarts de la conférence se passent
dans les accotés
vraiment
donc tous ils se disent
peut-être que tu lui ouvres un petit podcast depuis le FOSDEM
un petit live
mais j'ai déjà essayé en fait de le faire
peut-être même d'ailleurs cette année
donc on a déjà des places pour la cupcon
donc qui se passera à Valence en mai
mais peut-être que je prends un live de là-bas
ça pourrait être vraiment intéressant je pense
Ouais voilà j'avais déjà essayé de le faire
il y a longtemps
quand c'était celui de Barcelone
donc j'ai pu y avoir deux trois ans
bon voilà
autre temps, autre époque maintenant
peut-être que ce serait possible j'ai déjà un peu plus le matos pour le faire bien
et voilà un live report
un live report
de la conférence
de toute façon moi je passe mon temps à être
enfin je suis jamais dans les conférences
moi je suis toujours dans le bout
sur les contours
voilà je suis dans les couloirs mais c'est rare que j'aille dans les conférences
vous me verrez rarement
dans les salles de conférences mais plutôt à côté
si, il s'agit de chialer l'alcool
voilà un peu
merci beaucoup Mathieu
merci pour
pour ce talk déjà, pour les contributions que tu peux faire
déjà pour tout le travail fait
puis merci pour bien voulu
venir avec cette invitation
c'était à plaisir
et puis merci à toi d'avoir arrivé toute la discussion
c'était vachement intéressant j'ai appris des choses aussi
donc c'est vraiment cool
c'est le but et j'espère que les gens qui écoutent
là ont aussi appris des choses
c'est le principal c'est le plus important
et puis
je te dis à une prochaine alors au moins
au FOSDEM l'année prochaine mais j'espère
avant
ça marche et puis prenez soin de vous et tout ça
et puis on essaie de se voir rapidement
ça va bien
salut à tous
salut salut