Ebaõnnestunud uuesti avaldamine ei kustuta kunagi töötavat tagarakendust

1. septembril kustutas ebaõnnestunud uuesti avaldamine rakenduse tagarakenduse, mis oli olnud elav ja töötav umbes kaks ja pool tundi. Ebaõnnestunud avaldamise tagasivõtmise kood eemaldas kõik serverirakendused, mida avaldamine oli puudutanud, sealhulgas need, mis olid juba enne selle algust teenindamas. Nüüd kustutatakse ainult need rakendused, mille avaldamine lõi, ja juba olemasolev rakendus pannakse tagasi täpselt sellele versioonile, mida ta enne jooksis. Kaks järgmist parandust samal päeval tagasid, et tagasivõtmine käivitub ka siis, kui hostingplatvormi enda deploy-tööriist ebaõnnestub, ja et tervet rakendust ei märgita ebaõnnestunuks ainult seetõttu, et ta magas.

Kuidas tagarakendus avaldatakse

Kui sinu Mythexi rakendusel on tagarakendus (API või server, mitte ainult staatilised failid), ehitatakse avaldamisel see Dockerfile'ist (retsept, mis pakib rakenduse konteinerisse) ja rullitakse konteiner üle meie hostingplatvormi masinatele. Seejärel ootab tervisekontroll, kuni uus versioon on tõesti üles tõusnud ja püsib töös. Alles siis märgitakse avaldamine elavaks.

Kui kusagil ebaõnnestub, käivitub tagasivõtmine, et see tühistada. Selle õige tegemine on avaldamises peaaegu kõige olulisem, sest see käivitub just siis, kui midagi juba valesti läheb.

Probleem 1: tagasivõtmine kustutas selle, mis oleks pidanud taastuma

Tagasivõtmine hoidis nimekirja serverirakendustest, kuhu avaldamine oli paigaldanud, ja ebaõnnestumise korral hävitas need kõik. Esimese avaldamise puhul on see õige: rakendus loodi hetk tagasi, miski ei sõltu sellest ja kustutamine jätab asjad sellisesse seisu, nagu nad enne olid.

Uuesti avaldamise puhul on see täpselt vale. Rakendus oli juba olemas ja teenindas päris külastajaid. 25. septembril kustutas ebaõnnestunud uuesti avaldamine rakenduse API, mis oli olnud elav umbes kaks ja pool tundi.

Samas koodis peitus ka teine viga. Kui kustutamine ei õnnestunud, jäi katkine uus konteiner masinatesse alles, samal ajal kui omanikule öeldi, et tema praegune sait on endiselt elav. Kui tervisekontroll võib ebaõnnestuda, on uus konteiner juba igal masinal laiali rullitud. Mitte midagi tegemata ei ole sama, mis tagasi võtmine.

Parandus: kustuta ainult see, mille lõid, ja taasta ülejäänu

Iga avaldamine salvestab nüüd iga serverirakenduse kohta, mida ta puudutab:

• kas see avaldamine lõi selle, ja
• kui ei, siis millist konteinerit see jooksis vahetult enne.

Ebaõnnestumise korral saab iga rakendus ühe kolmest käsitlusest:

1. Selle avaldamise lõi: kustuta, nagu varem.
2. Oli juba olemas ja eelmine konteiner on teada: rulli eelmine konteiner tagasi samade seadistustega. Ehitamist ei toimu, liigub ainult konteiner.
3. Oli juba olemas ja eelmine konteiner on teadmata: jäta puutumata. Olemasolevat rakendust ei kustutata kunagi, isegi siis, kui me ei saa seda taastada.

Need reeglid on väike puhas funktsioon oma testidega, nii et otsus ei saa tagasi libiseda juurde „kustuta kõik” ilma, et test ebaõnnestuks.

Probleem 2: deploy-tööriist võis ebaõnnestuda enne, kui oleme kirja pannud, kuidas tagasi võtta

Vahetult pärast seda parandust leidsime selles lünga. Hostingplatvormi deploy-tööriist teeb oma suitsutestid: kui uued masinad jooksu ajal kokku kukuvad, lõpetab ta vea. Ta teeb seda aga pärast seda, kui uus konteiner on juba masinatel.

Meie kood registreeris rakenduse tagasivõtmiseks alles siis, kui tööriist oli edukalt tagasi tulnud. Kui tööriist ise deploy'd ebaõnnestuma, polnud rakendus veel tagasivõtmise nimekirjas ja midagi ei taastatud. Meie staging-keskkonnas jäi katkine konteiner katkisena teenindama.

Parandus: registreeri tagasivõtmine enne alustamist

Rakendus registreeritakse tagasivõtmiseks (koos sellega, kas ta loodi ja mis konteinerit ta jooksis) kohe, kui see on ette valmistatud ja enne, kui midagi masinatele rullitakse. Mis iganes pärast seda ka ebaõnnestub, tagasivõtmine teab, mida tagasi panna. Kontrollisime kohapeal: katkine uuesti avaldamine ebaõnnestus deploy-tööriista enda suitsutestides ja eelmine versioon jätkas vastamist.

Probleem 3: magav rakendus märgiti kui „ei käivitunud kunagi”

Avaldatud rakendused Mythexis lähevad tegevusetuna magama, et säästa sinu krediite. Uuesti avaldamine jätab magava masina peatatuks, seega peab tervisekontroll selle üles äratama. Seda küsiti platvormilt ühe korra ja vastust ignoreeriti.

1. septembril läks see üks käivitamispäring kaotsi. Terve API jäi seisma kogu viieminutilise tervisekontrolli ajaks ja märgiti ebaõnnestunuks sõnumiga „1 masin ei käivitunud kunagi (viimane olek: stopped)”.

Platvorm lükkab mõnikord käivitamise tagasi. Selle reprodutseerimise käigus tagastas ta meie provotseerimata konflikti „lease currently held” ja keeldub käivitamisest ka siis, kui masinat parasjagu uuendatakse.

Parandus: küsi uuesti ja koputa uksele

Tervisekontroll:

• küsib peatatud masina käivitamist ootamise ajal iga 20 sekundi järel,
• logib, mida platvorm vastas, kui ta keeldub, ja
• saadab rakendusele ühe tavalise päringu, nagu teeks külastaja. Platvormi proxy äratab magava masina, kui päring saabub.

Reprodutseerisime selle päris platvormil ajutise rakendusega, mille esimene käivitus lükati tagasi. Enne parandust ebaõnnestus avaldamine pärast 91 sekundit. Pärast seda avaldati see 20 sekundiga. Rakendus, mis tegelikult käivitamisel kokku kukub, ebaõnnestub endiselt, nagu peab.

Mida sellest õppisime

• Tagasivõtmine peab teadma erinevust uue ja olemasoleva vahel. „Tagasi võtta” millegi loodu puhul tähendab kustutamist. „Tagasi võtta” millegi juba olemasoleva puhul tähendab taastamist. Kui neid koheldakse ühtemoodi, kustutab turvamehhanism töötava rakenduse.
• Kirjuta enne tegutsemist üles, kuidas tagasi võtta. Kui tagasivõtmine registreeritakse alles pärast seda, kui samm õnnestub, ei ole poolelioleva sammu korral midagi tagasi võtta.
• Ära kunagi neela alla vastust päringule, millest sa sõltud. Üks ignoreeritud „ei” muutis terve rakenduse ebaõnnestunud avaldamiseks.

Samal päeval tehtud seotud parandus: kuidas püüda kinni rakendused, mis kukuvad kohe pärast avaldamist. Kui avaldamine ebaõnnestub sinu poolelt, leiad selle kohta teavet avaldamise tõrkeotsingu dokumentatsioonist.