MAAS (Metal as a Service) macht physische Server programmierbar und automatisiert deren Lebenszyklus. Bislang gab es mehrere Startwege, von komplett sandboxed in Multipass bis zu komplexeren Produktionsaufbauten. Canonical hat die Dokumentation überarbeitet und einen klareren, pragmatischen Pfad beschrieben: Ein Single‑Machine‑Deployment in Region+Rack‑Modus, aufgebaut mit dem MAAS‑Snap und dem PostgreSQL‑Snap. Das Ergebnis ist eine schnellere, realistischere Einstiegserfahrung für Tests, Homelabs und kleine Produktionsszenarien.

Was ist MAAS kurz zusammengefasst?

MAAS bietet eine zentrale Steuerfläche, um physische Maschinen zu entdecken, zu inventarisieren, zu kommissionieren, zu deployen und wieder freizugeben. Es verhält sich in vielen Aspekten wie eine Cloud‑Orchestrierung für Bare‑Metal: Netzwerkservices (DHCP, DNS), PXE‑Boot und eine UI/CLI ermöglichen automatisierte Installations‑ und Verwaltungsabläufe für Serverhardware.

Bisherige Einstiegsmöglichkeiten und ihre Grenzen

Für einen schnellen ersten Blick gab es bereits Anleitungen, die MAAS in einer komplett isolierten Umgebung demonstrieren. Ein Beispiel ist das Tutorial „Build a MAAS and LXD environment in 30 minutes with Multipass“, das eine Sandbox auf dem Notebook erzeugt. Dort kommt das Hilfsprogramm maas‑test‑db zum Einsatz, das sich gut eignet, um UI und grundlegende Maschinenlebenszyklen kennenzulernen — allerdings ohne echte Hardware und ohne die Netzwerkanforderungen eines Bare‑Metal‑Setups abzubilden.

Wer echte Server betreiben möchte, stieß bisher auf mehr Konfigurationsaufwand: Paket‑ und Service‑Setup, separate Datenbankkonfigurationen und die Gestaltung einer mehrschichtigen MAAS‑Topologie. Das machte die erste reale Erfahrung auf physischer Hardware für Einsteiger unnötig kompliziert.

Neuer empfohlenes Setup: MAAS‑Snap + PostgreSQL‑Snap in Region+Rack‑Modus

Die überarbeitete Dokumentation empfiehlt einen geradlinigen Weg: Installation des MAAS‑Snaps und des PostgreSQL‑Snaps auf einer einzigen Maschine im Region+Rack‑Modus. Diese Variante entspricht näher einer Standard‑MAAS‑Installation als die bisherigen sandbox‑Workflows und ist praktisch genug für Labore, Proof‑of‑Concepts und kleine Produktionsumgebungen.

Der Kern dieses Ansatzes:

• MAAS über den Snap bereitstellen – vereinfachte Paketverwaltung und Updates.
• PostgreSQL ebenfalls als Snap betreiben – einfache, isolierte Datenbankinstanz.
• Region+Rack‑Modus auf einer Maschine betreiben, um ein vollständiges MAAS‑Control‑Plane‑Setup zu erzeugen.

Diese Kombination reduziert den manuellen Aufwand beim Einrichten von Systemdiensten und Abhängigkeiten. Wer die Schritte der Anleitung befolgt, erhält eine lauffähige MAAS‑Umgebung, ohne von Beginn an komplexe Netzwerk‑Topologien planen zu müssen.

Die wichtigsten konfigurativen Schritte nach der Installation

Die neue «Configure MAAS»‑Anleitung führt unmittelbar nach der Installation durch die Basiskonfiguration, die nötig ist, damit MAAS mit physischer Hardware arbeiten kann. Zu den typischen Arbeitsschritten zählen:

• Anmeldung an der MAAS‑UI oder über die CLI und Anlage eines Administrator‑Kontos.
• Einrichtung der initialen Netzwerkdienste: DHCP‑ und DNS‑Einstellungen.
• Festlegen eines Upstream‑DNS‑Servers, damit Maschinen später Namen auflösen können.
• Identifizieren des Subnets, das MAAS verwalten soll (also das Netzwerk, in dem die Maschinen per PXE booten).
• Auswahl des Rack‑Controllers, der DHCP für das Subnet bereitstellen wird.
• Definition eines dynamischen IP‑Bereichs für automatische Adressvergabe.
• Aktivieren von DHCP auf der relevanten VLAN‑Schnittstelle, sofern VLANs im Einsatz sind.
• Setzen des Gateways für das Subnet, damit deployed Systeme Zugriff auf andere Netze erhalten.

Diese Schritte verbinden MAAS mit dem Netzwerk, das für das Booten, die Entdeckung, die Kommissionierung und das spätere Deployment der physischen Maschinen nötig ist. Der Fokus liegt auf einem pragmatischen Minimum an Entscheidungen, damit Einsteiger nicht frühzeitig in Architekturfragen verfallen, die erst in größeren Umgebungen relevant werden.

Warum dieser Ansatz praktisch ist

Die überarbeitete Dokumentation zielt darauf ab, die Zeitspanne zwischen Installation und der ersten echten Erfahrung mit Hardware zu verkürzen. Weniger Zeit für Paketinstallation und Service‑Kopfarbeit bedeutet mehr Zeit, um MAAS‑Workflows zu testen: Wie entdeckt MAAS Server? Wie läuft die Kommissionierung? Wie verhält sich das Deployment in meiner Netzwerktopologie?

Für Labore und PoCs ist das entscheidend: Sie bekommen ein realistischeres Bild vom Verhalten auf physischer Hardware, ohne gleich in komplexe Hochverfügbarkeits‑ oder verteilte Datenbankarchitekturen investieren zu müssen. Wenn die Umgebung später wachsen soll, besteht weiterhin die Möglichkeit, auf fortgeschrittene Konfigurationen umzusteigen — etwa die Konfiguration von PostgreSQL für Remote‑Verbindungen, die ebenfalls in der Dokumentation behandelt wird.

Empfehlungen für den Praxiseinstieg

Wer MAAS ausprobieren möchte, sollte dem neuen Getting‑Started‑Guide folgen und mit der empfohlenen Single‑Machine Region+Rack‑Installation beginnen. Kurz zusammengefasst:

• MAAS und PostgreSQL jeweils als Snap installieren.
• Die Basisnetzwerk‑Konfiguration erledigen: DNS, Subnet, DHCP‑Bereich, VLAN/Gateway.
• Ein oder zwei physische Maschinen anschließen und den Discovery/Commissioning‑Zyklus durchlaufen lassen.
• Bei Bedarf danach in die erweiterten Anleitungen wechseln, z. B. zur Remote‑Datenbankkonfiguration oder zum Aufbau einer verteilten MAAS‑Topologie.

Dieser gestufte Ansatz erleichtert das Lernen: Man bekommt früh sichtbare Ergebnisse und kann dann zielgerichtet in komplexere Themen einsteigen.

Fazit

Die neue Dokumentationslinie für MAAS verschlankt den Einstieg in Bare‑Metal‑Provisioning, indem sie einen pragmatischen, realitätsnahen Pfad beschreibt: ein einzelner MAAS‑Server in Region+Rack‑Modus, betrieben mit MAAS‑ und PostgreSQL‑Snaps. Für Labore, Proof‑of‑Concepts und kleine Produktionen ist das eine sinnvolle und zeitsparende Methode, um die Automatisierung physischer Server kennenzulernen — mit der Option, später auf komplexere Setups zu skalieren.