Հաճախորդի հարթակում շարունակական տեղակայման մեր իրականացումը

Մենք True Engineering-ում ստեղծել ենք հաճախորդների սերվերներին թարմացումների շարունակական առաքման գործընթաց և ցանկանում ենք կիսվել այս փորձով:

Սկզբից մենք մշակեցինք առցանց համակարգ հաճախորդի համար և այն տեղակայեցինք մեր սեփական Kubernetes կլաստերում: Այժմ մեր բարձր բեռի լուծումը տեղափոխվել է հաճախորդի հարթակ, որի համար մենք ստեղծել ենք լիովին ավտոմատ շարունակական տեղակայման գործընթաց: Դրա շնորհիվ մենք արագացրեցինք շուկայական ժամանակը՝ ապրանքի միջավայրում փոփոխությունների առաքումը:

Այս հոդվածում մենք կխոսենք Continuous Deployment (CD) գործընթացի կամ հաճախորդի հարթակ թարմացումների առաքման բոլոր փուլերի մասին.

1. Ինչպե՞ս է սկսվում այս գործընթացը:
2. համաժամացում հաճախորդի Git պահեստի հետ,
3. հետնամասի և ճակատային մասի հավաքում,
4. հավելվածի ավտոմատ տեղակայում թեստային միջավայրում,
5. ավտոմատ տեղակայում Արդ.

Մենք կկիսվենք տեղադրման մանրամասներով ճանապարհին:

1. Սկսեք CD-ն

Շարունակական տեղակայումը սկսվում է այն բանից, որ մշակողը փոփոխություններ է կատարում մեր Git պահեստի թողարկման մասնաճյուղում:

Մեր հավելվածն աշխատում է միկրոսերվիսային ճարտարապետությամբ, և դրա բոլոր բաղադրիչները պահվում են մեկ պահեստում: Դրա շնորհիվ հավաքվում և տեղադրվում են բոլոր միկրոծառայությունները, նույնիսկ եթե դրանցից մեկը փոխվել է:

Մենք աշխատանքը կազմակերպել ենք մեկ պահեստի միջոցով մի քանի պատճառով.

• Մշակման հեշտություն - հավելվածն ակտիվորեն զարգանում է, այնպես որ կարող եք միանգամից աշխատել բոլոր կոդերի հետ:
• Մեկ CI/CD խողովակաշար, որը երաշխավորում է, որ հավելվածը որպես միասնական համակարգ անցնում է բոլոր թեստերը և առաքվում է հաճախորդի արտադրական միջավայր:
• Մենք վերացնում ենք տարբերակների շփոթությունը. մենք պարտավոր չենք պահպանել միկրոսերվիսների տարբերակների քարտեզը և նկարագրել դրա կոնֆիգուրացիան յուրաքանչյուր միկրոծառայության համար Helm սկրիպտներում:

2. Համաժամացում հաճախորդի ելակետային կոդի Git պահոցի հետ

Կատարված փոփոխությունները ավտոմատ կերպով համաժամացվում են հաճախորդի Git պահոցի հետ: Այնտեղ կազմաձևվում է հավելվածի ժողովը, որը գործարկվում է մասնաճյուղը թարմացնելուց հետո և տեղակայվում է շարունակություն: Երկու գործընթացներն էլ ծագում են իրենց միջավայրում Git պահեստից:

Մենք չենք կարող ուղղակիորեն աշխատել հաճախորդի պահեստի հետ, քանի որ մշակման և փորձարկման համար մեզ անհրաժեշտ են մեր սեփական միջավայրերը: Մենք օգտագործում ենք մեր Git պահոցը այս նպատակների համար. այն համաժամանակացված է նրանց Git պահոցի հետ: Հենց որ ծրագրավորողը փոփոխություններ է հրապարակում մեր պահեստի համապատասխան մասնաճյուղում, GitLab-ն անմիջապես այդ փոփոխությունները մղում է հաճախորդին:

Դրանից հետո դուք պետք է հավաքեք: Այն բաղկացած է մի քանի փուլից՝ հետնամասի և ճակատային մասի հավաքում, փորձարկում և առաքում արտադրության:

3. Հետևի և ճակատային մասի հավաքում

Backend-ի և frontend-ի կառուցումը երկու զուգահեռ առաջադրանքներ են, որոնք կատարվում են GitLab Runner համակարգում: Դրա սկզբնական հավաքման կոնֆիգուրացիան գտնվում է նույն պահեստում:

GitLab-ում կառուցելու համար YAML սցենար գրելու ձեռնարկ.

GitLab Runner-ը վերցնում է կոդը անհրաժեշտ պահոցից, այն հավաքում Java հավելվածի կառուցման հրամանով և ուղարկում Docker ռեեստր։ Այստեղ մենք հավաքում ենք հետնամասը և ճակատը, ստանում Docker պատկերներ, որոնք մենք դնում ենք հաճախորդի կողմից գտնվող պահեստում: Docker պատկերները կառավարելու համար մենք օգտագործում ենք Gradle plugin.

Մենք համաժամացնում ենք մեր պատկերների տարբերակները թողարկման տարբերակի հետ, որը կհրապարակվի Docker-ում: Անխափան աշխատանքի համար մենք կատարել ենք մի քանի ճշգրտումներ.

1. Բեռնարկղերը չեն վերակառուցվում փորձարկման միջավայրի և արտադրական միջավայրի միջև: Մենք պարամետրիզացիաներ արեցինք, որպեսզի նույն կոնտեյները կարողանա աշխատել բոլոր կարգավորումների, շրջակա միջավայրի փոփոխականների և ծառայությունների հետ ինչպես փորձարկման միջավայրում, այնպես էլ արտադրության մեջ՝ առանց վերակառուցման:

2. Հավելվածը Helm-ի միջոցով թարմացնելու համար պետք է նշեք դրա տարբերակը: Մենք կառուցում ենք backend-ը, frontend-ը և թարմացնում հավելվածը. դրանք երեք տարբեր առաջադրանքներ են, ուստի կարևոր է ամենուր օգտագործել հավելվածի նույն տարբերակը: Այս առաջադրանքի համար մենք օգտագործում ենք տվյալներ Git պատմությունից, քանի որ մեր K8S կլաստերի կազմաձևումը և հավելվածները գտնվում են նույն Git պահոցում:

Մենք ստանում ենք հավելվածի տարբերակը հրամանի կատարման արդյունքներից
git describe --tags --abbrev=7.

4. Փորձարկման միջավայրում բոլոր փոփոխությունների ավտոմատ տեղակայում (UAT)

Այս կառուցման սցենարի հաջորդ քայլը K8S կլաստերի ավտոմատ թարմացումն է: Դա տեղի է ունենում պայմանով, որ ամբողջ հավելվածը կառուցված է, և բոլոր արտեֆակտները հրապարակված են Docker Registry-ում: Դրանից հետո սկսվում է թեստային միջավայրի թարմացումը:

Կլաստերի թարմացումը սկսվում է օգտագործել Սաղավարտի թարմացում. Եթե ​​արդյունքում ինչ-որ բան չընթանա ըստ պլանի, ապա Helm-ը ինքնաբերաբար և ինքնուրույն կվերադարձնի իր բոլոր փոփոխությունները: Նրա աշխատանքը վերահսկելու կարիք չունի։

Մենք տրամադրում ենք K8S կլաստերի կոնֆիգուրացիան հավաքման հետ միասին: Հետևաբար, հաջորդ քայլը այն թարմացնելն է. configMaps, տեղակայումներ, ծառայություններ, գաղտնիքներ և ցանկացած այլ K8S կոնֆիգուրացիաներ, որոնք մենք փոխել ենք:

Այնուհետև Helm-ը փորձարկման միջավայրում գործարկում է հավելվածի RollOut թարմացումը: Նախքան հավելվածը արտադրություն կտեղակայվի: Սա արվում է, որպեսզի օգտվողները կարողանան ձեռքով փորձարկել բիզնեսի հնարավորությունները, որոնք մենք դնում ենք փորձարկման միջավայրում:

5. Բոլոր փոփոխությունների ավտոմատ տեղակայում Արդ

Արտադրական միջավայրում թարմացում տեղադրելու համար պարզապես անհրաժեշտ է սեղմել մեկ կոճակ GitLab-ում, և բեռնարկղերը անմիջապես առաքվում են արտադրական միջավայր:

Նույն հավելվածը կարող է աշխատել տարբեր միջավայրերում՝ թեստային և արտադրական, առանց վերակառուցման: Մենք օգտագործում ենք նույն արտեֆակտները՝ հավելվածում ոչինչ չփոխելով, իսկ պարամետրերը դրսից ենք սահմանում։

Հավելվածի պարամետրերի ճկուն պարամետրացումը կախված է այն միջավայրից, որտեղ կիրառվելու է ծրագիրը: Մենք արտաքին միջավայրի բոլոր կարգավորումները տեղափոխել ենք. ամեն ինչ պարամետրացված է K8S կոնֆիգուրացիայի և Helm պարամետրերի միջոցով: Երբ Helm-ը հավաքում է փորձարկման միջավայրում, փորձարկման կարգավորումները կիրառվում են դրա վրա, իսկ արտադրանքի կարգավորումները՝ արտադրական միջավայրում:

Ամենադժվարը եղել է բոլոր օգտագործված ծառայություններն ու փոփոխականները, որոնք կախված են միջավայրից, պարամետրիզացնելը և դրանք վերածել շրջակա միջավայրի փոփոխականների և շրջակա միջավայրի պարամետրերի նկարագրություն-կոնֆիգուրացիաների Helm-ի համար:

Հավելվածի կարգավորումները օգտագործում են շրջակա միջավայրի փոփոխականներ: Դրանց արժեքները դրված են բեռնարկղերում՝ օգտագործելով K8S configmap, որը ձևավորվում է Go կաղապարների միջոցով: Օրինակ, դոմենի անվան համար շրջակա միջավայրի փոփոխական սահմանելը կարող է կատարվել այսպես.

APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}

.Values.global.env – այս փոփոխականը պահպանում է միջավայրի անվանումը (prod, stage, UAT):
.Values.app.properties.app_external_domain – այս փոփոխականում մենք սահմանել ենք ցանկալի տիրույթը .Values.yaml ֆայլում

Հավելվածը թարմացնելիս Helm-ը ձևանմուշներից ստեղծում է configmap.yaml ֆայլ և լրացնում է APP_EXTERNAL_DOMAIN արժեքը ցանկալի արժեքով՝ կախված այն միջավայրից, որտեղ սկսվում է հավելվածի թարմացումը: Այս փոփոխականն արդեն դրված է կոնտեյներով: Այն կարելի է մուտք գործել հավելվածից, ուստի յուրաքանչյուր հավելվածի միջավայր այս փոփոխականի համար տարբեր արժեք կունենա:

Համեմատաբար վերջերս, K8S աջակցությունը հայտնվեց Spring Cloud-ում, ներառյալ աշխատանքը configMaps-ի հետ. Գարնանային ամպ Kubernetes. Մինչ նախագիծն ակտիվորեն զարգանում և արմատապես փոխվում է, մենք չենք կարող այն օգտագործել արտադրության մեջ։ Բայց մենք ակտիվորեն վերահսկում ենք դրա վիճակը և օգտագործում այն ​​DEV կոնֆիգուրացիաներում: Հենց որ այն կայունանա, մենք շրջակա միջավայրի փոփոխականների օգտագործումից կանցնենք դրան:

Ընդհանուր

Այսպիսով, Continuous Deployment-ը կազմաձևված է և աշխատում է: Բոլոր թարմացումները տեղի են ունենում մեկ ստեղնաշարով: Արտադրանքի միջավայրում փոփոխությունների առաքումն ավտոմատ է: Եվ, որ կարևոր է, թարմացումները չեն կանգնեցնում համակարգը։

Ապագա պլաններ. տվյալների բազայի ավտոմատ միգրացիա

Մենք մտածեցինք տվյալների բազայի թարմացման և այս փոփոխությունները հետաձգելու հնարավորության մասին: Ի վերջո, միաժամանակ աշխատում են հավելվածի երկու տարբեր տարբերակներ՝ հինն է աշխատում, իսկ նորը՝ գործարկված: Իսկ հինը կանջատենք միայն այն ժամանակ, երբ վստահ լինենք, որ նոր տարբերակը աշխատում է։ Տվյալների բազայի միգրացիան պետք է թույլ տա ձեզ աշխատել հավելվածի երկու տարբերակների հետ:

Հետևաբար, մենք չենք կարող պարզապես փոխել սյունակի անվանումը կամ այլ տվյալներ: Բայց մենք կարող ենք ստեղծել նոր սյունակ, պատճենել տվյալները հին սյունակից և գրել գործարկիչներ, որոնք տվյալները թարմացնելիս միաժամանակ պատճենելու և թարմացնելու են այն մեկ այլ սյունակում: Իսկ հավելվածի նոր տարբերակի հաջող տեղակայումից հետո, հետգործարկման աջակցության շրջանից հետո, մենք կկարողանանք ջնջել հին սյունակը և ավելորդ դարձած ձգանը:

Եթե ​​հավելվածի նոր տարբերակը ճիշտ չի աշխատում, մենք կարող ենք վերադառնալ նախորդ տարբերակին, ներառյալ տվյալների բազայի նախորդ տարբերակը: Մի խոսքով, մեր փոփոխությունները թույլ կտան միաժամանակ աշխատել հավելվածի մի քանի տարբերակների հետ։

Մենք նախատեսում ենք ավտոմատացնել տվյալների բազայի միգրացիան K8S աշխատանքի միջոցով՝ ինտեգրելով այն CD գործընթացին: Եվ այս փորձը մենք անպայման կկիսվենք Habré-ում:

Source: www.habr.com