maskinen du ikke kan logge ind på

Første gang du arbejder med Talos, rækker du ud efter SSH og det er der ikke. Binary’en eksisterer ikke på filsystemet. Der er ingen shell. Root-filsystemet er read-only. Den eneste vej ind er en gRPC API der taler mutual TLS, og det eneste der lytter i den anden ende er en holdning til hvad et operativsystem bør være.

Det er desorienterende på en måde der er svær at overdrive for enhver der har brugt årevis på at behandle servere som steder man besøger. Muskelhukommelsen sidder dybt - noget går galt, du SSH’er ind, du roder rundt, du fikser det. Talos fjerner hele præmissen og beder dig genoverveje hvad “fiks det” betyder når maskinen er defineret af et enkelt YAML-dokument og enhver tilstand der afviger fra det dokument per definition er forkert.

den virtuelle generalprøve

De fleste møder Talos i et virtualiseret miljø først, et par VM’er på Proxmox eller en lokal hypervisor, og det er her de gamle vaner kommer for at dø. Du booter fra en ISO, maskinen går i maintenance mode og venter - ikke på at du logger ind og konfigurerer den, men på at du sender den en maskinkonfiguration fra din arbejdsstation. Noden læser konfigurationen, konvergerer mod den ønskede tilstand, og bliver enten det du beskrev eller fortæller dig hvorfor den ikke kan.

De små overraskelser hober sig op. Virtuelle diske dukker op som /dev/vda i stedet for /dev/sda og konfigurationen du kopierede fra en tutorial fejler stille. etcd kræver SSD-backed storage selv i et lab, og spinning disk får det til at flakse på måder der ligner netværksproblemer. Den VIP du konfigurerede til API-endpointet kommer ikke online før efter bootstrap, og du bruger tyve minutter på at fejlsøge noget der simpelthen ikke er sket endnu. Hver af disse er den slags lektion der ville være et hurtigt fix på et traditionelt system - rediger en config, genstart en service - men her kræver at du opdaterer maskinkonfigurationen og lader systemet rekonvergere. Feedback-loopet er længere, og resultatet er altid reproducerbart.

Det det virtuelle miljø lærer dig, under overfladen af detaljerne, er at Talos mener det. Immutabiliteten er ikke en filosofisk erklæring på en landingsside; du kan oprigtigt ikke installere tcpdump. Du enten bager det ind i en system extension gennem Image Factory eller du bruger talosctl pcap. Noden er ikke et sted. Den er en funktion af sin konfiguration.

bare metal

Når du rykker til fysisk hardware, bliver abstraktionen testet mod virkeligheden på en måde som VM’er ikke kan replikere. Disk paths varierer efter hardware. Multi-NIC maskiner kræver eksplicit subnet-konfiguration for at forhindre etcd i at binde sig til det forkerte interface. PXE boot-kæder involverer DHCP, TFTP, iPXE-scripts og en matchingtjeneste som Matchbox der renderer maskinspecifikke profiler baseret på MAC-adresse - infrastruktur der udelukkende eksisterer for at gøre spørgsmålet “hvad skal denne maskine være?” muligt at besvare fra netværket.

Det interessante er at når denne infrastruktur først eksisterer, reducerer provisionering af en ny node sig reelt til at anvende en konfiguration. En maskine booter, modtager sin identitet fra netværket, trækker Talos-imaget, konvergerer og tilslutter sig klusteret. Ingen SSH, ingen Ansible-playbook, ingen ingeniør der manuelt kører en checkliste igennem. Serveren er umulig at skelne fra sin konfiguration, og at erstatte den betyder at boote en ny med den samme YAML.

Det er her cattle-metaforen holder op med at være en metafor. En node der opfører sig dårligt bliver ikke debugget, den bliver erstattet - den hurtigere vej når debugging er mulig gennem talosctl men investeringen lever i konfigurationen, ikke i maskinen.

hetzner, og midtergrunden

Hetzner besætter et rum der gør økonomien i Talos særligt interessant. En dedikeret server med 64GB RAM, en 8-kernet Xeon og dobbelte NVMe-drev koster mindre per måned end en sammenlignelig cloud-instans koster per dag, og Talos skærer den operationelle byrde ved at administrere den hardware ned til noget et lille team kan håndtere.

Installationen på en dedikeret Hetzner-server har sin egen tekstur. Du booter ind i Hetzners rescue-system - ironisk nok en af de sidste gange du bruger SSH i dette workflow - sletter eventuel eksisterende RAID-konfiguration, skriver Talos-imaget direkte til NVMe’en og genstarter. Maskinen kommer op i maintenance mode og du anvender konfigurationen fra din arbejdsstation, præcis som alle andre steder. Hetzners netværk er den primære rynke: dedikerede servere bruger punkt-til-punkt /32-adressering med en gateway der også er en /32, hvilket betyder eksplicitte statiske ruter i maskinkonfigurationen. Privat netværk mellem servere går gennem vSwitch-VLAN’er frem for et managed subnet. Det er løselige detaljer, men de fanger dig hvis du antager standard subnet-baseret netværk.

Hetzner Cloud er en anden oplevelse, tættere på enhver anden cloud-udbyder men med sine egne særheder - en 32KB user-data-grænse der stille afskærer din maskinkonfiguration hvis du lader standardeksempler og dokumentation stå i, og en netværksmodel der kræver den rigtige variant af cloud controller manager-manifestet for at muliggøre pod-til-pod-kommunikation på tværs af noder. Cloud-siden fungerer fint nok, men de dedikerede servere er der hvor værdien skærpes, fordi hele pointen med Talos er at gøre kraftfuld hardware håndterbar uden et stort ops-team, og Hetzners dedikerede prissætning gør den hardware tilgængelig.

hvad der bærer på tværs

Det der træder frem fra at køre Talos på tværs af alle tre miljøer er at abstraktionen holder. Maskinkonfigurationen er den samme YAML uanset om den underliggende hardware er en Proxmox VM, en rackmonteret server eller en Hetzner-dedikeret boks. Den operationelle overflade er de samme talosctl-kommandoer. Opgraderinger fungerer ens overalt - et A/B boot-skema der skriver det nye image til den inaktive slot, genstarter, og automatisk ruller tilbage hvis den nye version ikke kommer op.

Det der ændrer sig mellem miljøer er infrastrukturen omkring klusteret, bootmekanismen og netværksmodellen og storage-topologien, og Talos forsøger bevidst ikke at abstrahere disse væk. Det giver dig en maskinkonfiguration med de rigtige knapper til hvert miljø og lader dig beskrive hvad maskinen skal se ud. Resten er konvergens.

Den reelle kraft i Talos, og i abstraktioner som den, er at de flytter kompleksitet ud af det tekniske og ind i det konceptuelle. Hvordan du provisionerer en node, hvordan du patcher en kerne, hvordan du roterer et certifikat - disse holder op med at være spørgsmål du bruger dine dage på at besvare. Det der står tilbage er hvad infrastrukturen skal gøre, hvilken form systemet skal tage, hvilke problemer der rent faktisk er værd at løse. Det mekaniske opløses, og det der åbner sig er rum til at tænke - om arkitektur, om design, om det arbejde kun mennesker kan udføre. Efter nok tid med det føles fraværet af SSH mindre som en begrænsning og mere som en invitation.