Republish Iliyoshindwa Haifuti Backend Inayofanya Kazi

Tarehe 25 Septemba, republish iliyoshindwa ilifuta backend ya app iliyokuwa hai na ikifanya kazi kwa takriban saa mbili na nusu. Msimbo unaorudisha nyuma publish iliyoshindwa uliondoa kila server app ambayo publish ile iligusa — ikiwemo zile ambazo tayari zilikuwa zinatoa huduma kabla haijaanza. Sasa ni app ambazo publish imezitengeneza tu ndizo zinazoweza kufutwa; app iliyokuwepo tayari inarudishwa kwenye toleo halisi ilikuwa inaendesha kabla. Marekebisho mawili ya siku hiyo hiyo yalihakikisha kwamba urudishaji huo pia unafanyika pale zana ya deploy ya jukwaa la hosting inaposhindwa, na kwamba app yenye afya haishindwi kwa sababu tu ilikuwa imelala.

Backend inavyochapishwa

App yako ya Mythex ikiwa na backend — API au server, si faili tuli tu — publish huijenga kutoka Dockerfile (mapishi ya kufunga app kuwa image) na kuisambaza image hiyo kwenye mashine za jukwaa letu la hosting. Kisha health check inasubiri toleo jipya lianze kikamilifu na kubaki hai kabla publish haijawekwa alama kuwa hai.

Kama kuna kitu kinashindwa njiani, rollback inaendeshwa kuutengua. Kurekebisha rollback kwa usahihi ni muhimu kuliko karibu kitu kingine chochote katika publishing, kwa sababu inaendeshwa hasa wakati tayari kuna tatizo.

Tatizo 1: rollback ilifuta kile ilichopaswa kurudisha

Rollback ilihifadhi orodha ya server apps ambazo publish ilizisambazia, na ikishindwa, iliziharibu zote. Hilo ni sahihi kwa publish ya kwanza: app iliundwa dakika chache zilizopita, hakuna kitu kinachoitegemea, na kuifuta kunaacha mambo kama yalivyokuwa.

Lakini ni kosa kabisa kwa republish. App tayari ilikuwepo na ilikuwa inahudumia wageni halisi. Tarehe 25 Septemba, API ya app iliyokuwa hai kwa takriban saa mbili na nusu ilifutwa na republish iliyoshindwa.

Kulikuwa na hitilafu ya pili iliyojificha kwenye msimbo huo huo. Pale ufutaji usipofanikiwa, image mpya iliyovunjika ilibaki kwenye mashine — wakati sisi tulimwambia mmiliki kwamba tovuti yake ya sasa bado iko hai. Kufikia wakati health check inaweza kushindwa, image mpya tayari imeshasambazwa kwenye kila mashine. Kutofanya chochote si sawa na kutengua.

Marekebisho: futa kile ulichounda tu, rudisha kingine

Sasa kila publish inarekodi, kwa kila server app inayogusa:

• kama publish hii iliunda app hiyo, na
• kama haikuunda, ni image ipi ilikuwa inaendesha kabla tu.

Ikishindwa, kila app inapata mojawapo ya matibabu matatu:

1. Iliundwa na publish hii: ifutwe, kama awali.
2. Ilikuwepo, na image ya awali inajulikana: isambaze tena image ya awali yenye usanidi uleule. Hakuna build — image tu inarudi nyuma.
3. Ilikuwepo, na image ya awali haijulikani: iachwe bila kuguswa. App iliyokuwepo haifutwi kamwe, hata pale tusipoweza kuirudisha.

Sheria hizi ni function ndogo safi yenye majaribio yake, kwa hiyo uamuzi hauwezi kurudi kwenye "futa kila kitu" bila jaribio kushindwa.

Tatizo 2: zana ya deploy inaweza kushindwa kabla hatujaandika jinsi ya kutengua

Muda mfupi baada ya marekebisho hayo, tuligundua pengo ndani yake. Zana ya deploy ya jukwaa la hosting inaendesha ukaguzi wake wa haraka: mashine mpya zikianguka, inatoa hitilafu. Lakini inafanya hivyo baada ya image mpya kuwa tayari imewekwa kwenye mashine.

Msimbo wetu ulisajili app kwa ajili ya rollback tu baada ya zana kurudisha mafanikio. Zana ilipoishia kwa kushindwa, app haikuwa bado kwenye orodha ya rollback, kwa hiyo hakuna kilichorudishwa. Kwenye mazingira yetu ya staging, republish iliyovunjika iliacha image iliyovunjika ikihudumia.

Marekebisho: sajili njia ya kutengua kabla ya kuanza

Sasa app inasajiliwa kwa ajili ya rollback — pamoja na kama iliundwa na image gani ilikuwa inaendesha — mara tu inapoandaliwa, kabla ya kitu chochote kusambazwa juu yake. Chochote kitakachoshindwa baadaye, rollback inajua cha kurudisha. Tulithibitisha kwa ndani: republish iliyovunjika ilishindwa kwenye ukaguzi wa haraka wa zana ya deploy, na toleo la awali liliendelea kujibu.

Tatizo 3: app iliyolala ilishindwa kama "haikuanza kamwe"

App zilizochapishwa kwenye Mythex hulala zinapokuwa hazitumiki ili kuokoa credits zako. Republish huacha mashine iliyolala ikiwa imesimama, kwa hiyo health check lazima imwamshe. Ilimwomba jukwaa kuanzisha mashine mara moja, na ikapuuza jibu.

Tarehe 25 Septemba, ombi hilo moja la kuanzisha lilipotea. API yenye afya iliyokuwa imesimama ilikaa hivyo kwa dakika tano nzima za health check, kisha ikashindwa kwa ujumbe "mashine 1 haikuanza kamwe (hali ya mwisho: stopped)".

Jukwaa wakati mwingine hukataa kuanzisha. Tukiwa tunarudia tatizo hili, lilirudisha mgongano wa "lease currently held" bila sisi kulichochea, na hukataa kuanzisha wakati mashine inasasishwa.

Marekebisho: endelea kuuliza, na ugonge mlango

Health check sasa:

• inauliza tena kuanzisha mashine iliyosimama kila sekunde 20 wakati inasubiri,
• inaandika kile jukwaa lilijibu pale linapokataa, na
• inatuma ombi moja la kawaida kwa app, kama mgeni angefanya — proxy ya jukwaa humwamsha mashine iliyolala ombi linapofika.

Tulilirudia tatizo kwenye jukwaa halisi kwa app ya majaribio ambayo kuanza kwake kwa mara ya kwanza kulikataliwa. Kabla ya marekebisho, publish ilishindwa baada ya sekunde 91. Baada ya marekebisho, ilichapishwa baada ya sekunde 20. App inayoanguka yenyewe inapowashwa bado itashindwa, kama inavyostahili.

Tulichojifunza

• Rollback lazima ijue tofauti kati ya mpya na iliyokuwepo. "Kutengua" kitu ulichounda ni kukifuta. "Kutengua" kitu kilichokuwepo tayari ni kukirudisha. Kuvitendea sawa ndiyo jinsi utaratibu wa usalama unavyofuta app inayofanya kazi.
• Andika jinsi ya kutengua kabla ya kuchukua hatua. Kama njia ya kutengua inarekodiwa tu baada ya hatua kufanikiwa, hatua inayoshindwa katikati haiachi kitu cha kutengulia nacho.
• Usipuuze jibu la ombi unalolitegemea. "Hapana" moja iliyopuuzwa iligeuza app yenye afya kuwa publish iliyoshindwa.

Marekebisho mengine yanayohusiana kutoka siku hiyo hiyo: kukamata app zinazoanguka mara tu baada ya kuchapishwa. Kwa kinachotokea publish inaposhindwa upande wako, angalia utatuzi wa publish kwenye docs.