Devoxx France 2025 - Comment transformons-nous les Restos du Coeur en Cloud Provider ?

Dans un context où 1 euro = 1 repas, venez découvrir comment un groupe de bénévoles s'est mis en tête de créer un cloud dans le but de "faire plus avec moins".

Ainsi, nous explorerons les motivations derrière ce projet, discutant des défis spécifiques rencontrés lors de la mise en place d'une infrastructure ouverte à un environnement associatif.

Vous découvrirez pourquoi et comment Kubernetes et OpenStack ont apportés l’évolutivité et la résilience nécessaires pour soutenir les Restos du Cœur dans leur mission.

De l'installation d'une baie dans les WC jusqu'à la mise en place d'une infrastructure robuste et scalable, nous vous invitons à découvrir les dessous techniques du projet : architecture, choix de configuration et stratégies déployées pour assurer une flexibilité maximale. Entre anecdotes, leçons apprises et innovations, nous montrerons comment cette infrastructure a transformé le SI de l'association.

Pour terminer, rejoignez-nous pour découvrir comment cette aventure technologique hors norme a permis de faire économiser des millions de repas (par an) à l'association.

Qui sait, peut-être que vous aussi, après cette université, vous souhaiterez nous rejoindre ?

Transcript

2. https://youtu.be/pccSZLjKfVo?si=i37eXU3V6biEiOki
3. https://youtu.be/pccSZLjKfVo?si=i37eXU3V6biEiOki
4. Disclaimer 1 Nous n’avons pas transformés les Restos du Coeur en Cloud Provider
5. Disclaimer 2 Sorry pour le fran-glais
6. Disclaimer 3 On aime les acronymes RDC = Restos du Coeur République Démocratique du Congo Rez de chaussée
7. who we are ?
8. Stéphane Trognon Uptime 32y Lead SRE @ SRE (bénévole) @ #3615 Ma vie @StephaneTrognon @stephanetrognon.bsky.social
9. Julien Briault Uptime 26y Ingé réseau | SRE @ Auteur @ Linux Pratique Responsable (bénévole) @ #3615 Ma vie @ju_hnny5 @jbriault.fr
11. https://www.youtube.com/watch?v=dQw4w9WgXcQ L’info partagée @StephaneTrognon
12. Merci @StephaneTrognon / @ju_hnny5
13. Des questions ? Posez-les ici : 󰜼 https://slido.com 👀 #3420722 @ju_hnny5
14. La parole est à vous ! Des questions ? @StephaneTrognon
15. Sommaire • Un peu (beaucoup) d’historique • Comment gérer une infra comme un projet Open Source ? Quelle organisation ? • La prise de décision, comment fait-on ? • Un peu (beaucoup) de technique ◦ Quelles ont été nos erreurs ? • Quel est notre futur ? Nos challenges ? • Comment contribuer à ce projet ? @ju_hnny5
16. Objectifs 1. Contexte : Que vous compreniez le “pourquoi” de ce projet ? 2. Vous partager nos apprentissages 3. Documenter ce que l’on fait (pour les futurs bénévoles, avoir une trace de ce qui était fait/mis en place) 4. Que vous puissiez monter, vous aussi, votre plateforme de cloud ? Et remplacer AWS, GCP, OVH @StephaneTrognon
17. @ju_hnny5
18. @ju_hnny5
19. Il y a 39 ans …
20. “J’ai une petite idée comme ça (...) un resto qui aurait comme ambition, au départ, de distribuer deux ou trois milles couverts par jour.” @ju_hnny5
21. @ju_hnny5
22. Les Restos en quelques chiffres … 163 millions de repas servis (2023-2024) 112 Associations départementales 2348 Lieux d’accueil (centre de distribution, etc). 78 000 Bénévoles réguliers (dont 35 000 qui utilisent l’informatique au quotidien) + de 40 Applications fonctionnelles (Applications utilisées par les bénévoles au quotidien) @ju_hnny5
23. Le fonctionnement global des Restos @ju_hnny5
24. Le fonctionnement global des Restos Antenne/Association Nationale Délégations régionale Antennes/Associations Départementale Centres de distribution Maraudes Etc @ju_hnny5
25. Antenne/Association Nationale Délégations régionale Antennes/Associations Départementale Centres de distribution Maraudes Etc @ju_hnny5
26. Qu’est-ce qu’il m’a donné envie de rejoindre les Restos ? @ju_hnny5
27. La distribution alimentaire : Ce n’était pas pour moi. @ju_hnny5
28. Premiers constats à mon arrivée aux Restos @ju_hnny5
29. La solitude du début @ju_hnny5
30. De voir faire avec l’historique … @ju_hnny5
31. Le pc qui “traine dans un coin” @ju_hnny5
32. Le pc qui “traine dans un coin” Des sauvegardes ?? ☠ De la redondance ?!? 💀 Y’a quoi là dessus ? 👀 Ça x112 ? (spoiler : presque) @ju_hnny5
33. Infra v0.1 : Le “DC aux WC” Oui, oui, c’est bien un WC … @ju_hnny5
34. @ju_hnny5
35. @ju_hnny5
36. “Pay as you go” “Payez au fur et à mesure”
37. Antenne/Association Nationale Délégations régionale Antennes/Associations Départementale Centres de distribution Maraudes Etc @ju_hnny5
38. Infra v1 : 2 vraies baies @ju_hnny5
40. @ju_hnny5
41. Infra v2 : Des nouveaux* serveurs 👀
42. C’est installé où ? 👀 @ju_hnny5
43. Chartres @ju_hnny5 Le premier DC des Restos (interne)
44. On y stock… de la nourriture et de la donnée…
45. Infra v2 : 3 baies 52U ?
46. On a commencé à construire …
47. Infra v2 : 3 baies 52U - Premier POP
48. Mais pourquoi ce projet ? @ju_hnny5
50. Association Nationale On aime vraiment (beaucoup) les acronymes 👀 @ju_hnny5
51. @ju_hnny5 Antenne/Association Nationale Délégations régionale Antennes/Associations Départementale Centres de distribution Maraudes Etc
55. @ju_hnny5
56. Pourquoi ce projet ? L’informatique des Restos est conséquente et le cloud publique ça coûte cher, très cher. Des repas sont amputés chaque année pour faire fonctionner cette informatique essentielle au bon fonctionnement de l’association. @StephaneTrognon
57. Souveraineté Autonomie Stratégique @StephaneTrognon / @ju_hnny5
58. @StephaneTrognon
59. Une organisation • Uniquement que des bénévoles ◦ Pas toujours disponibles ▪ On est pas à 35h • Une bande de 11 personnes ◦ Technicien-nes ◦ Ingénieur-e-s @StephaneTrognon
60. La communication • Un outil “moderne” • Permet d’isoler les projets par channels • A une approche plus “dev” • Beaucoup d’intégrations ◦ Les webhooks • En dehors de l’infra @StephaneTrognon
61. La communication Bonjour, Nous vous faisons part de la maintenance programmée suivante : Objet : Objet de l'intervention Début : 1970-01-01 @ 01:00 (Paris) Fin attendue : 1970-01-01 @ 02:00 (Paris) Infrastructure affectée ----------------------- Composants : xxxxx Localisation : France – xxxx – Salle serveurs Détails : Décrire ici les raisons de l'intervention. Si vous avez des questions ou des remarques, n’hésitez pas à nous contacter.
62. La communication @StephaneTrognon
63. Une équipe 🦾 @StephaneTrognon
64. Une équipe 🦾 Xavier Nicolas Julien Mathéo Stéphane Etienne Steve +3 autres personnes Comment ça tu n’es pas sur cette slide ? 👀 @StephaneTrognon
65. La motivation 🔥 “Je ne faisais pas assez de réseau dans mon emploi, je suis venu faire ce qui me passionne tout en faisant une bonne action.” Etienne @StephaneTrognon “Je veux mettre mes compétence IT au service d’une belle cause.” Steve “J’ai réalisé que je pouvais donner un peu de mon temps et de mes compétence pour faire un truc qui rend le monde un peu meilleur..” Xavier “Je voulais utiliser openstack pour distribuer des repas plutot que des bombes.” Xavier “Et si mon métier, ma passion pouvait également aider les personnes dans le besoin.” Stéphane
66. Une équipe 🦾 • Découpage par expertise ◦ Infra (middleware, hardware) ▪ Réseau ▪ OpenStack ▪ Observabilité ◦ SRE ◦ Sécu • 3 référents par sujet (pour avoir un quorum) @StephaneTrognon
67. ReX : Intégration de Stéphane🦖 • Organisation ◦ Beaucoup de sujet ◦ Reprise de l’existant difficile ◦ Volonté Amélioration continue ◦ Liberté de proposition ◦ Rituel simple • Technique ◦ L’autonomie technique difficile ◦ Partage avec l’équipe ◦ Share Session ◦ Archi Review ◦ Nombreuses technologie variées @StephaneTrognon
68. La gestion de projet @StephaneTrognon
69. La v1 : Tout dans la tête • Ça va bien quand tu es tout(e) seul(e) ◦ Difficile pour la contribution d’autres personnes ◦ Difficilement maintenable sur le long terme • Humain est faillible par définition ◦ Source d’erreurs ou d’oublies @ju_hnny5
70. Un outil pour nous aider ? @ju_hnny5
71. La v1-bis : Planner ? • Montrer ce que l’on fait ◦ Objectif : avoir de la transparence ◦ Avoir des “tickets” pour se remémorer • C’est bien l’outil mais il faut avoir une méthodologie ◦ Lance les idées dedans ◦ On trie pas ◦ On organise pas @ju_hnny5
72. Et si on re-challenge tout ? @StephaneTrognon
73. La v2 : Gestion de projet en équipe https://github.com/makeplane/plane @StephaneTrognon
74. Gestion de projet en équipe Une superbe alternative OSS à Jira et Notions. Découpage en plusieurs sous projets : @StephaneTrognon
75. Nos rituels @StephaneTrognon / @ju_hnny5
76. Rituel 1 : Points de synchro Tous les lundis soir à 21h. @StephaneTrognon
77. Rituel 2 : Share Sessions Un complément de la documentation, pour donner du contexte à un sujet technique. @ju_hnny5
78. Rituel 3 : Tech talks Partage d’un sujet technique, dans le but de continuer la veille techno d’un sujet qui pourrait avoir un intérêt pour l’équipe. @ju_hnny5
79. Recrutement De bénévoles @ju_hnny5
80. Processus de recrutement de bénévoles - Première rencontre (Julien ou autre personne de l’ équipe) - Rencontre de l’équipe lors de l’un de nos point de synchro - Onboarding (avec support + doc) de la personne @ju_hnny5
81. Le Quorum Et le vote démocratique associatif @ju_hnny5
82. @StephaneTrognon / @ju_hnny5
83. Algo de Feynman 1. Écrire le problème 2. Réfléchir 3. Écrire la solution https://ploum.net/2024-06-05-complexite-simplicite.html
84. Algo de Feynman • Se matérialise en 2 choses : ◦ ADR (Achitecture Decision Record) ◦ Architecture Review @StephaneTrognon
85. ADR : Un template pour simplifier l’écriture @StephaneTrognon https://github.com/cloudducoeur/docs-template
86. Archi-review : Un template pour simplifier l’écriture @StephaneTrognon https://github.com/cloudducoeur/docs-template
87. … et la bienveillance ??? “Read The Fucking Manual” “Lis le putain de manuel” @StephaneTrognon / @ju_hnny5
88. Très bon article sur le sujet : https://www.lvlup.fr/blog/rtfm-bienveillance “Quand est-ce qu’on a décidé qu’il serait normal de mal se parler ?”
89. Le RTFM problématique ? • On est des bénévoles …. Mais ça s’applique aussi à des salariés ! • Ça veut dire que la réponse est obligatoirement dans la doc ? ◦ Spoiler : tout n’est pas forcément dans la doc … • Une personne qui souhaitait se faire aider sera montée en compétences, elle trouvera plus naturel de reproduire ce comportement. @StephaneTrognon / @ju_hnny5
90. fIaaC ? @ju_hnny5
91. IaaC IaaC Infra As A Console Infra As A Code Avant Maintenant @ju_hnny5
92. Les offres @ju_hnny5
93. Nos offres Regions Edge Expertise IaaS, PaaS (OpenStack, Kubernetes) Accompagnement technique (Formation, consulting) IoT (Exemple : sondes) @StephaneTrognon / @ju_hnny5
94. Nos offres : Les régions Fournir des contrats d’APIs afin de standardiser l’accès à l’infrastructure, on en parlera un peu plus tard. 🤫 Accessible via : - La WebUI (Horizon) - La CLI (CLI OpenStack) - Ou le provider Pulumi/Terraform (Provider officiel OpenStack) @ju_hnny5
95. Nos offres : L’expertise - Parce que ça coûte cher pour une association qui fonctionne en permanence en “best-effort” - Permet de fournir une technique maintenable sur le long terme @StephaneTrognon
96. Nos offres : L’edge - l’IoT a une place importante dans le SI des Restos - Pour le présent et le futur @ju_hnny5
97. @ju_hnny5
98. Les 11 commandements @ju_hnny5
99. Eco-conception @ju_hnny5
100. 1 - L’éco-conception Infrastructure issue de 99% de dons : - Doit continuer à le rester, recherche constante de nouveaux dons ; - Pas d’achat de matériel au maximum (pour des raisons environnementales et économiques). @ju_hnny5
101. 2 - L’éco-conception Faire durer un maximum de temps du matériel destiné au rebut : - Augmenter la RAM, upgrade du CPU des machines, passage à du SSD - Conserver des pièces en stock en cas de dysfonctionnement matériel @ju_hnny5
102. 3 - L’éco-conception Choix de matériel pour leur efficacité énergétique (Cf la loi de Moore) Source : https://blog.octo.com/la-loi-de-moore-est-morte-et-c%27est-une-bonne-nouvelle @ju_hnny5
103. 4 - L’éco-conception La légèreté logicielle - On essaie, au maximum, d’embarquer des logiciels qui sont moins consommateurs de : - RAM - CPU - Stockage Exemple : remplacement d’Ubuntu Server par Debian, gain de 40% sur le stockage et la RAM utilisée (pour l’os d’undercloud). @ju_hnny5
104. 5 - Une plateforme ouverte - Une plateforme qui ne nécessite pas d’humain pour accéder/consommer des services - Les services sont consommables via des APIs - Ouverte à tout le monde aux Restos (techs) - Effort concentré @ju_hnny5
105. 6 - Des technologies ouvertes - Favoriser des technologies libres quand c’est possible voir Open Source - Favoriser les technologies qui sont soutenues par une fondation plutôt qu’une entreprise sauf : - Si pas le choix technique - Si l’entreprise nous aide - Si ça répond totalement à notre besoin (acceptation du risque potentiel) @ju_hnny5
106. 7 - Mesurer et optimiser - L’observabilité au coeur du projet pour optimiser au mieux les ressources et contrôler les coûts. - Pour être proactif - L’astreinte bénévole c’est pas simple ;) @StephaneTrognon
107. 8 - Apporter l’outillage nécessaire - Pour éviter de se retrouver avec des données qui fuitent sur des plateformes publiques gratuites - Aider les équipes au quotidien sur le terrain (gestion des mots de passe, partage d’informations, sondes, etc). @ju_hnny5
108. 9 - La sécurité : une nécessitée - “Parce que c’est l’affaire de tous, si c’est l’affaire de tous c’est celle de personne” - Notre rôle c’est d’héberger pour d’autres, il est crucial que la sécurité soit notre affaire @StephaneTrognon
109. 10 - La veille techno - Assez personnel mais on le partage - Canal de partage Slack @StephaneTrognon / @ju_hnny5
110. 11 - Instaurer un climat de confiance - La preuve par l’exemple - Les processus - La création de l’ÉQUIPE - Faire le lien avec l’AN au travers d’accompagnement @StephaneTrognon / @ju_hnny5
111. La parole est à vous ! Des questions ?
112. @StephaneTrognon
113. Définitions AZ (Availability Zone) ◦ Une AZ, ou “zone de disponibilité” s’apparente à un datacenter ou une baie. Dans notre cas, un datacenter. Un datacenter ◦ Un datacenter est un endroit où sont stockées les données. Une région ◦ Une région, au sens “cloud” du terme signifie est attaché à une ville, par exemple, dans notre cas, la région “Chartres” possède 2 datacenters (AZs) nommées “Lucé/AD28” et “Le Coudray/CCIN”. @StephaneTrognon
114. Overlay ≠ Underlay Ce que les gens voient vs Ce que nous voyons Définitions @StephaneTrognon
115. Overlay ≠ Underlay Ce que les gens utilisent vs Ce que nous maintenons Définitions @ju_hnny5
116. Présence Nationale 3 régions - Chartres - Marseille - Paris @ju_hnny5
117. @ju_hnny5 Un très grand nombre de sites
118. Première région : Chartres @ju_hnny5
119. Seconde région : Paris @ju_hnny5
120. Troisième région : Marseille @ju_hnny5
121. Que faut-il pour faire un cloud ? @StephaneTrognon
122. Quel(s) besoin(s) ? • Si c’est juste de la VM classique = Pas besoin de monter une plateforme de cloud • Si vous utilisez des services sur un cloud publiques, si oui, lesquels ? • Quelle volumétrie ? Besoin de scale ? @StephaneTrognon / @ju_hnny5
123. Le contexte particulier des Restos … • Comme pour certains centres de distribution, les baies en DC nous sont offertent (d’ailleurs on recherche sur nos 3 régions), sauf que : ◦ C’est à durée limitée (souvent 3 ans renouvelable) ◦ On peut bouger donc à tout moment ▪ Comme un centre de distribution @StephaneTrognon
124. Le contexte particulier des Restos … ◦ La capacité électrique est limitée (souvent 3kVA) ◦ La taille de la baie est plus ou moins toujours la même @ju_hnny5
125. Design : Dans sa globalité • Chaque région est identique (au maximum) • Chaque AZ est identique (au maximum) ◦ Interconnectées (inter-az) @ju_hnny5
127. On a besoin de vous ! Si vous avez de la place en datacenter, on recherche des baies sur Paris et Marseille.
128. La parole est à vous ! Des questions ?
129. 4.1 - Une source de vérité @StephaneTrognon
130. Une seule source de vérité ? • V1 : Spreadsheet pour stocker les informations • V2 : Inventaire de Rudder + Ansible + OctoDNS @StephaneTrognon
131. CMDB Configuration Management Database @StephaneTrognon
132. Pour quels besoins ? • Stocker l'inventaire notre hardware en stock • Définir les ranges d’IPs que nous allons utiliser • Base pour le DNS de l’infra • Réserver des IPs sans risque d’overlap • Etre la source d’inventaire pour nos outils d’automatisation (OctoDNS, Ansible, Pulumi, MaaS, etc). @StephaneTrognon
133. GLPI ? • Besoin d’une CMDB qui s’intègre avec notre outillage • CMDB qui reste “simple” d’utilisation ◦ La partie IPAM … • Besoin d’une CMDB “moderne” ◦ Peu d’intégration avec Ansible, Terraform, Pulumi, etc. • Très orienté IT, peu infra “moderne” @StephaneTrognon
134. V3 @StephaneTrognon
135. Photo non contractuelle* 😜 @StephaneTrognon
136. @ju_hnny5
137. • Ça marche bien mais ça a quelques problèmes : ◦ Ça casse avec les upgrades Netbox (Cc Python) ◦ Ça insite de déployer le token Netbox sur chaque noeud ▪ Pas de contrôle en amont de ce qu’il rentre dans la CMDB @ju_hnny5
138. Un peu de contrôle à l’entrée @StephaneTrognon / @ju_hnny5
139. 4.2 - Le réseau
140. Pour quels besoins ? • Pour des besoins internes et externes ◦ Le cloud à une portée publique de part l’exposition d’un certain nombre de services sur internet • Doit être fiable, résilient et avec une faible latence. • Diff entre underlay et overlay @ju_hnny5
141. Connecter ce beau monde @ju_hnny5
142. Le réseau 💀 • Réseau Out of band (OOB) • Réseau 1G (pour le management, provisionner les machines) • Réseau 10G 100G pour la production • V1 = 3 tier (L2) ◦ vxlan / vlan • V2 = Leaf/Spine/Super spine (Full L3) ◦ BGP EVPN + vxlan @ju_hnny5
143. Réseau Haute Performance @ju_hnny5
144. OPA : Réseau haute performance Réseau hérité de HPC : cluster de calcul (top 500 des plus gros calculateurs de la planète) @ju_hnny5
145. OPA : Réseau haute performance @ju_hnny5
146. OPA : Réseau haute performance @ju_hnny5
147. Infiniband vs Ethernet @ju_hnny5
148. Infiniband (OPA) Le réseau favoris des supercalculateurs, des hyperscalers et de l’IA ! Avantage(s) : - Faibles latences - Coûte pas très cher (surtout en occasion) - Gros débit (100G) Désavantage(s) : - Uniquement en local (sur une AZ) @ju_hnny5
149. Infiniband + Ethernet @ju_hnny5
150. Ethernet (fibre) Le réseau pour interconnecter les AZs, les régions. Avantage(s) : - Support du VXLAN - Protocoles de routage Désavantage(s) : - Coûte plus cher - Moins performant (10G) - Suffisant pour l’extérieur @ju_hnny5
151. Ethernet (RJ45) Le réseau pour l’IPMI (BMC) et l’OOB mais aussi le management/provisioning Avantage(s) : - Ça coûte pas cher - 1G de bande passante largement suffisant pour cet usage Désavantage(s) : - Ne peut pas être utilisé en prod (débit limité == 1G) @ju_hnny5
152. Switch console Appelé “SMA” chez nous pour “Save My A**” @ju_hnny5
153. NetDevOps : Quand le “DevOps” se met au réseau https://blog.jbriault.fr/netdevops-quand-le-devops-se-met-au-reseau/ @ju_hnny5
154. SDN Software Defined Network @ju_hnny5
155. Internet @ju_hnny5
156. Réseau de backbone “Maîtriser les tuyaux” @StephaneTrognon / @ju_hnny5
157. Pourquoi ? Réduire : - Nos dépendances à des opérateurs extérieurs (par point de présence) - Autonomie stratégique : les adresses IP nous appartiennent et ne nous sont pas facturées (comme ça peut être le cas chez certains cloud providers). - Les coûts d’accès réseau - Les latences @ju_hnny5
158. Pourquoi ? La portabilité - Tout comme pour les centres de distribution, nous pouvons être amené à bouger à n’importe quel moment - Posséder son propre réseau de backbone + ses adresses IP (v4/v6) permet ainsi d’éviter une interruption de service en cas d’indisponibilité d’une baie en cas de portabilité @ju_hnny5
159. Du VPN @ju_hnny5
160. Autonomie @StephaneTrognon
161. Autonomie des équipes Dans le fonctionnement actuel : - Pour chaque exposition publique d’un service, l’équipe du CDC doit intervenir pour modifier la configuration des edgelb (load-balancers HAProxy). - Crée donc une dépendance pour la consommation des services à l’équipe du CDC @StephaneTrognon / @ju_hnny5
162. V2 : Vue simplifiée @StephaneTrognon / @ju_hnny5
163. Only IPv6 ? @ju_hnny5
164. Only IPv6 à l’origin - Un pari risqué ? - Problème du “pauvre”, nous passons LIR (opérateur) - Les ranges d’IPv4 ça coûte super cher (environ 11k repas) - On cherche des mécènes si jamais 😜 - Notre origin (les régions) n’est disponible qu’en IPv6 @StephaneTrognon / @ju_hnny5
165. Only IPv6 à l’origin - La dual stack disponible via le CDN : - IPv4 - IPv6 - La grande majorité des sites sont accessibles en IPv6 - Certains services sont mis à disposition à l’origin en IPv4 via des nat gateway (exemple : IoT) @StephaneTrognon / @ju_hnny5
166. Only IPv6 à l’origin @StephaneTrognon / @ju_hnny5
167. Finalité du backbone • Autonomie pour les équipes ◦ Peut réserver une adresse IP en fonction de quotas dans le cloud sans dépendance directe à l’équipe du CDC ! • Réduction des coûts • Meilleurs débits à moindre coût • Evolutivité @StephaneTrognon / @ju_hnny5
168. On a besoin de vous ! Vous êtes opérateur, on a besoin de bande passant (peering), cross-co, et des liens type L2.
169. La parole est à vous ! Des questions ?
170. 4.3 - Le DNS
171. C’est toujours la faute du DNS
172. Le DNS d’underlay* • Se doit d’être toujours disponible • Distribué par définition • Parce que rentrer des IPs en dur dans ses services c’est le mal !!!! • Isolation de chaque strate @StephaneTrognon
173. Le DNS Qui fait autorité (détient les zones) : Qui résoud (sait auprès de qui chercher l’info) : @StephaneTrognon / @ju_hnny5
174. Stacks par AZ, inter-AZ @ju_hnny5
175. Stacks par AZ, inter-AZ @ju_hnny5
176. Déploiement des enregistrements DNS @ju_hnny5
177. Déploiement des enregistrements DNS • Nous sert pour les records : ◦ Internes (PowerDNS) ◦ Externes (Gandi) • Permet d’avoir un format unique pour créer nos records (pour les records statiques) • Récupérer les records depuis la source de vérité (Netbox) @ju_hnny5
178. Déploiement des enregistrements DNS + https://github.com/peteeckel/netbox-plugin-dns @StephaneTrognon
179. Déploiement des enregistrements DNS @StephaneTrognon / @ju_hnny5
180. Déploiement des enregistrements DNS @ju_hnny5
181. Déploiement des enregistrements DNS
182. L’importance des TLDs Isoler en fonction du besoin. Ne pas mettre tous ses oeufs dans le même panier. En cas de problème sur un TLD commun, vous êtes complètement aveugle. Le choix fait : - Pour le réseau : .net - Pour l’infra : .org - Pour l’accès publique (interne) : .cloud @ju_hnny5
183. Ne pas être aveugle en cas de problème = Séparation des besoins @StephaneTrognon / @ju_hnny5
184. “Ne pas mettre tous ses oeufs dans le même panier” @StephaneTrognon / @ju_hnny5
185. aucoeurdu. cloud @StephaneTrognon
186. AuCoeurDu.Cloud @StephaneTrognon
187. Au Coeur Du. Cloud @StephaneTrognon
188. console. aucoeurdu. cloud <service> .<region>. aucoeurdu. clou d Point d’entrée unique : Accès aux services cloud de manière régionalisée : @ju_hnny5
189. <service> .<region>. aucoeurdu. clou d Accès aux services cloud de manière régionalisée : Exemple : swift-1 .paris. aucoeurdu. cloud ns-2.marseille. aucoeurdu. cloud @ju_hnny5
190. doc.aucoeurdu. cloud Documentation accessible : @ju_hnny5
191. 4.4 - Du bare-metal
192. Du bare-metal @ju_hnny5
193. Du bare-metal • Globalement les serveurs ont en moyenne plus de 4 ans, moins de 10 ans. • A besoin d’être automatisé ◦ Eviter l’installation avec une “clé USB” • Uniformisation du hardware et des marques supportées (exemple : Dell, SuperMicro et Lenovo) @StephaneTrognon
195. On a besoin de vous ! Vous avez des équipements qui prennent la poussière … N’hésitez pas à nous contacter !
196. Du bare-metal as a service • Recherche de solutions @StephaneTrognon
197. Du bare-metal as a service https://github.com/canonical/maas - AGPLv3 • MaaS fournit une API consommable • MaaS permet de mettre à jour les logiciels embarqués (typiquement IDRAC) • Utilisable avec Terraform/Pulumi • Fournit un CLI • Fournit un WebUI KISS 😎 @ju_hnny5
198. Du bare-metal as a service @ju_hnny5
199. Du bare-metal as a service Répond à notre architecture “cloud” au sein d’une zone de disponibilité (AZ). @StephaneTrognon
200. Gérer notre bare-metal comme une VM @StephaneTrognon
201. Du bare-metal et le cycle de vie - Allumer/éteint automatiquement la machine via l’interface BMC (exemple IDRAC chez Dell) - Permet de déployer l’OS temporaire et définitive via le réseau en PXE et iPXE. @ju_hnny5
202. Du bare-metal et le cycle de vie • New ◦ La machine boot en PXE, MaaS détecte les paramètres BMC • Commissioning ◦ Remonte l’inventaire dans MaaS de la machine (CPU, RAM disque, NICs, GPUs) • Ready ◦ La machine est configurée côté BMC, MAAS peut gérer le “power control” @ju_hnny5
203. Du bare-metal et le cycle de vie • Allocated ◦ Configuration de la machine, RAM, bonding, addressing, RAID, LVM • Deploying ◦ La machine est ON avec l’OS et la configuration déployée • Releasing ◦ L’utilisateur a terminé avec cette machine, on peut wipe le disque et la réutiliser pour autre chose @ju_hnny5
204. 4.5 - Sources, Artefacts, Registry @StephaneTrognon
205. Nos commandements Une seule source de vérité tu auras Des déploiements totalement automatisés tu créeras Sous forme de MR tu contribureras @StephaneTrognon
206. Du code partout, pour tout ! @StephaneTrognon
207. Construction d’une Forge @StephaneTrognon
208. La gestion des artefacts - V1 : - States Terraform - States Pulumi - V2 : - des ISOs - Package Linux - … @StephaneTrognon
209. Et nos images Docker ? - V1 : - Merci au Docker Hub - V2 : - Mise en place d’Harbor - Normalisation de nos images - Proxy Cache sur chaque AZ @StephaneTrognon
210. Et nos images Docker ? @StephaneTrognon
211. La parole est à vous ! Des questions ?
212. 4.6 - Micro-services @StephaneTrognon
213. Instant pub pause ! @StephaneTrognon
214. Under-undercloud Sous le capot @ju_hnny5
215. @ju_hnny5
216. Kube… pourquoi ? • Faciliter les déploiements et la mise à l’échelle des éléments de “l’undercloud”* • Gestion “as code” + • Astreinte friendly 🩷 @ju_hnny5
217. Kube… pourquoi ? @ju_hnny5
218. Blue/Green pattern @ju_hnny5
219. Le véritable “undercloud” Le moteur @ju_hnny5
220. @ju_hnny5
221. Quoi ?! OpenStack en 2025 ?! @ju_hnny5
222. Pourquoi ? @StephaneTrognon / @ju_hnny5 • Fournit les contrats d’API pour rendre l’infrastructure accessible et ouverte. ◦ Permet la gestion via : ▪ WebUI ▪ Provider Terraform/Pulumi ▪ CLI • Ce n’est pas une technologie “hype” non-maintainable. • Se connecte à nos bouts d’infrastructures existants*
223. @ju_hnny5
224. @ju_hnny5 OpenStack et ce dont il a besoin pour fonctionner
225. @ju_hnny5 OpenStack et les micro-services
226. @ju_hnny5
227. OpenStack from scratch (via Ansible) @ju_hnny5 • Horrible à maintenir (montées de versions) • Python 3 … (Cc les dépendances) • Ça ne scale pas des masses …
228. @ju_hnny5 V2 - OpenStack w/ Kubernetes
229. @StephaneTrognon / @ju_hnny5
230. @StephaneTrognon / @ju_hnny5
231. @ju_hnny5 Overlay Underlay Du DNS as a Service
232. @ju_hnny5 Gérer ses secrets
233. Kube-ception ? @ju_hnny5
234. @ju_hnny5
235. Vue simplifiée du fonctionnement @ju_hnny5
236. @ju_hnny5 Underlay Overlay Ça tourne dans des vms
237. @ju_hnny5 Ici pour être plus exact !
238. @ju_hnny5 Overlay Underlay De la DB as a Service
239. 4.7 - Stockage @StephaneTrognon
240. V1 - TrueNas @ju_hnny5 Avantage(s) : - Une solution “pas chère” - Open Source - Support le NFS Désavantage(s) : - Qui ne scale pas vraiment … - La résilience … - Utile quand on n’a pas une grosse volumétrie de données
241. @StephaneTrognon
242. V2 - Ceph, partout ! @ju_hnny5
243. @StephaneTrognon Overlay Underlay Du Storage as a Service
244. Schrodinger Ceph Ne pas reproduire cette cascade chez vous @ju_hnny5
245. V2 - Schrodinger Ceph @ju_hnny5 Infrastructure basée sur des dons : - Tailles de disques pas forcément identiques - Des disques de 1TO, 2TO et 8TO - Des disques de marques différentes - Certaines marques sont à éviter …
246. La parole est à vous ! Des questions ?
247. 4.8 - Hyperviseurs (Compute) @StephaneTrognon
248. @StephaneTrognon
249. @ju_hnny5
250. @ju_hnny5 MOCHE Utilisé dans l’underlay
251. Hyper-convergence Pour un max de puissance dans le moins d’espace possible @StephaneTrognon
252. V1 : Architecture classique 📄 Hyperviseur A Hyperviseur B Hyperviseur C Hyperviseur D Stockage A Stockage B Stockage C Stockage D @StephaneTrognon
253. V2 - Architecture Hyper-convergée 📄 Hyperviseur A + Stockage Hyperviseur B + Stockage Hyperviseur C + Stockage Hyperviseur D + Stockage @ju_hnny5
254. V2 - Architecture Hyper-convergée 📄 • Choix lié principalement à : ◦ La taille des baies que l’on a à disposition ◦ La techno de stockage utilisée (Cc Ceph) ◦ Ça coûte moins cher • Ça a quand même quelques soucis : ◦ La maintenance est plus compliquée (Cc les reboots) ◦ Faut un réseau qui dépote et des machines avec de bons CPUs @ju_hnny5
255. 4.9 - Observabilité @StephaneTrognon
256. V1 - Du monito…quoi ? • Le monitoring était inexistant ◦ “Attendre que ça gueule” • Arrivée rapide de plein de machines/vms ◦ Besoin d’automatisation et de monitoring • Utilisation de Prometheus seul en v1 @ju_hnny5
257. V1 - Du monito…quoi ? • Le fonctionnement de la métrologie (via Prometheus notamment) : @StephaneTrognon
258. V1 - Du monito…quoi ? • Le fonctionnement de la métrologie (via Prometheus notamment) : @StephaneTrognon
259. @ju_hnny5
260. V3 - Arrivée de VictoriaMetrics https://www.youtube.com/watch?v=bzLtWjUj2k0
261. V3 - Arrivée de VictoriaMetrics @StephaneTrognon/@ju_hnny5
262. Les sondes “Blackbox” @ju_hnny5
263. Les sondes “Blackbox” • Utilisation de l’exporter “Prometheus Blackbox Exporter” ◦ Simple binaire, un peu chia** à configurer • Une VM présente dans un datacenter différent de nos propres DCs (VPS, etc). @ju_hnny5
264. Status Page avec Uptime Kuma Pour les utilisateurs finaux : - Éviter que les gens viennent ping en direct “ça marche paaaaasssssss” - En réalité ils viennent quand même :( Désavantage de la solution (challenge en cours) : - Ne supporte pas Terraform pour l’ajout de nouvelles sondes - Ne se connecte pas à Prometheus/VictoriaMetrics @StephaneTrognon
265. Le service discovery avec … @StephaneTrognon
266. Arrivée de Consul • Base clé/valeur utilisant le protocole Raft pour la HA (comme ETCD de Kubernetes) • Fonctionne en mode client (agent) / server • Possède un DNS intégré (non utilisé pour le moment) @StephaneTrognon
267. Arrivée de Consul Une machine est déployée, elle est automatiquement supervisée. @StephaneTrognon
268. Réécriture et libération @ju_hnny5
269. 4.10 - Energie @ju_hnny5
270. Une gestion de l’énergie particulière @ju_hnny5
271. OpenBareMetal : C’est pas Versailles ici ! Julien Briault (@ju_hnny5) julien.briault@restosducoeur.org
272. @ju_hnny5 L’alimentation électrique - Contrat à la consommation Plus je consomme, plus je paie … - “Plus un appareil consomme, plus il chauffe …”
273. RAPL “Running Average Power Limit” @ju_hnny5
274. @ju_hnny5 https://github.com/hubblo-org/scaphandre
275. @ju_hnny5 OpenBareMetal
276. @ju_hnny5 OpenBareMetal • Ce n’est pas “Open Bar e ” ◦ Si la machine n’est pas disponible (car en mauvaise santé) il ne la déploie pas. • Si le pool mis à disposition n’est plus disponibles ◦ Il vient interroger les machines qui sont hors-pool et non-allouées (mais en “ready”) ◦ Dans le cas contraire, l’outil alerte
277. @ju_hnny5 OpenBareMetal
278. @ju_hnny5 @ju_hhny5
279. @ju_hnny5 OpenBareMETALLLLLLLL !!!!!!! • Vient réaliser une requête PromQL (MetricsQL) ◦ Par défaut, toutes les 10s ◦ Sur un service donné (exemple, taux d’utilisation d’un pool KVM) ◦ Sur les sondes de température de la salle serveur ◦ https://crates.io/crates/prometheus-client • OpenBareMetal est un micro-service, fournit avec une Helm Chart pour l’installer
280. @ju_hnny5 OpenBareMETALLLLLLLL !!!!!!! • Prise en compte de plugins (scripts) de pre/post provisioning ◦ Par défaut en bash • Configuration des seuils ◦ Seuil de déclanchement du provisioning ◦ Seuil de maintient ◦ Seuil de déclanchement du dé-provisioning ▪ Application du plugin (script) de drain/taint si besoin.
281. @ju_hnny5 OpenBareMETALLLLLLLL !!!!!!! • Une CLI simple : ◦ obmetalctl pool list ◦ obmetalctl node list ◦ obmetalctl scale —pool <pool_name> —force
282. @ju_hnny5 Le résultat … • Division par 3 de la consommation électrique /an/pop • Plus besoin d’humain pour faire “scale” le matériel.
283. La parole est à vous ! Des questions ?
284. @StephaneTrognon
285. 5.1 - Upgrades @StephaneTrognon
286. Mises à jours OS Automatique https://github.com/normation/rudder @ju_hnny5
287. Mises à jours OS Automatique - Campagnes de patch management totalement automatisées 👀 @ju_hnny5
288. • Vérifier l’application du benchmark CIS • Alerter sur les connexions hors heures ouvrées • Alerter en cas de CVE >= 7.0 sur Slack/Teams Un SIEM/XDR ? 👀 @StephaneTrognon
289. Mises à jours des régions • Région de “Chartres” ◦ Première région, région dite de “test” à terme ◦ Elle permet de valider que les mises à jours fonctionne. ◦ N'hébergera à terme que de la “sandbox”, “preprod (staging)” • Ordre des upgrades : Région “Chartres” > “Marseille” > “Paris” @StephaneTrognon
290. Notifications dans des canaux dédiés dans Slack ◦ Via abonnement aux flux RSS des fournisseurs (comme Debian / Ubuntu) ou encore l’ANSSI Personne ne regarde vraiment ces alertes ◦ Car la grande majorité ne nous concernent pas (Coucou les alertes Microsoft) ◦ Trop d’endroits différents ◦ L’information n’est pas claire et pas uniformisée V1 - Maintenir une veille active @ju_hnny5
291. OpenCVE @ju_hnny5
292. Pourquoi le mettre en place? • Recevoir uniquement des alertes concernant notre infrastructure ◦ Lié à un vendor et/ou une version spécifique d’un produit • Comprendre plus facilement quel système est impacté par la faille ◦ Format unique d’affichage des informations • Traiter plus efficacement et rapidement les problèmes de sécurité @ju_hnny5
293. A quoi ressemble la notification RSS OpenCVE @ju_hnny5
294. 5.2 - Contrôle des accès @StephaneTrognon
295. L’IAM @StephaneTrognon
296. L’IAM @StephaneTrognon
297. Important pour la convergence et l’accès aux ressources des régions. Un utilisateur obtient des quotas alloués en fonction de son poste et des informations stockées sur son profil (notamment dans Keycloak). L’IAM @StephaneTrognon
298. 2 règles importantes : • Les évolutions de configuration des machines sont appliquées via de la CI|CD • En cas de besoin, il est possible de se connecter via : Pas de connexion directe sur les machines ? @StephaneTrognon
299. @StephaneTrognon
300. Bus- factor @ju_hnny5
301. La documentation
302. La documentation 1. L'onboarding pour les nouveaux arrivants. 2. L'architecture, vue d'ensemble de l'infrastructure et de son fonctionnement. 3. L'architecture détaillée qui vise à fournir le détail de chaque stack technique déployée. 4. Les runbooks qui visent à documenter les actions à réaliser dans le cadre du "run". 5. Les astuces/howtos 6. Les architecture review 7. Les post-mortems @StephaneTrognon / @ju_hnny5
303. @StephaneTrognon / @ju_hnny5
304. La gestion multi-envs @StephaneTrognon / @ju_hnny5
305. L’abstraction et l’uniformisation • Une CLI unique pour abstraire et uniformisé le travail collaboratif. @ju_hnny5
306. @ju_hnny5
307. L’abstraction et l’uniformisation ❯ The ultimate helper for Le Cloud du Coeur Usage: cdctl [command] Available Commands: common Common usage completion Generate the autocompletion script for the specified shell devops DevOps made easy help Help about any command infra Manage infrastructure network Manage network onboarding Onboarding made easy version Show version information Flags: --config string config file (default is $HOME/.cdctl.yaml) -h, --help help for cdctl Use "cdctl [command] --help" for more information about a command. @ju_hnny5
308. L’abstraction et l’uniformisation ❯ mkdir nginx-provisioning ❯ cd nginx-provisioning ❯ cdctl devops ansible init-repo --application "Nginx" --group "nginx_server" . Created inventory/group_vars/nginx_server directory. You can now edit it to add your Ansible group variables. Created inventory/hosts.yml. You can now edit it to add your Ansible hosts. ❯ tree . . ├── README.md ├── Taskfile.yml ├── ansible.cfg ├── inventory │ ├── group_vars │ │ └── nginx_server │ │ └── consul.yml │ └── hosts.yml ├── playbook.yml └── roles 4 directories, 6 files @ju_hnny5
309. L’abstraction et l’uniformisation ❯ cdctl common search “nginx” ❯ cdctl infra devices list -s <POP/AZ_NAME> +----+----------------+---------+-----------+------+--------------+--------------+------------------+----------------+ | ID | NAME | STATUS | SITE | RACK | ROLE | MANUFACTURER | TYPE | IP ADDRESS | +----+----------------+---------+-----------+------+--------------+--------------+------------------+----------------+ | 17 | restotest001 | Active | AD28-CHA1 | BS001| poc | Dell | PowerEdge R730xd | 10.10.10.10/24 | | 18 | restotest002 | Active | AD28-CHA1 | BS001| poc | Dell | PowerEdge R730xd | 10.10.10.11/24 | +----+----------------+---------+-----------+------+--------------+--------------+------------------+----------------+ @ju_hnny5
310. Point d’entrée des dépôts Git @StephaneTrognon
311. Point d’entrée des dépôts Git • Taskfile = Makefile plus moderne ◦ Plus naturel pour des non-devs (Cc yaml) • Est appelé par la CI ◦ Permet de run les tâches localement (hors CI) • Logique identique sur chaque dépôt (peu importe l’outil appelé : Ansible, Terraform, Pulumi) ◦ task check ◦ task apply @StephaneTrognon
312. Point d’entrée des dépôts Git @StephaneTrognon
313. Le déploiement de configuration @StephaneTrognon
314. • Stockage des roles et collections dans Gitlab • Chaque applicatif séparé possède son dépôt Git qui lui est dédié ◦ Exemple : ▪ Ansible/Collections/rudder ▪ Ansible/Playbooks/rudder-provisioning • Chaque déploiement est réalisé via la CI (Gitlab Runner) ◦ Les runners sont éphémères, sont créés dans Kubernetes en fonction du besoin. : Déploiement de configuration @StephaneTrognon
315. Pulumi et … @ju_hnny5
316. • Stockage des projets dans Gitlab ◦ Des states dans MinIO • Utile pour abstraire l’accès à certains éléments d’infrastructure. ◦ Exemple : https://blog.jbriault.fr/pulumi-proxmox-cloudinit/ : Configuration et abstraction @ju_hnny5
317. https://www.youtube.com/watch?v=IAwu-WCN6Nw @ju_hnny5
319. @ju_hnny5
320. *Environ 1,5 millions de repas distribués en plus. @StephaneTrognon
321. *Environ 6 millions de repas distribués en plus. Sondes de température @ju_hnny5
322. Context • Projet né à l’AD28 comme un autre projet en lien* • La supervision + alerting des chambres froides ◦ ça coûte cher, très cher (coût /an) ◦ différent d’une AD à une autre @ju_hnny5
323. Context Pour faire fonctionner un tel système il faut : Des serveurs avec : @ju_hnny5
324. Sous le capot : Un peu de Technique … • Matériel standard ◦ ESP32 ou 8266 (standard de l’IoT) • Sondes certifiées pour de l’alimentaire @ju_hnny5
325. Sous le capot : Un peu de Technique … - Standard de l’IoT : MQTT (messaging) - Envoie des données dans une base de données Open Source (VictoriaMetrics) @ju_hnny5
326. https://www.youtube.com/watch?v=bzLtWjUj2k0 De l’AD28 à l’industrialisation : Historique et v1 du projet
327. En route vers l’industrialisation … • 1 boitier + alimentation USB C • 1 à 2 sondes de température certifiées de -55°C à + 125°C (4 sondes ultérieurement après tests complémentaires) @ju_hnny5
328. Pour faire simple • Les sondes envoient les données dans le “Cloud” des Restos • Rétention d’un an • Données distribuées et sauvegardées @ju_hnny5
329. *Environ 700 k de repas distribués en plus. @StephaneTrognon
330. @ju_hnny5 @ju_hnny5
331. Pour + de 15 000 postes de travail @ju_hnny5
332. Linux du Coeur • Besoin de stockage pour : ◦ La mise à disposition des images ISO ◦ L’accès aux majs (repo geo-localisés) • Besoin d’outillage pour build les images ◦ CI/CD Gitlab @ju_hnny5
333. Linux du Coeur • L’outillage pour le dépannage (Open Source) • La mise à disposition de packages customs ◦ Système de “GPO” pour Linux ◦ Déploiement de nouvelles apps @ju_hnny5
334. Un remplaçant à WeTransfer* @StephaneTrognon
335. CoeurCode
336. @StephaneTrognon / @ju_hnny5 *Environ 12 millions de repas distribués en plus. +30 autres services
337. @StephaneTrognon / @ju_hnny5
339. Marque déposée Comme le sont : Propriété des Restos du Coeur. L’image est donc protégée, notamment dans son utilisation. @StephaneTrognon / @ju_hnny5
340. @StephaneTrognon / @ju_hnny5
341. Conclusion ? • Pas de technologie magique qui répond à tous les besoins • On apprend tous les jours de nos erreurs sur ce projet, c’est comme ça que l’on avance. ◦ On continuera à vous partager nos échecs • On est loin d’avoir fait économiser tous les repas que nous souhaitons mais avec l’aide de chacun-e, on s’y rapproche de jour en jour • On est qu’au début d’une magnifique aventure, pourquoi pas y contribuer vous aussi ? @StephaneTrognon / @ju_hnny5
342. Conclusion ? Dans le futur : - Continuer de développer la plateforme et notamment le “Platform Engineering” utilisant le “Cloud du Coeur”. - De plus en plus d’IA permettant d’aider les bénévoles sur le terrain. @StephaneTrognon / @ju_hnny5
344. On a besoin de vous ! @ju_hnny5
346. Pourquoi pas toi ? - Chef-fe de projet - Développeur PHP, Python, Java - Admin / Ingé infrastructure - Des gens avec usage et non produit (SRE) @StephaneTrognon / @ju_hnny5
347. Merci pour votre écoute
350. Merci 🩷 Eric, Christine, Laurent, Antoine, Christophe, Chrystelle, Côme, Yves, Quentin, Bernard, Pierre, Fatima, Stéphane, Nicolas, Etienne, Steve, Xavier, Alexandre, Guillaume, Sébastien, Philippe, Adrien, Jolan, Christian, Daniel, Yvette, Thierry, Stéphanie, Pascal, Denis, Pierre-Antoine, Jean-François, Soraya, Frederic, Bruno, Yves, Jacky, Xavier, Alexandra, Agnes, Julien, Nadine, Fabienne, David, Donovan, Julie, Cédric … (Trouverez-vous les doublons ?) @ju_hnny5
351. Votre avis compte pour nous @StephaneTrognon
352. On compte sur vous ! cloudducoeur.org