Zum Inhalt

Was man von Hand darf

Wir haben alle per SSH Zugriff auf die Hosts und könnten dort alles ändern. Diese Seite zieht die Grenze: was man auf einem Host von Hand tun darf und was nicht, jeweils mit Begründung.

Auf einen Blick

Von Hand machen wir auf den Hosts nur Dinge, die die Konfiguration nicht verändern. Jede Änderung an der Konfiguration geht über das Repo und apply.

Tätigkeit Von Hand erlaubt? Warum
Nachsehen: Logs lesen, Status prüfen, laufende Container ansehen ja Ändert nichts.
Container zur Fehlersuche stoppen, starten oder neu starten (systemctl stop, start, restart) ja Nur vorübergehend; ändert keine Konfiguration.
Container dauerhaft stoppen nein, über das Repo Gehört zur Konfiguration: desiredState: "stopped" in der Stack-Datei.
Daten aus dem Backup zurückholen (Restore) ja Holt Daten zurück, ändert keine Konfiguration.
Dienst neu einlesen lassen (systemctl reload) nein Es gibt nichts neu einzulesen.
Container, Unit-Dateien oder Konfiguration ändern nein Das Repo stimmt nicht mehr, und apply macht es rückgängig.
SELinux abschalten oder Labels von Hand setzen (setenforce 0, chcon) nein Schaltet einen Schutz ab bzw. umgeht das Repo.

Nachsehen

Logs lesen, den Status eines Dienstes prüfen oder nachsehen, welche Container laufen, verändert nichts auf dem Host. Das darf man immer, und es ist bei jeder Störung der erste Schritt. Wie das geht, steht in Container-Status und Logs ansehen.

Container starten, stoppen und neu starten

Im Normalfall kümmert sich niemand von Hand darum, ob ein Container läuft: Jedes apply startet alle Container, die laut Repo laufen sollen, und stürzt ein laufender Container ab, startet systemd ihn von selbst neu (Restart=always).

Bei der Fehlersuche darf man einen Container trotzdem von Hand stoppen, starten oder neu starten. Das ändert keine Konfiguration, nur, ob der Container gerade läuft.

Ein von Hand gestoppter Container bleibt gestoppt. Restart=always greift nur, wenn ein laufender Container abstürzt, nicht, wenn man ihn absichtlich stoppt. Nach der Fehlersuche muss man ihn deshalb wieder starten, entweder mit systemctl start oder mit apply, das alle gestoppten Container wieder startet.

Dauerhaft stoppen geht über das Repo. Soll ein Container länger gestoppt bleiben, trägt man in seiner Stack-Datei desiredState: "stopped" ein und rollt das aus. Dann steht im Repo, dass er absichtlich nicht läuft, und das nächste apply startet ihn nicht versehentlich wieder. Mehr dazu: Stop a container without removing it in der syslet-Doku

Neu starten hilft vor allem, wenn ein Container abgestürzt ist und nicht von selbst wieder hochkommt. systemd versucht es zwar erneut, wartet aber nach jedem Fehlschlag länger bis zum nächsten Versuch (exponentieller Backoff) und kann so schon mehrere Minuten pausieren. Ist die Ursache behoben, etwa weil eine Datenbank wieder läuft, bringt ein systemctl restart den Container sofort wieder hoch.

Kein reload: systemctl reload lässt einen Dienst seine Konfiguration neu einlesen. Weil auf dem Host nichts von Hand geändert wird, gibt es nichts neu einzulesen; Änderungen an der Konfiguration bringt apply auf den Host und startet die betroffenen Dienste dabei selbst neu.

Wie das geht, steht in Gecrashten Dienst wieder hochbringen.

Restore aus dem Backup

Ein Restore holt Daten zurück, zum Beispiel eine Datenbank oder hochgeladene Dateien. Die Daten einer App liegen nicht im Repo (siehe Infrastructure as Code), also gibt es dort auch nichts, was nicht mehr übereinstimmen könnte. Wie das geht, steht in App aus dem Backup wiederherstellen.

Konfiguration ändern

Container von Hand anlegen oder ändern, Unit-Dateien bearbeiten, Umgebungsvariablen anpassen: all das ist nicht erlaubt.

Was syslet verwaltet, zeigt das nächste plan als Abweichung (Drift), und das nächste apply macht es rückgängig, egal wer es ausführt. Die Änderung ist dann einfach wieder weg, oft ohne dass die Person, die apply ausführt, weiß, warum es sie gab.

Was syslet nicht sieht, etwa eine Änderung innerhalb eines laufenden Containers, bleibt bestehen, steht aber nirgends im Repo. Beim nächsten Update oder Neuaufbau ist sie verschwunden, und niemand weiß mehr, dass es sie gab.

In beiden Fällen ist das Repo nicht mehr die Wahrheit über die Server, und genau darauf verlassen wir uns (siehe Grundsätze).

SELinux

SELinux abzuschalten (setenforce 0) nimmt allen Containern den Schutz voreinander. Labels von Hand zu setzen (chcon) behebt ein Problem nur auf diesem einen Host und nur bis zum nächsten Neuaufbau. Die richtige Lösung ist die passende Volume-Option in der Stack-Datei; siehe SELinux und „Permission denied“ durch SELinux beheben.

Auch im Notfall nicht

Auch wenn es schnell gehen muss, ändern wir die Konfiguration nicht von Hand. Jede Konfigurationsänderung geht über die Dateien im Repo und apply, auch die schnelle Korrektur einer einzelnen Zeile.

Der Weg über das Repo ist kaum langsamer: Datei ändern und cue cmd apply ausführen dauert nur Sekunden. Dafür ist die Korrektur danach für alle sichtbar und wird nicht beim nächsten apply stillschweigend wieder rückgängig gemacht, mitten in der nächsten Störung.

Weiterlesen