Ձախողված վերահրապարակումը երբեք չի ջնջում աշխատող backend-ը

Սեպտեմբերի 25-ին ձախողված վերահրապարակումը ջնջեց հավելվածի backend-ը, որը մոտ երկու ու կես ժամ ակտիվ և աշխատող էր։ Ձախողված հրապարակումը հետ շրջող կոդը ջնջեց բոլոր սերվերային հավելվածները, որոնց հրապարակումը դիպել էր, ներառյալ այն հավելվածները, որոնք արդեն սպասարկում էին նախքան այն սկսելը։ Այժմ ջնջվում են միայն այն հավելվածները, որոնք հենց հրապարակումն է ստեղծել. գոյություն ունեցող հավելվածը վերադարձվում է հենց այն տարբերակին, որով աշխատում էր մինչ այդ։ Նույն օրը արված երկու հետագա շտկում ապահովեց, որ հետ շրջումը աշխատի նաև այն դեպքում, երբ հոսթինգ հարթակի սեփական deploy գործիքն է ձախողվում, և որ առողջ հավելվածը չի ճանաչվում ձախողված միայն այն պատճառով, որ քնած էր։

Ինչպես է հրապարակվում backend-ը

Երբ Mythex հավելվածն ունի backend, այսինքն՝ API կամ սերվեր, և ոչ միայն ստատիկ ֆայլեր, հրապարակումը այն կառուցում է Dockerfile-ից (բաղադրատոմս, որով հավելվածը փաթեթավորվում է image-ի մեջ) և այդ image-ը տեղադրում է մեր հոսթինգ հարթակի մեքենաների վրա։ Դրանից հետո health check-ը սպասում է, որ նոր տարբերակը իրոք բարձրանա և մնա աշխատող, և միայն դրանից հետո հրապարակումը նշվում է որպես ակտիվ։

Եթե այս ընթացքում ինչ-որ բան ձախողվում է, գործարկվում է rollback՝ այն հետ շրջելու համար։ Այս rollback-ը ճիշտ աշխատեցնելը գրեթե ամենակարևոր բանն է հրապարակման մեջ, քանի որ այն գործարկվում է հենց այն պահին, երբ արդեն ինչ-որ բան սխալ է ընթանում։

Խնդիր 1. rollback-ը ջնջում էր այն, ինչ պետք էր վերականգնել

Rollback-ը պահում էր այն սերվերային հավելվածների ցանկը, որոնց հրապարակումը տեղադրել էր, և ձախողման դեպքում ջնջում էր դրանցից յուրաքանչյուրը։ Առաջին հրապարակման համար դա ճիշտ էր. հավելվածը րոպե առաջ էր ստեղծվել, ոչինչ դրա վրա կախված չէր, և ջնջումը թողնում էր ամեն ինչ նախկին վիճակում։

Վերահրապարակման դեպքում դա բացարձակապես սխալ էր։ Հավելվածն արդեն գոյություն ուներ և սպասարկում էր իրական այցելուներին։ Սեպտեմբերի 25-ին ձախողված վերահրապարակումը ջնջեց հավելվածի API-ն, որը մոտ երկու ու կես ժամ ակտիվ էր եղել։

Այդ նույն կոդում թաքնված էր երկրորդ խնդիր։ Եթե ջնջումը չէր ավարտվում, խափանված նոր image-ը մնում էր մեքենաների վրա, մինչդեռ մենք հավելվածի սեփականատիրոջը տեղեկացնում էինք, որ նրա ընթացիկ կայքը դեռ ակտիվ է։ Մինչև health check-ը կարող էր ձախողվել, նոր image-ը արդեն տեղադրված էր յուրաքանչյուր մեքենայի վրա։ Ոչինչ չանելը նույնը չէ, ինչ հետ շրջելը։

Շտկումը. ջնջել միայն այն, ինչ ստեղծել ես, իսկ մնացածը վերականգնել

Այժմ յուրաքանչյուր հրապարակում յուրաքանչյուր սերվերային հավելվածի համար գրանցում է.

• արդյո՞ք այս հրապարակումն է այն ստեղծել, և
• եթե ոչ, ո՞ր image-ով էր այն աշխատում անմիջապես մինչ այդ։

Ձախողման դեպքում յուրաքանչյուր հավելված ստանում է երեք մշակումներից մեկը.

1. Ստեղծվել է այս հրապարակման կողմից. ջնջել, ինչպես առաջ։
2. Արդեն գոյություն ուներ, նախորդ image-ը հայտնի է. վերատեղակայել նախորդ image-ը նույն կոնֆիգուրացիայով։ Build չկա. տեղափոխվում է միայն image-ը։
3. Արդեն գոյություն ուներ, նախորդ image-ը հայտնի չէ. չդիպչել։ Գոյություն ունեցող հավելվածը երբեք չի ջնջվում, նույնիսկ եթե մենք չենք կարող այն վերականգնել։

Այս կանոնները փոքր, մաքուր ֆունկցիա են՝ սեփական թեստերով, այնպես որ որոշումը չի կարող նորից վերադառնալ «ջնջել ամեն ինչ» սկզբունքին առանց թեստի ձախողման։

Խնդիր 2. deploy գործիքը կարող էր ձախողվել, նախքան մենք կգրանցեինք, թե ինչպես հետ շրջել

Այդ շտկումից քիչ անց մենք գտանք դրա բացը։ Հոսթինգ հարթակի deploy գործիքն իր սեփական smoke ստուգումներն է կատարում. եթե նոր մեքենաները խափանվում են, գործիքը սխալով է ավարտվում։ Բայց դա արվում է հետո, երբ նոր image-ը արդեն տեղադրված է մեքենաների վրա։

Մեր կոդը հավելվածը rollback-ի ցանկում գրանցում էր միայն այն ժամանակ, երբ գործիքը հաջողությամբ էր վերադառնում։ Երբ ինքը գործիքը ձախողում էր deploy-ը, հավելվածը դեռ ցանկում չէր, և ոչինչ չէր վերականգնվում։ Մեր staging միջավայրում խափանված վերահրապարակումը թողեց խափանված image-ը ակտիվ։

Շտկումը. գրանցել հետ շրջելու միջոցը մինչ սկսելը

Հավելվածն այժմ գրանցվում է rollback-ի համար. ստեղծվել է այն, թե ոչ, և ինչ image-ով էր աշխատում, հենց որ այն պատրաստվում է, և մինչ որևէ բան կտեղակայվի դրա վրա։ Ինչ էլ հետո ձախողվի, rollback-ը գիտի, թե ինչ վերադարձնի։ Մենք ստուգել ենք լոկալ. խափանված վերահրապարակումը ձախողվեց deploy գործիքի սեփական smoke ստուգումների ժամանակ, և նախորդ տարբերակը շարունակեց պատասխանել։

Խնդիր 3. քնած հավելվածը ձախողվեց որպես «երբեք չսկսված»

Mythex-ի հրապարակված հավելվածները, որպեսզի խնայեն քո կրեդիթները, անգործության ժամանակ քնում են։ Վերահրապարակումը թողնում է քնած մեքենան կանգնած, ուստի health check-ը պետք է այն արթնացնի։ Նա մեկ անգամ խնդրում էր հարթակից մեքենան գործարկել և անտեսում էր պատասխանը։

Սեպտեմբերի 25-ին այդ մեկ գործարկման հարցումը ոչ մի տեղ չհասավ։ Առողջ API-ն կանգնած մնաց ամբողջ հինգ րոպեանոց health check-ի ընթացքում և ձախողվեց «1 մեքենա երբեք չսկսվեց (վերջին վիճակը՝ stopped)» հաղորդագրությամբ։

Հարթակը երբեմն մերժում է գործարկումը։ Այս խնդիրը վերարտադրելիս այն առանց մեր որևէ առաջացման վերադարձրեց «lease currently held» կոնֆլիկտ, և այն մերժում է գործարկումները, երբ մեքենան թարմացվում է։

Շտկումը. շարունակել հարցնել և թակել դուռը

Health check-ն այժմ.

• կրկին հարցնում է կանգնած մեքենայի գործարկումը յուրաքանչյուր 20 վայրկյանը մեկ մինչ սպասելը,
• գրանցում է, թե ինչ է պատասխանել հարթակը, երբ այն մերժում է, և
• ուղարկում է մեկ սովորական հարցում հավելվածին այնպես, ինչպես կանի այցելուն. հարթակի պրոքսին արթնացնում է քնած մեքենան, երբ հարցում է գալիս։

Իրական հարթակի վրա վերարտադրեցինք այս խնդիրը մի ժամանակավոր հավելվածով, որի առաջին գործարկումը մերժվեց։ Շտկումից առաջ հրապարակումը ձախողվում էր 91 վայրկյանից հետո։ Շտկումից հետո այն հրապարակվեց 20 վայրկյանում։ Հավելվածը, որը իրոք խափանվում է բեռնվելիս, դեռ ձախողվում է, ինչպես և պետք է։

Ինչ ենք սա սովորել

• Rollback-ը պետք է տարբերի նորը գոյություն ունեցողից. «Հետ շրջել» այն բանի համար, որը դու ստեղծել ես, նշանակում է ջնջել։ «Հետ շրջել» այն բանի համար, որն արդեն եղել է, նշանակում է վերականգնել։ Դրանք միատեսակ վարելը այն է, ինչի պատճառով անվտանգության մեխանիզմը ջնջում է աշխատող հավելված։
• Գրի առ, թե ինչպես հետ շրջել, մինչ գործելը. Եթե հետ շրջելու միջոցը գրանցվում է միայն այն բանից հետո, երբ քայլը հաջողվում է, քայլը, որը կես ճանապարհին է ձախողվում, ոչինչ չի թողնում, որով հետ շրջել։
• Երբեք մի անտեսիր պատասխանը այն հարցումի, որից կախված ես. Մեկ անտեսված «ոչ»-ը ակտիվ հավելվածը վերածեց ձախողված հրապարակման։

Նույն օրվա կապված շտկումը. ինչպես են բռնվում հավելվածները, որոնք խափանվում են հրապարակումից անմիջապես հետո։ Եթե հրապարակումը ձախողվում է քո կողմից, տես հրապարակման խնդիրների լուծումը փաստաթղթերում։