Ein Kubernetes-Cluster, eine Handvoll einzelner Maschinen, alles in OpenTofu, und Ausrollungen, die Git-Commits sind. Warum die unmodische Hälfte unseres Entwurfs Absicht ist, und vier Infrastrukturregeln, die ohne Ausnahme gelten.
Es gibt ein Genre von Infrastrukturbeiträgen, das ein Service Mesh aufzählt, drei Observability-Anbieter, eine Multi-Cloud-Failover-Geschichte und ein Plattformteam, und mit "und so bedienen wir 4.000 Nutzer" endet. Dies ist nicht dieser Beitrag. Unsere Infrastruktur ist darauf ausgelegt, langweilig zu sein, und die Langeweile ist tragend. Teil 5 der Reihe.
Alles läuft bei OVHcloud in Frankreich, was laut Teil 1 kein Zufall war. Darin hat die Plattform genau zwei Formen.
Ein Kubernetes-Cluster betreibt die Koordinationsschicht: die Verwaltungsoberfläche auf app.email.eu, die öffentliche Website, die Statusseite, unsere Messungen und die geplanten Aufgaben, die die Plattform aufgeräumt halten. Das sind die Bauteile, die wir oft ausrollen, und das Cluster gibt uns rollende Updates, Selbstheilung und einfache horizontale Skalierung genau dort, wo wir sie brauchen. Daneben betreibt es unsere Postgres-Datenbanken, verwaltet von einem Operator, mit Replikaten und einem Verbindungspooler, was Teil 4 von der Ausfallseite her behandelt hat.
Einzelne virtuelle Maschinen betreiben die schweren Säulen: Mail, Dateispeicher, Chat, Meetings, Dokumentbearbeitung. Das ist die unmodische Hälfte des Entwurfs, und sie ist beabsichtigt. Diese Produkte halten Zustand, sind hungrig nach Plattenplatz und wollen stabile Netzidentitäten; die IP-Adresse eines Mailservers ist Teil seiner Reputation. Sie aktualisieren in ihrem eigenen Takt, nicht in unserem. Und sie auf getrennten Maschinen zu halten, hält Ausfälle getrennt: Ein schlechter Tag für den Dateiserver kann dem Mailserver physisch nicht den Speicher wegnehmen. Kubernetes kauft seine Magie mit einer Schicht Indirektion, die wir lieber nicht unter eine Mail-Ablage legen.
Die Prüfung, die wir anlegen, ist einfach. Profitiert dieses Bauteil davon, automatisch verschoben zu werden, oder wüssten wir um drei Uhr nachts lieber genau, auf welcher Maschine es liegt, wenn etwas nicht stimmt? Webdinge bestehen die erste Prüfung. Mail besteht die zweite.
Der gesamte Bestand, Cluster, Maschinen, DNS, Verteiler, ist in OpenTofu beschrieben, dem quelloffenen Werkzeug für Infrastruktur als Code, in einem Repository. Die Maschinen richten sich selbst aus Skripten ein, die man gefahrlos wiederholen kann, sodass "richte einen Mailknoten ein" keine Wiki-Seite mit Schritten ist, sondern ein Skript, das jedes Mal dasselbe Ergebnis liefert. Stürbe eine Maschine unwiederbringlich, bauten wir sie aus dem Repository neu auf und nicht aus dem Gedächtnis.
Geheimnisse folgen demselben Prinzip mit einer Wendung: Sie liegen verschlüsselt im Repository (Verschlüsselung mit age, Schlüssel bei Menschen, nie im Klartext in git), und das Ausrollwerkzeug weigert sich, irgendetwas anzuwenden, wenn die lokalen Geheimnisse von der verschlüsselten Quelle der Wahrheit abweichen. Diese Wache gibt es, weil "welcher Laptop hat die richtigen Variablen" der Weg ist, auf dem Teams große Unfälle bauen.
Ausrollungen sind Git-Commits. Unsere eigene CI auf ci.email.eu (die Regel zu europäischen Anbietern gilt auch für Bauinfrastruktur) baut jede Änderung zu einem Image mit dem Kennzeichen genau des Commits, der es erzeugt hat, und diese Kennzeichen sind unveränderlich: Ein Kennzeichen kann nie still etwas anderes bedeuten. Aber bauen ist nicht ausliefern. Nichts erreicht die Produktion, weil Code zusammengeführt wurde. Eine Ausrollung ist ein eigener Commit von einer Zeile, von einem Menschen geschrieben und gepusht, der ändert, welches Image die Produktion betreibt; die Pipeline wendet genau diese Festlegung an und wartet, bis die Ausrollung gesund ist. So blieben die zwei Eigenschaften erhalten, die uns wichtig waren, als Ausrollen noch ein Mensch mit einem Skript war: Jede Ausrollung ist eine bewusste menschliche Entscheidung, und die Ausrollgeschichte ist einfach Git-Geschichte, sodass Zurückrollen bedeutet, einen Commit zurückzunehmen.
Keine dieser Regeln ist exotisch. Ihr Wert liegt darin, dass sie absolut sind: Sie gelten, wenn Sie müde sind, wenn Sie sicher sind, und wenn Sie es eilig haben, und genau dann werden sie gebraucht.
Weil Langeweile sich zu Ihren Gunsten verzinst. Weniger bewegliche Teile heißt weniger neuartige Ausfallarten, und eine Plattform, die aus einem Repository rekonstruierbar ist, heißt, dass unsere Katastrophengeschichte nicht von jemandes Gedächtnis abhängt. Wenn ein Anbieter Sie mit Architektur blendet, ist es eine faire Frage, wer die Aufregung bezahlt. Unsere Antwort ist, dass das niemand tun sollte, also haben wir sie entfernt.
Als Nächstes Teil 6: wie wir all das beobachten, warum unsere Statusseite dieselben Zahlen zeigt, auf die wir uns alarmieren, und was wir für die Tage gebaut haben, an denen doch etwas kaputtgeht.