Thema: provisioning
-
Windows-Antwortdateien (unattend.xml): Konfigurationsphasen und wo Setup danach sucht
Eine Antwortdatei unattend.xml liefert Einstellungen für bestimmte Konfigurationsphasen von Windows Setup; bei der Bereitstellung sind vor allem windowsPE, generalize, specialize und oobeSystem relevant. Setup findet die Datei über eine feste implizite Suchreihenfolge und legt sie in %WINDIR%\Panther im Cache ab; Windows System Image Manager erstellt solche Dateien und kann Passwörter lokaler Konten verbergen, aber nicht verschlüsseln.
-
Ansible-Ad-hoc-Befehle und Check-Modus für einen sicheren ersten Lauf gegen eine Serverflotte
Ein Ad-hoc-Befehl mit `ansible` führt ein Modul ohne Playbook auf einem oder mehreren Hosts aus. In Kombination mit `--check --diff` und einem eng gefassten `--limit` kann ein Agent sehen, was eine Änderung an einer Flotte bewirken würde, bevor sie tatsächlich erfolgt.
-
Windows-Image mit Sysprep generalisieren: /generalize, /oobe, /shutdown und das Rearm-Limit
Sysprep /generalize entfernt computerspezifische Informationen wie die SID und die konfigurierten Geräte aus einer Windows-Installation, damit sich das Image auf andere Computer verteilen lässt. Ab Windows 8.1/Server 2012 kann Sysprep bis zu 1001-mal pro Image ausgeführt werden (unter Windows 7/Server 2008 R2 dreimal); Fehler beim Generalisieren hinterlassen Spuren in den Panther-Logs unter System32\Sysprep.
-
SSH-Host-Keys und Machine-ID auf einem geklonten Linux-Host neu erzeugen
Ein frisch geklonter Linux-Host braucht eigene SSH-Host-Keys und eine eigene Machine-ID, bevor er in eine Flotte aufgenommen wird. `ssh-keygen -A` und `systemd-machine-id-setup` können diese erzeugen, doch bei einem bereits gebooteten Klon mit doppelter Machine-ID sind ein neu geschriebener Wert und ein Reboot nötig. Nur der Duplikatabgleich über die ganze Flotte belegt wirklich, dass das Klonen nicht einfach überall dieselben Kennungen kopiert hat.
-
Linux-Golden-Image fürs Klonen vorbereiten: Host Keys, machine-id, Logs und Netzwerkregeln
Ein Linux-Image, das mehrfach geklont werden soll, darf weder eine befüllte /etc/machine-id (oder eine veraltete /var/lib/dbus/machine-id) noch vorhandene SSH-Host-Keys, an die MAC-Adresse gebundene Netzwerkkonfiguration oder cloud-init-Zustand enthalten. Sonst starten alle Klone mit denselben Kennungen wie ihre Geschwister; und wer die Host Keys entfernt, ohne sie beim ersten Start neu erzeugen zu lassen, hinterlässt Klone ohne SSH-Zugang.
-
Server sicher ausser Betrieb nehmen: aus allen Systemen entfernen, die ihm noch vertrauen
Die Ausserbetriebnahme besteht nicht nur im Ausschalten: DNS, Monitoring, Backup-Jobs, der Inventareintrag und ein etwaiges Computerobjekt im Verzeichnisdienst vertrauen dem Server weiter oder erwarten ihn, solange niemand sie explizit bereinigt. Der Speicher braucht vor Wiederverwendung oder Entsorgung ein Sanitisierungsverfahren, das zum Medientyp passt.
-
Machine Images mit Packer erstellen: Builder, Provisioner, validate und build
HashiCorp Packer trennt die Builder eines Templates (welche Plattform das Image erzeugt) von den Provisionern (was die Maschine konfiguriert, bevor sie als Image festgehalten wird). `packer init` installiert die benötigten Plugins, `packer validate` prüft Syntax und Konfiguration, bevor `packer build` das Template ausführt, und als sensitive markierte Variablen halten Zugangsdaten aus Templates und Logs fern.
-
Debian preseed und Ubuntu autoinstall: zwei Formate für automatisierte Installationen, nicht austauschbar
Der Debian-Installer wird über eine preseed-Datei automatisiert, die debconf-Fragen beantwortet. Ubuntu Server (ab 20.04) und Desktop (ab 23.04) nutzen dagegen das YAML-Format autoinstall von Subiquity, geliefert als cloud-init-user-data oder als autoinstall.yaml auf dem Installationsmedium. Die Formate sind zwischen den Distributionen nicht übertragbar und sollten vor einer unbeaufsichtigten Installation validiert werden.
-
Provisioning-Agents für den ersten Windows-Start in der Cloud: EC2Launch v2, Azure VM Agent und cloudbase-init
AWS, Azure und die meisten anderen Clouds betreiben in Windows-Images einen kleinen Agenten, der beim ersten Start User Data bzw. Custom Data verarbeitet. Gängig sind EC2Launch v2, die Provisioning- und Windows-VM-Agents von Azure (sie legen Custom Data in CustomData.bin ab, führen es aber nicht aus) sowie das Open-Source-Tool cloudbase-init. Jeder protokolliert an einem anderen Ort, den man prüfen sollte, wenn die Provisionierung scheinbar stillschweigend gescheitert ist.
-
Prüfliste nach der Bereitstellung vor der Übergabe eines Servers
Ein Server, der bootet, ist noch kein Server, der bereit für den Produktivbetrieb ist. Diese Prüfliste gibt einem Agenten eine feste Reihenfolge von Prüfungen vor (Zeit, Namensauflösung, Patch-Stand, Monitoring, Backup-Anbindung, Zugriff und Baseline-Scan), die durchzuführen sind, bevor ein neu bereitgestellter Host als erledigt markiert wird.
-
Konfigurationsmanagement versus Image Baking: Wo Idempotenz und Drift entscheiden
Konfigurationsmanagement-Tools führen ein laufendes System bei jedem Lauf wieder auf einen deklarierten Zustand zurück, während Image Baking diesen Zustand einmalig beim Build festschreibt. Idempotenz macht die wiederholte Ausführung des ersten Ansatzes sicher; die Wahl zwischen Baking und Konfiguration beim Boot ist letztlich die Entscheidung, wo Drift auftreten darf.
-
Neuen Server benennen, taggen und erfassen: eine Methodik für Hostnamen und Inventar
Ein Server, der bereitgestellt, aber nicht einheitlich benannt, nicht mit Eigentümer und Zweck getaggt und nicht in einem Inventar erfasst wird, ist faktisch undokumentierte Infrastruktur, sobald die Person, die ihn aufgebaut hat, weiterzieht. Diese Methodik legt den Hostnamen unter Linux und Windows fest und definiert, was ein minimaler Inventareintrag enthalten muss.
-
cloud-init auf einer frischen Debian- oder Ubuntu-Instanz steuern: user-data, status --wait und sichere Wiederholungsläufe
cloud-init wendet user-data einmalig beim ersten Boot an. `cloud-init status --wait` blockiert, bis dieser Lauf beendet ist, damit ein Provisioning-Skript nicht mit ihm kollidiert. `cloud-init schema --system` findet eine fehlerhafte user-data-Datei vor dem nächsten Boot, und `cloud-init clean` ist der dokumentierte Weg, für Tests einen vollständigen Neulauf zu erzwingen.
Maschinenlesbar: JSON