Umzug ins Internet: Proxy, Härtung, Überwachung

Der Umzug ist durch. Alle Dienste laufen in Containern, verwaltet über ein Panel, hinter einem gemeinsamen Eingang. Dieser Eintrag ist die Zusammenfassung dessen, was dabei entstanden ist — und was ich anders gemacht habe als vorher.

Der Eingang

Ein Reverse Proxy nimmt alles entgegen. Er kümmert sich um Zertifikate, verteilt nach Hostname auf die Dienste und ist die einzige Stelle, an der etwas von außen ankommt.

Der Unterschied zu meinem alten Aufbau: Vorher gab es einen Webserver mit einer Konfigurationsdatei pro Dienst, die ich von Hand gepflegt habe. Jetzt gibt es einen Proxy mit einer Oberfläche, in der ein neuer Dienst ein Eintrag ist — Hostname, Ziel, Zertifikat automatisch.

Was gleich geblieben ist und mir wichtig war:

• Kein Dienst lauscht auf einer öffentlichen Adresse. Alle nur intern, erreichbar über den Proxy.
• Die Firewall lässt eingehend genau drei Dinge durch: Verwaltungszugang, Web, und die Spielserver-Ports.
• Die Weiterleitungskopfzeilen sind gesetzt, damit Anwendungen die echte Adresse des Anfragenden sehen und ihre eigenen Adressen richtig bilden.

Die Falle mit Containern und der Firewall

Ein Punkt, der mich mehrere Stunden gekostet hat und den ich vorher nicht kannte: Docker umgeht die übliche Firewall.

Wenn man einen Port eines Containers veröffentlicht, trägt Docker eigene Regeln ein — und zwar in einer Kette, die vor den üblichen Regeln greift. Ein Port, den man für „nur lokal" hält, ist damit unter Umständen aus dem Internet erreichbar, obwohl die Firewall ihn nicht freigibt.

Die Lösung ist, Ports entweder gar nicht zu veröffentlichen (Dienste erreichen sich über ein gemeinsames Netzwerk per Name) oder ausdrücklich an eine bestimmte Adresse zu binden. Und zusätzlich eigene Regeln in der Kette zu ergänzen, die Docker dafür vorsieht.

Das ist die Sorte Wissen, die man einmal erwirbt und danach bei jedem Aufbau braucht. Vorher hätte ich geschworen, dass mein Aufbau dicht ist.

Härtung

Zugang nur mit Schlüssel, keine Passwörter, kein Verwaltungskonto direkt.

Automatische Sperren bei auffälligem Verhalten. Wiederholte Fehlanmeldungen, massenhafte Anfragen auf nicht existierende Adressen. Die Regeln greifen auf die Protokolle des Proxys zu.

Grenzen pro Dienst. Jeder Container hat feste Werte für Speicher und Rechenzeit. Das ist die Konsequenz aus dem alten Aufbau, in dem ein Bau alles andere mitreißen konnte — und aus einem Prozess, der sich unerlaubt Rechenzeit genommen hat.

Ausgehende Verbindungen eingeschränkt für Dienste, die keine brauchen.

Getrennte Zugänge. Das Panel erlaubt es, jemandem Zugriff auf einen einzelnen Dienst zu geben, ohne ihm die Maschine zu geben. Das war einer der Hauptgründe für den ganzen Umbau.

Überwachung, neue Fassung

Meine alte Überwachung hat gefragt: Läuft, was laufen soll? Die neue fragt zusätzlich: Läuft etwas, das nicht laufen sollte?

Konkret:

• Erreichbarkeit von außen, für jeden öffentlichen Dienst, von einem anderen Ort aus.
• Lebenszeichen der Anwendungen, wie bisher.
• Sicherungen, mit Alters- und Größenprüfung.
• Speicherplatz mit Hochrechnung, nicht als Prozentwert.
• Grundlast im Vergleich zur Vorwoche. Der neue Punkt. Ein Prozess, der Rechenzeit verbraucht, ohne dazuzugehören, fällt genau hier auf.
• Offene Ports, regelmäßig von außen geprüft und mit einer erwarteten Liste verglichen.

Der letzte Punkt ist der, den ich am meisten empfehlen würde. Er beantwortet eine Frage, die man sonst nur beim Aufsetzen stellt und danach nie wieder — obwohl sich die Antwort mit jedem neuen Dienst ändern kann.

Die Reihenfolge, die den Umzug ruhig gemacht hat

Der Umzug lief in einer festen Reihenfolge, und die war der Grund, warum die Ausfallzeit gering blieb.

Zuerst alles Neue nur auf der neuen Maschine. Kein Umzug, sondern paralleler Aufbau. Damit gibt es einen Zeitraum, in dem beide Systeme existieren und nur eines benutzt wird.

Dann der unwichtigste Dienst. Zwei Wochen laufen lassen. In dieser Zeit lernt man das neue Verfahren an etwas, dessen Ausfall niemanden stört.

Dann die sichtbaren, aber verkraftbaren Dienste. Die Webseite. Sichtbar genug, um echte Erfahrungen zu sammeln, verkraftbar genug, um eine Stunde Ausfall auszuhalten.

Zuletzt die zusammenhängenden Teile in einem Rutsch. Alles, was sich eine Datenbank teilt, muss gemeinsam umziehen. Das ist der einzige Schritt mit echter Ausfallzeit, und er will vorbereitet sein.

Der alte Server bleibt. Vier Wochen, unangetastet. Die Umschaltung läuft über die Namensauflösung, der Rückweg ist damit eine Änderung von Minuten.

Was ich beim Umzug über meine eigene Dokumentation gelernt habe

Der Umzug hat eine Schwäche offengelegt, die vorher nicht auffiel: Ich hatte kein Verzeichnis dessen, was überhaupt läuft.

Es gab keine Liste der Dienste. Keine Liste der Zeitpläne. Keine Liste der Zertifikate, der Zugänge, der Verbindungen zwischen Diensten. All das war über Jahre entstanden, und die einzige vollständige Quelle war die laufende Maschine selbst.

Der praktische Weg, so etwas zu erstellen, ist unangenehm ehrlich: alles anschauen, was auf der Maschine aktiv ist — laufende Dienste, Zeitpläne, Ports, Zertifikate, Verzeichnisse — und für jeden Eintrag entscheiden, ob er mitkommt.

Bei diesem Durchgang habe ich mehrere Dinge gefunden, die seit Monaten liefen und niemandem mehr nützten. Sie sind nicht mit umgezogen — und das ist der versteckte Gewinn eines Umzugs: Er ist die einzige Gelegenheit, bei der man gezwungen ist, alles einmal in die Hand zu nehmen.

Was der Umzug tatsächlich gekostet hat

Grob: zwei Wochen Vorbereitung nebenher, ein langes Wochenende Durchführung, danach etwa zwei Wochen Nacharbeit an Kleinigkeiten.

Die Ausfallzeit für die sichtbaren Dienste lag bei unter einer Stunde, weil ich die Reihenfolge eingehalten habe: erst Unwichtiges, dann Sichtbares, zuletzt die zusammenhängenden Teile in einem Rutsch.

Was länger gedauert hat als geplant, war nicht das Umziehen, sondern das Beschreiben. Jeder Dienst braucht eine Definition: Abbild, Startbefehl, Variablen, Grenzen. Für Standardsoftware gibt es Vorlagen, für eigene Anwendungen schreibt man sie selbst — und dabei merkt man, wie viele undokumentierte Annahmen im alten Aufbau steckten.

Genau das ist der eigentliche Gewinn. Ein Umzug zwingt einen, alles einmal auszusprechen, was vorher implizit war.