Watchtower vågnede, kiggede efter opdateringer og gik i seng igen - 476 gange uden at udrette noget.
Et halvt år uden opdateringer - og et bibliotek ødelagt af én
Automatiske opdateringer bliver som regel diskuteret, som om der findes ét rigtigt svar. Det gør der ikke. Der findes to reelle risici, de trækker i hver sin retning, og forskellen mellem dem afgør, hvordan man bør indrette sig.
Fejlen der ikke meldte sig
Opsætningen monterede en fil med registry-legitimation ind i containeren. Stien fandtes ikke på værten - og når Docker bliver bedt om at montere noget, der ikke eksisterer, opretter den det som en mappe. Watchtower fik altså en tom mappe der, hvor den forventede en fil, og hvert eneste forsøg på at hente et image fejlede.
Containeren kørte. Sundhedstjekket var grønt. Den lavede bare ingenting. Det er den farligste slags fejl: ikke den, der vælter noget, men den der ser ud som om alt er i orden. Var den crashet i marts, havde jeg opdaget det i marts.
Resultatet af de 476 gennemløb. Hver eneste endte med scanned=0 og updated=0.
Fra fejlen opstod til den blev opdaget. Ved et tilfælde, under en gennemgang af noget andet.
Genskabt fra en databasebackup, programmet selv havde lagt i en undermappe. Uden den havde strukturen været tabt.
Regnestykket: et halvt år uden sikkerhedsopdateringer på en reverse proxy, et hjemmeautomatiseringssystem, en netværkscontroller og tyve andre tjenester - hvoraf flere kan nås fra internettet.
Og så det modsatte problem
Samme dag fandt jeg et fotobibliotek med fireogtyve tusind billeder, som havde stået stille siden august året før. Det var gået i stykker under en opgradering: softwaren var sprunget fra version 1.127 til 2.x, og undervejs havde udviklerne skiftet databasemotor. Springer man mellemtrinnene over, kan den nye server ikke læse den gamle database.
Den startede op, fandt intet den kunne forstå, og begyndte reelt forfra. Billederne lå der stadig, og det lykkedes at få dem tilbage - men kun fordi programmet selv havde lagt en databasebackup i en undermappe, ingen havde kigget i.
- v1.127
- v2.x
- databasen kan ikke læses
- tomt bibliotek
- v1.127
- mellemversion
- motoren migreres
- v2.x
- data intakt
Så på samme dag, i samme opsætning: en tjeneste ødelagt af manglende opdateringer, og en tjeneste ødelagt af en opdatering.
Begge ting er sande
De to risici er ikke lige store, og de opfører sig ikke ens. Det er dér, svaret ligger.
Den usynlige risiko
Ikke at opdatere betyder kendte sikkerhedshuller i software, der er eksponeret mod internettet. Risikoen vokser stille og roligt, og du opdager den ikke selv.
Den synlige risiko
At opdatere automatisk betyder, at en container en nat kan komme op i en version, der ikke kan læse sine egne data. Risikoen er pludselig - men du opdager den med det samme.
Forskellen der afgør
Den første risiko er usynlig og voksende. Den anden er synlig og øjeblikkelig. Synlige problemer er langt billigere end usynlige, og derfor er svaret ikke at vælge side, men at gøre den synlige risiko håndterbar.
Fire valg gør forskellen
Forskellen mellem "Watchtower er tændt" og "Watchtower er under kontrol" er ikke værktøjet. Det er fire beslutninger om, hvordan det bruges.
Tilvalg frem for fravalg
Uden --label-enable opdaterer Watchtower alt. Med det opdaterer den kun containere, der udtrykkeligt er mærket. Det vender bevisbyrden om: glemsomhed fører til at for lidt bliver opdateret, frem for at noget vigtigt bliver revet med.
Et tidspunkt hvor nogen er vågen
Standarden er et interval regnet fra containerens opstart, altså i praksis et tilfældigt tidspunkt. Lørdag formiddag er et bedre valg: går noget i stykker, opdager du det inden for minutter og har hele dagen til at rulle tilbage. Husk tidszonen - en server i UTC forstår "klokken 10" anderledes end du gør.
Noget der siger til
En automatisk opdatering uden overvågning er et væddemål om, at intet går galt. Et sundhedstjek pr. maskine, der melder ind hvert femte minut, er den investering, der gør automatikken forsvarlig. Uden den er det ikke automatisering, men håb.
Pin det der ikke må flytte sig
Databaser kan ikke nedgradere deres egne datafiler. Din proxy og din VPN er netop dem, der giver dig adgang til at reparere noget. Og software med et migreringsforløb skal gennem mellemversionerne i rækkefølge. De tre kategorier hører ikke til i den automatiske pulje.
Det handler ikke om Watchtower
Begge fejl havde samme form: systemet så rask ud, mens det ikke virkede. Watchtower kørte og opdaterede intet. Fotobiblioteket kørte og manglede hovedparten af sit indhold. Ingen af dem sendte et signal.
Under samme oprydning fjernede jeg treogtyve forældreløse certifikater, hvoraf ét havde fejlet sin fornyelse dagligt i månedsvis. Ikke fordi de fyldte noget - men fordi en fejl, der altid er der, gør dig blind for den næste.
Det er den egentlige pointe. Automatiske opdateringer er ikke målet. Målet er at kunne skelne mellem "det virker" og "det ser ud som om det virker" - og indrette tingene, så forskellen er synlig inden for minutter frem for måneder. Watchtower med de fire valg er et skridt på vejen. Watchtower tændt uden dem er bare endnu en ting, der kan svigte i stilhed.
Mere at læse
Oversættelse uden en token-regning
PlantGeekz findes på 16 sprog. Noget skrives med en betalt model, resten oversættes på vores egen GPU. Hvorfor den billige model ikke er en genvej, når teksten er fuld af botaniske navne.
Plantegenkendelse på egen GPU
Sådan sætter PlantGeekz navn på et plantefoto med BioCLIP 2 på vores egen GPU. Hvad den kan, hvad den ikke kan, og hvorfor det er en fordel at have den stående hjemme.
Store datamængder
Hvad der sker med et system, når tabellerne vokser fra hundrede tusind rækker til tyve millioner. Hvad det koster ikke at have styr på datamodellen, og hvad jeg gør ved det.
Har I noget, der skal bygges ordentligt?
Skriv et par linjer om, hvad I sidder med. Så vender jeg tilbage med, hvad jeg tænker. Også hvis svaret er, at en anden løser det bedre.