Upgrade to Pro — share decks privately, control downloads, hide ads and more …

TADx 2024 - Comment nous avons transformé les ...

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.

Julien Briault

September 17, 2024
Tweet

More Decks by Julien Briault

Other Decks in Technology

Transcript

  1. 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
  2. “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.”
  3. 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).
  4. Le fonctionnement global des Restos @ju_hnny5 Antenne/Association Nationale Délégations régionale

    Antennes/Associations Départementale Centres de distribution Maraudes Etc
  5. Le pc qui “traine dans un coin” @ju_hnny5 Des sauvegardes

    ?? ☠ De la redondance ?!? 💀 Y’a quoi là dessus ? 👀 Ça x112 ? (spoiler : presque)
  6. 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
  7. 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
  8. 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.
  9. 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 ! ✔
  10. 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
  11. 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
  12. 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
  13. • 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
  14. • Déploiement des noeuds immuables ◦ Pour la mise à

    l’échelle automatisée ◦ Déclenchements automatisables via la REST API MaaS + Packer = 🩷 @ju_hnny5
  15. • 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
  16. - 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
  17. • 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
  18. • 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
  19. Kube… pourquoi ? • Faciliter les déploiements et la mise

    à l’échelle des éléments de “l’undercloud”* • Gestion “as code” + • Astreinte friendly 🩷 @ju_hnny5
  20. @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
  21. 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 …
  22. 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
  23. “Les besoins vont bien au delà d’un simple besoin de

    VM (dans un même endroit).” @ju_hnny5
  24. Architecture classique 📄 Hyperviseur A Hyperviseur B Hyperviseur C Hyperviseur

    D Stockage A Stockage B Stockage C Stockage D @ju_hnny5
  25. Architecture Hyper-convergée 📄 Hyperviseur A + Stockage Hyperviseur B +

    Stockage Hyperviseur C + Stockage Hyperviseur D + Stockage @ju_hnny5
  26. @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
  27. @ju_hnny5 Laisser les serveurs allumés ? • Contrat à la

    consommation ◦ Plus je consomme, plus je paie • Allumer/éteindre de manière totalement automatisée
  28. @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…
  29. @ju_hnny5 L’observabilité : Service discovery • Une machine apparaît =

    Automatiquement supervisée ◦ Chaque machine expose ses services à superviser • Gain de temps considérable
  30. Une seule source de vérité ? • V1 : Spreadsheet

    pour stocker les informations • V2 : Inventaire de Rudder + Ansible + OctoDNS @ju_hnny5
  31. 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
  32. 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
  33. 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).
  34. 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
  35. 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
  36. @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
  37. @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
  38. @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…)