#Docker

Eine Software, an der der Betrieb hängt, sollte sich nicht selbst auf die neueste Version aktualisieren. Unser Passwort-Tresor Vaultwarden lief auf dem Automatik-Kanal, zog Ende Juli die Version 1.37.0, und seitdem konnte niemand mehr eine Einladung in die Firmen-Organisation annehmen. Die letzte, die funktioniert hatte, war sechs Wochen alt; der Fehler war beim Hersteller gemeldet, die Korrektur noch nicht fertig. Wer immer die neueste Version nimmt, testet sie für alle anderen mit.

Aktuell ist ein Programm nicht, nur weil irgendwo automatisch danebensteht. Unser Vaultwarden lief unter der Kennzeichnung neueste Version und war trotzdem sechs Wochen hinterher, weil die neue Fassung nie geholt wurde. Das nachgezogene Update schloss neun Sicherheitslücken auf einmal, darunter eine, die Zugriff über Mandantengrenzen hinweg erlaubte. Seitdem schaue ich nicht in die Einstellung, sondern in die laufende Version. Automatisch heißt nur, dass es jemand einmal so eingerichtet hat, nicht, dass es geschieht.

Die eingerichtete Speicher-Grenze griff im Ernstfall nicht, weil sie ohne Zeitlimit auf das Ende laufender Anfragen wartete. In unserem Dokumentenarchiv Paperless sollte ein Prozess oberhalb von einem Gigabyte sanft ersetzt werden, doch unter dem Dauerstrom eingehender Akten-Scans wartete der Austausch geduldig, während der Prozess binnen Minuten auf vier bis sechs Gigabyte wuchs und das System ihn schließlich hart beendete. Seit der Austausch nach 45 Sekunden erzwungen wird, hält die Grenze auch unter Last. Eine Grenze ohne Frist ist keine Grenze, sie ist eine Bitte.

Ein Dienst darf sich selbst neu starten, aber nur mit fester Bremse und nur als Schadensbegrenzung, nicht als Reparatur. Unser Dokumentenarchiv Paperless war wegen eines bekannten Speicherlecks erst sieben Stunden, dann noch einmal anderthalb Stunden nicht erreichbar, bis jemand den Container von Hand neu startete. Jetzt prüft ein kleiner Wächter alle zwei Minuten den Zustand und startet höchstens einmal in zehn Minuten neu, aus Stunden werden so drei bis vier Minuten. Die Ursache beheben wir trotzdem, der Wächter kauft nur die Zeit bis dahin.

Ein neues Programm kann einen Dienst lahmlegen, mit dem es scheinbar nichts zu tun hat, sobald beide sich einen Server teilen. Unser Dokumentenarchiv lief zwölf Tage stabil und war dann sieben Stunden nicht erreichbar: Ein frisch installierter KI-Assistent belegte dauerhaft knapp zwei Gigabyte Arbeitsspeicher, und dem Archiv fehlte genau der Puffer, mit dem es bis dahin über die Runden kam. Der Neustart dauerte eine Minute, das Verstehen einen Abend. Auf einer geteilten Maschine ändert jeder neue Mieter die Statik für alle anderen.

Nach zwei Monaten Laufzeit fällt ein Dienst oft deshalb aus, weil eine Voreinstellung langsam vollgelaufen ist. Unser Mailserver nahm keine Verbindung mehr an, obwohl der Container als laufend gemeldet war. Die Voreinstellung im Docker-Image erlaubte 1024 gleichzeitig geöffnete Dateien, und genau 1024 waren belegt. Wir haben das Limit auf fünfundsechzigtausend gesetzt, danach waren es zweiundzwanzig. Eine Voreinstellung ist für den ersten Testlauf gedacht, nicht für den Dauerbetrieb.

Zwei laufende Exemplare eines wichtigen Programms reichen als Absicherung nicht, wenn beide im Gleichtakt altern. Unser Dokumentensystem Paperless hatte zwei Webserver-Prozesse als Reserve, doch beide starteten morgens zur selben Minute, verbrauchten gleich schnell Speicher und wurden deshalb fast gleichzeitig ausgetauscht. Genau in dieses Fenster fiel die Meldung vom Empfang, die Seite reagiere nicht. Seit drei Prozesse mit kleinerer Schwelle laufen, springt bei jedem Wechsel eine warme Reserve ein, die Seite antwortet in einer Drittelsekunde. Eine Reserve schützt nur, wenn sie nicht im selben Takt ausfällt wie das, was sie ersetzen soll.

Einem Programm, das immer mehr Speicher frisst, setzt man eine feste Grenze, statt auf einen Fix zu warten. Unser Dokumentenarchiv wurde am Tresen unbenutzbar, mit Antwortzeiten von 33 Sekunden, weil ein einzelner Serverprozess über Stunden auf sieben Gigabyte anwuchs und den ganzen Server mit sich zog. Der Fehler ist dem Hersteller bekannt und derzeit nicht behebbar, also bekam der Docker-Container eine Speichergrenze, und jeder Arbeitsprozess wird automatisch ersetzt, sobald er zu groß wird. Manche Fehler kann man nicht reparieren, nur einzäunen.

Den ganzen Server schützt man vor einem einzelnen fehlerhaften Programm wie das Auto vor einem defekten Verbraucher: mit einer Sicherung. Unsere Dokumentenverwaltung hat ein Speicherleck und füllt rund acht Gigabyte in acht Stunden, behoben ist das noch nicht. Deshalb hat der Dienst eine feste Speichergrenze bekommen, und heute Mittag griff sie zum ersten Mal: kurzer Neustart des einen Dienstes, der Rest des Servers lief ungestört weiter. Eine Grenze behebt den Fehler nicht, aber sie bestimmt, wie groß er werden darf.

Gegen einen Fehler, den der Hersteller selbst nicht beheben kann, hilft kein Warten auf ein Update, sondern eine Grenze, hinter der er keinen Schaden mehr anrichtet. Bei unserer Dokumentenablage über Docker wuchs ein einzelner Dienst auf sieben Gigabyte und riss den ganzen geteilten Server in die Knie, Last bis 118, das Öffnen eines Belegs dauerte 33 Sekunden. Der Fehler ist bekannt und nicht zu flicken, also gab ich dem Dienst eine feste Speichergrenze und einen nächtlichen Neustart. Was man nicht reparieren kann, sperrt man ein, bevor es die Nachbarn mitreißt.

Ja, die eigene Datensicherung kann den ganzen Betrieb lahmlegen, wenn niemand prüft, ob sie sich auch selbst aufräumt. Bei uns lief die Aufräum-Automatik still aus: statt sieben Tage sammelten sich vierundfünfzig, 208 GB alte Sicherungen, bis die Platte zu hundert Prozent voll war und Docker keinen einzigen Container mehr starten konnte. Alles, was in der Hetzner-Cloud lief, war mit einem Schlag offline. Eine Sicherung, die niemand kontrolliert, wird irgendwann selbst die Gefahr, vor der sie schützen sollte.

Die ganze Cloud lag lahm, weil eine einzige Festplatte zu hundert Prozent voll war. Docker konnte für die Gesundheitsprüfungen keinen Prozess mehr starten, also warf der vorgeschaltete Router alle Container als ungesund aus dem Verkehr, und jede Seite die dort hing gab nur noch einen Fehler zurück. Mein erster Verdacht fiel auf die Namensauflösung, dabei genügte ein Blick auf den freien Speicher. Elf Gigabyte Zwischenspeicher gelöscht, und die Dienste kamen von selbst zurück. Das Kleinste, das man übersieht, legt das Größte lahm.

Die alte Internet-Adresse kann man nicht kündigen, sobald die Weiterleitung steht, denn die Weiterleitung lebt genau von dieser Adresse. Als ich Ende Juni die alte Marken-Seite stillgelegt habe, blieben Namensauflösung, Zertifikat und der Eintrag im Nginx-Container bewusst bestehen, nur die Inhalte sind weg. Fehlt eines davon, landet der Besucher bei einer Sicherheitswarnung oder im Nichts statt auf der neuen Seite. Eine Weiterleitung ist kein Abschied, sondern ein Schild, das jemand halten muss.

Weil Docker und der Reverse Proxy so einen Endpunkt tausende Male am Tag abfragen. Bei mir hat ein Health-Check in einem Dienst bei jedem Aufruf eine kostenpflichtige Such-API (Tavily) angestoßen. In vierundzwanzig Stunden waren das über viertausend Aufrufe und rund zehn Euro, ohne dass die eigentliche Funktion ein einziges Mal lief. Seitdem prüft ein Health-Check bei mir nur lokal: Läuft der Prozess, antwortet er. Nichts, was Geld kostet oder nach außen telefoniert.

Sehr. Wir haben neun Server auf vier verdichtet und die Datenhaltung auf einen zentralen PostgreSQL-Server zusammengeführt. Die Kosten sind von rund einundachtzig auf sechsundvierzig Euro im Monat gesunken, und statt fünf Backup-Skripten gibt es eins. Weniger Teile heißt vor allem weniger, das nachts schweigend kaputtgehen kann.