Cloud privé OpenStack
Monter l'infrastructure privée, son stockage distribué et son réseau, puis documenter la procédure pour que l'équipe puisse la reproduire.
Ma contributionLe projet en quelques mots
ARCL (Architecture Cloud) est un projet d'équipe du second semestre de quatrième année. L'objectif : déployer une application web sur une architecture hybride, c'est-à-dire répartie entre un cloud privé monté par nos soins et un cloud public loué chez Google.
Le travail s'est réparti en trois volets confiés à des membres différents. Le mien était le cloud privé : partir d'une station de travail vide et en faire une infrastructure capable d'héberger des machines virtuelles, avec du stockage répliqué et de la haute disponibilité.
Cloud public GCP
Provisionnement des ressources Google Cloud via Terraform.
Autres membresApplication
Un jeu du pendu multijoueur temps réel (Node.js, Express, Socket.IO, PostgreSQL, JWT), servant de charge à déployer.
Autres membresDu poste de travail au cloud privé
Toute l'infrastructure tient sur une seule station de travail, grâce à la virtualisation imbriquée : la machine physique héberge trois machines virtuelles qui se comportent comme trois serveurs distincts. J'ai écrit la procédure complète de déploiement, en six phases, pour que chaque membre de l'équipe puisse recréer le même environnement chez lui.
Préparer l'hyperviseur
Installation de KVM et libvirt sur la machine physique, qui joue le rôle de centre de données miniature.
Provisionner les nœuds
Création automatisée de trois machines virtuelles, chacune dotée d'un disque système et d'un disque vierge réservé au stockage distribué.
Amorcer l'orchestration
Transformation du nœud de contrôle en poste de pilotage : Docker, environnement Python isolé, Ansible et Kolla-Ansible.
Injecter l'architecture
Application de la configuration commune (globals.yml, inventaire multinode), chaque personne générant ses propres mots de passe - aucun secret n'est versionné.
Déployer
Chaîne Ansible complète : préparation des serveurs, contrôles préalables, puis déploiement d'OpenStack (30 à 45 minutes).
Valider
Vérification des hyperviseurs et de l'état du cluster de stockage, avant de laisser l'équipe déployer ses ressources par Terraform.
Ce qui a été livré
Infrastructure hyperconvergée
Trois nœuds assurant à la fois le calcul et le stockage, sur une station de travail unique. Le contrôleur porte les services centraux et le réseau, les deux autres nœuds exécutent les machines virtuelles.
Stockage distribué Ceph
Un cluster Ceph déployé séparément via cephadm sert de socle
de stockage commun aux images, aux volumes et aux disques des machines
virtuelles, avec réplication des données entre les nœuds.
Réseau et haute disponibilité
Réseau virtualisé Open vSwitch avec encapsulation VXLAN, séparation entre le réseau d'administration et celui des instances, et adresse virtuelle partagée gérée par Keepalived et HAProxy. La haute disponibilité des machines virtuelles elles-mêmes est assurée par Masakari, qui les relance automatiquement si un nœud tombe.
Interconnexion avec le cloud public
Deux passerelles VPN WireGuard redondées assurent la liaison site-à-site avec Google Cloud. Elles partagent une adresse virtuelle et la même identité cryptographique, de sorte qu'une bascule de l'une à l'autre reste invisible côté cloud public. Une règle d'anti-affinité garantit qu'elles ne s'exécutent jamais sur le même nœud physique.
Stockage objet compatible S3
Une passerelle RadosGW expose le cluster Ceph via une API compatible S3, adossée à l'authentification centralisée d'OpenStack.
Procédure reproductible
Un manuel opératoire et deux scripts permettent de reconstruire l'environnement depuis une machine vierge. Le provisionnement a ensuite été réécrit en Terraform avec cloud-init, pour remplacer l'installation manuelle du système par une image préconfigurée.
Synthèse du projet
Travail réalisé
Un cloud privé OpenStack à trois nœuds monté depuis une machine vide, avec stockage distribué Ceph, réseau virtualisé, haute disponibilité des services comme des instances, et une liaison VPN redondée effectivement opérationnelle vers le cloud public. La procédure complète a été documentée et scriptée pour être reproductible par l'équipe.
Ce que le projet m'a apporté
Une compréhension concrète de ce qu'il y a derrière un service cloud : le calcul, le stockage et le réseau ne sont plus des cases à cocher chez un fournisseur, mais des composants qu'il faut assembler et faire tenir ensemble. C'est aussi le projet qui m'a le plus confronté à l'écart entre une documentation officielle et la réalité d'une installation.