Neuspjelo ponovno objavljivanje nikada ne briše backend koji radi

Dana 25. septembra, neuspjelo ponovno objavljivanje izbrisalo je backend jedne aplikacije koji je bio živ i radio oko dva i po sata. Kod koji poništava neuspjelu objavu uklonio je svaku server aplikaciju koju je objava dotaknula — uključujući i one koje su već radile prije nego što je počela. Sada se samo aplikacije koje je objava kreirala ikada brišu; aplikacija koja je već postojala vraća se na tačnu verziju koju je imala prije. Dvije naknadne ispravke istog dana osigurale su da se to poništavanje izvrši i kada alat za deploy hosting platforme sam zakaže, te da zdrava aplikacija ne bude označena kao neuspjela samo zato što je spavala.

Kako se backend objavljuje

Kada vaša Mythex aplikacija ima backend — API ili server, a ne samo statičke fajlove — objava ga gradi iz Dockerfile-a (recepta za pakovanje aplikacije u image) i postavlja taj image na mašine na našoj hosting platformi. Zatim health check čeka da se nova verzija zaista podigne i ostane aktivna prije nego što objava bude označena kao živa.

Ako nešto pođe po zlu na tom putu, pokreće se rollback koji to poništava. Ispravno raditi rollback važi više od gotovo čega drugog u objavljivanju, jer se pokreće upravo kada je nešto već pošlo po zlu.

Problem 1: rollback je izbrisao ono što je trebao vratiti

Rollback je vodio listu server aplikacija na koje je objava postavljena i u slučaju greške uništio je svaku od njih. To je ispravno za prvu objavu: aplikacija je upravo nastala, ništa od nje ne zavisi, a brisanje ostavlja stvari onakvim kakve su bile.

To je potpuno pogrešno za ponovno objavljivanje. Aplikacija je već postojala i služila je stvarnim posjetiteljima. Dana 25. septembra, API aplikacije koji je bio živ oko dva i po sata izbrisan je neuspjelom ponovnom objavom.

U istom kodu krila se i druga greška. Tamo gdje brisanje nije uspjelo, pokvareni novi image ostajao je na mašinama — dok smo vlasniku javljali da je njegov trenutni sajt i dalje živ. Do trenutka kada health check može pasti, novi image je već postavljen na svaku mašinu. Ne raditi ništa nije isto što i poništiti.

Ispravka: uništi samo ono što si kreirao, vrati ostalo

Svaka objava sada bilježi, za svaku server aplikaciju koju dotakne:

• da li je ovu objavu kreirala, i
• ako nije, koji image je pokretala neposredno prije.

Pri grešci, svaka aplikacija dobija jedan od tri tretmana:

1. Kreirala ju je ova objava: uništi je, kao i prije.
2. Već je postojala, poznat je prethodni image: ponovo postavi prethodni image sa istom konfiguracijom. Nema builda — samo se image vraća.
3. Već je postojala, prethodni image nije poznat: ostavi je netaknutom. Postojeća aplikacija se nikada ne briše, čak ni kada je ne možemo vratiti.

Ova pravila su mala čista funkcija sa vlastitim testovima, tako da se odluka ne može vratiti na „uništi sve” bez da padne test.

Problem 2: alat za deploy je mogao zakazati prije nego što smo zapisali kako poništiti

Ubrzo nakon te ispravke, pronašli smo rupu u njoj. Alat za deploy hosting platforme pokreće vlastite smoke provjere: ako nove mašine padnu, izlazi sa greškom. Ali to radi nakon što je novi image već na mašinama.

Naš kod registrovao je aplikaciju za rollback tek kada je alat uspješno vratio rezultat. Kada je sam alat zakazao deploy, aplikacija još nije bila na listi za rollback, pa se ništa nije vratilo. Na našem staging okruženju, neuspjela ponovna objava ostavila je pokvareni image u radu.

Ispravka: registruj poništavanje prije početka

Aplikacija se sada registruje za rollback — uz to da li je kreirana i koji image je pokretala — čim se pripremi, prije nego što se bilo šta postavi na nju. Šta god da pukne poslije, rollback zna šta treba vratiti. Provjerili smo lokalno: neuspjela ponovna objava pala je na smoke provjerama samog alata za deploy, a prethodna verzija je i dalje odgovarala.

Problem 3: spavajuća aplikacija označena je kao „nikada nije pokrenuta”

Objavljene aplikacije na Mythexu spavaju kada su neaktivne kako bi uštedjele vaše kredite. Ponovna objava ostavlja spavajuću mašinu zaustavljenom, pa health check mora da je probudi. On je od platforme tražio da mašinu pokrene jednom i ignorisao je odgovor.

Dana 25. septembra, taj jedini zahtjev za pokretanje nije ništa postigao. Zdrav API je stajao zaustavljen čitavih pet minuta health checka i označen je kao neuspjeh uz poruku „1 machine never started (last state: stopped)”.

Platforma ponekad odbije pokretanje. Dok smo ovo reprodukovali, vratila je konflikt „lease currently held” bez da smo to namjerno izazvali, a odbija pokretanja dok se mašina ažurira.

Ispravka: stalno pitaj i pokucaj na vrata

Health check sada:

• traži ponovo pokretanje zaustavljene mašine svakih 20 sekundi dok čeka,
• bilježi šta je platforma odgovorila kada odbije, i
• šalje jedan obični zahtjev aplikaciji, baš kao što bi to uradio posjetilac — proxy platforme probudi spavajuću mašinu čim stigne zahtjev.

Reprodukovali smo to na pravoj platformi sa privremenom aplikacijom čije je prvo pokretanje bilo odbijeno. Prije ispravke, objava je pala nakon 91 sekunde. Poslije, objavljena je za 20 sekundi. Aplikacija koja se stvarno ruši pri pokretanju i dalje pada, kao što i treba.

Šta smo iz toga naučili

• Rollback mora znati razliku između novog i postojećeg. „Poništi” za nešto što si kreirao znači brisanje. „Poništi” za nešto što je već bilo znači vraćanje. Tretirati ih isto je način na koji mehanizam zaštite obriše aplikaciju koja radi.
• Zapiši kako poništiti prije nego što djeluješ. Ako se poništavanje zabilježi tek nakon što korak uspije, korak koji pukne na pola puta ne ostavlja ništa čime bi se poništio.
• Nikada ne ignoriši odgovor na zahtjev od kojeg zavisiš. Jedno ignorisano „ne” pretvorilo je zdravu aplikaciju u neuspjelu objavu.

Srodna ispravka iz istog dana: hvatanje aplikacija koje se ruše odmah nakon objave. Za ono što se dešava kada objava pukne na vašoj strani, pogledajte rješavanje problema sa objavom u dokumentaciji.