Sí, es posible montar un laboratorio de nube privada bastante completo en una única máquina Linux. Canonical permite desplegar Canonical OpenStack con Sunbeam, evolución del proyecto MicroStack, concentrando en un solo nodo los roles de control, cómputo y almacenamiento. Si se combina con Terraform, imágenes Ubuntu Cloud y un firewall virtual como OpenWrt, el resultado es un entorno muy útil para aprender OpenStack, probar automatización y reproducir arquitecturas cloud sin contratar infraestructura a un hiperescalares.

Las claves de una nube privada OpenStack en 20 segundos

• Canonical permite desplegar OpenStack en un único servidor para laboratorios y aprendizaje.
• Un mismo nodo puede asumir los roles de control, cómputo y almacenamiento.
• Terraform puede automatizar redes, routers, reglas de seguridad e instancias mediante el provider de OpenStack.
• OpenWrt puede funcionar como appliance virtual para experimentar con routing y segmentación.
• Un diseño de un solo nodo sirve para laboratorio, pero no ofrece la resiliencia de una nube de producción.

La idea resulta especialmente interesante para administradores de sistemas, estudiantes y desarrolladores que quieran entender qué ocurre realmente detrás de servicios como EC2 o Azure Virtual Machines. En lugar de limitarse a crear una máquina virtual desde un panel público, pueden construir las redes, gestionar imágenes, asignar direcciones, definir reglas de seguridad y automatizar todo mediante código.

Hay, eso sí, una actualización terminológica importante. Aunque MicroStack sigue siendo un nombre muy conocido, la documentación actual de Canonical presenta el producto como Canonical OpenStack, desplegado mediante el comando sunbeam. Canonical mantiene precisamente un tutorial oficial para montar todo el entorno en una sola máquina.

Qué puede caber realmente dentro de una sola máquina

Un laboratorio de estas características reproduce buena parte de los componentes fundamentales de una nube IaaS.

La arquitectura puede plantearse de esta forma:

Capa	Tecnología	Función
Host físico	Ubuntu Server/Desktop	Servidor base
Virtualización	KVM	Ejecución de máquinas virtuales
Cloud	Canonical OpenStack / Sunbeam	Gestión de recursos
Compute	Nova	Ciclo de vida de instancias
Networking	Neutron	Redes, subredes y routers
Imágenes	Glance	Imágenes de sistemas operativos
Identidad	Keystone	Usuarios, proyectos y permisos
Almacenamiento	MicroCeph	Backend de almacenamiento
Automatización	Terraform	Infrastructure as Code
Firewall opcional	OpenWrt	Routing y perímetro virtual
Configuración de VMs	cloud-init	Aprovisionamiento inicial

En un despliegue normal estos componentes acabarían repartidos entre distintos nodos. En el laboratorio se concentran deliberadamente para reducir el coste y la complejidad física.

Canonical establece para su tutorial básico un mínimo de 4 núcleos x86-64, 16 GiB de RAM, 100 GiB de almacenamiento SSD y un disco adicional sin formatear para MicroCeph. También admite ejecutar el laboratorio dentro de una máquina virtual, aunque advierte de la pérdida de rendimiento.

Para trabajar con varias VMs de forma cómoda resulta razonable disponer de bastante más memoria. Los 16 GiB sirven como punto de partida; 32 o 64 GiB ofrecen mucha más libertad para experimentar.

Instalación: ahora el protagonista es Sunbeam

La instalación actual comienza con el paquete openstack de Canonical:

sudo snap install openstack

El paquete incorpora sunbeam, la herramienta que abstrae buena parte de la complejidad de desplegar OpenStack.

Después se prepara el nodo:

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

Y se inicializa asignando al mismo servidor los tres papeles principales:

sunbeam cluster bootstrap --role control,compute,storage

En el tutorial simplificado puede utilizarse también:

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

Sunbeam despliega por debajo diferentes elementos, entre ellos Kubernetes para alojar funciones del plano de control, Juju, el hipervisor de OpenStack y MicroCeph para almacenamiento.

Después puede configurarse el entorno:

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

Y comprobar que funciona lanzando una primera instancia:

sunbeam launch ubuntu --name test

Esto ya proporciona un pequeño cloud funcional en un único servidor.

Terraform convierte el laboratorio en infraestructura reproducible

El siguiente paso es probablemente el más interesante: dejar de crear los recursos manualmente.

Existe un provider de OpenStack para Terraform que permite administrar mediante código buena parte de los servicios disponibles en la plataforma, desde Nova y Neutron hasta Cinder, Glance o Keystone.

La configuración conceptual puede comenzar así:

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

provider "openstack" {
  cloud = "lab"
}

A partir de ahí pueden declararse recursos como redes:

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

Una subred:

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
}

Y finalmente instancias:

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

  network {
    uuid = openstack_networking_network_v2.lab.id
  }
}

La ventaja aparece cuando el laboratorio crece. Redes, máquinas, reglas y dependencias dejan de existir únicamente como una configuración realizada manualmente y pasan a estar descritas en archivos versionables.

Un:

terraform apply

puede reconstruir el entorno.

Y eso acerca mucho más el laboratorio a la forma en que se administra infraestructura cloud real.

Añadir OpenWrt como firewall virtual

Otra posibilidad interesante consiste en desplegar OpenWrt como una máquina virtual dentro del propio entorno.

OpenWrt puede ejecutarse sobre x86 y está documentado para funcionar virtualizado con QEMU/KVM, por lo que resulta apropiado para experimentar con appliances de red.

Una arquitectura sencilla podría utilizar dos interfaces virtuales:

Internet / red externa
        |
     OpenWrt
        |
   red privada OpenStack
        |
  VM1   VM2   VM3

OpenWrt puede encargarse entonces de routing, NAT, políticas de firewall o servicios adicionales.

El laboratorio permite experimentar con situaciones que resultan más difíciles de reproducir en una instalación básica de máquinas virtuales: varias redes tenant, routers virtuales, aislamiento entre proyectos o reglas de entrada y salida.

Eso sí, OpenStack ya dispone de Neutron para proporcionar networking y grupos de seguridad. OpenWrt no es necesario para construir el cloud. Su utilidad está en convertir el laboratorio en un entorno más rico donde experimentar con una appliance de red dentro de la propia infraestructura.

cloud-init elimina otra tarea manual

Las imágenes Ubuntu Cloud están preparadas para trabajar con cloud-init, de modo que una VM puede recibir automáticamente su configuración durante el primer arranque.

Por ejemplo:

#cloud-config
packages:
  - nginx

runcmd:
  - systemctl enable --now nginx

Terraform puede entregar este contenido mediante user_data.

Eso permite pasar de:

crear una VM → entrar por SSH → instalar paquetes → modificar configuración

a:

terraform apply → VM creada y configurada

Para un laboratorio de Infrastructure as Code, esta diferencia es importante. Terraform describe la infraestructura y cloud-init se encarga de la configuración inicial del sistema invitado.

Lo que este laboratorio enseña mejor que una cuenta en AWS

Montar una nube de este tipo sirve para entender conceptos que los grandes proveedores cloud ocultan deliberadamente detrás de servicios administrados.

Al crear una instancia de AWS EC2 no es necesario conocer Nova, Neutron o KVM.

Aquí sí.

El administrador puede observar cómo se relacionan:

Terraform
   ↓
OpenStack API
   ↓
Nova ─────────→ KVM
   ↓
Neutron ──────→ networking
   ↓
Glance ───────→ imágenes
   ↓
Ceph ─────────→ almacenamiento

También permite provocar errores.

Una ruta incorrecta, una regla de seguridad demasiado restrictiva o una red externa mal definida hacen visible inmediatamente qué capa está fallando.

Desde el punto de vista formativo, esa experiencia tiene mucho valor.

Un servidor no convierte el laboratorio en una nube de producción

Aquí aparece la principal precaución.

Que OpenStack pueda ejecutarse en un único servidor no significa que esa arquitectura deba utilizarse como diseño general para producción.

El propio tutorial de Canonical especifica que el despliegue simplificado está destinado al aprendizaje. Para entornos productivos remite a procedimientos diferentes y permite ampliar el clúster con nuevos nodos.

En una máquina única existe un punto único de fallo:

Falla el host
     ↓
Falla compute
     ↓
Falla almacenamiento
     ↓
Falla control plane
     ↓
Falla todo el cloud

No existe alta disponibilidad real del hardware y tampoco puede realizarse una migración en vivo hacia otro hipervisor si solamente existe uno.

Una nube privada de producción suele separar funciones, disponer de varios nodos de cómputo y almacenamiento redundante, redes independientes y mecanismos de alta disponibilidad.

Por tanto, el término adecuado es laboratorio cloud privado all-in-one.

Y para eso funciona especialmente bien.

De un nodo a una nube real

La ventaja es que los conceptos aprendidos no se pierden al crecer.

Canonical OpenStack permite añadir posteriormente nuevas máquinas al clúster y separar los roles de control, cómputo y almacenamiento.

El laboratorio puede evolucionar de:

1 servidor
Control + Compute + Storage

a:

Control nodes
     |
Compute nodes
     |
Storage nodes
     |
Networks separadas

Terraform puede seguir administrando los recursos de los usuarios prácticamente con la misma lógica.

Ese es probablemente el mayor atractivo del experimento. Por el precio de un servidor Linux con suficiente RAM puede construirse una plataforma donde aprender KVM, OpenStack, Ceph, redes virtuales, cloud-init y Terraform trabajando conjuntamente.

No sustituye a AWS, Azure o Google Cloud, ni pretende hacerlo. Tampoco convierte automáticamente una máquina en una infraestructura empresarial tolerante a fallos.

Pero sí permite comprender qué significa realmente construir una nube privada antes de dar el salto a varios servidores.

Preguntas frecuentes

¿Se puede instalar OpenStack completo en un solo servidor?

Sí. Canonical proporciona oficialmente un procedimiento para ejecutar Canonical OpenStack con los roles de control, cómputo y almacenamiento sobre una única máquina, especialmente orientado a aprendizaje y laboratorio.

¿MicroStack sigue existiendo?

El nombre MicroStack sigue asociado al proyecto, pero la documentación actual de Canonical utiliza principalmente Canonical OpenStack y Sunbeam para la instalación y operación.

¿Puede Terraform administrar OpenStack?

Sí. El provider de OpenStack para Terraform permite gestionar recursos de servicios como Nova, Neutron, Cinder, Glance y Keystone, entre otros.

¿Es recomendable utilizar un único nodo en producción?

No como arquitectura resiliente. Un único servidor concentra todos los servicios y constituye un punto único de fallo. Para producción deben estudiarse despliegues multinodo, redundancia de almacenamiento, networking y alta disponibilidad.