TADx 2024 - Comment nous avons transformé les Restos du Coeur en Cloud Provider

Cette conférence vous plongera au cœur d'une transformation audacieuse, où les Restos du Cœur ont évolué pour devenir un fournisseur de services Cloud (en interne). À travers cette histoire captivante, nous explorerons en détail le projet de construction d'une plateforme de cloud privé reposant sur les technologies robustes d'OpenStack et de Kubernetes.

Nous commencerons par discuter des motivations derrière cette initiative avant-gardiste, mettant en lumière les défis uniques rencontrés dans l'adaptation de concepts de cloud computing au sein d'une organisation à but non lucratif. Nous examinerons également les raisons qui ont conduit à choisir OpenStack comme pilier fondamental de cette transformation et démontrerons pourquoi, même en 2024, il reste une option pertinente et performante.

Au cours de la présentation, nous plongerons dans les détails techniques de l'infrastructure, décrivant la conception de la plateforme de cloud privé, son architecture basée sur OpenStack et Kubernetes, ainsi que les choix de configuration spécifiques qui ont été faits pour répondre aux besoins particuliers des Restos du Cœur.

Ainsi, vous découvrirez comment la combinaison d'OpenStack et de Kubernetes a permis de créer une infrastructure flexible, évolutive et résiliante, tout en maximisant l'efficacité opérationnelle. Des retours d'expérience concrets seront partagés, mettant en lumière les succès, les leçons apprises et les perspectives d'avenir pour cette initiative novatrice.

Rejoignez-nous pour explorer les coulisses de cette transformation technologique exceptionnelle, découvrir les raisons pour lesquelles OpenStack demeure une solution de choix en 2024, et apprendre comment la convergence de technologies de pointe a permis de propulser les Restos du Cœur vers de nouveaux horizons numériques au service de leur mission humanitaire.

Transcript

1. Comment nous avons transformé les Restos du Coeur en Cloud Provider Julien Briault (@ju_hnny5) julien.briault@restosducoeur.org
2. R E S T O S *merci à l’ami Denis (Zwindler)
3. Rex de 3 ans de construction d’une infrastructure en milieu associatif Julien Briault julien.briault@restosducoeur.org
4. Disclaimer 1 Nous n’avons pas transformés les Restos du Coeur en Cloud Provider @ju_hnny5
5. Disclaimer 2 Sorry pour le fran-glais @ju_hnny5
6. Disclaimer 3 RDC = Restos du Coeur République Démocratique du Congo Rez de chaussée @ju_hnny5
7. Julien Briault Uptime 26y Ingé réseau | SRE @ Auteur @ Linux Pratique Conférencier (DevoxxFR, VoxxedDays Luxembourg, Google DevFest) Responsable Infra (bénévole) @ #whoami @ju_hnny5
8. @ju_hnny5
9. Il y a 39 ans … @ju_hnny5
10. “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.”
12. Les RDC en quelques chiffres … @ju_hnny5 • 171 millions de repas servis (2022-2023) ◦ +1,3 millions (2021-2022) • 112 associations départementales • 78 000 bénévoles ◦ ~ 35 000 bénévoles utilisant l’informatique au quotidien • 2 333 lieux d’accueil (centre de distribution, etc).
13. Le fonctionnement global des Restos @ju_hnny5
14. Le fonctionnement global des Restos @ju_hnny5 Antenne/Association Nationale Délégations régionale Antennes/Associations Départementale Centres de distribution Maraudes Etc
15. “Tant que nous sommes là, c’est que ça ne va pas.” @ju_hnny5
16. @ju_hnny5 Antenne/Association Nationale Délégations régionale Antennes/Associations Départementale Centres de distribution Maraudes Etc
17. Premiers constats à mon arrivée aux Restos @ju_hnny5
18. La solitude du début @ju_hnny5
19. De voir faire avec l’historique … @ju_hnny5
20. Le pc qui “traine dans un coin” @ju_hnny5
21. Le pc qui “traine dans un coin” @ju_hnny5 Des sauvegardes ?? ☠ De la redondance ?!? 💀 Y’a quoi là dessus ? 👀 Ça x112 ? (spoiler : presque)
22. Infra v0.1 : Le “DC aux WC” Oui, oui, c’est bien un WC …
23. @ju_hnny5
24. @ju_hnny5
25. @ju_hnny5 Antenne/Association Nationale Délégations régionale Antennes/Associations Départementale Centres de distribution Maraudes Etc
26. Infra v1 : 2 vraies baies
27. Infra v1 : 2 vraies baies @ju_hnny5
28. @ju_hnny5
29. @ju_hnny5
30. Infra v2 : Des nouveaux* serveurs 👀
31. C’est installé où ? @ju_hnny5
32. Chartres @ju_hnny5
33. On y stock… de la nourriture et de la donnée… @ju_hnny5
34. Infra v2 : 3 baies 52U ? @ju_hnny5
35. @ju_hnny5 On a commencé à construire …
36. Infra v2 : 3 baies 52U - Premier POP 98% de dons
37. Résilience @ju_hnny5
38. Quorum @ju_hnny5
39. @ju_hnny5 Pour les humains …. Et les machines ! Dans la prise de décision Pour la HA
40. Mais pourquoi ce projet ? @ju_hnny5
41. @ju_hnny5
42. @ju_hnny5 Antenne Nationale
43. @ju_hnny5 Antenne/Association Nationale Délégations régionale Antennes/Associations Départementale Centres de distribution Maraudes Etc
44. @ju_hnny5
45. @ju_hnny5
47. @ju_hnny5
48. @ju_hnny5 L’organisation
49. On aime les chats ! (obviously)
50. L’organisation de l’équipe - Techniciens (x3) - Admins/Ingés (x5)
51. L’organisation de l’équipe Points de synchro - Une fois par semaine - Durée variable - Tous les lundis soir (à 21h00) - Organisation : - Une partie sur les sujets en cours et les nouveaux (point d’avancement) - Une partie sur la présentation des nouveaux arrivants s’il y en a - Présentation des nouvelles architectures review + noter la/les décision(s) - Discussion libre
52. L’état d’esprit L’état d’esprit
53. L’état d’esprit : Culture du retour
54. @ju_hnny5 Surveillance et observabilité
55. Surveillance et observabilité 1. Toute application déployée se doit d’être observée 2. Les alertes doivent être configurées 3. Les alertes doivent avoir en relation : a. La documentation “runbook” b. Les graphiques
56. Surveillance et observabilité
57. Surveillance et observabilité
58. @ju_hnny5 Rétroaction continue
59. Rétroaction continue • Utiliser les retours utilisateurs et les métriques de performance pour améliorer en continue les performances des applications déployées.
60. @ju_hnny5 L’amélioration continue
61. L’amélioration continue • On accepte d’être humain ◦ L’humain est par définition imparfait
62. @ju_hnny5 Itération rapide
63. Itération rapide - Ajustements rapides en fonction des retours et des besoins.
64. Itération rapide ➔ Multi-envs : ◆ Sandbox/Dev • Pour jouer sans rien casser ! ◆ Preprod/Staging • Appliquer/tester sur la Merge Request avant de merge. ◆ Prod • Appliquer sur la production ! ✔
65. @ju_hnny5 Blameless
66. Blameless postmortems
67. Blameless postmortems
68. @ju_hnny5 Connecter ce beau monde
69. Le réseau 💀 • Réseau Out of band (OOB) • Réseau 1G (pour le management, provisionner les machines) • Réseau 10G pour la production • V1 = 3 tier (L2) ◦ vxlan / vlan • V2 = Leaf/Spine/Super spine (Full L3) ◦ BGP EVPN + vxlan @ju_hnny5
70. @ju_hnny5
71. Règle 1 : Du code (partout) sur l’infra ? @ju_hnny5
72. Tout est code* … 📄 • Limiter le “Shadow IT” • Déploiements accélérés • Rollbacks facilités • Application des bonnes pratiques de sécurité (SAST/DAST) et de développement (linter, etc) dans nos pipelines (CI/CD) • Revue des modifications, travail en équipe facilité, oeil externe @ju_hnny5
73. Tout est code … 📄 @ju_hnny5 https://www.youtube.com/watch?v=aZvsplOAd7c https://www.youtube.com/watch?v=IAwu-WCN6Nw
74. Règle 2 : La sécurité au coeur du projet @ju_hnny5
75. Pas de connexion directe sur les machines 👀 @ju_hnny5
76. 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 ? @ju_hnny5
77. • 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 ? 👀 @ju_hnny5
78. reNgine : Pour la reco 👀
79. Règle 3 : Infrastructure immuable @ju_hnny5
80. @ju_hnny5 + = 🩷
81. • Déploiement des noeuds immuables ◦ Pour la mise à l’échelle automatisée ◦ Déclenchements automatisables via la REST API MaaS + Packer = 🩷 @ju_hnny5
82. Tout n’est pas immuable @ju_hnny5
83. • Déploiement des noeuds muables ◦ Déploiement des agents* via cloud-init • Gérer le cycle de vie du serveur ◦ Gérer le serveur physique comme une VM ◦ Redéployer facilement si besoin • Création des enregistrements DNS dédiés à l’administration (parfait pour provisionner en suite les noeuds avec Ansible) MaaS en renfort ! 🦾 @ju_hnny5
84. @ju_hnny5
85. - Déployer : - Les utilisateurs et clés SSH + configuration SSHd - La configuration DNS - Hardening (Application des règles du benchmark CIS) - Déploiement du MOTD - Installation des paquets par défaut - L’agent se lance toutes les 2mn : - Corrige en cas de détection de drifts - Report des corrections apportées sur Slack : Maintenir une base commune @ju_hnny5
86. : Maintenir une base commune @ju_hnny5
87. - Campagnes de patch management totalement automatisées 👀 : Un parc up-to-date ! @ju_hnny5
88. Règle 4 : Déploiement de configuration @ju_hnny5
89. • 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 @ju_hnny5
90. Règle 5 : Le partage @ju_hnny5
91. • L’infra doit être partagée ◦ Accessible à tous aux Restos (équipes informatique) ◦ Effort concentré : une app avec un intérêt peut être proposée et mise à disposition de tout le monde • Tout doit être documenté ◦ Exemple : “run books” en cas de pépin sur l’infra ▪ Stack déployée = obligatoirement documentée ◦ Pas de rétention d’information ▪ On est pas éternel • Construction commune sans oublier les objectifs Le partage @ju_hnny5
92. Parlons de Cloud maintenant @ju_hnny5
93. Under-undercloud Sous le capot @ju_hnny5
95. Kube… pourquoi ? • Faciliter les déploiements et la mise à l’échelle des éléments de “l’undercloud”* • Gestion “as code” + • Astreinte friendly 🩷 @ju_hnny5
96. Kube… pourquoi ? @ju_hnny5
97. Blue/Green pattern @ju_hnny5
98. Le véritable “undercloud” Le moteur @ju_hnny5
99. @ju_hnny5
100. Quoi ?! OpenStack en 2024 ?! @ju_hnny5
101. @ju_hnny5 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
102. @ju_hnny5
103. @ju_hnny5 MOCHE Utilisé dans l’underlay
104. 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 …
105. OpenStack + Kubernetes (underlay) @ju_hnny5
106. @ju_hnny5 OpenStack et les micro-services
107. @ju_hnny5
108. L’auto-partage de l’informatique @ju_hnny5
109. Overlay ≠ Underlay @ju_hnny5 Ce que les gens voient vs Ce que nous voyons
110. Overlay ≠ Underlay @ju_hnny5 Ce que les gens utilisent vs Ce que nous maintenons
111. OpenStack ? • Les antennes départementales peuvent déployer leur service sur l’infrastructure de manière transparente • L’antenne nationale a à sa disposition des ressources qui peuvent se mettre à l’échelle à moindre coût @ju_hnny5
112. “Les besoins vont bien au delà d’un simple besoin de VM (dans un même endroit).” @ju_hnny5
113. @ju_hnny5 @ju_hnny5 Le Cloud du Coeur
115. @ju_hnny5 Overlay Underlay
116. @ju_hnny5 Gérer ses secrets
117. @ju_hnny5 Overlay Underlay
118. @ju_hnny5 Overlay Underlay
119. Hyper-convergence @ju_hnny5
120. Architecture classique 📄 Hyperviseur A Hyperviseur B Hyperviseur C Hyperviseur D Stockage A Stockage B Stockage C Stockage D @ju_hnny5
121. Architecture Hyper-convergée 📄 Hyperviseur A + Stockage Hyperviseur B + Stockage Hyperviseur C + Stockage Hyperviseur D + Stockage @ju_hnny5
122. @ju_hnny5 L’hyper-convergence ? • Matériel : PowerEdge R730xd ◦ Hyperviseur (KVM) + Ceph embarqué (OSDs en façade) ◦ Noeuds : ▪ Bi-Xeon (32 coeurs) ▪ 512 -> 1k RAM ▪ x10 OSDs (entre 2 et 4TO /disque) ▪ Réseau 10G • Ceph-mon, manager, dashboard sont embarqués dans Kubernetes
123. Une gestion de l’énergie particulière @ju_hnny5
124. @ju_hnny5 Laisser les serveurs allumés ? • Contrat à la consommation ◦ Plus je consomme, plus je paie • Allumer/éteindre de manière totalement automatisée
125. OpenBareMetal : C’est pas Versailles ici ! Julien Briault (@ju_hnny5) julien.briault@restosducoeur.org
126. L’humain @ju_hnny5
127. @ju_hnny5 L’humain • Éviter les tâches ingrates ◦ C’est relou de devoir allumer/éteindre manuellement des machines … ❕ • Scale automatiquement… Nope ☠ ◦ Il suffit que personne ne soit dispo au moment où on a besoin de mettre à l’échelle le matériel, ça ne fonctionne pas très bien…
128. @ju_hnny5 La climatisation
129. @ju_hnny5
130. + = 🩷 @ju_hnny5
131. Kube-ception ? @ju_hnny5
132. @ju_hnny5
133. @ju_hnny5 Underlay Overlay Ça tourne dans des vms
134. @ju_hnny5 Ici pour être plus exact !
135. L’observabilité @ju_hnny5
136. @ju_hnny5 L’observabilité
137. @ju_hnny5 L’observabilité https://www.youtube.com/watch?v=bzLtWjUj2k0&t=1150s
138. @ju_hnny5 L’observabilité : Service discovery • Une machine apparaît = Automatiquement supervisée ◦ Chaque machine expose ses services à superviser • Gain de temps considérable
139. Fournir du service fiablement et rapidement @ju_hnny5
140. La source de vérité
141. Une seule source de vérité ? • V1 : Spreadsheet pour stocker les informations • V2 : Inventaire de Rudder + Ansible + OctoDNS @ju_hnny5
142. @ju_hnny5 CMDB Configuration Management Database
143. @ju_hnny5 V3
144. @ju_hnny5
145. Netbox (WebUI, CLI, Agent) • Netbox Agent : remontée journalière de l’inventaire des machines (écrit en Go) • nbctl : permet d'interagir avec Netbox en CLI, réserver des adresses IP pour les équipements qui ne sont pas déployées par MaaS* (écrit en Go) • La WebUI permettant d’afficher et visualiser les éléments (racks, IPAM, record DNS des machines, etc). https://github.com/infra-rdc/nbctl @ju_hnny5
146. + Open Source = 🩷 @ju_hnny5 https://github.com/infra-rdc
147. @ju_hnny5 @ju_hnny5
148. La documentation
149. La documentation
150. La documentation On y retrouve : - L'onboarding pour les nouveaux arrivants - L'architecture, vue d'ensemble de l'infrastructure et de son fonctionnement - L'architecture détaillée qui vise à fournir le détail de chaque stack technique déployée - Les runbooks qui visent à documenter les actions à réaliser dans le cadre du "run" - La communication, cette section vise à fournir les templates de communication et surtout, où communiquer l'information (à qui) - Les astuces/howtos - Les architecture review - Les post-mortems
151. La gestion de projets
152. La gestion de projets - Mode Kanban.
153. Pour la planète 👀
154. Bon pour la planète ! - L'infrastructure est construite à 98% de dons et doit continuer à le rester. ☁ - La recherche de nouveaux dons de matériel informatique pour l'infrastructure doit être une priorité sur l'achat de matériel (sauf pour les consommables qui sont plus compliqués à récupérer en don).
155. Economie(s)
156. L’argent On parle au maximum de repas. Éliminer/diminuer les facteurs coûts importants : - Le matériel - Grâce aux dons - L’énergie - Grâce aux partenariats - La matière grise - Grâce au bénévolat
157. Déployer un service (sans trop se mouiller)
158. Déployer un service Pour qu’un service soit considéré comme “en production” : - Passer par une archi-review (validation en équipe de la solution) - Gestion “as-code” via dépôt Git (et déploiement via CI/CD) - Documentation d’architecture + archi détaillée - Documentation “runbook” - Alerting + observabilité - Communication sur #annnonces-infrastructure
159. Les services @ju_hnny5
160. @ju_hnny5 *Environ 1,5 millions de repas distribués en plus.
161. @ju_hnny5 *Environ 700 000 repas distribués en plus.
162. @ju_hnny5 *Environ 6 millions de repas distribués en plus. Sondes de température
163. @ju_hnny5 Sondes de température https://www.youtube.com/watch?v=bzLtWjUj2k0&t=1150s
164. @ju_hnny5 *Environ 700 k de repas distribués en plus.
165. @ju_hnny5 • Hotspot Wi-Fi (Wi-Fi BYOD et interne) • Accepter les CGU sur le Wi-Fi ouvert (BYOD) ◦ N’a accès qu’à internet (filtré) • Filtrage de certains sites Web (via DNS menteur) • Authentification des utilisateurs en SSO pour le Wi-Fi interne • Enregistrement sur 1 an des données techniques de connexion Wi-Fi
166. @ju_hnny5 *Environ 100 k de repas distribués en plus.
167. @ju_hnny5 Donner une seconde vie aux objets
168. @ju_hnny5
169. @ju_hnny5 *Environ 12 millions de repas distribués en plus. +30 autres services
170. @ju_hnny5 Quelques chiffres pour terminer 📝 • Environ : ◦ 700 VMs (éphémères pour la plupart) ◦ 400 Pods (monte jusqu’à 700) ◦ 80 serveurs/AZ (allumés en fonction du besoin) • 6 personnes actives sur le projet (on recrute 󰗞) • Plusieurs millions d’euros économisés (et donc de repas distribués) • Une dizaine d’entreprises partenaires
172. @ju_hnny5 Au-delà de l’infra c’est surtout une équipe • Fournir une équipe d’experts aux Restos ◦ L’expertise coûte chère à une association • Aider les ressources nationales qui sont en sous-nombre (2 pour la partie pure technique…)
173. On a besoin de vous ! @ju_hnny5
175. @ju_hnny5
176. Merci pour votre écoute
177. Un petit retour ? A vous de jouer ! @ju_hnny5
178. Merci ! @ju_hnny5
179. Des questions ?