Epäonnistunut uudelleenjulkaisu ei koskaan poista toimivaa taustapalvelua

Syyskuun 25. päivänä epäonnistunut uudelleenjulkaisu poisti sovelluksen taustapalvelun, joka oli ollut käynnissä ja toiminut noin kaksi ja puoli tuntia. Epäonnistuneen julkaisun peruuttava koodi poisti jokaisen palvelinsovelluksen, johon julkaisu oli koskenut, myös ne, jotka olivat jo palvelemassa ennen julkaisun alkua. Nyt vain julkaisun itse luomia sovelluksia poistetaan koskaan. Jo olemassa oleva sovellus palautetaan täsmälleen siihen versioon, jota se ajoi ennen julkaisua. Kaksi samana päivänä tehtyä jatkokorjausta varmisti, että peruutus toimii myös silloin, kun alustan oma julkaisutyökalu epäonnistuu, eikä tervettä sovellusta merkitä epäonnistuneeksi vain siksi, että se nukkui.

Näin taustapalvelu julkaistaan

Kun Mythex-sovelluksessasi on taustapalvelu, eli API tai palvelin eikä pelkkiä staattisia tiedostoja, julkaisu rakentaa sen Dockerfilestä (resepti, jolla sovellus pakataan kuvaksi) ja ajaa kuvan hostausalustamme koneille. Sen jälkeen terveystarkistus odottaa, että uusi versio todella käynnistyy ja pysyy pystyssä, ennen kuin julkaisu merkitään käyttöön otetuksi.

Jos jokin vaihe epäonnistuu, peruutus palauttaa tilanteen. Sen tekeminen oikein on tärkeämpää kuin melkein mikään muu julkaisussa, koska se toimii juuri silloin, kun jokin on jo menossa pieleen.

Ongelma 1: peruutus poisti sen, minkä piti palauttaa

Peruutus piti kirjaa palvelinsovelluksista, joihin julkaisu oli viety, ja epäonnistuessaan se tuhosi jokaisen niistä. Ensimmäisessä julkaisussa tämä on oikein: sovellus luotiin hetki sitten, mikään ei ole siitä riippuvainen, ja sen poistaminen jättää tilanteen entiselleen.

Uudelleenjulkaisussa se on täysin väärin. Sovellus oli jo olemassa ja palveli oikeita vierailijoita. 25. syyskuuta epäonnistunut uudelleenjulkaisu poisti sovelluksen API:n, joka oli ollut käynnissä noin kaksi ja puoli tuntia.

Samassa koodissa oli piilossa myös toinen vika. Jos poisto ei onnistunut, rikkinäinen uusi kuva jäi koneille, vaikka omistajalle kerrottiin nykyisen sivuston olevan yhä käynnissä. Kun terveystarkistus voi epäonnistua, uusi kuva on jo ajettu jokaiselle koneelle. Ei tekeminen ei ole sama asia kuin peruuttaminen.

Korjaus: tuhoa vain se, minkä loit, ja palauta muut

Jokainen julkaisu tallentaa nyt jokaisesta koskemastaan palvelinsovelluksesta:

• onko tämä julkaisu luonut sen, ja
• jos ei, mitä kuvaa se ajoi juuri ennen julkaisua.

Epäonnistuessa jokainen sovellus käsitellään yhdellä kolmesta tavasta:

1. Julkaisu loi sovelluksen: tuhoa se kuten ennenkin.
2. Sovellus oli jo olemassa ja edellinen kuva tiedetään: ota käyttöön edellinen kuva samalla kokoonpanolla. Ei rakentamista, vain kuva siirtyy takaisin.
3. Sovellus oli jo olemassa, eikä edellistä kuvaa tiedetä: jätä se rauhaan. Olemassa olevaa sovellusta ei koskaan poisteta, vaikka sitä ei voitaisi palauttaa.

Nämä säännöt ovat pieni puhdas funktio omilla testeillään, joten päätös ei voi palata takaisin ”tuhoa kaikki” -malliin ilman, että testi epäonnistuu.

Ongelma 2: deploy-työkalu saattoi epäonnistua ennen kuin peruutus oli kirjattu

Pian tämän korjauksen jälkeen löysimme siihen aukon. Alustan deploy-työkalu ajaa omat savutestinsä: jos uudet koneet kaatuvat, se päättyy virheeseen. Se tekee tämän kuitenkin sen jälkeen, kun uusi kuva on jo koneilla.

Koodimme rekisteröi sovelluksen peruutuslistalle vasta, kun työkalu palautti onnistuneen tuloksen. Kun työkalu itse epäonnistutti julkaisun, sovellusta ei ollut vielä listalla, eikä mitään palautettu. Staging-ympäristössämme epäonnistunut uudelleenjulkaisu jätti rikkinäisen kuvan palvelemaan.

Korjaus: kirjaa peruutus ennen aloittamista

Sovellus rekisteröidään nyt peruutuslistalle, ja tieto siitä, luotiinko se ja mitä kuvaa se ajoi, tallennetaan heti kun se on valmisteltu ja ennen kuin mitään viedään sen päälle. Mikä tahansa myöhemmin epäonnistuukin, peruutus tietää, mitä palauttaa. Testasimme tämän paikallisesti: rikkinäinen uudelleenjulkaisu epäonnistui deploy-työkalun omissa savutesteissä, ja edellinen versio jatkoi vastaamista.

Ongelma 3: nukkuva sovellus merkittiin ”ei koskaan käynnistynyt”

Julkaistut sovellukset Mythexissä nukkuvat, kun niitä ei käytetä, jotta krediittejäsi säästetään. Uudelleenjulkaisu jättää nukkuvan koneen pysäytetyksi, joten terveystarkistuksen täytyy herättää se. Tarkistus pyysi alustaa käynnistämään koneen kerran ja jätti vastauksen huomiotta.

1. syyskuuta tuo yksi käynnistyspyyntö meni ohi. Terve API seisoi pysähtyneenä koko viiden minuutin terveystarkistuksen ajan, ja se merkittiin epäonnistuneeksi viestillä ”1 kone ei koskaan käynnistynyt (viimeksi tila: pysäytetty)”.

Alusta joskus kieltäytyy käynnistämästä konetta. Toistaessamme ongelmaa se palautti ilman, että provosoimme sitä, ”lease currently held” -ristiriitavirheen, ja se kieltäytyy käynnistämästä konetta aina, kun konetta päivitetään.

Korjaus: pyydä uudelleen ja koputa ovelle

Terveystarkistus tekee nyt seuraavaa:

• pyytää pysäytettyä konetta käynnistymään uudelleen 20 sekunnin välein odottaessaan,
• kirjaa, mitä alusta vastasi, kun se kieltäytyy, ja
• lähettää sovellukselle yhden tavallisen pyynnön, kuten vierailija tekisi. Alustan välityspalvelin herättää nukkuvan koneen, kun pyyntö saapuu.

Toistimme ongelman oikealla alustalla käyttäen kertakäyttöistä sovellusta, jonka ensimmäinen käynnistys hylättiin. Ennen korjausta julkaisu epäonnistui 91 sekunnin jälkeen. Korjauksen jälkeen se julkaistiin 20 sekunnissa. Sovellus, joka oikeasti kaatuu käynnistyessään, epäonnistuu edelleen, kuten pitääkin.

Mitä opimme

• Peruutuksen täytyy tietää ero uuden ja olemassa olevan välillä. ”Peruuta” tarkoittaa luodulle asialle poistoa ja jo olemassa olleelle palautusta. Kun nämä käsitellään samalla tavalla, turvamekanismi poistaa toimivan sovelluksen.
• Kirjaa, miten peruutus tehdään, ennen kuin toimit. Jos peruutus kirjataan vasta vaiheen onnistuttua, vaihe joka epäonnistuu puolivälissä jättää peruutettavaa ei mitään.
• Älä koskaan ohita vastausta pyyntöön, johon luotat. Yksi sivuutettu ”ei” muutti terveen sovelluksen epäonnistuneeksi julkaisuksi.

Samalta päivältä tuli myös toinen korjaus: sovellusten kaatumisen havaitseminen heti julkaisun jälkeen. Kun julkaisu epäonnistuu sinun päässäsi, katso julkaisun vianmääritys dokumentaatiosta.