Hoe een privécloud op te zetten met MicroStack en Terraform op een Linux-server

Ja, het is mogelijk om een vrij volledige private cloud lab op één enkele Linux-machine op te zetten. Canonical maakt het mogelijk om Canonical OpenStack met Sunbeam te implementeren, een evolutionaire versie van MicroStack, waarbij op één enkele node de rollen van control, compute en storage worden gecombineerd. Wanneer je dit combineert met Terraform, Ubuntu Cloud-images en een virtual firewall zoals OpenWrt, ontstaat een zeer praktische omgeving om OpenStack te leren, automatisering te testen en cloud-architecturen na te bootsen zonder dat je grote infrastructuur hoeft aan te schaffen bij hyperscalers.

De kernpunten van een private OpenStack-cloud in 20 seconden

• Canonical maakt het mogelijk om OpenStack op één enkele server te draaien, ideaal voor labs en leerdoeleinden.
• Hetzelfde knooppunt kan de rollen van control, compute en storage vervullen.
• Terraform automatiseert netwerken, routers, beveiligingsregels en instanties via de OpenStack provider.
• OpenWrt kan als virtuele appliance fungeren voor experimenten met routing en segmentatie.
• Een enkel knooppunt is geschikt voor lab-omgevingen, maar biedt niet de veerkracht van een productiecloud.

Dit concept is vooral interessant voor systeembeheerders, studenten en ontwikkelaars die willen begrijpen wat er achter services zoals EC2 of Azure Virtual Machines gebeurt. In plaats van enkel een virtuele machine te maken via een publiek dashboard, kunnen ze zelf netwerken opbouwen, images beheren, IP-adressen toewijzen, beveiligingsregels instellen en alles automatiseren met code.

Er is wel een belangrijke terminologische upgrade: hoewel MicroStack nog steeds bekend is, hanteert de officiële documentatie van Canonical nu vooral de namen Canonical OpenStack en sunbeam voor de deployment. Canonical biedt ook een officiële tutorial aan voor het opzetten van een dergelijke omgeving op een enkele machine.

Wat kan er echt binnen één enkele machine passen?

Een dergelijke lab-omgeving bootst een groot deel van de essentiële componenten van een IaaS-cloud na.

De architectuur kan er zo uitzien:

In een reguliere inzet zouden deze componenten verdeeld zijn over meerdere nodes. In het lab worden ze bewust geconcentreerd om de kosten en fysieke complexiteit te beperken.

Canonical stelt voor deze basisopstelling minimaal 4 x86-64 kernen, 16 GiB RAM, 100 GiB SSD-opslag en een ongeformatteerde schijf voor MicroCeph voor. Het is ook mogelijk om het lab binnen een VM te draaien, al wordt dan wel performance verloren.

Voor het comfortabel werken met meerdere VMs is het raadzaam om meer RAM te gebruiken. 16 GiB is een goed startpunt, maar 32 of 64 GiB bieden veel meer flexibiliteit voor experimenten.

Installatie: Sunbeam als hoofdrolspeler

De installatie begint met het openstack-pakket van Canonical:

sudo snap install openstack

Dit pakket bevat sunbeam, de tool die veel van de complexiteit bij het deployen van OpenStack abstraheert.

Vervolgens wordt het knooppunt voorbereid:

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

En daarna wordt het cluster gestart met de drie hoofdrollen:

sunbeam cluster bootstrap --role control,compute,storage

Voor een vereenvoudigde setup kan ook met:

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

Sunbeam zet achter de schermen verschillende componenten op, waaronder Kubernetes voor control plane functies, Juju, de hypervisor van OpenStack en MicroCeph voor storage.

Vervolgens kan het omgeving worden geconfigureerd:

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

En je kunt al een eerste instantie lanceren om te testen of alles werkt:

sunbeam launch ubuntu --name test

Zo heb je binnen één machine een klein werkend cloud-omgeving.

Terraform maakt het lab reproduceerbaar als infrastructuur

De volgende stap is waarschijnlijk het meest interessant: automatisch resources beheren in plaats van alles handmatig doen.

Er bestaat een OpenStack-provider voor Terraform, waarmee je via code diensten zoals Nova, Neutron, Cinder, Glance en Keystone kunt beheren.

Een basisconfiguratie begint bijvoorbeeld zo:

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

provider "openstack" {
  cloud = "lab"
}

Vervolgens kunnen netwerken worden gedeclareerd:

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

En subnets:

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
}

Tot slot kunnen instances worden gedeclareerd:

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

  network {
    uuid = openstack_networking_network_v2.lab.id
  }
}

Het grote voordeel van deze aanpak komt naar voren wanneer het lab groeit. Netwerken, machines, regels en afhankelijkheden worden niet meer alleen handmatig beheerd, maar staan in versieerbare bestanden.

Een simpele:

terraform apply

herbouwt het volledige environment.

Zo wordt het lab veel meer een kopie van hoe een echte cloud-infrastructuur wordt beheerd.

OpenWrt toevoegen als virtuele firewall

Een andere interessante optie is om OpenWrt als virtuele machine binnen de omgeving te deployen.

OpenWrt draait op x86 en wordt gedocumenteerd voor virtualisatie met QEMU/KVM, waardoor het uitermate geschikt is voor experimenten met netwerk appliances.

Een eenvoudige architectuur kan bijvoorbeeld bestaan uit twee virtuale interfaces:

Internet / externe netwerk
        |
     OpenWrt
        |
   privé-netwerk OpenStack
        |
  VM1   VM2   VM3

OpenWrt regelt dan routing, NAT, firewallregels en andere diensten.

Het lab stelt je in staat om bij te leren over situaties die lastig na te bootsen zijn in een basis VM-omgeving: meerdere tenant-netwerken, virtuele routers, isolatie tussen projecten, en regels voor inkomend en uitgaand verkeer.

Het is wel zo dat OpenStack zelf Neutron gebruikt voor netwerken en beveiligingsgroepen. OpenWrt is niet per se nodig voor het draaien van de cloud. De meerwaarde ligt in het verrijken van het lab als een omgeving waar je met een netwerk appliance kunt experimenteren binnen je eigen infrastructuur.

cloud-init vereenvoudigt nog een handmatige taak

Ubuntu Cloud-images zijn voorbereid voor cloud-init, waarmee een VM automatisch tijdens de eerste opstart kan worden geconfigureerd.

Bijvoorbeeld:

#cloud-config
packages:
  - nginx

runcmd:
  - systemctl enable --now nginx

Terraform kan dit stukje configuratie via user_data meegeven.

Daarmee verander je van:

een VM maken → via SSH ingaan → pakketten installeren → configuratie aanpassen

naar:

terraform apply → VM wordt gemaakt en direct geconfigureerd

Voor een Infrastructure as Code lab is dat onderscheid belangrijk. Terraform beschrijft de infrastructuur, en cloud-init verzorgt de initiële configuratie van het gast-systeem.

Wat deze lab beter maakt dan een AWS-account

Het opzetten van zo’n cloud-infrastructuur helpt om concepten te doorgronden die grote cloudproviders bewust verbergen achter beheerde diensten.

Bij het starten van een AWS EC2-instantie is het niet nodig om kennis te hebben van Nova, Neutron of KVM.

Dat is hier wel het geval.

De beheerder krijgt inzicht in de onderlinge verbindingen:

Terraform
   ↓
OpenStack API
   ↓
Nova ─────────→ KVM
   ↓
Neutron ──────→ netwerken
   ↓
Glance ───────→ images
   ↓
Ceph ─────────→ opslag

Het helpt ook fouten te ontdekken.

Een verkeerde netwerk-instelling, een te restrictieve beveiligingsregel of een fout in de externe connectie maken meteen zichtbaar waar het probleem zit.

Deze ervaringskennis is bijzonder waardevol voor opleiding en inzicht.

Een enkele server maakt geen productieclouddienst

Daar ligt de belangrijkste waarschuwing.

Dat OpenStack op één enkele machine draait, betekent niet dat deze architectuur geschikt is voor productie.

De Canonical-tutorial benadrukt dat een eenvoudige deployment vooral bedoeld is voor leerdoeleinden. Voor productiesituaties wordt uitgebreid met meerdere nodes, redundantie en hoge beschikbaarheid gewerkt.

In een enkele machine bestaat een gevaarpunt van uitval:

Host faalt
     ↓
Compute faalt
     ↓
Opslag faalt
     ↓
Control plane faalt
     ↓
Gehele cloud uit

Er is geen sprake van echte high availability, en het migreren van VM’s tijdens runtime is niet mogelijk tenzij er meerdere hypervisors zijn.

Een professionele private cloud bestaat uit meerdere knooppunten voor compute, storage, en netwerk, met redundantie en automatische failover.

Dus, de juiste term is een all-in-one private cloud lab.

En dat is precies waarvoor het uitstekend geschikt is.

Van één knooppunt naar een echte cloud

Het voordeel is dat je opgedane kennis niet verloren gaat bij uitbreiding.

Canonical OpenStack ondersteunt het toevoegen van nieuwe nodes aan de cluster en kan rollen van control, compute en storage scheiden.

Het lab kan evolueren van:

1 server
Control + Compute + Storage

Naar:

Control nodes
     |
Compute nodes
     |
Storage nodes
     |
Gescheiden netwerken

Terraform blijft de resources beheren volgens dezelfde logica.

Daar ligt misschien wel de grootste waarde van dit experiment. Van een betaalbare Linux-server met voldoende RAM kan je een platform bouwen waar je leert KVM, OpenStack, Ceph, virtuele netwerken, cloud-init en Terraform samen te gebruiken.

Het vervangt niet AWS, Azure of Google Cloud, en is ook niet bedoeld om automatisch een fault-tolerant enterprise infrastructure te worden. Maar het geeft wel inzicht in wat het bouwen van een private cloud inhoudt, voordat je overgaat op meerdere servers.

Veelgestelde vragen

Kan ik een complete OpenStack-implementatie op één server zetten?

Ja. Canonical biedt een officiële methode om Canonical OpenStack met control, compute en storage rollen op één machine uit te voeren, vooral voor leerdoeleinden en labs.

Bestaat MicroStack nog?

De naam MicroStack wordt nog wel gebruikt, maar de officiële Canonical-documentatie verwijst nu vooral naar Canonical OpenStack en Sunbeam bij de installatie en operaties.

Kan Terraform OpenStack beheren?

Ja. De OpenStack-provider voor Terraform maakt het mogelijk om diensten zoals Nova, Neutron, Cinder, Glance en Keystone te beheren via code.

Is het verstandig om een enkele node in productie te gebruiken?

In productie wordt het sterk afgeraden. Eén enkele server vormt een enkel punt van falen. Voor productieomgevingen worden multi-node deployments, redundantie en hoge beschikbaarheid aanbevolen.