Erststart-Arbeit mit cloud-init erledigen

Was läuft und wann

Jedes Linux-Image trägt cloud-init. Beim ersten Start liest es die user-data, die deiner Bestellung beigefügt ist, wendet sie einmal an und schreibt eine Markierung, sodass es nie wieder läuft. Das alles passiert, bevor du irgendetwas eingegeben haben könntest, und genau das ist der Punkt: Das Fenster zwischen der Existenz einer Instanz und ihrer Konfiguration ist das Fenster, das du nicht haben solltest.

Validiere das Dokument, bevor du bestellst. Der Schema-Checker fängt den Einrückungsfehler ab, der dich sonst einen Rebuild kosten würde:

cloud-init schema --config-file user-data.yaml --annotate

Eine user-data, die die nützlichen Dinge tut

#cloud-config
hostname: edge-01
fqdn: edge-01.example.com
timezone: UTC

users:
  - name: deploy
    groups: [sudo]
    shell: /bin/bash
    sudo: "ALL=(ALL) NOPASSWD:ALL"
    ssh_authorized_keys:
      - ssh-ed25519 AAAAC3Nza... deploy@laptop

ssh_pwauth: false
disable_root: true

package_update: true
package_upgrade: true
packages:
  - nftables
  - vnstat
  - mtr-tiny

write_files:
  - path: /etc/ssh/sshd_config.d/10-local.conf
    permissions: "0644"
    content: |
      PermitRootLogin no
      PasswordAuthentication no
      AllowUsers deploy

runcmd:
  - [systemctl, enable, --now, nftables]
  - [systemctl, restart, ssh]

Die erste Zeile ist weder ein Kommentar noch optional. Ohne #cloud-config wird das Dokument still ignoriert und die Instanz bootet, als hättest du nichts angehängt.

Auf AlmaLinux wird groups: [sudo] zu groups: [wheel] und der Dienst, der neu gestartet werden muss, ist sshd. Alles andere ist identisch.

Zusehen, wie es funktioniert

cloud-init status --long
journalctl -u cloud-final -b
less /var/log/cloud-init-output.log

Das Journal verrät dir, welche Stufe fehlgeschlagen ist. cloud-init-output.log enthält die tatsächliche Ausgabe deiner runcmd-Einträge, und dort steht der Grund.

Keine Geheimnisse hineinschreiben

User-data bleibt für die gesamte Lebensdauer von innerhalb der Instanz lesbar:

cloud-init query userdata

Alles darin ist für jeden Prozess verfügbar, der Root erreicht, und für jeden, der einen Snapshot der Festplatte wiederherstellt. Verwende es, um eine Anmeldedaten zu installieren, die das Geheimnis abruft, nicht um das Geheimnis selbst zu tragen.

Testen ohne eine Instanz zu verbrennen

cloud-init clean --logs --reboot

Das entfernt die Markierung, die Logs und die gecachte Datenquelle und bootet dann in einen frischen ersten Start. Führe es auf einem Wegwerf-System aus. Führe es in Produktion aus, und du wirst entdecken, was dein runcmd beim zweiten Mal tut, was selten das ist, was es beim ersten Mal getan hat.

Wo aufhören

cloud-init ist für das Bootstrapping gedacht und hat keine Ahnung, in welchem Zustand die Maschine morgen sein sollte. Verwende es, um den Punkt zu erreichen, an dem deine echten Werkzeuge übernehmen können: ein Schlüssel, ein Netzwerk, ein Agent. Höre dort auf. Sechzig Zeilen sind eine gesunde user-data, und sechshundert sind ein Konfigurationsverwaltungssystem ohne Möglichkeit zu konvergieren.

cloud-init query -a
cloud-init query ds.meta_data

Instanz-ID, Standortcode, Hostname und die beim Boot zugewiesenen Adressen befinden sich alle dort; das ist, was ein Skript braucht, wenn es sich irgendwo registrieren muss und noch nicht weiß, wo es aufgewacht ist.