Neuspešna ponovna objava nikoli ne izbriše delujočega zaledja

1. septembra je neuspešna ponovna objava izbrisala zaledje aplikacije, ki je bilo živo in je delovalo približno dve in pol ure. Koda, ki razveljavi neuspešno objavo, je odstranila vsako strežniško aplikacijo, ki se je objava dotaknila — tudi tiste, ki so že strežale, preden se je začela. Zdaj se izbrišejo samo aplikacije, ki jih je ustvarila objava; obstoječa aplikacija se vrne na točno tisto različico, ki je tekla prej. Dva nadaljnja popravka istega dne sta poskrbela, da se razveljavitev sproži tudi tedaj, ko orodje za namestitev samega ponudnika gostovanja odpove, in da zdrava aplikacija ne pade samo zato, ker je spala.

Kako se zaledje objavi

Kadar ima tvoja aplikacija Mythex zaledje — API ali strežnik, ne le statične datoteke — objava zgradi zaledje iz Dockerfile (recepta, po katerem se aplikacija zapakira v sliko) in to sliko razporedi na stroje pri našem ponudniku gostovanja. Nato health check počaka, da se nova različica res zažene in ostane zagnana, šele potem je objava označena kot živa.

Če kjer koli na poti kaj odpove, se zažene povratni postopek, ki to razveljavi. Ta povratni postopek je pri objavljanju skoraj najpomembnejši, ker se sproži ravno takrat, ko je nekaj že narobe.

Težava 1: povratni postopek je izbrisal tisto, kar bi moral obnoviti

Povratni postopek je hranil seznam strežniških aplikacij, na katere je objava namestila, in ob neuspehu jih je uničil vse. Pri prvi objavi je to pravilno: aplikacija je bila pravkar ustvarjena, nič od nje ni odvisno in izbris pusti stvari take, kot so bile.

Pri ponovni objavi je to ravno narobe. Aplikacija je že obstajala in je strežala pravim obiskovalcem. 25. septembra je neuspešna ponovna objava izbrisala API aplikacije, ki je bil živ približno dve in pol ure.

V isti kodi je bila skrita še ena napaka. Kjer izbris ni uspel, je pokvarjena nova slika ostala na strojih, mi pa smo lastniku še vedno sporočali, da je njegova trenutna stran živa. Ko lahko health check odpove, je nova slika na vseh strojih že nameščena. Nič narediti ni enako kot razveljaviti.

Popravek: izbriši samo tisto, kar si ustvaril, ostalo obnovi

Vsaka objava zdaj za vsako strežniško aplikacijo, ki se je dotakne, zabeleži:

• ali jo je ta objava ustvarila, in
• če je ni, katero sliko je tekla tik pred tem.

Ob neuspehu dobi vsaka aplikacija eno od treh obravnav:

1. To aplikacijo je ustvarila ta objava: izbriši jo, kot prej.
2. Aplikacija je že obstajala, prejšnja slika je znana: ponovno namesti prejšnjo sliko z isto konfiguracijo. Brez gradnje — premakne se samo slika nazaj.
3. Aplikacija je že obstajala, prejšnja slika ni znana: pusti jo pri miru. Obstoječa aplikacija se nikoli ne izbriše, tudi če je ne moremo obnoviti.

Ta pravila so majhna čista funkcija z lastnimi testi, tako da se odločitev ne more vrniti k „izbriši vse“, ne da bi padel test.

Težava 2: orodje za namestitev je lahko odpovedalo, preden smo zapisali, kako razveljaviti

Kmalu po tem popravku smo v njem našli vrzel. Orodje za namestitev ponudnika gostovanja izvaja lastne preverjalne teste: če se novi stroji zrušijo, izstopi z napako. Vendar to naredi potem, ko je nova slika že na strojih.

Naša koda je aplikacijo za povratni postopek registrirala šele, ko je orodje uspešno vrnilo rezultat. Ko je orodje samo odpovedalo namestitev, aplikacija na seznamu za povratni postopek še ni bila, zato ničesar ni obnovil. Na našem testnem okolju je neuspešna ponovna objava pustila pokvarjeno sliko, da še naprej streže.

Popravek: razveljavitev registriraj, preden začneš

Aplikacija je zdaj registrirana za povratni postopek — z zapisom, ali je bila ustvarjena in katero sliko je tekla — takoj ko je pripravljena in preden se nanjo namesti karkoli. Kar koli odpove pozneje, povratni postopek ve, kaj mora vrniti. Lokalno smo preverili: pokvarjena ponovna objava je odpovedala v preverjalnih testih orodja za namestitev, prejšnja različica pa je še naprej odgovarjala.

Težava 3: spečo aplikacijo smo označili kot „se ni nikoli zagnala“

Objavljene aplikacije na Mythexu za varčevanje s krediti med nedejavnostjo spijo. Ponovna objava pusti zaustavljen stroj ustavljen, zato mora health check stroj prebuditi. Platformi je poslal zahtevo za zagon enkrat in odgovora ni upošteval.

1. septembra ta ena zahteva za zagon ni dosegla cilja. Zdrav API je ostal ustavljen za celih pet minut health checka in je bil označen z „1 stroj se ni nikoli zagnal (zadnje stanje: stopped)“.

Platforma včasih zagon zavrne. Med reproduciranjem je brez našega vzroka vrnila konflikt „lease currently held“, zagone pa zavrača tudi med posodabljanjem stroja.

Popravek: vztrajaj in potrkaj na vrata

Health check zdaj:

• med čakanjem vsakih 20 sekund znova zahteva zagon ustavljenega stroja,
• zabeleži, kaj je platforma odgovorila, kadar zagon zavrne, in
• pošlje eno običajno zahtevo aplikaciji, kot bi jo poslal obiskovalec — proxy platforme prebudi speči stroj, ko pride zahteva.

Na pravi platformi smo to reproducirali z začasno aplikacijo, katere prvi zagon je bil zavrnjen. Pred popravkom je objava padla po 91 sekundah, po njem je bila objavljena v 20 sekundah. Aplikacija, ki se dejansko zruši ob zagonu, še vedno pade, kot mora.

Kaj smo iz tega vzeli

• Povratni postopek mora poznati razliko med novim in obstoječim. „Razveljavi“ za nekaj, kar si ustvaril, pomeni izbriši. „Razveljavi“ za nekaj, kar je bilo že tam, pomeni obnovi. Če obe stvari obravnavaš enako, varnostni mehanizem izbriše delujočo aplikacijo.
• Zapiši, kako razveljaviti, preden ukrepaš. Če se razveljavitev zabeleži šele po tem, ko korak uspe, korak, ki na pol poti odpove, pusti nič, s čimer bi lahko razveljavil.
• Nikoli ne prezri odgovora na zahtevo, od katere si odvisen. En prezrt „ne“ je zdravo aplikacijo spremenil v neuspešno objavo.

Sorodni popravek istega dne: zaznavanje aplikacij, ki se zrušijo takoj po objavi. Za to, kaj se zgodi, ko objava na tvoji strani ne uspe, glej odpravljanje težav pri objavi v dokumentaciji.