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.