Hetzner-Cloud, wie wärs mit dogfooding?

Hetzner vermarktet seit einiger Zeit seine virtuellen Server über eine neue Plattform namens „Hetzner Cloud“ und es gibt sogar ein Terraform-Plugin dafür. Aber anscheinend nutzen es die Leute selbst nicht und vermutlich auch keine anderen provisioning Tools in hochautomatisierten Umgebungen, denn die wenigen verfügbaren Base-Images für virtuelle Server sind steinalt und erfordern nach Kernelupgrades einen Reboot (z.B. Ubuntu 18.04). Weiterhin schlägt beim Start ein ziemlich nutzloser apt-daily-upgrade.timer an , für den man dann erst mal ein passendes lock-wait implementieren bzw raussuchen darf:

 eval $(apt-config shell StateDir Dir::State/d)
 exec 3>${StateDir}/daily_lock
 if ! flock -w 3600 3; then
     echo "E: Could not acquire lock" >&2
     exit 1
 fi

 # dann selber den kram machen
 apt-get --yes dist-upgrade 
 … 
 usw

Dann einen fälligen Reboot (/var/run/reboot-required) auszuführen ist insbesondere bei Terraform ziemliche Frickelei und quasi nicht sauber zu realisieren, wenn man nicht noch ein Konfigurationssystem wie z.B. chef verwendet, das automatisch nach einer Zeitspanne erneut den Zustand der VM überprüft und anpasst.

Während man vielleicht noch das remote-exec für einen Reboot hinbekommt, so lässt sich uU eine Race-Kondition bei weiteren Scripts/remote-execs nicht verhindern und Terraform ist dann schon mit der nächsten ssh-connection auf der VM, die gerade rebootet und den ganzen terraform apply run zerstört.

Warum kann Hetzner nicht einfach jede Nacht (oder mindestens 1x die Woche) ein neues Base-Image bauen, Digital Ocean und andere machen das auch, seit Jahren.

PS: Wo ich gerade dabei bin: Das ganze ist leider auch deshalb half-assed, weil traditionelle Rootserver und DNS-Produkte von Hetzner nicht im Terraform-Plugin integriert sind, hier muss man doch wieder auf alte Ruby-Tools ausweichen oder für DNS auf cloudflare. Das ist schade, denn Digital Ocean und Vultr können das auch seit Ewigkeiten, von den richtigen Cloud-Anbietern wie AWS, Azure und GCP brauchen wir garnicht reden.

Durch das Fehlen der „Altprodukte“ wie den Rootservern, einem Markt bei dem Hetzner noch immer Preis-Leistungs-Weltmeister ist, verschenkt das Unternehmen viele Businesskunden, die ansonsten ihre CI/CD-Umgebungen darüber aufgebaut hätten und ihr VC dann lieber bei Amazon verbrennen.

PPS: mirror.hetzner.de scheint auch nicht so ganz zuverlässig zu sein. Während der Mirror sich aktualisiert, fliegt ein apt-get update einem um die Ohren:

hcloud_server.chef01 (remote-exec): E: Failed to fetch http://mirror.hetzner.de/ubuntu/packages/dists/bionic-updates/main/binary-amd64/Packages.xz  File has unexpected size (527320 != 531652). Mirror sync in progress? [IP: 213.133.99.97 80]
 hcloud_server.chef01 (remote-exec):    Hashes of expected file:
 hcloud_server.chef01 (remote-exec):     - Filesize:531652 [weak]
 hcloud_server.chef01 (remote-exec):     - SHA256:03fcba5bb70314db9f9ee7fe8a20b29218fe4c6adfc80574788dc048377f3fbf
 hcloud_server.chef01 (remote-exec):     - SHA1:05de5554be6dd08fcd165da4bf6e065f95857378 [weak]
 hcloud_server.chef01 (remote-exec):     - MD5Sum:fa29053de2528ee10a4c725dd1307048 [weak]
 hcloud_server.chef01 (remote-exec):    Release file created at: Tue, 26 Feb 2019 18:59:59 +0000

Ich kenne deren Infrastruktur nicht, aber mit einem Blue/Green-Deployment sollte das doch eigentlich nicht passieren: Man synchronisiert die jeweils nicht aktive Instanz (per rsync oder was auch immer) und ändert dann schlicht den Symlink, von dem der Webserver aus die Dateien bereitstellt. Alternativ schwenkt man das ganze Setup am Eingangs-HAproxy/Rerverseproxy einfach um. Bonuspunkte, wenn man das Ganze parallel betreiben kann (d.h. fallback für gerade laufende Paketdownloads).