Oui, il est tout à fait possible de monter un laboratoire de cloud privé assez complet sur une seule machine Linux. Canonical permet de déployer Canonical OpenStack avec Sunbeam, évolution du projet MicroStack, en concentrant sur un seul nœud les rôles de contrôle, de calcul et de stockage. Lorsqu’il est combiné avec Terraform, des images Ubuntu Cloud et un pare-feu virtuel comme OpenWrt, l’environnement ainsi créé devient un outil très pratique pour apprendre OpenStack, tester l’automatisation et reproduire des architectures cloud sans avoir besoin d’infrastructures auprès de grands fournisseurs d’échelle.

Les clés d’une cloud privée OpenStack en 20 secondes

• Canonical permet de déployer OpenStack sur un seul serveur pour des laboratoires et de la formation.
• Un même nœud peut jouer les rôles de contrôle, calcul et stockage.
• Terraform peut automatiser la création de réseaux, routeurs, règles de sécurité et instances via le provider OpenStack.
• OpenWrt peut fonctionner comme appliance virtuelle pour expérimenter le routage et la segmentation.
• Une architecture mono-nœud est idéale pour un laboratoire, mais ne garantit pas la résilience d’une infrastructure de production.

Cette approche est particulièrement intéressante pour les administrateurs système, étudiants et développeurs souhaitant comprendre ce qui se passe réellement derrière des services comme EC2 ou Azure Virtual Machines. Au lieu de simplement créer une machine virtuelle depuis une interface publique, ils peuvent construire des réseaux, gérer des images, attribuer des adresses, définir des règles de sécurité et automatiser tout cela via du code.

Il existe toutefois une mise à jour terminologique importante. Bien que MicroStack reste un nom couramment utilisé, la documentation officielle de Canonical présente désormais le produit sous le nom de Canonical OpenStack, déployé via la commande sunbeam. Canonical propose justement un tutoriel officiel pour mettre en place tout cet environnement sur une seule machine.

Ce qui peut réellement tenir dans une seule machine

Un laboratoire de ce type reproduit une grande partie des composants fondamentaux d’un cloud IaaS.

L’architecture peut se présenter ainsi :

Dans un déploiement standard, ces composants seraient répartis sur plusieurs nœuds. Dans le laboratoire, ils sont volontairement regroupés pour réduire les coûts et la complexité physique.

Canonical indique que pour son tutoriel de base, il faut au minimum 4 cœurs x86-64, 16 Go de RAM, 100 Go de stockage SSD et un disque supplémentaire non formaté pour MicroCeph. Il est aussi possible d’exécuter le laboratoire dans une machine virtuelle, avec toutefois une perte de performance.

Pour travailler confortablement avec plusieurs VMs, il est conseillé d’avoir beaucoup plus de mémoire. Les 16 Go initialement recommandés constituent un bon point de départ ; 32 ou 64 Go offrent une marge de manœuvre bien plus grande pour expérimenter.

Installation : maintenant, le héros, Sunbeam

L’installation commence avec le package openstack de Canonical :

sudo snap install openstack

Ce package inclut sunbeam, l’outil qui simplifie grandement le déploiement d’OpenStack.

Ensuite, il faut préparer le nœud :

sunbeam prepare-node-script --bootstrap | bash -x
newgrp snap_daemon

Puis initialiser en assignant les trois rôles principaux au même serveur :

sunbeam cluster bootstrap --role control,compute,storage

Pour un tutoriel simplifié, on peut aussi utiliser :

sunbeam cluster bootstrap --accept-defaults --role control,compute,storage

Sunbeam déploie en arrière-plan différents éléments, notamment Kubernetes pour le plan de contrôle, Juju, l’hyperviseur OpenStack lui-même et MicroCeph pour le stockage.

Ensuite, il est possible de configurer l’environnement :

sunbeam configure --accept-defaults --openrc demo-openrc

Et vérifier que tout fonctionne en lançant une première instance :

sunbeam launch ubuntu --name test

Ce qui crée un petit cloud opérationnel sur une seule machine.

Terraform : transformer le laboratoire en une infrastructure reproductible

L’étape suivante, probablement la plus intéressante, consiste à automatiser la création des ressources.

Il existe un provider Terraform pour OpenStack qui permet de gérer via du code une grande partie des services disponibles dans la plateforme, de Nova et Neutron à Cinder, Glance ou Keystone.

Voici une configuration de base :

terraform {
  required_providers {
    openstack = {
      source = "terraform-provider-openstack/openstack"
    }
  }
}

provider "openstack" {
  cloud = "lab"
}

On peut ensuite déclarer des ressources, par exemple pour les réseaux :

resource "openstack_networking_network_v2" "lab" {
  name = "lab-network"
}

Puis une sous-réseau :

resource "openstack_networking_subnet_v2" "lab" {
  name       = "lab-subnet"
  network_id = openstack_networking_network_v2.lab.id
  cidr       = "10.10.10.0/24"
  ip_version = 4
}

Et enfin, des instances :

resource "openstack_compute_instance_v2" "server" {
  name        = "ubuntu-lab"
  image_name  = "ubuntu"
  flavor_name = "m1.small"

  network {
    uuid = openstack_networking_network_v2.lab.id
  }
}

L’avantage se manifeste lorsque le laboratoire s’agrandit. Réseaux, machines, règles et dépendances ne sont plus seulement une configuration manuelle, mais sont décrits dans des fichiers versionnables.

Une simple commande :

terraform apply

peut alors reconstruire tout l’environnement, le rapprochant ainsi de la gestion d’une infrastructure cloud réelle.

Intégrer OpenWrt comme pare-feu virtuel

Une autre option très intéressante consiste à déployer OpenWrt en tant que machine virtuelle dans l’environnement same.

OpenWrt peut tourner sur x86 et est documenté pour fonctionner sous virtualisation avec QEMU/KVM, ce qui en fait une solution appropriée pour expérimenter avec des appliances réseau.

Une architecture simple pourrait utiliser deux interfaces virtuelles :

Internet / réseau externe
        |
     OpenWrt
        |
   réseau privé OpenStack
        |
  VM1   VM2   VM3

OpenWrt pourra alors gérer le routage, le NAT, les politiques de pare-feu ou des services additionnels.

Ce laboratoire permet d’expérimenter avec des scénarios plus complexes à reproduire sur une configuration de machines virtuelles classiques : réseaux multi-locataires, routeurs virtuels, isolations entre projets ou règles d’entrée/sortie.

Il faut souligner que OpenStack dispose déjà de Neutron pour fournir la connectivité réseau et les groupes de sécurité. OpenWrt n’est pas indispensable pour construire le cloud. Son intérêt réside dans la création d’un environnement plus riche pour expérimenter avec un appliance réseau intégré dans l’infrastructure.

cloud-init, une autre tâche automatisée

Les images Ubuntu Cloud sont conçues pour fonctionner avec cloud-init, permettant à une VM de recevoir automatiquement sa configuration lors du premier démarrage.

Exemple :

#cloud-config
packages:
  - nginx

runcmd:
  - systemctl enable --now nginx

Terraform peut fournir ce contenu via le paramètre user_data.

Ce qui permet de passer de :

Créer une VM → Connexion SSH → Installer des paquets → Modifier la configuration

à :

terraform apply → VM créée et configurée automatiquement

Pour un laboratoire d’Infrastructure as Code, cette différence est cruciale. Terraform décrit l’infrastructure, tandis que cloud-init automatise la configuration initiale du système invité.

Ce que ce laboratoire enseigne mieux que de disposer d’un compte AWS

Construire un tel cloud aide à comprendre des concepts que les grands fournisseurs de cloud dissimulent volontairement derrière leurs services gérés.

Créer une instance AWS EC2 ne nécessite pas de connaître Nova, Neutron ou KVM.

Ici, si.

L’administrateur peut voir comment les services sont liés :

Terraform
   ↓
API OpenStack
   ↓
Nova ─────────→ KVM
   ↓
Neutron ──────→ réseau
   ↓
Glance ───────→ images
   ↓
Ceph ─────────→ stockage

Cela permet aussi de provoquer des erreurs immédiatement visibles : une mauvaise route, une règle de sécurité trop restrictive ou un réseau externe mal configuré. Ces erreurs deviennent instantanément apparentes et compréhensibles.

Une telle expérience a une grande valeur pédagogique.

Un seul serveur ne transforme pas le laboratoire en une cloud de production

Voici l’avertissement principal :

Que OpenStack tourne sur un seul serveur ne signifie pas que cette architecture doit servir de modèle pour un environnement en production.

Le tutoriel officiel de Canonical précise que cette configuration simplifiée est destinée à la formation. Pour un environnement de production, il faut envisager des déploiements avec plusieurs nœuds et des procédures différentes, permettant d’étendre le cluster.

Un seul serveur présente un point unique de défaillance :

Défaillance de l'hôte
     ↓
Fuite du calcul
     ↓
Fuite du stockage
     ↓
Fuite du plan de contrôle
     ↓
Perte de tout le cloud

Il n’y a pas de haute disponibilité réelle du matériel, ni possibilité de migration en direct vers un autre hyperviseur si un seul hyperviseur existe.

Une cloud privée de production répartit généralement les fonctions, dispose de plusieurs nœuds de calcul et de stockage redondants, de réseaux indépendants et de mécanismes de haute disponibilité.

Le terme adéquat ici est laboratoire cloud privé tout-en-un.

Et c’est précisément ce que cette approche permet de faire très bien.

D’un nœud à une vraie cloud

L’avantage principal est que les concepts appris ne se perdent pas en s’adaptant à une infrastructure plus grande.

Canonical OpenStack permet d’ajouter ultérieurement de nouveaux nœuds au cluster, séparant les rôles de contrôle, calcul et stockage.

Le laboratoire peut évoluer ainsi :

1 serveur
Contrôle + Calcul + Stockage

vers :

nœuds de contrôle
     |
nœuds de calcul
     |
nœuds de stockage
     |
Réseaux séparés

Terraform peut continuer à gérer la plupart des ressources de manière cohérente, même dans cette configuration plus complexe.

C’est probablement l’aspect le plus attractif de cette démarche : en investissant dans un simple serveur Linux avec assez de RAM, on peut construire une plateforme où apprendre KVM, OpenStack, Ceph, réseaux virtuels, cloud-init et Terraform en travaillant de concert.

Cela ne remplace pas AWS, Azure ou Google Cloud, ni ne vise à le faire. De même, cela ne transforme pas automatiquement une machine en infrastructure d’entreprise tolérante aux pannes.

Mais cela permet de comprendre réellement ce que signifie construire un cloud privé avant de passer à une infrastructure multi-nœuds.

Questions fréquentes

Peut-on installer OpenStack complet sur un seul serveur ?

Oui. Canonical fournit une procédure officielle pour exécuter Canonical OpenStack avec les rôles de contrôle, calcul et stockage sur une seule machine, spécialement destinée à l’apprentissage et à la formation.

MicroStack existe-t-il toujours ?

Le nom MicroStack est encore associé au projet, mais la documentation officielle de Canonical utilise principalement Canonical OpenStack et Sunbeam pour l’installation et la gestion.

Terraform peut-il gérer OpenStack ?

Oui, le provider Terraform pour OpenStack permet de gérer la majorité des ressources comme Nova, Neutron, Cinder, Glance ou Keystone par le biais de code.

Est-il recommandé d’utiliser un seul nœud en production ?

Non, en tant que architecture résiliente. Un seul serveur concentre tous les services et constitue un point de défaillance unique. Pour une mise en production, il faut envisager des déploiements multi-nœuds, avec redondance du stockage, des réseaux et des mécanismes de haute disponibilité.