Publish-ը երկու անգամ սեղմելիս այժմ հրապարակվում է մեկ անգամ

Նույն հավելվածի երեք հրապարակման հարցում հասավ մեր API-ին 84 միլիվայրկյան ընդմիջումով, և յուրաքանչյուրը սկսեց այդ հավելվածի լրիվ deploy։ Դրանք մրցում էին նույն հոսթինգի վրա, և արդյունքում ստեղծված թողարկումներից մի քանիսը ձախողվեցին, քանի որ մյուսներն արդեն հասել էին առաջ, իսկ միակ տեսանելի նշանը «release failed» նամակն էր. հավելվածն ի վերջո լավ էր աշխատում։ Այժմ հրապարակումը, որ գալիս է այն ժամանակ, երբ նույն հավելվածի համար մյուսն արդեն աշխատում է, երկրորդ build չի սկսում։ Բազան է որոշում, թե որ հարցումն է հաղթում, և մյուսներին ասվում է ճշմարտությունը. հրապարակումն արդեն ընթացքի մեջ է։

Ինչ եղավ

Երբ հրապարակում եք հավելված Mythex-ում, API-ն գրանցում է deployment ձեր հավելվածի համար և խնդրում է մեր orchestrator-ին՝ ծառայությանը, որը գործարկում է build-երը, կառուցել և թողարկել այն։ Հրապարակումը կարող է սկսվել Publish կոճակից, մեկ այլ բրաուզերի ներդիրից, կամ agent-ից, երբ խնդրում եք հրապարակել։ Կրկնակի սեղմումը, երկու ներդիր կամ agent-ի հարցում, որ կրկնվում է, կարող են բոլորը առաջացնել ավելի քան մեկ հրապարակում նույն հավելվածի համար գրեթե նույն պահին։

Այս դեպքում երեքը հասան 84 մվ-ի մեջ։ Յուրաքանչյուրն աշխատեցրեց լրիվ deploy։ Հոսթինգ պլատֆորմի վրա նույն հավելվածի թողարկումները ստեղծվեցին նույն վայրկյանում, և երեքից մի քանիսը ձախողվեցին, քանի որ մյուսները արդեն ընթացքի մեջ էին։ Հետագա թողարկումը խրվեց, իսկ հավելվածը հետո աշխատեց։

Դա էր, որ հեշտ էր բաց թողնել։ Օգտատերը տեսավ մեկ աշխատող հավելված։ Ձախողումները երևում էին միայն որպես release-failure նամակներ։

Ինչու ոչինչ չէր կանգնեցնում դա

Հրապարակման կոդն արդեն ուներ քայլ, որ նայում էր նախագծի ընթացիկ deploy-ներին։ Բայց այն, ինչ անում էր, նշում էր յուրաքանչյուր ընթացիկ deploy որպես ձախողված՝ նախքան սկսելը. «superseded by a new publish»։ Այն նախատեսված էր մաքրելու այն build-երը, որոնք մնացել էին կործանված պրոցեսից։

Պրակտիկայում դա նշանակում էր, որ build-ի մեջտեղում եկած երկրորդ հրապարակումը հայտարարում էր առաջինը մեռած և սկսում էր իրեն։ Երկուսն էլ ավարտվում էին նույն հավելվածի դեմ։ Կողպում չկար. կար քայլ, որ ակտիվորեն մաքրում էր ճանապարհը մրցավազքի համար։

Առաջին հրապարակման համար կար երկրորդ, ավելի տարօրինակ ախտանիշ։ Քանի որ դեռ deployment գրառում չկար վերօգտագործելու համար, երկու համաժամանակյա առաջին հրապարակում փորձում էին ավելացնել մեկը։ Բազան ունի եզակի ինդեքս հավելվածի հղման անվան վրա (նրա slug-ը, ինչպես your-app-ը your-app.mythex.ai-ում), ուստի երկրորդ ավելացումը ձախողվում էր։ API-ն դա թարգմանում էր «այդ հղման անունը արդեն զբաղված է»-ի, և խորհուրդ էր տալիս օգտատիրոջը վերանվանել հավելվածը, որը այդ պահին հաջողությամբ հրապարակվում էր այդ անվան տակ։

Շտկումը. պահպանումը կողպումն է

Deployment գրառումը պահպանելն այժմ մեկ պայմանական բազայի թարմացում է. վերցրու այս տողը և նշիր որպես կառուցվող միայն եթե ոչ ոք չի հրապարակում այն։ Քանի որ դա մեկ հրաման է, բազան լուծում է նույն միլիվայրկյանում եկած հարցումները։ Ճիշտ մեկը փոխում է տողը։ Մյուսները տեսնում են, որ զրո տող է փոխվել, կանգնում են և երբեք չեն հասնում orchestrator-ին։

Կողպումը պետք է նաև ելք ունենա, երբ դրա պահողը մահանում է։ Եթե API-ն վերագործարկվեր հրապարակման մեջտեղում, տողը հավերժ կմնար «building» նշված, և հավելվածը անհնար կլիներ նորից հրապարակել։ Ուստի տողը, որի սեփականատերը դադարել է heartbeat ուղարկել՝ գործընթացը յուրաքանչյուր 30 վայրկյանը մեկ թարմացնում է տողը, իսկ հինգ րոպե լռությունը նշանակում է մահ, կարող է նորից վերցվել։ Այդ շեմը գալիս է heartbeat-ից, ոչ թե build-ի տևողության մասին ենթադրությունից։ Օգտատիրոջ սեփական Dockerfile-ը կառուցելը կարող է օրինականորեն երկար տևել, և դանդաղ build, որ դեռ heartbeat է անում, պահում է իր կողպումը։

Քայլը, որ նախկինում ձախողում էր բոլոր ընթացիկ deploy-ները հրապարակումից առաջ, այլևս չի աշխատում։ Միայն այն գրառումները, որ մնացել են մեռած պրոցեսից, են մաքրվում։

Պարտվողին ասել ճշմարտությունը

Պարտվող հարցումն այժմ ստանում է հստակ պատասխան՝ publish_in_progress, ընթացքի մեջ գտնվող deployment-ի ID-ով։ Յուրաքանչյուր տեղ, որ կարող է սկսել հրապարակում, այն մշակում է.

• Աշխատանքային տարածքը հետևում է արդեն աշխատող build-ին՝ սխալ ցուցադրելու փոխարեն։
• Agent-ին ասվում է, որ այս հավելվածի հրապարակում արդեն աշխատում է, և սպասի դրան, այլ ոչ թե ասվում է, որ ինչ-որ բան ձախողվել է. դա նախկինում կարող էր ուղարկել այն «շտկելու» Dockerfile-ը և նորից փորձելու։
• Առաջին հրապարակման բախումը հղման անվան վրա ստուգվում է. եթե տողը, որ պահում է անունը, այս նախագծի սեփական ընթացիկ հրապարակումն է, պատասխանը «արդեն հրապարակվում է» է, ոչ թե «այդ անունը զբաղված է»։ Իրական բախումը մեկ այլ նախագծի հետ դեռ ստանում է վերանվանման հաղորդագրությունը։

Ինչպես ստուգեցինք

Գրել ենք վերարտադրման սկրիպտ, որը միաժամանակ աշխատեցնում է նույն հավելվածի երեք հրապարակում իրական բազայի և կեղծ orchestrator-ի դեմ, և հաշվում է, թե քանի deploy է պահանջվել orchestrator-ից։ Այն ընդգրկում է և առաջին հրապարակումը, և արդեն կենդանի հավելվածի վերահրապարակումը։ Շտկումից առաջ հաշվում էր երկու deploy։ Հետո՝ մեկ։

Սկրիպտը ընդգրկում է նաև փախուստի ելքը. այն նշում է հավելվածի տողը որպես կառուցվող՝ առանց heartbeat տաս րոպեի համար, նորից հրապարակում է և ստուգում, որ նոր հրապարակումը վերցնում է տողը և աշխատում։

Միավոր թեստերը կողպումը պահում են այն երկու բանի վրա, որ կողպումը պետք է անի. միաժամանակյա երեք վերահրապարակումից ճիշտ մեկն է անցնում, իսկ մյուս երկուսին ասվում է, որ հրապարակում է ընթացքի մեջ։ Եվ այն build-ը, որի սեփականատերը մահացել է, կարող է վերցվել։ Մեկ այլ թեստ ստուգում է, որ նոր փորձը չի փոխանցում նախորդ փորձի սխալի հաղորդագրությունը։

Ինչ սովորեցինք

• Մաքրող կոդը կարող է մրցավազք լինել։ «Ձախողիր ամեն ինչ, որ ընթացքի մեջ է, ապա սկսիր» կարծես հիգիենա է։ Երկու կանչողի դեպքում դա յուրաքանչյուրն է, որ մյուսին չեղարկում։
• Թողեք բազային որոշել։ Կարդալ, ապա գրել բացում է բաց մեկ այլ հարցման համար։ Մեկ պայմանական թարմացումը չի բացում։
• Յուրաքանչյուր կողպում պետք է ունենա ժամկետ, կապված կենդանության հետ։ Առանց դրա՝ կործանումը դառնում է խրված հավելված։
• Սխալի հաղորդագրությունները հրահանգներ են։ «Այդ անունը զբաղված է»-ը մարդկանց ասում էր սխալ բան անել։ Ճիշտ հաղորդագրությունը ավելի պարզ էր և ճշմարիտ։

Հրապարակման մասին ավելին փաստաթղթերում՝ ինչպես հրապարակել։ Եվ կապված շտկում՝ ձեր հրապարակված հավելվածը մնում է առցանց, երբ նորից եք հրապարակում։