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ésiliente, 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. @ju_hnny5
38. Mais pourquoi ce projet ? @ju_hnny5
39. @ju_hnny5
40. @ju_hnny5 Antenne Nationale
41. @ju_hnny5 Antenne/Association Nationale Délégations régionale Antennes/Associations Départementale Centres de distribution Maraudes Etc
42. @ju_hnny5
43. @ju_hnny5
45. @ju_hnny5
46. @ju_hnny5 Connecter ce beau monde
47. 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
48. @ju_hnny5
49. Règle 1 : Du code (partout) sur l’infra ? @ju_hnny5
50. 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
51. Tout est code … 📄 @ju_hnny5 https://www.youtube.com/watch?v=aZvsplOAd7c https://www.youtube.com/watch?v=IAwu-WCN6Nw
52. Règle 2 : La sécurité au coeur du projet @ju_hnny5
53. Pas de connexion directe sur les machines 👀 @ju_hnny5
54. 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
55. • 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
56. reNgine : Pour la reco 👀
57. Règle 3 : Infrastructure immuable @ju_hnny5
58. @ju_hnny5 + = 🩷
59. • Déploiement des noeuds immuables ◦ Pour la mise à l’échelle automatisée ◦ Déclenchements automatisables via la REST API MaaS + Packer = 🩷 @ju_hnny5
60. Tout n’est pas immuable @ju_hnny5
61. • 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
62. @ju_hnny5
63. - 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
64. : Maintenir une base commune @ju_hnny5
65. - Campagnes de patch management totalement automatisées 👀 : Un parc up-to-date ! @ju_hnny5
66. Règle 4 : Déploiement de configuration @ju_hnny5
67. • 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
68. Règle 5 : Le partage @ju_hnny5
69. • 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
70. Parlons de Cloud maintenant @ju_hnny5
71. Under-undercloud Sous le capot @ju_hnny5
73. Kube… pourquoi ? • Faciliter les déploiements et la mise à l’échelle des éléments de “l’undercloud”* • Gestion “as code” + • Astreinte friendly 🩷 @ju_hnny5
74. Kube… pourquoi ? @ju_hnny5
75. Blue/Green pattern @ju_hnny5
76. Le véritable “undercloud” Le moteur @ju_hnny5
77. @ju_hnny5
78. Quoi ?! OpenStack en 2024 ?! @ju_hnny5
79. @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
80. @ju_hnny5
81. @ju_hnny5 MOCHE Utilisé dans l’underlay
82. 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 …
83. OpenStack + Kubernetes (underlay) @ju_hnny5
84. @ju_hnny5 OpenStack et les micro-services
85. @ju_hnny5
86. L’auto-partage de l’informatique @ju_hnny5
87. Overlay ≠ Underlay @ju_hnny5 Ce que les gens voient vs Ce que nous voyons
88. Overlay ≠ Underlay @ju_hnny5 Ce que les gens utilisent vs Ce que nous maintenons
89. 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
90. “Les besoins vont bien au delà d’un simple besoin de VM (dans un même endroit).” @ju_hnny5
91. @ju_hnny5 @ju_hnny5 Le Cloud du Coeur
93. @ju_hnny5 Overlay Underlay
94. @ju_hnny5 Gérer ses secrets
95. @ju_hnny5 Overlay Underlay
96. @ju_hnny5 Overlay Underlay
97. Hyper-convergence @ju_hnny5
98. Architecture classique 📄 Hyperviseur A Hyperviseur B Hyperviseur C Hyperviseur D Stockage A Stockage B Stockage C Stockage D @ju_hnny5
99. Architecture Hyper-convergée 📄 Hyperviseur A + Stockage Hyperviseur B + Stockage Hyperviseur C + Stockage Hyperviseur D + Stockage @ju_hnny5
100. @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
101. Une gestion de l’énergie particulière @ju_hnny5
102. @ju_hnny5 Laisser les serveurs allumés ? • Contrat à la consommation ◦ Plus je consomme, plus je paie • Allumer/éteindre de manière totalement automatisée
103. @ju_hnny5
104. + = 🩷 @ju_hnny5
105. Kube-ception ? @ju_hnny5
106. @ju_hnny5
107. @ju_hnny5 Underlay Overlay Ça tourne dans des vms
108. Fournir du service fiablement et rapidement @ju_hnny5
109. La source de vérité
110. Une seule source de vérité ? • V1 : Spreadsheet pour stocker les informations • V2 : Inventaire de Rudder + Ansible + OctoDNS @ju_hnny5
111. @ju_hnny5 CMDB Configuration Management Database
112. @ju_hnny5 V3
113. @ju_hnny5
114. 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
115. + Open Source = 🩷 @ju_hnny5 https://github.com/infra-rdc
116. @ju_hnny5 @ju_hnny5
117. Les services @ju_hnny5
118. @ju_hnny5 *Environ 1,5 millions de repas distribués en plus.
119. @ju_hnny5 *Environ 700 000 repas distribués en plus.
120. @ju_hnny5 *Environ 6 millions de repas distribués en plus. Sondes de température
121. @ju_hnny5 Sondes de température https://www.youtube.com/watch?v=bzLtWjUj2k0&t=1150s
122. @ju_hnny5 *Environ 700 k de repas distribués en plus.
123. @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
124. @ju_hnny5 *Environ 12 millions de repas distribués en plus. +30 autres services
125. @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
127. @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…)
128. On a besoin de vous ! @ju_hnny5
130. @ju_hnny5
131. Merci pour votre écoute
132. Un petit retour ? @ju_hnny5
133. Merci ! @ju_hnny5
134. Des questions ?