Grundsätze im Selfhosting¶

Nach diesen Regeln betreiben wir unsere eigenen Server. Hier stehen sie kurz mit ihrer Begründung; die Details stehen auf den verlinkten Seiten. Was für die gesamte Infrastruktur gilt, steht in Grundsätze.

Alles läuft in Containern¶

Alle Anwendungen und Dienste auf unseren Servern laufen in Containern. Auf den Hosts selbst liegt nur die Grundlage: das Betriebssystem, Podman, der WireGuard-Tunnel und ein paar Dateien, die wir von Hand pflegen.

Warum: Jede Anwendung bringt im Container mit, was sie braucht, und kommt den anderen nicht in die Quere. Ein Update tauscht den Container aus, ohne den Host zu verändern, und eine App lässt sich rückstandslos entfernen.

Mehr dazu: Podman, Statische Konfiguration

SELinux bleibt an, Volumes immer mit :Z oder :z¶

SELinux ist auf allen Hosts aktiviert und bleibt es. Jedes Volume und jeder Bind-Mount bekommt die Option :Z (nur dieser Container) oder :z (mehrere Container), zum Beispiel in syslet/werner/stack-hedgedoc.cue. Ausnahmen gibt es nur dort, wo nicht umgelabelt werden darf oder kann.

Warum: SELinux gibt jedem Container ein eigenes Label. Ein kompromittierter Container kommt dadurch nicht an die Dateien anderer Container oder des Hosts. Die Volume-Option sorgt dafür, dass die Daten das passende Label bekommen.

Mehr dazu: SELinux

Secrets nur verschlüsselt im Repo¶

Passwörter, Tokens und Schlüssel (Secrets) liegen nur verschlüsselt im Repo. Für den Terraform-State, die Zugangsdaten interner Dienste wie Datenbanken und Startpasswörter gibt es begründete Ausnahmen.

Warum: Ein Repo kann in falsche Hände geraten, etwa über einen verlorenen Laptop. Und die Git-Historie vergisst nichts: Ein Secret, das einmal unverschlüsselt committet wurde, gilt als bekannt und muss ausgetauscht werden.

Mehr dazu: Secrets im Repo

Vor jedem Image-Update den Changelog lesen¶

Bevor wir eine Anwendung auf eine neue Version heben, lesen wir den Changelog aller Versionen dazwischen. Wir drehen nie einfach nur den Tag hoch.

Warum: Zwischen zwei Versionen können Breaking Changes, geänderte Konfigurationsoptionen, Datenbank-Migrationen oder Pflicht-Zwischenversionen liegen. Nach einer Datenbank-Migration geht der Weg zurück oft nur noch über ein Backup.

Mehr dazu: Image-Version anheben