Kubonyeza Chapisha Mara Mbili Sasa Kunachapisha Mara Moja

Maombi matatu ya kuchapisha programu hiyohiyo yalifika kwenye API yetu ndani ya milisekunde 84 za kila mmoja, na kila moja lilianzisha deploy kamili ya programu hiyo. Yalishindana kufika kwenye hosting ileile, na baadhi ya matoleo yaliyotokana yalishindwa kwa sababu nyingine ilikuwa imefika kwanza. Dalili pekee inayoonekana ilikuwa barua pepe ya "release failed" — programu yenyewe iliishia kuwa sawa. Sasa uchapishaji unaofika wakati mwingine kwa programu hiyohiyo ukiwa unaendelea hauanzishi build ya pili. Hifadhidata ndiyo inayoamua ombi lipi linashinda, na mengine yanaambiwa ukweli: uchapishaji tayari unaendelea.

Kilichotokea

Unapochapisha programu kwenye Mythex, API inarekodi deployment kwa ajili yake na kuomba orchestrator yetu — huduma inayoendesha builds — kuijenga na kuitoa. Uchapishaji unaweza kuanzia kwenye kitufe cha Chapisha, kutoka kichupo kingine cha kivinjari, au kutoka kwa wakala unapomwomba achapishe. Kubofya mara mbili, vichupo viwili, au ombi la wakala linalofika mara mbili vyote vinaweza kuzalisha zaidi ya uchapishaji mmoja kwa programu hiyo karibu wakati mmoja.

Katika kesi hii, matatu yalifika ndani ya ms 84. Kila moja lilikimbia deploy kamili. Kwenye jukwaa la hosting, matoleo ya programu hiyo yaliundwa ndani ya sekunde moja, na matatu kati yake yalishindwa kwa sababu mengine tayari yalikuwa yanaendelea. Toleo moja la baadaye lilikwama, lakini programu ilifanya kazi baadaye.

Hiyo ndiyo iliyofanya iwe rahisi kukosa. Mtumiaji aliona programu moja inayofanya kazi. Kushindwa kulionekana tu kama barua pepe za kushindwa kwa toleo.

Kwa nini hakuna kilichozuia

Msimbo wa uchapishaji ulikuwa na hatua iliyoangalia deployments zinazoendelea za mradi. Lakini ilichofanya ni kuweka alama kwamba kila deployment inayoendelea imeshindwa kabla ya kuanza — "imebadilishwa na uchapishaji mpya". Ilikusudiwa kusafisha builds zilizoachwa na mchakato uliokufa.

Kwa vitendo, uchapishaji wa pili unaofika katikati ya build ulitangaza wa kwanza kuwa umekufa na kuanzisha wake. Zote mbili zilimalizika dhidi ya programu hiyohiyo. Hakukuwa na kufuli; kulikuwa na hatua iliyofuta njia kwa bidii na kuunda mbio.

Kulikuwa pia na dalili ya pili ya ajabu kwa uchapishaji wa kwanza wa programu. Bila rekodi ya deployment ya kutumia tena, uchapishaji mbili wa kwanza zilizofika kwa wakati mmoja zote zilijaribu kuingiza rekodi moja. Hifadhidata ina faharasa ya kipekee kwenye jina la kiungo la programu (slug yake, kama your-app kwenye your-app.mythex.ai), kwa hiyo kuingiza la pili kulishindwa. API ilitafsiri hilo kuwa "jina hilo la kiungo limechukuliwa" — ikimshauri mtumiaji abadilishe jina la programu ambayo wakati huo ilikuwa inachapishwa kwa mafanikio chini ya jina hilo.

Suluhisho: dai ndilo kufuli

Kudai rekodi ya deployment sasa ni sasisho moja la hifadhidata lenye sharti: chukua mstari huu na uuweke kwenye hali ya kujenga ikiwa tu hakuna anayeuchapisha. Kwa kuwa ni taarifa moja, hifadhidata inamaliza maombi yanayofika kwa wakati mmoja. Mmoja tu kati yao ndiye anayebadilisha mstari. Wengine wanaona kwamba mistari sifuri imebadilika, wanasimama, na hawafiki kamwe kwenye orchestrator.

Kufuli pia linahitaji njia ya kutoka pale mmiliki wake anapokufa. Ikiwa API ilianzishwa upya katikati ya uchapishaji, mstari ungebaki na alama ya "inajenga" milele na programu isingeweza kuchapishwa tena. Kwa hiyo mstari ambao mmiliki wake ameacha kutuma mapigo ya moyo — uchapishaji unaoendelea unasasisha mstari kila sekunde 30, na kimya cha dakika tano kinahesabika kuwa kimekufa — unaweza kudaiwa tena. Kizingiti hicho kinatokana na mapigo ya moyo, si kukisia muda wa build. Kujenga Dockerfile ya mtumiaji mwenyewe kunaweza kudumu kwa muda mrefu kihalali, na build ya polepole inayoendelea kutuma mapigo ya moyo inaendelea kushikilia dai lake.

Hatua iliyoshindwa kwa kila deployment inayoendelea haiendeshwi tena kabla ya uchapishaji. Ni rekodi zilizoachwa na mchakato uliokufa tu ndizo zinazosafishwa.

Kumwambia aliyepoteza ukweli

Ombi linalopoteza sasa linapata jibu wazi: publish_in_progress, pamoja na kitambulisho cha deployment inayoendelea. Kila mahali panapoweza kuanzisha uchapishaji kinashughulikia hilo:

• Nafasi ya kazi inafuata build iliyokwishaanza badala ya kuonyesha hitilafu juu yake.
• Wakala anaambiwa kwamba uchapishaji wa programu hii tayari unaendelea na kwamba aisubiri, badala ya kuambiwa kwamba kuna kitu kimeshindwa — jambo ambalo hapo awali lingeweza kumtuma kujaribu "kurekebisha" Dockerfile na kujaribu tena.
• Mgongano wa uchapishaji wa kwanza kwenye jina la kiungo unakaguliwa: ikiwa rekodi inayoshikilia jina ni uchapishaji unaoendelea wa mradi huu wenyewe, jibu ni "tayari inachapishwa", si "jina hilo limechukuliwa". Mgongano halisi na mradi mwingine bado unapata ujumbe wa kubadilisha jina.

Jinsi tulivyokagua

Tuliandika hati ya kurudia tukio inayoendesha uchapishaji watatu wa programu moja kwa wakati mmoja dhidi ya hifadhidata halisi na orchestrator ya kuigiza, kisha inahesabu deploy ngapi orchestrator inaombwa. Inafunika uchapishaji wa kwanza na urudiaji wa programu iliyo hewani. Kabla ya marekebisho, ilihesabu deploy mbili. Baada ya, moja.

Hati pia inafunika njia ya dharura: inaweka alama ya mstari wa programu kuwa unajenga bila mapigo ya moyo kwa dakika kumi, kisha inachapisha tena na kuangalia kama uchapishaji mpya unadai mstari na kuendesha.

Majaribio ya kitengo yanashikilia kufuli kwenye mambo mawili ambayo kufuli lazima lifanye: kati ya urudiaji watatu wa wakati mmoja, mmoja tu ndio anapita, na wawili wengine wanaambiwa kwamba uchapishaji unaendelea; na build ambayo mmiliki wake amekufa inaweza kudaiwa. Jaribio jingine linaangalia kwamba jaribio jipya halibebi ujumbe wa hitilafu wa jaribio la awali.

Tuliyojifunza

• Msimbo wa usafi unaweza kuwa mbio iliyojificha. "Shindwa chochote kinachoendelea, kisha anza" unaonekana kama usafi. Kukiwa na wapigaji wawili, kila mmoja anafuta kazi ya mwingine.
• Acha hifadhidata iamue. Kusoma kisha kuandika kunaacha pengo kwa ombi jingine. Sasisho moja lenye sharti halina pengo.
• Kila kufuli linahitaji muda wa kuisha unaofungamana na uhai. Bila hilo, hitilafu moja inageuka kuwa programu iliyokwama.
• Ujumbe wa hitilafu ni maagizo. "Jina hilo limechukuliwa" lilimwambia mtu afanye jambo lisilo sahihi. Ujumbe sahihi ulikuwa rahisi zaidi na wa kweli.

Zaidi kuhusu kuchapisha kwenye nyaraka: jinsi ya kuchapisha. Na marekebisho yanayohusiana: programu yako iliyochapishwa inabaki hewani wakati unachapisha upya.