Neveiksmīga atkārtota publicēšana nekad neizdzēš darbīgu aizmugurējo daļu

1. septembrī neveiksmīga atkārtota publicēšana izdzēsa lietotnes aizmugurējo daļu, kas bija dzīva un darbojās aptuveni divas ar pusi stundas. Kods, kas atsauc neizdevušos publicēšanu, noņēma katru servera lietotni, ko publicēšana bija skārusi, — arī tās, kas jau kalpoja pirms tās sākuma. Tagad tiek dzēstas tikai tās lietotnes, ko publicēšana izveidoja; jau esoša lietotne tiek atjaunota tieši tajā versijā, kas tai darbojās pirms tam. Divi turpmākie labojumi tajā pašā dienā nodrošināja, ka atsaukšana notiek arī tad, kad paša hostinga platformas izvietošanas rīks neizdodas, un ka vesela lietotne netiek atzīta par neizdevušos tikai tāpēc, ka tā bija aizmigusi.

Kā tiek publicēta aizmugurējā daļa

Kad jūsu Mythex lietotnei ir aizmugurējā daļa — API jeb serveris, nevis tikai statiskas lapas —, publicēšana to izveido no Dockerfile (receptes, kā lietotni iepakot attēlā) un izvieto šo attēlu uz mašīnām mūsu hostinga platformā. Pēc tam veselības pārbaude gaida, līdz jaunā versija tiešām ir palaista un darbojas, un tikai tad publicēšana tiek atzīta par dzīvu.

Ja kaut kas pa ceļam neizdodas, tiek palaista atsaukšana, lai to atceltu. Pareiza atsaukšana ir gandrīz svarīgākā no visa publicēšanas procesa, jo tā darbojas tieši tad, kad jau kaut kas noiet greizi.

1. problēma: atsaukšana izdzēsa to, kas bija jāatjauno

Atsaukšana turēja sarakstu ar servera lietotnēm, uz kurām publicēšana bija izvietota, un neveiksmes gadījumā iznīcināja visas. Pirmajai publicēšanai tas ir pareizi: lietotne tika izveidota tikko, neviens no tās nav atkarīgs, un tās dzēšana atstāj lietas tādas, kādas tās bija.

Atkārtotai publicēšanai tas ir tieši pretēji. Lietotne jau pastāvēja un apkalpoja reālus apmeklētājus. 25. septembrī neveiksmīga atkārtota publicēšana izdzēsa lietotnes API, kas bija dzīva aptuveni divas ar pusi stundas.

Tajā pašā kodā slēpās vēl viens kļūmes veids. Ja dzēšana neizdevās, bojātais jaunais attēls palika uz mašīnām, kamēr mēs apliecinājām īpašniekam, ka viņa pašreizējā vietne joprojām ir dzīva. Līdz brīdim, kad veselības pārbaude var neizdoties, jaunais attēls jau ir izvietots uz visām mašīnām. Nedarīt neko nav tas pats, kas atsaukt.

Labojums: dzēst tikai to, ko radīji, pārējo atjaunot

Katra publicēšana tagad saglabā katrai servera lietotnei, ko tā skar:

• vai šī publicēšana to izveidoja, un
• ja nē, kāds attēls tai darbojās tieši pirms tam.

Neveiksmes gadījumā katra lietotne saņem vienu no trim apstrādēm:

1. Izveidojusi šī publicēšana: dzēst, kā līdz šim.
2. Jau pastāvēja, iepriekšējais attēls zināms: izvietot iepriekšējo attēlu ar tādu pašu konfigurāciju. Nekas netiek veidots no jauna — atgriežas tikai attēls.
3. Jau pastāvēja, iepriekšējais attēls nav zināms: neaiztikt. Esoša lietotne nekad netiek dzēsta, pat ja to nevaram atjaunot.

Šie noteikumi ir neliela tīra funkcija ar saviem testiem, tāpēc lēmums nevar atkal nonākt līdz „dzēst visu”, neizgāžot testu.

2. problēma: izvietošanas rīks var neizdoties, pirms mēs būtu pierakstījuši, kā atsaukt

Drīz pēc šī labojuma atklājām tajā robu. Hostinga platformas izvietošanas rīks pats veic dūmu pārbaudes: ja jaunās mašīnas avarē, tas iziet ar kļūdu. Bet tas to dara pēc tam, kad jaunais attēls jau ir mašīnās.

Mūsu kods lietotni reģistrēja atsaukšanai tikai pēc tam, kad rīks bija veiksmīgi atgriezies. Ja pats rīks izvietošanu noraidīja, lietotne vēl nebija atsaukšanas sarakstā, tāpēc nekas netika atjaunots. Mūsu staging vidē neveiksmīga atkārtota publicēšana atstāja bojāto attēlu apkalpojam.

Labojums: reģistrēt atsaukšanu pirms sākuma

Lietotne tagad tiek reģistrēta atsaukšanai — ar to, vai tā tika izveidota un kādu attēlu tā darbināja — tiklīdz tā ir sagatavota un pirms kaut kas tiek izvietots. Lai kas pēc tam neizdotos, atsaukšana zina, ko atjaunot. Mēs to pārbaudījām lokāli: neveiksmīga atkārtota publicēšana tika apturēta izvietošanas rīka pašu dūmu pārbaudēs, un iepriekšējā versija turpināja atbildēt.

3. problēma: aizmigusi lietotne tika atzīta par „nekad nesākušos”

Mythex publicētās lietotnes aizmieg, kad tās nav lietotas, lai taupītu jūsu kredītus. Atkārtota publicēšana atstāj aizmigušu mašīnu apturētu, tāpēc veselības pārbaudei tā ir jāmodina. Tā lūdza platformu mašīnu palaist vienu reizi un ignorēja atbildi.

1. septembrī šis viens palaišanas pieprasījums nepalīdzēja. Vesela API stāvēja apturēta visu piecu minūšu veselības pārbaudes laiku un tika atzīta par neizdevušos ar kļūdu „1 mašīna nekad nesākās (pēdējais stāvoklis: stopped)”.

Platforma dažkārt tiešām noraida palaišanu. Reproducējot šo problēmu, tā atgrieza konflikta kļūdu „lease currently held” pat tad, kad mēs to nebijām izraisījuši, un tā noraida palaišanas, kamēr mašīna tiek atjaunināta.

Labojums: turpināt prasīt un pieklauvēt pie durvīm

Veselības pārbaude tagad:

• katras 20 sekundes atkal lūdz palaist apturētu mašīnu, kamēr gaida,
• pieraksta, ko platforma atbildēja, kad tā noraida, un
• nosūta vienu parastu pieprasījumu lietotnei, tā kā to darītu apmeklētājs — platformas starpniekserveris pamodina aizmigušu mašīnu, kad ienāk pieprasījums.

Mēs to reproducējām reālajā platformā ar īslaicīgu lietotni, kuras pirmo palaišanu platforma noraidīja. Pirms labojuma publicēšana neizdevās pēc 91 sekundes. Pēc labojuma tā tika publicēta 20 sekundēs. Lietotne, kura patiesi avarē palaišanas brīdī, joprojām neizdodas, kā tam jādara.

Ko no tā guvām

• Atsaukšanai jāzina starpība starp jaunu un esošu. „Atsaukt” kaut ko, ko radīji, nozīmē dzēst. „Atsaukt” kaut ko, kas jau bija, nozīmē atjaunot. Ja abus traktē vienādi, drošības mehānisms izdzēš darbīgu lietotni.
• Pieraksti, kā atsaukt, pirms rīkojies. Ja atsaukšana tiek pierakstīta tikai pēc tam, kad solis ir izdevies, solis, kas neizdodas pusceļā, neatstāj neko, ar ko atsaukt.
• Nekad neignorē atbildi uz pieprasījumu, no kura esi atkarīgs. Viena ignorēta „nē” pārvērta veselu lietotni neveiksmīgā publicēšanā.

Saistīts labojums no tās pašas dienas: avāriju lietotnēm tieši pēc publicēšanas. Par to, kas notiek, ja publicēšana neizdodas jūsu pusē, skatiet publicēšanas problēmu risināšanu dokumentācijā.