Loading video player...
Déjà.
Merci beaucoup à toutes et à tous de venir voir justement ce petit REX
autour du Platform engineering et
au niveau des Restos du cœur,
comment on l'a appliqué
Alors premier petit disclaimer avant de commencer,
s'il y en a qui détestent le franglais,
je suis désolé d'avance, je risque d'en faire assez régulièrement.
Sorry pour le franglais et le deuxième disclaimer.
J'aime bien les gifs ou gifs, peu importe comment on le dit, mais le premier
alors normalement c'est censé être le deuxième.
Disclaimer mais j'ai oublié de modifier cette slide.
Pardon.
On aime beaucoup les acronymes aux Restos du cœur.
Alors si vous voyez RDC c'est pour Restos du cœur,
pas République Démocratique du Congo ni rez de chaussée.
Voilà, c'est dit.
Alors je vais faire un petit 3615 ma vie, même si je suis né
bien après le Minitel et que j'ai jamais connu.
Donc je m'appelle Julien Briault, donc je suis ingénieur réseau
chez Deezer comme ça a été introduit, j'ai 27 ans d’uptime depuis juin dernier.
Je suis auteur sur Linux pratique
qui est maintenant devenu SysOps Pratique si je dis pas de bêtises,
obviously
Je suis bénévole donc aux Restos du cœur sur mon temps libre et je suis fan.
Enfin, je suis fan d'un film qui s'appelle Short Circuit, avec le robot que vous voyez
là, qui est ni plus ni moins que le Wally raciste des années 80.
Je peux pas le définir mieux que ça.
D'où mon pseudo d'ailleurs sur X anciennement Twitter.
Et puis BlueSky. Alors normalement j'ai une petite vidéo pour vous.
Je ne sais pas si ça va fonctionner.
Voilà.
Donc je suis désolé si j'ai plombé
un peu l'ambiance.
La vidéo n'est pas de moi.
Donc ça c'était pour introduire les restos rapidement, sachant que bon,
je pense que tout le monde connait les Restos du cœur ici.
Mais ce qui est important à
rappeler, c'est que cette année, on a malheureusement 40 ans.
Alors je dis malheureusement parce que l'association est censée, enfin,
elle était censée disparaître
puisque ça voudrait dire qu'il n'y a plus de précarité.
Et malheureusement se passe
l'effet complètement inverse, à savoir on grandit de jour en jour.
Donc pour parler des restos, malheureusement, je suis désolé
pour ceux qui n'aiment pas les maths, quoi qu'en
tant qu'informaticien dans le monde, globalement on aime à peu près tous ça.
Il faut parler un peu de chiffres et notamment sur la période
2023-2024, c'est 163 millions de repas qu'on a distribués
On a au total, et c'est pour que vous compreniez un petit peu
pourquoi on en est arrivés à créer cette plateforme.
On a 113 entités juridiques totalement différentes puisqu'on a 112
associations départementales plus une association nationale.
On a également 2348 lieux d'accueil.
Donc ça peut être les maraudes,
ça peut être également aussi les centres de distribution.
Donc, c'est ce que tout le monde connaît.
Et ce que tout le monde voit à la télé d'ailleurs,
c'est là où on vient distribuer les denrées alimentaires.
On a environ entre 75 000 et 80 000.
Alors là, en ce moment, on est plutôt autour des 78 000 bénévoles réguliers.
Ça varie en permanence puisqu'il y a pas mal de turnover au niveau des bénévoles.
En fonction des disponibilités, on peut monter jusqu'à 100 000, parfois
en période de collecte, notamment pendant les collectes nationales,
et on a 35000 utilisateurs quotidiens au niveau de l'informatique,
35 000, c'est monstrueux.
On a un peu plus d'une quarantaine d'applications
différentes et de nouvelles applications qui se déploient avec le temps.
Et on a surtout plus 300 informaticiens avec des niveaux complètement différents
d'une association à l'autre, répartis sur tout le territoire.
Donc voilà, un petit peu pour parler
de l'organisation globale des restos, le mieux c'est de parler de pyramide,
puisque c'est clairement une structure un peu pyramidale.
C'est à dire que vous avez l'association nationale tout en haut, les délégations
régionales, les associations départementales et en toute fin
ce que tout le monde connait les centres de distribution.
Moi j'aime bien commencer mes conférences, notamment par une petite histoire
et notamment celle de mon arrivée aux Restos.
Alors je suis arrivé au niveau de l'association
départementale d'Eure et Loir.
Est ce qu'il y a des gens qui sont dans le 28 ? Ici?
Yes, je suis tout seul.
Alors ben justement, je suis tout seul et c'est une très
bonne introduction sur le fait que quand je suis arrivé aussi
au niveau de l'informatique dans le 28, j'étais tout seul et il y avait
notamment tout un historique, il fallait que je fasse avec notamment.
Et alors quand je parle d'historique, je pense que, enfin, si vous pensez
associatif, c'est effectivement bien ce genre d'historique, donc à savoir le PC
qui traîne dans un coin avec plein de questions qui se posent
autour de ça, à savoir est ce qu'il y a des sauvegardes de ce truc là ?
Spoiler alert non.
Est ce qu'il y a de la redondance ?
Bon, c'était visible, il n'y avait pas.
Il n'y avait qu'un seul PC qui servait de serveur.
Y’a quoi qui tourne là dessus ?
J'en sais absolument rien, parce que forcément,
il n'y avait pas la documentation et ça presque x 112.
Vous imaginez 112 fois ce merdier là.
Alors je me suis dit ça tombe bien, je suis ingénieur en informatique,
donc est-ce que je pourrais pas monter une petite infrastructure pour héberger
justement les différents besoins de l'association départementale.
Et c'est comme ça qu'est né ce que j'ai appelé le DC aux WC,
puisque c'est, si on regarde bien en fait, derrière
on a un WC et un mitigeur qui pendouille.
Bon, dans les faits, ça peut paraître une idée de merde
comme ça, mais en réalité le WC a été condamné, il n'y a plus d'eau.
C'est juste que, encore une fois, contexte associatif,
il n'y avait que ça de disponible.
On notera quand même la climatisation qui a été posée.
Stratégiquement devant,
mais on tend vers quelque chose d'un petit peu plus sérieux puisque cette fois ci
on a le réseau qui est redondé et les serveurs qui sont redondés.
On a même des backup qui sont faits localement.
Alors il y en
a d'autres qui se sont dit en fait gérer des serveurs physiquement,
ça m'emmerde un peu, c'est pas forcément mon truc, ça m'embête.
Pourquoi pas passer éventuellement par du cloud public ?
Souvent c'est du cloud public à tois lettres,
je les ai pas cités, mais j'imagine que vous avez quelques idées.
Alors de qui ça peut être ?
Alors le gros souci de ça.
Alors je ne sais pas pourquoi “Devoir faire avec l’historique” Bon c'est pas très grave.
Le gros problème de ça, c'est que ça coûte très cher
et notamment parce que sur le cloud public, vous faites,
ce que l'on appelle du Pay As You Go.
Donc globalement, vous payez au fur et à mesure
en fonction de ce que vous consommez.
Je ne vais pas vous réinventer tout le principe du cloud public.
Je pense que tout le monde est au fait là dessus
et donc
la délégation régionale Centre-Val de Loire
a entendu parler de ce que j'ai fait et déployer les différentes
trentaines d'applications au niveau du département.
Il s'est dit Julien, ce que.
Est ce que tu serais ok pour nous le faire aussi au niveau de la région ?
Donc on est passé de 400 utilisateurs actifs à 5000.
Donc vous vous imaginez que ça va pas tenir,
ça va tenir difficilement sur quatre serveurs.
Donc je me suis dit OK, pas de souci, on va essayer de récupérer des dons.
Et donc là, cette fois ci, problème de riche, on a un serveur
qui sert de support de PC portable pour configurer les serveurs
et par contre cette fois ci beaucoup plus de serveurs,
beaucoup plus de, enfin, l'infrastructure est encore une fois redondé.
Et tout ça, ça a été rendu possible parce que vous l'avez
peut être déjà vu passer, mais ça m'arrive très régulièrement de faire des appels
aux dons, notamment sur X ou sur Blue Sky, ou même sur LinkedIn
et est arrivé après.
Ensuite, le moment entre guillemets, que moi j'appelais la délivrance,
c'est lorsque Deezer.
Donc la société, où je travaille actuellement
s'est dit bah en fait on va bouger une certaine partie de nos serveurs,
on a certains du coup qu'on va essayer, qu'on va sortir
et plutôt que de les mettre à la poubelle, on s'est dit
pourquoi pas les donner aux restos ?
Et donc nous, on est venu avec nos camionnettes
chercher au total un peu plus de dix tonnes de serveurs,
dix tonnes à bouger parce qu'en plus de ça, on n'avait pas de hayon,
donc il a fallu les charger une première fois, les décharger.
Enfin bref, ça a été
mon dos s'en souvient encore.
Donc on est allé chercher les dix tonnes de serveurs.
Et donc vous allez me dire
mais c'est bien, on dit tonnes de serveurs,
donc ça représente un peu plus de 300 machines.
Mais qu'est ce que tu veux faire avec 300 machines ?
Tu veux lancer une un centre de calcul ou d'essais nucléaires ?
Non. L'idée continuait un petit peu à mûrir dans ma tête en me disant
ça serait bien.
Après, plus tard, éventuellement, pourquoi pas, de l'offrir à tout le monde.
Et donc il a fallu les installer ces machines, Donc où est ce que c'est installé
dans un endroit où c'est pour ça. Ça tombe bien hein ?
Effectivement, visiblement, je suis le seul à habiter près de Chartres.
Dans un endroit où on voit rien à perte de vue à part des champs,
une cathédrale et le premier data center des Restos du cœur.
Dans un endroit où historiquement on y stock
de la nourriture, mais maintenant de la donnée aussi également.
Et donc je vais laisser un petit peu celui là, je le mets.
Voilà, on a commencé à construire, on s'est dit
maintenant qu'on a les serveurs,
on va commencer à faire quelque chose encore plus sérieux.
Et donc c'est comme ça qu'on en est arrivé à la deuxième version
de l'infrastructure, avec trois baies qu'on a commencé à assembler.
Et donc voilà à quoi ça ressemble maintenant.
Donc ça, c'est le tout premier
point de présence avec tous les serveurs des Restos du cœur.
Alors vous allez me dire mais pourquoi ?
Pourquoi ce projet ? Et pourquoi avoir besoin
d'autant de serveurs puisque enfin, vous imaginez bien.
Que pour 5000 utilisateurs, c'est peut être un peu overkill.
Et donc c'est là où l’AN, donc l'Association nationale,
je l'ai dit, on aimait bien les acronymes aux Restos du cœur,
donc tout en haut de l'échelle, Là, ça y est, je suis arrivé tout en haut,
s'est dit
Julien, est ce que tu ne veux pas faire la même chose,
mais pour toutes les associations départementales ?
Alors ça, ça tombait bien
parce que j'avais déjà cogité depuis un petit moment à cette idée.
Et donc, pourquoi elle s'est dit ?
Pourquoi ça pourrait être intéressant ?
C'est parce que l'Association nationale qui fournit les services
pour toutes les associations départementales,
n'avait absolument aucune idée de quel était le besoin
des associations, associations départementales
et ce qui tournait dans ces différentes associations.
Et donc on s'est dit
en fait, en réalité, c'est comme mettre un bout de scotch
sur une faille béante
de leur côté, puisque dès qu'ils voyaient une feuille apparaître puis essayer
de voir avec l'association départementale sur des Aim points publics pour le corriger.
Mais bon, bah c'est comme un bout de scotch.
Et puis un truc, c'est que s'il fallait héberger tout le monde,
ça coûterait un pognon monstre, notamment parce qu'au resto, 1 €
c'est égal, un repas et donc 1 € dépensé, c'est un repas qui n'est pas distribué.
Et donc nous, on s'est dit
ok, on va se mettre quelques objectifs en tête, notamment
celui de fournir une infrastructure qui est ouverte, accessible,
qui ne coûte qu'un, enfin, qui est fiable parce qu'elle doit être de confiance,
qui ne coûte presque rien.
On dit quand je dis presque rien, on sait qu'on a 90 9,9 % de dons,
mais il y a encore deux trois trucs quand même qu'on est obligés de payer.
On doit être indépendants au maximum en terme de technologie.
Donc c'est pour ça qu'on a fait le choix principalement de l'open source
et une expertise aussi qui est partagée.
Donc c'est à dire qu'on a une équipe qui, du coup fournit son expertise aussi
pour toutes les associations départementales, lorsqu'elles ont besoin
d'expertise sur certains sujets. Alors pour y arriver
Pour construire un tel truc, il faut quand même quelques règles.
Et la première, c'est de se dire il faut limiter le Shadow IT.
Eh donc, pour ça, notamment du code partout,
dans toute l'infrastructure et gérer as code de A à Z.
Alors historiquement, au resto, on a toujours un peu fait du IAAC.
On n'avait pas tout à fait la même définition.
Avec mes collègues de l'Association nationale, c'est
à dire qu'ils user du infra as a console, nous on fait de l'infra as a code.
Si je préfère remettre dans le.
Donc l’infra as a console.
Alors tout ça.
Donc, comme je l'ai dit, pour limiter le Shadow IT
pour accélérer le déploiement.
On est passé quand même de un mois de mise en œuvre à à peine cinq minutes.
Donc là, à chaque fois, on nous dit
mais vous allez trop vite pour les restos.
Ça nous permet de faciliter rollback.
Bref, je ne vais pas énumérer tous les intérêts d'une CI etc.
Mais c'est du coup installer un petit peu partout pour tout ce qu'on.
Tout ce qu'on met en place et aussi notamment,
ça nous permet d'améliorer la sécurité directement intégrée dans la CI
Donc en parlant de sécurité, pareil J’aime bien ce gif là, je le trouve rigolo.
On s'est dit pas de connexion en directe sur les machines donc.
C'est à dire que toutes les machines qu'on met
à travers la plateforme, il y a absolument aucune possibilité de se connecter SSH.
Déjà parce que c'est un peu compliqué à gérer on va dire au niveau
des différentes personnes qu'on
a qui on
fourni l'accès, et puis parce que c'est pour des questions de sécurité.
Et donc les déploiements sont essentiellement donc par la CI/CD
Donc, c'est la CI/CD
qui a la possibilité de déployer des choses,
et éventuellement, quand il y a un besoin d'un accès sécurisé quelque part,
on fournit un accès téléport.
Donc ça, c'est à travers la plateforme, ça crée automatiquement les identifiants.
Ça crée aussi également les différents accès.
On n'a pas à le gérer.
Et la troisième règle,
c'est qu'on essaie de faire au maximum de l'infrastructure immuable.
Alors, pour les éléments, pour ce qu'on appelle nous, l’underlay, c'est à dire
les serveurs qui font tourner Cloud, on utilise MAAS : Metal as a Service et packer
pour déployer automatiquement nos images et tuer nos serveurs.
Donc les serveurs qui font tourner le cloud n'importe quel moment.
Mais malheureusement tout n'est pas immuable.
Et donc encore une fois, MAAS vient en renfort avec justement Cloud
Unit qui nous permet de déployer des VM, de pouvoir se connecter dessus, etc.
La quatrième règle ça va être d'automatiser pour déléguer.
Alors on utilise massivement pour les serveurs
qui sont qui font tourner cloud Ansible pour déployer les différents services.
Pour ce qui tourne sur le cloud, c'est essentiellement du Kubernetes.
Et donc la fiabilité pour nous, ce n'est pas uniquement la fiabilité.
L'automatisation c'est pas, c'est pas vraiment un luxe.
L'idée, c'est de pouvoir quand même aider de plus en plus de gens.
Donc on a besoin de ça justement pour pouvoir aider de plus en plus de gens.
Et la cinquième règle, c'est documenter pour transmettre.
C'est globalement le partage.
Et donc pour ça, on y arrive, notamment via ce qu'on appelle des share sessions.
Donc toutes les deux semaines, on a des sessions de partage
sur un sujet spécifique pour expliquer comment ça a marché avant,
comment ça a été déployé, comment on le maintient
et qu'est ce qu'on fait quand ça sonne.
On a.
Globalement, tout doit être documenté, donc on a une myriade de documentation
au niveau de l'infrastructure et c’est aussi une construction commune.
Donc globalement
tout le monde est au fait de ces sujets là et tout le monde y contribue.
Alors maintenant, on va parler de Cloud rapidement
et notamment ce qui nous fait tourner, ce qui est sous le capot du cloud.
Et donc naturellement, on utilise Kubernetes parce que
pour faire tourner des microservices, il n'y a pas mieux que Kube
et donc on fait du Blue green sur à peu près tous nos éléments
qui font tourner Cloud.
Et alors vous allez me dire mais.
J'ai pas cliqué.
Au bon endroit, pas pardon, faire du blue green
avec,
faire du blue/green, sur des éléments qui sont sous le
sous le cloud, ce que les gens ne voient pas,
ça peut être risqué et en fait en réalité pas du tout.
En tout cas pas pour nous.
Ce que ça nous permet de faire des montées de version de manière transparente.
Et donc le
véritable moteur de Cloud chez nous, c'est OpenStack.
Alors vous allez me dire mais quoi OpenStack en 2025 qui fait de l'open
stack ici ?
Qui est content d'en faire ?
Alors j'ai pas précisé qui en gère parce que.
C'est pas tout à fait pareil.
Alors nous on fait ce qu'on
appelle du contexte driven développement, c'est à dire penser avant de coder.
Donc on essaie de réfléchir
à la solution qui fit au mieux par rapport à notre usage.
Et nous notamment,
on a utilisé un algorithme pour ça qui s'appelle Algo de Feynman qui dit
tu écris ton problème, tu réfléchis, tu écris la solution.
C'est bête, mais ça fonctionne parfaitement.
Et donc notamment nous, notre problème, enfin notre problématique
à laquelle il fallait répondre, c'est de pouvoir tout rendre API pour
justement pouvoir fournir cette plateforme qui soit consommable.
Et donc c'est pour ça qu'on a utilisé Open Stack, qui fournit tout un ensemble
de microservices qui expose des API et qui après derrière sont consommables.
Donc ça nous permet d'avoir du bloc storage, de l'object storage, du compute,
du GPU aussi. Maintenant du réseau du VPN.
de service du LBS de service du kubes de service.
Globalement, tout ça dans la plateforme.
Et donc
toutes ces choses là, on les retrouve dans un seul
point d'entrée qu'est la console du Club du cœur qui est le cloud.
Enfin la plateforme des Restos du cœur où à l'intérieur,
vous allez pouvoir soit consommer de l’object storage
ou un compute de manière tout à fait classique, ou éventuellement passer
par justement le portail pour les développeurs notamment,
mais pas que, aussi pour les pour les correspond
ce que nous on appelle les correspondants informatiques
qui sont en fait les informaticiens dans les associations départementales.
Pouvoir en un clic déployer un service et derrière passagère, automatiquement
ça crée le repos Git ça vient automatiquement y envoyer
via Slack les différents creds pour se connecter.
Ça, ça génère la CI, etc.
Et ça supervise
toute l'applicatif,
et donc notamment au niveau du monitoring, donc à côté de la plateforme.
Donc ça, vous avez cette console, un peu la même chose que ce que vous auriez sur
les grand Cloud dans cette console unique.
Et à côté de ça, par contre, nous on fournit du coup un grafana
qui vient, qui vient afficher les différentes données
différentes applications qui sont déployées.
Donc tout ce qu'il y a à déployer, forcément, observé notre côté.
Donc on va avoir Victoria Metrics
qui va venir collecter les métriques, automatiquement,
on a Open Search qui va venir lui collecter les logs.
Donc ça c'est pas forcément obligatoire, c'est en fonction de la demande
de l'utilisateur sur les applicatifs que nous on fournit.
Par contre c'est forcément logger.
Mais par contre quand vous déployez,
quand quelqu'un déploie par exemple un buckets,
on ne va pas forcément regardé les logs du bucket.
On va avoir consul pour le service Discovery de toutes les machines,
on va avoir Grafana pour l'affichage final
et Jaeger pour la partie trace.
Et si vous êtes intéressé, j'ai donné une conférence sur le sujet
justement, notamment sur Victoria Metrics
qui est un remplaçant de Prometheus en open source.
Et nous on l'utilise pour deux cas.
Donc le premier c'est le cloud du cœur en lui même, l'infrastructure
et les autres pour les utilisateurs et le deuxième
cas, c'est pour les chambres froides que je vais vous présenter juste après.
Et donc voilà le cloud du cœur.
Donc c'est une marque maintenant qui est totalement indépendante des restos.
Vous avez, vous avez
les Enfoirés, les Restos du cœur et le Club du Cœur est une marque
qui appartient aux Restos du cœur.
Donc l'abstraction.
Nous, au niveau
du projet, on a une CLI, notamment pour aider à la contribution.
Donc c'est une CLI, qui a été développée en interne
et qui nous permet plein de choses.
Donc déjà de fournir en fait
une structure qui est commune sur les dépôts terraform, Ansible, etc.
C'est la CLI en fait qui va générer automatiquement le repos
avec toute la structure.
Donc on a tous la même structure sur laquelle travailler.
Donc ça, c'est vraiment en dessous, en fait, le capot
ce qu'on va faire pour réaliser des actions communes.
Donc s’il y a, par exemple, besoin de commander.
Pour les gens qui sont côté infrastructure, commander un sumnet
automatiquement ça envoie une notif sur Slack à l'équipe réseau
et elle valide ou pas.
Donc ça c'est pas sur ceux qui déploient sur Cloud, c'est pour en dessous.
C'est un peu le même principe pour ceux qui sont qui déploient sur la plateforme.
On va uniformiser les commandes comme ça.
Du coup on a quelque chose d'assez, c'est clair.
Et puis aussi l'aide à la recherche d'informations.
Comme il y a beaucoup d'infra,
il y a beaucoup de choses en fait autour de ça.
La CLI va permettre de chercher aux différents endroits
et de retourner l'information tout de suite
en fonction des différents points d'entrée.
Donc voilà un petit peu à quoi ça ressemble.
Donc pour ça, on utilise Ego et Cobra pour ceux qui font du go,
on a donc.
Voilà un exemple d'initialisation d'un repo en cible.
On a. Si par exemple on veut chercher.
Alors ça c'est pour les gens qui gèrent le cloud du cœur.
Chercher une information pour un device particulier.
Ils ont la possibilité de le récupérer, notamment
via la CLI puisque tout est API sur le club du cœur.
Et donc voilà un petit peu la vue d'ensemble, donc tout le bas.
Donc les datacenters, serveurs physiques, la plateforme, ça
c'est ce que nous, on gère en fait, au niveau de l'équipe, du Cloud du cœur
et ensuite après il y a les choses qu'on rend
consommable et les produits finaux qui va être.
Par exemple, dernièrement, on a hébergé la radio des Restos du cœur,
on a à cœurGPT, on va changer le nom
parce que GPT étant une marque déposée,
c'est l'IA qui est en train de se développer
autour des Restos du cœur, on a Passbolt
Bref, plein, plein de plein de projets comme ça qui tournent là dessus.
Et donc, vous l'aurez compris, les restos, hein aime énormément l'open source.
Donc voilà un petit peu la
myriade de projets open source qui font fonctionner
cette plateforme.
Normalement.
Voilà, en parlant de projet open source, on a développé en réponse.
Alors ça, ça n'a
rien à voir avec la plateforme directement,
si ce n'est qu'on héberge en fait tous les besoins de ce truc là
sur la plate forme, on a développé en réponse
à la problématique de la fin de vie de Windows dix.
Et comme notre parc, c'est essentiellement du don on va.
On n'allait pas racheter des PC parce qu'encore une fois 1 € un repas,
donc s'il fallait racheter des PC, c'est un peu plus de 30 millions
pour tous les restos.
Donc on s'est dit on va développer notre distribution Linux
qui est en fait un clone de Windows à quelque chose près.
Mais par contre vraiment très orienté par rapport à notre, à notre besoin.
Et donc
j'ai mis plus que plus de 15 000 postes, mais en réalité on est plutôt autour
des 25 000 postes actuellement qui vont être concernés par Linux du cœur
et donc tous les dépôts de packages de ce genre de choses.
Des outils par exemple pour prendre la main distance.
Là dessus, tout est déployé
sur le cloud cœur, de la même manière qu'une application standard est déployée.
Un autre projet qui lui tourne dans la plateforme
Kube, qui est déployé sur le cloud du cœur, c'est les sondes du cœur.
C'est.
Alors ça, c'est typiquement métier, c'est comment on est capable de s'assurer que.
Donc, c'est ce qui utilise Victoria Métrics,
comment on est capable de s'assurer
qu'on n'a pas une rupture dans la chaîne du froid.
Donc, vu que nous, on entrepose en fait les denrées alimentaires,
on doit être capable de vérifier que justement
il n'y a pas une rupture au niveau de la chaîne du froid
et d'être alerté, notamment quand on a une perte de température
et une montée de température dans une chambre froide.
On avait déjà eu le cas et un peu plus de 100 000 €
de denrées alimentaires qui partent à la poubelle.
Donc on préfère éviter ce genre de situation.
Surtout qu'un boîtier, là en l'occurrence, c'est un truc qu'on a développé maison
qui fonctionne avec Victoria Métrics qui utilise Grafana pour pouvoir
afficher les métriques et les alertes sont gérées aussi par Victoria Metrics.
Donc globalement, avec de l'open source et un boîtier qui est en ESP.
En fait, pour ceux à qui ça parle,
on arrive à avoir des sondes qui convoquent,
qui coûtent entre 15 et 20 € à peu près par chambre froide,
là où on était entre 1500 et 4 000 € par chambre froide par an.
Là c'est 15 € à vie,
c'est pas négligeable.
Donc c'est pour ça, 6 millions de repas distribués en plus grâce à ça
et un peu plus d'une trentaine d'autres services
qui représentent un total approximatif de 12 millions de repas servis en plus
grâce à cette plateforme.
Et on en est très loin
d'être arrivés au terme puisqu'il y a encore plein de choses.
Pardon pardon.
On est très loin d'être arrivés au terme de ce projet, mais
progressivement, on a plein de choses qui se développent là dessus
puisque l'idée c'est de pouvoir innover sans que ça coûte un rond.
Bah voilà, alors ça c'était pour vous partager rapidement radio resto,
la radio des Restos du cœur qui est qui a été publié, en début du mois,
justement pour les 40 ans, ça a tourné sur les Restos du cœur.
On a eu un décrochage sur les radios nationales,
on a des gros, gros animateurs qui sont venus là.
Par exemple, on a le fils de Coluche qui était là, on avait,
on avait plein d'animateurs, de grosses radios qui sont venus
sur l'événement et j'ai même eu l'occasion de pouvoir animer.
C'était pas du tout prévu avec Thierry Marx.
Une émission.
Donc voilà pour pour terminer en quelques chiffres.
Donc c'est un peu plus de 1100 VM qui tourne actuellement sur Club du cœur.
Un peu plus de 500 pods.
On a 80 serveurs en moyenne par AZ.
Donc les AZ c'est les zones de disponibilités.
On a.
On est en train de se déployer un petit peu partout sur Paris,
Chartres Marseille Chartres historique.
Mais Paris et Marseille, c'est tout nouveau.
Pour être au plus proche des utilisateurs.
Donc c'est plusieurs millions d'euros économisés et plusieurs millions
de repas distribués en plus si jamais vous êtes intéressés pour nous rejoindre.
Bien sûr, on recrute bénévoles.
Vous l'aurez compris,
on est une vingtaine d'entreprises partenaires et c'est à peu près tout.
Je dis souvent voilà, donc voilà, j'ai terminé, Vous l'aurez compris,
on a besoin de vous.
Bon ça
c'est notre dicton : Fail fast, Iterate, Share Food.
Donc voilà, j’ai terminé.
Merci beaucoup.
Je ne sais pas si on a encore un peu de temps pour les questions.
On a cinq minutes pour les questions.
Est ce qu'il y a quelqu'un a des questions ?
Il y a deux questions.
Bonjour, donc déjà merci pour le talk, c'est super !
Bravo
Kube tu le déploies sur OpenStack.
Alors je ne l'ai pas précisé ici, mais c'est le côté un petit peu
un peu particulier du projet, c'est qu'on a un kube qui fait fonctionner
les microservices d'Openstack et OpenStack fournit du kubes de service.
Donc on a Kube OpenStack Kube.
En réalité,
le Kube qui est fourni par OpenStack, il te pop une VM sur un autre compute,
mais c'est les microservices qui gèrent le Kubes de service, bah tourne dans le Kube
Ok, je sais pas si c'est clair.
Oui c'est un peu.
J'avais peur de cette réponse. Et.
Comment tu gères le cycle de vie ?
OpenStack c'est une version tous les six mois. Oui.
Comment tu fais ?
Eh bien en fait, les hubrates tous les six mois.
Alors c'est là.
C'est là où alors on a eu très peu de soucis dernièrement
sur les montées de version, ça a été moins le cas, on va dire, avant,
sur les 2024.
Globalement, à partir de 2024, les versions ont commencé
véritablement instable.
On a juste une fois
un petit soucis de fin.
C'est pas un petit souci parce qu'en fait on pouvait plus poper de compute
de token en fait au niveau des compute, mais sinon globalement
on n'a pas trop de soucis à monter de version.
Justement,
Kube nous permet de faire des montées de version assez facilement grâce à ça.
Super Et de façon
on a un environnement de staging avant de passer en production.
Donc en fait on teste d'abord sur notre environnement de staging
que tout passe bien en fait dans le kube de staging
et ensuite une fois que ça c'est ok, on balance en production.
Alors pourquoi aussi on a différentes régions Chartres, Paris, Marseille, Chartres
à terme d'émergeur à plus de production
Ce sera un peu comme GCP,
notre région de déploiement, notre première région de déploiement.
Donc on déplorera sur Chartres en premier,
ensuite après sur Paris et dernièrement sur Marseille.
Ok voilà.
Oui. Ah bah il y avait une autre question.
Désolé.
Bonjour.
Merci.
Et puis ça fait se poser plein de questions.
Je vais en garder qu'une comme ça il en restera du temps pour la troisième.
C'est quoi ton principal apprentissage depuis que tu t'es
embarqué sur le club du cœur ?
Alors depuis que je me suis embarqué là dessus,
alors ça a été principalement OpenStack,
puisque c'est ce qui est littéralement le cœur du projet.
C'est là où on a le.
On a passé le plus de temps à essayer de le rendre stable
parce que c'est pas le truc le plus stable de la planète à l'origine.
Donc il a fallu très régulièrement aller
regarder dans le code pour comprendre comment les choses fonctionnent.
C'est là où on véritablement on a pris le plus de choses.
En fait, c'est vraiment sur la partie OpenStack puisque une fois que Openstack
a été fonctionnel, tout le reste était consommable très facilement.
Donc on a pu,
développer après les choses plus facilement.
Mais vraiment, c'est OpenStack qui nous a pris le.
Plus de temps.
Et qui nous a appris plus de choses
aussi. Parce que OpenStack,
ça paraît compliqué comme ça, mais en réalité c'est juste complexe.
Mais de manière assez simple dans le sens où ça reste des micros, des microservices
qui se connectent à des bouts d'infrastructure, qui exposent des API.
Quand vous avez compris ça.
Bah en réalité
c'est pas si compliqué que ça, c'est juste que d'un microservices à l'autre,
d'un projet OpenStack à l'autre, c'est pas forcément la même architecture.
Donc il faut à chaque fois réapprendre un petit peu comment ça fonctionne.
Mais la base est commune
c'est du même cache et du rabbit mq et c'est du MariaDB pour la DB.
Donc vous avez ces trois éléments de base qui sont communs à tout le monde.
Et ensuite après
il y a des petites différences d'architecture d'un projet à l'autre.
Oui, il y avait une question ici.
Bonjour, merci pour le talk
alors je me pose des questions surtout de run.
Vous êtes douze.
Il y a OpenStack et les.
La fly n’est plus à jour puisqu'on est 18.
Mais ça n'empêche pas que la question reste valable,
c'est que vous avez OpenStack plusieurs cluster.
Il faut gérer les montées de versions, il ne faut pas casser.
Comment ? Comment vous arrivez à 18 ?
Gérer tout ça c'est justement le.
Le choix vert kube tout de suite a été décisif pour nous
parce qu'on a déjà essayé et je ne l'ai pas détaille ici
parce que je n'avais pas le temps.
Mais on a commencé from scratch à déployer OpenStack et c'est absolument
pas scalable, ni facilement montable en termes de version.
On a essayé aussi la version docker ou d'ailleurs.
On commence à y revenir progressivement pour certains use cases
parce que c'est kube et pas forcément très utile dans tout.
Et Kubernetes
reste quand même la meilleure option par rapport à ce que nous on en fait.
Notamment parce que globalement, au niveau de la compétence,
au niveau de l'équipe, il y a beaucoup de gens qui font du kube.
Et au delà de ça, parce que c'est ce qui est “le plus facile”,
nous, on aime bien kube
parce que pour nous, on l'appelle l'outil astreinte friendly.
C'est à dire que globalement, s'il y a un nœud qui tombe,
il est capable de se débrouiller tout seul.
Donc pour nous,
ça nous permet justement en tant que bénévole
de ne pas avoir intervenir tous les trois quatre matins.
C'est pour ça en fait qu'on est sur du kube.
C'est pour ça qu'on a cette capacité quand même à avoir plusieurs
cluster OpenStack qui tournent sans que ça soit forcément très compliqué.
Parce que justement on a déjà entre guillemets passé beaucoup de temps
sur ce que nous on appelle l’underlay
C'est ce qui tourne sous le Cloud globalement,
pour que les choses soient faciles, que les déploiements soient,
comment dire, plus smooth on va dire au niveau de l'équipe
et que tout le monde travaille de la même manière.
C'est terminé.
Je suis désolé. Bah, si vous avez d'autres questions,
je suis disponible dans les couloirs, il n'y a pas de soucis.
Merci beaucoup.
Revivez la PlatformCon Live Day Paris 2025 ! Julien Briault, Ingénieur réseau / SRE chez Deezer, a relevé le pari de bâtir une plateforme cloud moderne, sécurisée, automatisée et résiliente… sans budget cloud, sans équipe dédiée à plein temps, et au sein d’une association caritative. Au programme : CI/CD, Infrastructure as Code, Kubernetes, OpenStack, observabilité, sécurité par défaut, et même du DNS/Storage/DB as a Service… Le tout, pensé pour être maintenable, scalable et frugal. Au-delà des choix techniques, c’est une approche contextuelle du Platform Engineering qui émerge : centrée sur l’impact, adaptée aux moyens et conçue pour durer, même quand les équipes tournent. Ici, chaque optimisation réalisée, ce sont potentiellement des millions de repas supplémentaires qui peuvent être distribués ! --- Retrouvez toutes nos offres et notre actualité : 🚀 Nos offres WeScale : https://www.wescale.fr/ CTO Office : https://www.wescale.fr/cto-office ScaleVision : https://www.wescale.fr/ScaleVision La Fabrik : http://www.wescale.fr/la-fabrik Le Training : https://www.wescale.fr/formations Renfort Technique : https://www.wescale.fr/renfort-technique 📰 Actualité PlatformCon Live Day Paris : https://platformconlive.fr/ Blog : https://blog.wescale.fr/ Newsletter : https://info.wescale.fr/inscription-n... Podcast : https://www.podcastics.com/podcast/we... LinkedIn : / wescale