Sistemas

MAAS de Canonical: guía real para empezar a automatizar bare metal con Ubuntu

Publicado el 20/07/2026 Análisis y guía práctica en su-ip.es

Canonical ha simplificado el arranque con MAAS en julio de 2026. Te contamos qué cambia, qué necesitas revisar y cuándo tiene sentido automatizar bare metal con Ubuntu.

Canonical ha movido MAAS a un terreno mucho más práctico para quien quiere empezar con bare metal sin perder una tarde entera montando piezas sueltas. El 14 de julio de 2026, Ubuntu publicó una nueva guía de instalación y arranque para MAAS que simplifica el primer despliegue con el snap de MAAS y el snap de PostgreSQL, pensado para un laboratorio, una prueba de concepto o incluso un entorno pequeño con servidores reales.

La noticia importa porque muchas herramientas de automatización hablan como si todo empezara ya en la nube, pero en infra real siguen existiendo racks, nodos físicos, laboratorios, Kubernetes sobre metal, entornos regulados y equipos que necesitan reutilizar máquinas rápido. Ahí es donde MAAS convierte el hardware en un recurso programable, y lo nuevo de julio de 2026 es que arrancar con esa idea es bastante menos enrevesado que antes.

Resumen rápido: qué ha pasado y por qué importa

14 de julio de 2026: Canonical publica una nueva pieza oficial centrada en instalar MAAS de forma más directa.
El flujo recomendado para empezar usa MAAS snap + PostgreSQL snap.
La documentación de arranque propone un despliegue single-machine en modo region+rack.
El objetivo es facilitar un homelab, PoC o despliegue pequeño antes de pasar a topologías mayores.
Canonical refuerza además la idea de que MAAS cubre el día 0 y Landscape el día 2 cuando el parque Ubuntu crece.

Qué ha publicado Canonical exactamente

La pieza oficial de Ubuntu explica que el arranque con MAAS ahora se apoya en una documentación nueva y más lineal. En vez de obligarte a saltar entre tutoriales pensados sobre todo para entornos de prueba aislados, el nuevo enfoque empuja a instalar MAAS, levantar PostgreSQL, inicializar el servicio, crear la cuenta de administrador y empezar a configurar red y descubrimiento de máquinas reales.

Ese matiz es importante. Canonical no está diciendo que MAAS sea “más simple” porque haga menos cosas, sino porque el primer recorrido hacia un entorno útil ahora encaja mejor con cómo trabaja alguien que quiere tocar hardware de verdad. La guía “Get started” se presenta como punto de entrada válido para un laboratorio doméstico, una PoC pequeña o una instalación inicial de producción contenida.

Qué es MAAS y por qué puede interesarte hoy

MAAS es la plataforma de Canonical para descubrir, comisionar, desplegar y reutilizar servidores físicos desde un plano de control central. La idea práctica es tratar el bare metal como si fuera un recurso parecido a una nube privada: con inventario, automatización, APIs y reprovisionado repetible, en vez de depender de procedimientos manuales máquina por máquina.

Eso encaja especialmente bien en escenarios donde la nube pública no es la respuesta completa: clusters Kubernetes sobre metal, edge, entornos con GPUs caras, private cloud, laboratorios, entornos regulados o infra local con requisitos de red concretos. Si ya te interesó nuestra pieza sobre Ubuntu Livepatch en Arm64, aquí aparece la otra cara del mismo problema: no solo importa mantener sistemas, también importa desplegarlos y reciclarlos bien desde el principio.

Administrador de sistemas desplegando servidores bare metal desde un panel central en una sala técnica moderna — MAAS está pensado para tratar servidores físicos como recursos reutilizables, no como máquinas aisladas que se tocan a mano una por una.

Qué cambia en la práctica con la nueva guía de julio de 2026

La mejora no está en un botón mágico, sino en la reducción de fricción inicial. Canonical destaca tres cambios prácticos:

Instalación más directa: el flujo recomendado usa los snaps de MAAS y PostgreSQL para montar un entorno completo sin diseñar desde el minuto uno una arquitectura mayor.
Configuración básica encadenada: después de instalar, la documentación enlaza enseguida con la parte útil de verdad: DNS upstream, subred gestionada, DHCP, rango dinámico, gateway y red donde arrancarán los nodos.
Enfoque realista: deja de ser solo un tutorial bonito en sandbox y pasa a orientarte hacia máquinas físicas y una red donde los equipos hacen PXE, se descubren, se comisionan y se despliegan.

Eso significa que pruebas mejor la herramienta antes de comprometerte con ella. Si una solución de bare metal te obliga a construir demasiado contexto antes de ver valor, mucha gente la abandona. Canonical intenta corregir justo ese punto de abandono.

Qué necesitas revisar antes de probar MAAS

La promesa de “bare metal programable” suena bien, pero conviene no entrar a ciegas. Antes de levantar MAAS, merece la pena revisar esto:

Red disponible para PXE y DHCP: necesitas decidir qué segmento controlará MAAS y evitar choques con otros servicios ya activos.
Acceso de gestión fuera de banda: cuanto mejor tengas IPMI, Redfish o equivalente, más sentido tiene automatizar de verdad.
Qué quieres demostrar: no es lo mismo probar descubrimiento y reprovisionado en un lab que preparar una base para Kubernetes o private cloud.
Hardware reutilizable: MAAS luce más cuando puedes descubrir, comisionar, desplegar y luego reciclar nodos sin rehacer el proceso entero.
Inventario mínimo claro: subredes, VLAN, gateway, DNS y rangos IP deben estar definidos aunque el entorno sea pequeño.

Si estas piezas no están mínimamente claras, el problema no será MAAS sino entrar a automatizar una red que todavía no está decidida. Igual que en nuestra guía sobre configurar un router Movistar, aquí también vale la misma regla: antes de tocar, hay que saber qué red mandas, desde dónde y con qué límites.

Dónde encaja Landscape y por qué Canonical insiste en ello

Otra parte interesante del mensaje de Canonical es que MAAS no pretende hacerlo todo. En la pieza del 9 de julio de 2026, Ubuntu recuerda que MAAS cubre sobre todo el día 0: descubrir, validar, desplegar y reasignar hardware. Cuando el sistema ya está corriendo, entra Landscape como capa de operaciones del día 2: visibilidad, mantenimiento, monitorización, parches y gestión continuada del parque Ubuntu.

Eso es una señal saludable. En vez de vender una suite difusa que “sirve para todo”, Canonical separa mejor el flujo: primero conviertes el metal en recurso desplegable; luego mantienes ese estate Ubuntu con otra capa de control. Para equipos pequeños eso ayuda a entender qué problema resuelve cada herramienta. Para equipos grandes, ayuda a no mezclar aprovisionado, cumplimiento y lifecycle management como si fueran lo mismo.

Equipo de operaciones revisando estado de servidores Ubuntu, parches y provisión bare metal en un centro de datos — Canonical separa bien el trabajo: MAAS para aprovisionar y reciclar metal, Landscape para operar y mantener sistemas Ubuntu con continuidad.

Para qué casos tiene más sentido

Homelab serio o laboratorio técnico donde quieres aprender reprovisionado real y no solo levantar VMs sueltas.
Prueba de concepto para private cloud o Kubernetes sobre hardware propio.
Edge o sedes con servidores físicos que necesitas reinstalar o reasignar con rapidez.
Entornos con GPUs, almacenamiento local o requisitos regulatorios donde el bare metal sigue mandando.
Parques Ubuntu que crecerán y luego necesitarán una capa de operaciones continuada con Landscape.

Errores comunes al plantearlo

Probar MAAS en una red que no controlas y culpar a la herramienta cuando el caos viene del DHCP o del PXE.
Esperar valor con una sola máquina improvisada y sin un caso claro de reprovisionado.
Confundir instalación con producción: que el entorno arranque no significa que tu diseño de red o de alta disponibilidad esté resuelto.
No separar día 0 y día 2, esperando que MAAS sustituya toda la gestión posterior del estate.
Entrar sin objetivo operativo: si no sabes si vas a probar hardware discovery, despliegue Ubuntu, Kubernetes o OpenStack, acabarás midiendo mal el resultado.

FAQ rápida

¿MAAS sirve solo para grandes centros de datos?

No. La documentación nueva de Canonical está pensada precisamente para que puedas empezar en un homelab, una PoC pequeña o una instalación reducida antes de crecer.

¿Qué aporta frente a instalar Ubuntu a mano en varios servidores?

Repetibilidad, descubrimiento, inventario y reprovisionado. Si una máquina cambia de función o hay que reciclarla, la idea es no empezar desde cero con trabajo manual.

¿Hace falta nube para que tenga sentido?

No. Justamente el valor de MAAS es llevar una experiencia parecida a la automatización cloud al hardware físico.

¿MAAS sustituye a Landscape?

No. MAAS y Landscape resuelven fases distintas del ciclo de vida: uno aprovisiona y el otro ayuda a operar y mantener sistemas Ubuntu a largo plazo.

Fuentes oficiales

Conclusión

Lo nuevo de julio de 2026 no convierte MAAS en una herramienta trivial, pero sí la acerca bastante a una primera prueba útil. Y eso, en infra, vale mucho: una plataforma que te deja llegar antes al momento de verdad, que es descubrir hardware, configurar red, desplegar Ubuntu y decidir si el enfoque encaja en tu entorno.

Si gestionas sistemas, laboratorios o metal propio, este es uno de esos temas donde merece la pena mirar la fuente oficial y probar con intención. No porque “bare metal” se haya puesto de moda, sino porque cada vez más equipos necesitan automatización real sin regalar todo su stack a una nube pública.