Seeds mit cloud-init automatisch einrichten

Mit einer cloud-init-Konfiguration richten Sie einen Seed schon beim allerersten Boot automatisch ein: Pakete installieren, Dienste starten, Konfigurationsdateien anlegen, einen Webserver bereitstellen, ganz ohne manuelle SSH-Sitzung. dataforest setzt dafür auf cloud-init, den De-facto-Standard für die Erstkonfiguration von Cloud-Servern. Diese Anleitung erklärt, was cloud-init ist, wo Sie es angeben, und zeigt ein vollständiges Beispiel.

Was cloud-init ist

Cloud-init ist das Werkzeug, das viele Linux-Distributionen beim ersten Start einer frisch erstellten Maschine ausführen. Es liest die sogenannte User-Data, die Sie der Maschine mitgeben, und richtet das System danach ein, bevor Sie sich das erste Mal anmelden. Genau diese User-Data hinterlegen Sie bei dataforest im Feld Cloud-init. Cloud-init ist ein etabliertes Open-Source-Projekt; die offizielle cloud-init-Dokumentation beschreibt alle Module und Optionen im Detail.

Wichtig ist das Timing: Cloud-init läuft einmalig beim ersten Boot des Seeds. Sobald die Einrichtung abgeschlossen ist, wird es nicht erneut ausgeführt, auch nicht bei späteren Neustarts. So eignet sich cloud-init ideal für die einmalige Grundinstallation, nicht für wiederkehrende Aufgaben.

Wo Sie cloud-init angeben

Beim Erstellen eines Seeds finden Sie unterhalb der Erweiterungen den optionalen Abschnitt Cloud-init. Klicken Sie auf Cloud-init hinzufügen und fügen Sie Ihre Konfiguration in das Eingabefeld ein. Lassen Sie das Feld leer, startet der Seed mit der Standard-Konfiguration des gewählten Images.

Auch bei einer Neuinstallation können Sie eine cloud-init-Konfiguration angeben: im Seed-Detail unter Verwalten im Abschnitt Seed leeren und neu installieren. Da bei der Neuinstallation ein neuer erster Boot stattfindet, läuft cloud-init dann erneut.

Die cloud-init-Konfiguration wird nicht dauerhaft gespeichert. Nach der Einrichtung wird sie vom Seed entfernt. Wenn Sie eine Neuinstallation durchführen, müssen Sie die gewünschte Konfiguration deshalb erneut eintragen.

Beispiel: einen Webserver beim ersten Boot bereitstellen

Am gebräuchlichsten ist eine cloud-config: ein YAML-Dokument, das cloud-init beim Boot abarbeitet. Eine cloud-config beginnt immer mit der Zeile #cloud-config. Das folgende Beispiel aktualisiert die Pakete, installiert den Webserver nginx, hinterlegt eine eigene Startseite und startet den Dienst:

#cloud-config
package_update: true
package_upgrade: true
packages:
  - nginx
write_files:
  - path: /var/www/html/index.html
    content: |
      <h1>Bereitgestellt per cloud-init</h1>
runcmd:
  - [ systemctl, enable, --now, nginx ]

Zeile für Zeile:

• package_update und package_upgrade bringen Paketquellen und installierte Pakete auf den aktuellen Stand. Eine frische Installation kann veraltete Pakete mit bekannten Sicherheitslücken enthalten.
• packages installiert die gewünschten Pakete, hier nginx. cloud-init wählt den passenden Paketmanager automatisch, das funktioniert unter Debian und Ubuntu ebenso wie unter AlmaLinux und RockyLinux.
• write_files legt Dateien an, hier eine einfache Startseite. Der Pfad /var/www/html gilt für Debian und Ubuntu; auf AlmaLinux und RockyLinux liegt das nginx-Verzeichnis unter /usr/share/nginx/html.
• runcmd führt Befehle am Ende des Bootvorgangs aus, hier aktiviert und startet es nginx. Alle Befehle laufen mit Root-Rechten, ein vorangestelltes sudo ist nicht nötig.

Anders als in allgemeinen cloud-init-Anleitungen müssen Sie hier weder einen Benutzer anlegen noch den Root-Login absichern: Ihr Zugang wird von dataforest bereits eingerichtet (mehr dazu im nächsten Abschnitt). Sie konzentrieren sich also ganz auf das, was Ihr Server tun soll.

Lieber ein Shell-Skript?

Statt einer cloud-config können Sie auch ein gewohntes Shell-Skript einfügen. Beginnen Sie es mit der üblichen Shebang-Zeile, dann wird es direkt ausgeführt:

#!/bin/bash
apt-get update
apt-get install -y nginx
systemctl enable --now nginx

Dieses Beispiel gilt für Debian und Ubuntu; auf AlmaLinux und RockyLinux verwenden Sie dnf statt apt-get. Eine cloud-config wie oben ist meist die robustere Wahl, weil sie den Paketmanager selbst wählt und das Ergebnis unabhängiger von der Distribution ist.

Ihre Zugangsdaten bleiben erhalten

Die Anmeldedaten, die Sie bei der Erstellung gewählt haben (SSH-Schlüssel oder Passwort), werden unabhängig von der cloud-init-Konfiguration immer eingerichtet. Sie müssen Login-Informationen also nicht in Ihre Konfiguration schreiben, und Sie sperren sich auch nicht aus, wenn Sie sie weglassen.

Wenn Sie in einer cloud-config zusätzliche SSH-Schlüssel über ssh_authorized_keys angeben, werden diese zu den verwalteten Schlüsseln hinzugefügt, nicht ersetzt. Auch Hostname und Standard-Benutzer sind bereits vorkonfiguriert, um diese Grundeinstellungen müssen Sie sich also nicht kümmern.

Regeln und Grenzen

Damit Ihre cloud-init-Konfiguration zuverlässig läuft, beachten Sie folgende Punkte:

• Maximale Größe: 32 KiB (32 768 Bytes).
• Klartext: Der Inhalt wird im Klartext verarbeitet. Legen Sie hier keine Passwörter, Token oder anderen geheimen Daten ab.
• Gültiges YAML: Eine cloud-config beginnt mit #cloud-config und muss danach ein gültiges YAML-Dokument sein, sonst wird die Erstellung abgelehnt. Welche Module Sie darin verwenden, ist nicht eingeschränkt.

Überprüfen, ob cloud-init gelaufen ist

Verbinden Sie sich nach der Erstellung per SSH mit dem Seed und fragen Sie den Status von cloud-init ab:

cloud-init status --long

status: done bedeutet, dass die Einrichtung abgeschlossen ist. Steht dort noch running, läuft cloud-init gerade, warten Sie kurz und prüfen Sie erneut. Die vollständige Ausgabe von cloud-init inklusive aller Meldungen finden Sie im Log:

cat /var/log/cloud-init-output.log

Hier sehen Sie, welche Pakete installiert wurden und ob Ihre Befehle erfolgreich waren. Wenn etwas nicht wie erwartet funktioniert hat, ist /var/log/cloud-init-output.log die erste Anlaufstelle zur Fehlersuche. Für das Beispiel oben können Sie zusätzlich prüfen, ob der Dienst läuft:

systemctl status nginx

Fertig

Ihr Seed richtet sich jetzt beim ersten Boot selbst ein. Beginnen Sie am besten mit einer kleinen Konfiguration wie im Beispiel oben und bauen Sie sie Schritt für Schritt aus, bis Ihr Server genau so startet, wie Sie ihn brauchen.