Hindi Nabubura ng Pumalpak na Republish ang Gumaganang Backend

Noong Setyembre 25, binura ng isang pumalpak na republish ang backend ng isang app na live at gumagana nang mga dalawa't kalahating oras. Tinanggal ng code na nag-uundo sa pumalpak na publish ang bawat server app na hinawakan ng publish — kasama na ang mga nakaserbisyo na bago pa ito nagsimula. Ngayon, tanging mga app na ginawa ng isang publish lang ang binubura. Ang app na dati nang umiiral ay ibinabalik sa eksaktong bersyong pinapatakbo nito bago ang publish. Dalawang follow-up na ayos ang ginawa rin nang araw na iyon: tinitiyak nitong tumatakbo rin ang undo kapag pumalpak ang sariling deploy tool ng hosting platform, at hindi nabibigyan ng failure ang malusog na app dahil lang natutulog ito noon.

Paano nai-publish ang isang backend

Kapag may backend ang iyong Mythex app — isang API o server, hindi lang static files — gagawin ng publish ang build nito mula sa Dockerfile (isang recipe para ibalot ang app sa isang image) at ilalabas ang image na iyon sa mga makina ng hosting platform namin. Pagkatapos, maghihintay ang health check hanggang sa tunay na tumakbo at manatiling tumatakbo ang bagong bersyon bago markahang live ang publish.

Kapag may pumalpak sa daan, tatakbo ang rollback para i-undo ito. Mahalagang tama ang rollback na iyon, mas mahalaga pa kaysa halos anumang bahagi ng publishing, dahil tumatakbo ito mismo kapag may nagkakamali na.

Problema 1: binura ng rollback ang dapat sana ay ibinalik

Nagtatago ang rollback ng listahan ng mga server app na pinagdeploy-an ng publish, at kapag pumalpak, sinisira nito ang bawat isa. Tama iyon sa unang publish: kagagawa lang ng app, walang nakadepende rito, at ang pagbura nito ay nag-iiwan ng dating kalagayan ng lahat.

Mali naman iyon sa republish. Umiiral na ang app at nagseserbisyo na ng totoong bisita. Noong Setyembre 25, binura ng pumalpak na republish ang API ng isang app na live nang mga dalawa't kalahating oras.

May pangalawang failure mode na nakatago sa parehong code. Kapag hindi natuloy ang pagbura, mananatili sa mga makina ang bagong image na sira, habang sinasabi namin sa may-ari na live pa rin ang kasalukuyang site niya. Pagdating ng puntong puwedeng pumalpak ang health check, nailagay na ang bagong image sa bawat makina. Ang hindi paggawa ng anuman ay hindi katumbas ng pag-undo.

Ang ayos: burahin lang ang ginawa mo, ibalik ang iba

Ngayon, nire-record ng bawat publish, para sa bawat server app na hinahawakan nito:

• kung ginawa ito ng publish na ito, at
• kung hindi, aling image ang pinapatakbo nito bago ang publish.

Kapag pumalpak, may isa sa tatlong gagawin sa bawat app:

1. Ginawa ng publish na ito: burahin, gaya ng dati.
2. Dati nang umiiral at alam ang nakaraang image: i-redeploy ang nakaraang image gamit ang parehong configuration. Walang build; ang image lang ang ibinabalik.
3. Dati nang umiiral at hindi alam ang nakaraang image: iwanan. Hindi binubura ang umiiral na app, kahit hindi namin ito maibalik.

Maliit na pure function na may sariling tests ang mga patakarang ito, kaya hindi na babalik ang "burahin ang lahat" nang hindi pumapalya ang isang test.

Problema 2: puwedeng pumalpak ang deploy tool bago pa naisulat kung paano mag-undo

Hindi nagtagal pagkatapos ng ayos na iyon, may nakita kaming butas. Nagpapatakbo ang deploy tool ng hosting platform ng sarili nitong smoke checks: kung mag-crash ang mga bagong makina, lalabas ito na may error. Pero ginagawa nito iyon pagkatapos na nailagay na ang bagong image sa mga makina.

Ang code namin ay nagrerehistro lang ng app para sa rollback kapag nagbalik nang maayos ang tool. Kapag ang mismong tool ang pumalpak sa deploy, hindi pa naka-rehistro ang app sa listahan ng rollback, kaya walang naibalik. Sa staging namin, isang sirang republish ang nag-iwan ng sirang image na tumatakbo pa.

Ang ayos: irehistro ang undo bago magsimula

Nare-rehistro na ngayon ang app para sa rollback, kasama kung nagawa ito at kung anong image ang pinapatakbo nito, sa sandaling ihanda ito at bago pa ilagay dito ang anuman. Anuman ang pumalpak pagkatapos, alam ng rollback kung ano ang ibabalik. Na-verify namin ito nang lokal: pumalpak ang isang sirang republish sa smoke checks ng deploy tool, at patuloy na sumagot ang nakaraang bersyon.

Problema 3: minarkahang "hindi nagsimula" ang app na natutulog

Natutulog ang mga na-publish na app sa Mythex kapag idle, para makatipid ka ng credits. Iniiwan ng republish na nakahinto ang natutulog na makina, kaya kailangang gisingin ito ng health check. Minsan lang nitong hinihiling sa platform na simulan ang makina, at binabalewala ang sagot.

Noong Setyembre 25, napunta sa wala ang nag-iisang hiling na iyon. Nanatiling nakahinto ang isang malusog na API sa buong limang minutong health check at minarkahang pumalpak dahil sa "1 machine never started (last state: stopped)".

Minsan talaga tumatanggi ang platform sa start. Habang inuulit namin ang problema, nagbalik ito ng conflict na "lease currently held" nang hindi namin ito pinupukaw, at tumatanggi ito sa start habang may ina-update na makina.

Ang ayos: magtanong ulit, at kumatok

Ngayon, ginagawa ng health check ang mga ito:

• tinatanong ulit kung simulan ang nakahintong makina kada 20 segundo habang naghihintay,
• itinatala ang sagot ng platform kapag tumatanggi ito, at
• nagpapadala ng isang karaniwang request sa app, gaya ng ginagawa ng bisita. Ginigising ng proxy ng platform ang natutulog na makina kapag may dumating na request.

Inulit namin ito sa totoong platform gamit ang isang pansamantalang app na tinanggihan ang unang start. Bago ang ayos, pumalpak ang publish pagkatapos ng 91 segundo. Pagkatapos ng ayos, nailathala ito sa loob ng 20 segundo. Pumapalya pa rin ang app na tunay na nag-crash sa pagsisimula, gaya ng nararapat.

Ang natutunan namin

• Kailangang alam ng rollback ang pagkakaiba ng bago at umiiral na. Ang "undo" sa ginawa mo ay pagbura. Ang "undo" sa dati nang naroon ay pagbabalik. Kapag pareho ang trato sa dalawa, ganito binubura ng isang safety mechanism ang gumaganang app.
• Isulat muna kung paano mag-undo bago kumilos. Kung naitatala lang ang undo pagkatapos magtagumpay ang isang hakbang, ang hakbang na pumalpak sa kalagitnaan ay walang magagamit na pang-undo.
• Huwag balewalain ang sagot sa request na kailangan mo. Isang "hindi" na hindi pinansin ang nagpalit ng malusog na app sa pumalpak na publish.

Kaugnay na ayos mula sa parehong araw: kung paano nahuhuli ang mga app na nag-crash pagkatapos ma-publish. Para sa mga nangyayari kapag pumalpak ang publish sa panig mo, tingnan ang troubleshooting ng publish sa docs.