Één Kubernetes-cluster, een handvol losse machines, alles in OpenTofu, en uitrollen die git-commits zijn. Waarom de onmodieuze helft van ons ontwerp opzet is, en vier infrastructuurregels die zonder uitzondering gelden.
Er is een genre infrastructuurartikel dat een service mesh opsomt, drie leveranciers voor observability, een verhaal over failover tussen clouds en een platformteam, en eindigt met "en zo bedienen we 4.000 gebruikers". Dit is dat artikel niet. Onze infrastructuur is ontworpen om saai te zijn, en die saaiheid is dragend. Deel 5 van de reeks.
Alles draait bij OVHcloud in Frankrijk, wat volgens deel 1 geen toeval was. Daarbinnen heeft het platform precies twee vormen.
Een Kubernetes-cluster draait de coördinatielaag: de beheeromgeving op app.email.eu, de publieke website, de statuspagina, onze metingen, en de geplande taken die het platform opgeruimd houden. Dit zijn de onderdelen die we vaak uitrollen, en het cluster geeft ons rollende updates, zelfherstel en eenvoudige horizontale schaal precies waar we die nodig hebben. Daarnaast draait het onze Postgres-databases, beheerd door een operator, met replica's en een verbindingspooler, waar deel 4 de storingskant van behandelde.
Losse virtuele machines draaien de zware pijlers: mail, bestandsopslag, chat, vergaderingen, documentbewerking. Dit is de onmodieuze helft van het ontwerp, en het is opzet. Deze producten houden toestand bij, zijn hongerig naar schijfruimte, en willen stabiele netwerkidentiteiten; het IP-adres van een mailserver is deel van zijn reputatie. Ze updaten op hun eigen ritme en niet op het onze. En ze op aparte machines houden houdt storingen apart: een slechte dag voor de bestandsserver is fysiek niet in staat de mailserver van geheugen te beroven. Kubernetes koopt zijn magie met een laag indirectie die we liever niet onder een mailspool leggen.
De toets die we aanleggen is eenvoudig. Heeft dit onderdeel er voordeel bij automatisch verplaatst te worden, of willen we om drie uur 's nachts liever precies weten op welke machine het staat als er iets mis is? Webdingen halen de eerste toets. Mail haalt de tweede.
Het hele bezit, cluster, machines, DNS, verdelers, staat beschreven in OpenTofu, het opensource-gereedschap voor infrastructuur-als-code, in één repository. De machines richten zichzelf in vanuit scripts die je veilig kunt herhalen, dus "zet een mailknooppunt op" is geen wikipagina met stappen, het is een script dat elke keer hetzelfde resultaat oplevert en dat je opnieuw kunt draaien. Zou een machine onherstelbaar sterven, dan bouwen we hem opnieuw vanuit de repository en niet vanuit het geheugen.
Geheimen volgen hetzelfde principe met één draai: ze staan versleuteld in de repository (versleuteling met age, sleutels bij mensen, nooit leesbaar in git), en het uitrolgereedschap weigert iets toe te passen als de lokale geheimen afwijken van de versleutelde bron van waarheid. Die wacht bestaat omdat "welke laptop heeft de juiste variabelen" de manier is waarop teams grote ongelukken krijgen.
Uitrollen zijn git-commits. Onze eigen CI op ci.email.eu (de regel over Europese leveranciers geldt ook voor bouwinfrastructuur) bouwt elke wijziging tot een image met een label van precies de commit die hem opleverde, en die labels zijn onveranderlijk: een label kan nooit stil iets anders gaan betekenen. Maar bouwen is niet uitleveren. Er komt niets in productie omdat code is samengevoegd. Een uitrol is een eigen commit van één regel, geschreven en gepusht door een mens, die verandert welk image productie draait; de pijplijn past precies die verwijzing toe en wacht tot de uitrol gezond is. Zo bleven de twee eigenschappen behouden die ons uitmaakten toen uitrollen nog een mens met een script was: elke uitrol is een bewuste menselijke beslissing, en de uitrolgeschiedenis is gewoon git-geschiedenis, dus terugdraaien is een commit terugdraaien.
Geen van deze regels is exotisch. Hun waarde zit erin dat ze absoluut zijn: ze gelden als je moe bent, als je het zeker weet, en als je haast hebt, en dat is precies wanneer ze nodig zijn.
Omdat saai in je voordeel samengesteld doorwerkt. Minder bewegende delen betekent minder nieuwe storingsvormen, en een platform dat vanuit één repository te reconstrueren is betekent dat ons rampscenario niet afhangt van iemands geheugen. Als een provider je verblindt met architectuur, is het een eerlijke vraag wie de spanning betaalt. Ons antwoord is dat niemand dat hoort te doen, dus hebben we hem weggehaald.
Hierna deel 6: hoe we dit alles bewaken, waarom onze statuspagina dezelfde cijfers laat zien waarop we onszelf alarmeren, en wat we hebben gebouwd voor de dagen dat er toch iets stukgaat.