Բարեւ բոլորին! Ես Պավել Ագալեցկին եմ։ Ես աշխատում եմ որպես թիմի ղեկավար մի թիմում, որը մշակում է Lamoda առաքման համակարգը: 2018 թվականին ես ելույթ ունեցա HighLoad++ կոնֆերանսում, և այսօր ուզում եմ ներկայացնել իմ զեկույցի սղագրությունը։

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

Հավելվածների տեղակայում VM-ում

Սկսենք նրանից, որ 3 տարի առաջ ընկերության բոլոր համակարգերն ու ծառայությունները տեղադրվեցին սովորական վիրտուալ սերվերների վրա: Տեխնիկապես այն կազմակերպված էր այնպես, որ մեր համակարգերի բոլոր ծածկագրերը պահվում և հավաքվում էին ավտոմատ հավաքման գործիքների միջոցով՝ օգտագործելով ջենկիններ: Օգտագործելով Ansible-ը, այն տարածվեց մեր տարբերակների կառավարման համակարգից դեպի վիրտուալ սերվերներ: Ավելին, մեր ընկերության յուրաքանչյուր համակարգ տեղակայվել է առնվազն 2 սերվերի վրա՝ մեկը գլխին, երկրորդը՝ պոչում։ Այս երկու համակարգերը բացարձակապես նույնական էին միմյանց հետ իրենց բոլոր պարամետրերով, հզորությամբ, կոնֆիգուրացիայով և այլն: Նրանց միջև միակ տարբերությունն այն էր, որ գլուխը ստանում էր օգտատերերի տրաֆիկ, մինչդեռ պոչը երբեք չէր ստանում օգտվողի տրաֆիկ:

Ինչու՞ դա արվեց:

Երբ մենք տեղադրեցինք մեր հավելվածի նոր թողարկումները, մենք ցանկանում էինք ապահովել անխափան տարածում, այսինքն՝ առանց նկատելի հետևանքների օգտատերերի համար: Սա ձեռք բերվեց այն փաստի շնորհիվ, որ Ansible-ի օգտագործմամբ հաջորդ կազմված թողարկումը դուրս եկավ մինչև պոչը: Այնտեղ մարդիկ, ովքեր ներգրավված էին տեղակայման մեջ, կարող էին ստուգել և համոզվել, որ ամեն ինչ լավ է. բոլոր չափումները, բաժինները և հավելվածները աշխատում էին. գործարկվում են անհրաժեշտ սցենարները։ Միայն այն բանից հետո, երբ համոզվեցին, որ ամեն ինչ կարգին է, երթեւեկությունը փոխվեց։ Այն սկսեց գնալ դեպի սերվեր, որը նախկինում պոչ էր: Իսկ այն, որը նախկինում ղեկավարն էր, մնաց առանց օգտատերերի տրաֆիկի, մինչդեռ դրա վրա դեռ կա մեր հավելվածի նախորդ տարբերակը։

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

Ի՞նչ առավելություններ տեսանք այս ամենում։

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

Բայց այս ամենում մենք տեսանք նաև մի քանի թերություններ.

1. Բացի արտադրական միջավայրից, զարգացման միջավայրից, կան այլ միջավայրեր։ Օրինակ՝ qa և preproduction։ Այն ժամանակ մենք ունեինք բազմաթիվ սերվերներ և մոտ 60 ծառայություն։ Այս պատճառով անհրաժեշտ էր յուրաքանչյուր ծառայության համար պահպանեք վերջին տարբերակը դրա համար վիրտուալ մեքենա. Ավելին, եթե ցանկանում եք թարմացնել գրադարանները կամ տեղադրել նոր կախվածություններ, դուք պետք է դա անեք բոլոր միջավայրերում: Ձեզ անհրաժեշտ էր նաև համաժամեցնել այն ժամանակը, երբ դուք պատրաստվում եք տեղադրել ձեր հավելվածի հաջորդ նոր տարբերակը այն ժամանակի հետ, երբ devops-ը կատարում է անհրաժեշտ միջավայրի կարգավորումները: Այս դեպքում հեշտ է հայտնվել մի իրավիճակում, երբ մեր միջավայրը բոլոր միջավայրերում միանգամից որոշակիորեն տարբեր կլինի։ Օրինակ՝ QA միջավայրում կլինեն գրադարանների որոշ տարբերակներ, իսկ արտադրական միջավայրում՝ տարբեր, ինչը կբերի խնդիրների։
2. Կախվածությունները թարմացնելու դժվարություն ձեր դիմումը. Դա կախված է ոչ թե քեզանից, այլ մյուս թիմից։ Մասնավորապես, devops թիմից, որը սպասարկում է սերվերները: Դուք պետք է նրանց համապատասխան առաջադրանք տաք և նկարագրեք, թե ինչ եք ուզում անել:
3. Այն ժամանակ մեր ունեցած մեծ խոշոր մոնոլիտները նույնպես ուզում էինք բաժանել առանձին փոքր ծառայությունների, քանի որ հասկանում էինք, որ դրանք շատանալու են։ Այն ժամանակ մենք արդեն ունեինք դրանցից ավելի քան 100-ը, յուրաքանչյուր նոր ծառայության համար անհրաժեշտ էր ստեղծել առանձին նոր վիրտուալ մեքենա, որը նույնպես պետք է պահպանվեր և գործարկվեր։ Բացի այդ, ձեզ հարկավոր է ոչ թե մեկ մեքենա, այլ առնվազն երկու: Այս ամենին գումարվում է QA միջավայրը։ Սա խնդիրներ է առաջացնում և ձեզ համար ավելի դժվարացնում նոր համակարգեր ստեղծելն ու գործարկելը: բարդ, թանկ և երկարատև գործընթաց:

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

Մենք երկար մտածեցինք, թե որ մեկը կարող ենք վերցնել։ Փաստն այն է, որ այն ժամանակ սովորական վիրտուալ սերվերների վրա տեղակայման այս կույտը որոշ չափով հնացած էր, քանի որ նրանք չունեին օպերացիոն համակարգերի վերջին տարբերակները: Ինչ-որ պահի նույնիսկ FreeBSD կար, որն այնքան էլ հարմար չէր աջակցելու համար։ Մենք հասկացանք, որ պետք է հնարավորինս արագ տեղափոխվենք դոկեր: Մեր devop-ները նայեցին իրենց առկա փորձին տարբեր լուծումներով և ընտրեցին Nomad-ի նման համակարգը:

Անցեք Nomad-ին

Nomad-ը HashiCorp-ի արտադրանքն է: Նրանք հայտնի են նաև իրենց այլ լուծումներով.

«Հյուպատոս» ծառայության հայտնաբերման գործիք է:

«Տեռաֆորմ» - սերվերների կառավարման համակարգ, որը թույլ է տալիս կարգավորել դրանք կոնֆիգուրացիայի միջոցով, այսպես կոչված, ենթակառուցվածքը որպես կոդ:

«Բոմժ» թույլ է տալիս տեղակայել վիրտուալ մեքենաներ տեղական կամ ամպի մեջ հատուկ կազմաձևման ֆայլերի միջոցով:

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

Ի՞նչ է ձեզ անհրաժեշտ՝ ձեր համակարգը Nomad-ում տեղակայելու համար:

1. Առաջին հերթին ձեզ հարկավոր է դոկերի պատկեր ձեր դիմումը. Դուք պետք է այն կառուցեք և տեղադրեք դոկերի պատկերների պահոցում: Մեր դեպքում սա արհեստագործական է. համակարգ, որը թույլ է տալիս դրա մեջ մղել տարբեր տեսակի արտեֆակտներ: Այն կարող է պահել արխիվներ, դոկերի պատկերներ, կոմպոզիտորական PHP փաթեթներ, NPM փաթեթներ և այլն:
2. Նաև անհրաժեշտ է կազմաձևման ֆայլ, որը կպատմի Nomad-ին, թե ինչ, որտեղ և ինչ քանակությամբ եք ուզում տեղակայել:

Երբ մենք խոսում ենք Nomad-ի մասին, այն օգտագործում է HCL լեզուն որպես տեղեկատվական ֆայլի ձևաչափ, որը նշանակում է HashiCorp-ի կազմաձևման լեզու. Սա Yaml-ի գերկոմպլեկտ է, որը թույլ է տալիս նկարագրել ձեր ծառայությունը Nomad-ի տերմիններով:

Այն թույլ է տալիս ասել, թե քանի կոնտեյներ եք ուզում տեղակայել, որոնցից պատկերները տեղակայման ընթացքում տարբեր պարամետրեր փոխանցել նրանց: Այսպիսով, դուք կերակրում եք այս ֆայլը Nomad-ին, և այն թողարկում է կոնտեյներներ՝ ըստ դրա:

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

Հետևաբար, մենք որոշեցինք, որ մեզ համար հարմար կլինի տեղադրել մեր բոլոր կազմաձևման ֆայլերը մեկ ընդհանուր պահոցում տեղակայելու համար: Այս կերպ դրանք տեսանելի էին. դրանք հեշտ էր պահպանել, և մենք կարող էինք տեսնել, թե ինչ համակարգեր ունենք: Անհրաժեշտության դեպքում հեշտ է նաև ինչ-որ բան թարմացնել կամ փոխել: Նոր համակարգ ավելացնելը նույնպես դժվար չէ. պարզապես անհրաժեշտ է ստեղծել կոնֆիգուրացիայի ֆայլ նոր գրացուցակի ներսում: Դրա ներսում կան հետևյալ ֆայլերը՝ service.hcl, որը պարունակում է մեր ծառայության նկարագրությունը, և որոշ env ֆայլեր, որոնք թույլ են տալիս կարգավորել հենց այս ծառայությունը, որը տեղակայվում է արտադրության մեջ:

Այնուամենայնիվ, մեր որոշ համակարգեր արտադրվում են ոչ թե մեկ օրինակով, այլ միանգամից մի քանի օրինակով: Հետևաբար, մենք որոշեցինք, որ մեզ համար հարմար կլինի պահպանել ոչ թե կոնֆիգուրները իրենց մաքուր ձևով, այլ կաղապարային տեսքով: Եվ մենք ընտրեցինք ջինջա 2. Այս ձևաչափով մենք պահում ենք ինչպես ծառայության կոնֆիգուրացիաները, այնպես էլ դրա համար անհրաժեշտ env ֆայլերը:

Բացի այդ, մենք պահեստում տեղադրել ենք տեղակայման սցենար, որը ընդհանուր է բոլոր նախագծերի համար, որը թույլ է տալիս գործարկել և տեղակայել ձեր ծառայությունը արտադրության մեջ, ցանկալի միջավայրում, ցանկալի թիրախում: Այն դեպքում, երբ մենք մեր HCL կոնֆիգուրը վերածեցինք կաղապարի, ապա HCL ֆայլը, որը նախկինում Nomad-ի սովորական կոնֆիգուրացիա էր, այս դեպքում սկսեց մի փոքր այլ տեսք ունենալ։

Այսինքն՝ մենք փոխարինեցինք որոշ կոնֆիգուրացիայի տեղակայման փոփոխականներ փոփոխական ներդիրներով, որոնք վերցված են env ֆայլերից կամ այլ աղբյուրներից։ Բացի այդ, մենք հնարավորություն ստացանք դինամիկ կերպով հավաքել HCL ֆայլերը, այսինքն՝ կարող ենք օգտագործել ոչ միայն սովորական փոփոխական ներդիրները։ Քանի որ jinja-ն աջակցում է հանգույցներ և պայմաններ, դուք կարող եք նաև այնտեղ ստեղծել կազմաձևման ֆայլեր, որոնք փոխվում են՝ կախված նրանից, թե կոնկրետ որտեղ եք տեղադրում ձեր հավելվածները:

Օրինակ, դուք ցանկանում եք տեղակայել ձեր ծառայությունը նախնական արտադրության և արտադրության վրա: Ենթադրենք, որ նախնական արտադրության ժամանակ դուք չեք ցանկանում գործարկել cron սկրիպտները, այլ պարզապես ցանկանում եք տեսնել ծառայությունը առանձին տիրույթում, որպեսզի համոզվեք, որ այն գործում է: Յուրաքանչյուրի համար, ով տեղակայում է ծառայությունը, գործընթացը շատ պարզ և թափանցիկ է թվում: Ձեզ անհրաժեշտ է ընդամենը գործարկել deploy.sh ֆայլը, նշել, թե որ ծառայությունն եք ցանկանում տեղակայել և որ թիրախին: Օրինակ, դուք ցանկանում եք որոշակի համակարգ տեղակայել Ռուսաստանում, Բելառուսում կամ Ղազախստանում: Դա անելու համար պարզապես փոխեք պարամետրերից մեկը, և դուք կունենաք ճիշտ կազմաձևման ֆայլ:

Երբ Nomad ծառայությունն արդեն տեղակայված է ձեր կլաստերում, այն այսպիսի տեսք ունի.

Նախ, ձեզ հարկավոր է դրսում ինչ-որ հավասարակշռող, որը կստանա օգտատերերի ամբողջ տրաֆիկը: Այն կաշխատի հյուպատոսի հետ և դրանից կպարզի, թե որտեղ, որ հանգույցի վրա, որ IP հասցեում է գտնվում կոնկրետ ծառայությունը, որը համապատասխանում է որոշակի տիրույթի անվանմանը: Հյուպատոսում ծառայությունները գալիս են հենց Nomad-ից: Քանի որ դրանք միևնույն ընկերության արտադրանք են, դրանք բավականին կապված են միմյանց հետ: Կարելի է ասել, որ Nomad out of the box-ը կարող է գրանցել իր մեջ գործարկված բոլոր ծառայությունները հյուպատոսի ներսում։

Երբ ձեր առջևի բեռի հավասարակշռիչը գիտի, թե որ ծառայությանը պետք է ուղարկի երթևեկությունը, այն ուղարկում է համապատասխան կոնտեյներ կամ բազմաթիվ բեռնարկղեր, որոնք համապատասխանում են ձեր հավելվածին: Բնականաբար, պետք է մտածել նաև անվտանգության մասին։ Թեև բոլոր ծառայություններն աշխատում են բեռնարկղերի նույն վիրտուալ մեքենաների վրա, դա սովորաբար պահանջում է կանխել ցանկացած ծառայությունից որևէ այլ ծառայություն անվճար մուտքը: Մենք դրան հասել ենք սեգմենտացիայի միջոցով: Յուրաքանչյուր ծառայություն գործարկվել է իր սեփական վիրտուալ ցանցում, որի վրա սահմանվել են երթուղային կանոններ և այլ համակարգեր և ծառայություններ մուտքի թույլտվություն/մերժման կանոններ: Նրանք կարող էին տեղակայվել ինչպես այս կլաստերի ներսում, այնպես էլ դրանից դուրս: Օրինակ, եթե ցանկանում եք կանխել ծառայության միացումը կոնկրետ տվյալների բազայի հետ, դա կարելի է անել ցանցի մակարդակի սեգմենտավորման միջոցով: Այսինքն, նույնիսկ սխալմամբ, դուք չեք կարող պատահաբար միանալ թեստային միջավայրից ձեր արտադրության տվյալների բազայի հետ:

Որքա՞ն արժեցավ անցումը մեզ մարդկային ռեսուրսների առումով։

Ամբողջ ընկերության անցումը Nomad-ին տևեց մոտավորապես 5-6 ամիս: Մենք շարժվեցինք ծառայություն առ ծառայություն, բայց բավականին արագ տեմպերով: Յուրաքանչյուր թիմ պետք է ստեղծեր իր բեռնարկղերը ծառայությունների համար:

Մենք որդեգրել ենք այնպիսի մոտեցում, որ յուրաքանչյուր թիմ ինքնուրույն է պատասխանատու իր համակարգերի դոկեր պատկերների համար: Devops-ն ապահովում է տեղակայման համար անհրաժեշտ ընդհանուր ենթակառուցվածքը, այսինքն՝ աջակցություն բուն կլաստերին, աջակցություն CI համակարգին և այլն։ Իսկ այն ժամանակ մենք ունեինք «Նոմադ» տեղափոխված ավելի քան 60 համակարգ, որը կազմում էր մոտ 2 հազար կոնտեյներ։

Devops-ը պատասխանատու է տեղակայման և սերվերների հետ կապված ամեն ինչի ընդհանուր ենթակառուցվածքի համար: Եվ յուրաքանչյուր մշակող թիմ, իր հերթին, պատասխանատու է իր կոնկրետ համակարգի համար բեռնարկղերի ներդրման համար, քանի որ թիմն է, որ գիտի, թե իրեն ընդհանրապես ինչ է պետք կոնկրետ կոնտեյներով:

Nomad-ից հրաժարվելու պատճառները

Ի՞նչ առավելություններ ստացանք՝ ի թիվս այլոց, Nomad-ի և docker-ի միջոցով տեղակայման անցնելով:

1. Մենք ապահովել հավասար պայմաններ բոլոր միջավայրերի համար։ Մշակման մեջ օգտագործվում են QA միջավայր, նախաարտադրություն, արտադրություն, նույն կոնտեյների պատկերները՝ նույն կախվածություններով։ Համապատասխանաբար, դուք գործնականում ոչ մի հնարավորություն չունեք, որ այն, ինչ կավարտվի արտադրության մեջ, այն չէ, ինչ դուք նախկինում փորձարկել եք տեղական կամ ձեր փորձարկման միջավայրում:
2. Մենք էլ գտանք, որ բավական է հեշտ է ավելացնել նոր ծառայություն. Տեղակայման տեսանկյունից ցանկացած նոր համակարգ գործարկվում է շատ պարզ: Պարզապես գնացեք կոնֆիգուրացիաներ պահող պահոց, այնտեղ ավելացրեք ձեր համակարգի մեկ այլ կոնֆիգուրացիա, և ամեն ինչ պատրաստ է: Դուք կարող եք ձեր համակարգը տեղակայել արտադրության մեջ՝ առանց devops-ի հավելյալ ջանքերի:
3. Բոլորը կազմաձևման ֆայլեր մեկ ընդհանուր պահոցում պարզվեց, որ գտնվում է վերանայման փուլում. Այն ժամանակ, երբ մենք տեղակայում էինք մեր համակարգերը՝ օգտագործելով վիրտուալ սերվերներ, մենք օգտագործում էինք Ansible-ը, որի կազմաձևերը գտնվում էին նույն պահեստում: Այնուամենայնիվ, մշակողների մեծամասնության համար սա մի փոքր ավելի դժվար էր աշխատել: Այստեղ կոնֆիգուրացիաների և կոդի ծավալը, որը դուք պետք է ավելացնեք ծառայությունը գործարկելու համար, դարձել է շատ ավելի փոքր: Բացի այդ, devops-ի համար շատ հեշտ է ուղղել կամ փոխել այն: Անցումների դեպքում, օրինակ, Nomad-ի նոր տարբերակի, նրանք կարող են վերցնել և զանգվածաբար թարմացնել նույն տեղում գտնվող բոլոր օպերացիոն ֆայլերը։

Բայց մենք հանդիպեցինք նաև մի քանի թերությունների.

Պարզվեց, որ մենք չկարողացավ հասնել անխափան տեղակայման Nomad-ի դեպքում. Տարբեր պայմաններում բեռնարկղեր գլորելիս այն կարող էր պարզվել, որ այն աշխատում է, և Nomad-ն այն ընկալում էր որպես երթևեկություն ընդունելու պատրաստ կոնտեյներ: Դա տեղի է ունեցել նախքան դրա ներսում հավելվածն անգամ գործարկվելու հնարավորություն ուներ: Այդ պատճառով համակարգը կարճ ժամանակահատվածում սկսեց արտադրել 500 սխալ, քանի որ երթևեկությունը սկսեց գնալ դեպի կոնտեյներ, որը դեռ պատրաստ չէր ընդունել այն:

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

Այսպիսով, մենք որոշեցինք մտածել, թե ուր պետք է գնանք հաջորդը: Այդ պահին մենք շատ ավելի գիտակցեցինք, թե ինչի ենք ուզում հասնել: Այսինքն՝ մենք ցանկանում ենք հուսալիություն, մի փոքր ավելի շատ գործառույթներ, քան տրամադրում է Nomad-ը, և ավելի հասուն, ավելի կայուն համակարգ:

Այս առումով մեր ընտրությունը ընկավ Kubernetes-ի վրա՝ որպես կլաստերներ գործարկելու ամենատարածված հարթակ: Հատկապես հաշվի առնելով, որ մեր բեռնարկղերի չափերն ու քանակը բավականաչափ մեծ էին: Նման նպատակների համար Kubernetes-ը թվում էր ամենահարմար համակարգը, որին մենք կարող էինք նայել:

Անցում դեպի Kubernetes

Ես ձեզ մի փոքր կպատմեմ Kubernetes-ի հիմնական հասկացությունների մասին և ինչպես են դրանք տարբերվում Nomad-ից:

Առաջին հերթին, Kubernetes-ի ամենահիմնական հայեցակարգը pod հասկացությունն է: Պատիճ մեկ կամ մի քանի բեռնարկղերի խումբ է, որոնք միշտ աշխատում են միասին: Եվ նրանք միշտ աշխատում են այնպես, կարծես խստորեն մեկ վիրտուալ մեքենայի վրա: Նրանք միմյանց հասանելի են տարբեր նավահանգիստների IP 127.0.0.1-ի միջոցով:

Ենթադրենք, որ դուք ունեք PHP հավելված, որը բաղկացած է nginx-ից և php-fpm-ից՝ դասական սխեմայով: Ամենայն հավանականությամբ, դուք կցանկանաք միշտ միասին պահել ինչպես nginx, այնպես էլ php-fpm կոնտեյներները: Kubernetes-ը թույլ է տալիս հասնել դրան՝ դրանք նկարագրելով որպես մեկ ընդհանուր պատիճ: Սա հենց այն է, ինչ մենք չկարողացանք ստանալ Nomad-ի հետ:

Երկրորդ հայեցակարգն է տեղակայումը. Փաստն այն է, որ պատիճն ինքնին անցողիկ բան է, այն սկսվում և անհետանում է: Ցանկանու՞մ եք նախ սպանել ձեր բոլոր նախորդ կոնտեյներները, այնուհետև միանգամից գործարկել նոր տարբերակները, թե՞ ցանկանում եք դրանք աստիճանաբար դուրս բերել: Սա այն գործընթացն է, որի համար պատասխանատու է տեղակայման հայեցակարգը: Այն նկարագրում է, թե ինչպես եք տեղադրում ձեր պատյանները, ինչ քանակությամբ և ինչպես թարմացնել դրանք:

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

Եվ չորրորդ հիմնական հայեցակարգն է Մուտք. Սա ծառայություն է, որն աշխատում է Kubernetes կլաստերի վրա: Այն գործում է որպես արտաքին բեռի հավասարակշռող, որն ընդունում է բոլոր հարցումները: Օգտագործելով Kubernetes API-ը, Ingress-ը կարող է որոշել, թե որտեղ պետք է ուղարկվեն այդ հարցումները: Ավելին, նա դա անում է շատ ճկուն։ Կարելի է ասել, որ այս հոսթին և այսինչ URL-ին ուղղված բոլոր հարցումներն ուղարկվում են այս ծառայությանը: Եվ այս հարցումները, որոնք գալիս են այս հոսթին և մեկ այլ URL, ուղարկվում են մեկ այլ ծառայության:

Ամենաթեժ բանը հավելված մշակողի տեսանկյունից այն է, որ դուք ինքներդ կարող եք կառավարել այդ ամենը։ Կարգավորելով Ingress-ի կազմաձևը՝ դուք կարող եք ուղարկել այս կամ այն ​​API-ին եկող ամբողջ տրաֆիկը առանձին կոնտեյներներ, որոնք գրված են, օրինակ, Go-ում: Բայց այս տրաֆիկը, որը գալիս է նույն տիրույթ, բայց այլ URL, պետք է ուղարկել PHP-ով գրված կոնտեյներներ, որտեղ շատ տրամաբանություն կա, բայց դրանք այնքան էլ արագ չեն։

Եթե ​​այս բոլոր հասկացությունները համեմատենք Nomad-ի հետ, ապա կարող ենք ասել, որ առաջին երեք հասկացությունները բոլորը միասին Ծառայություն են: Իսկ վերջին հայեցակարգը բացակայում է բուն Nomad-ում։ Մենք օգտագործել ենք արտաքին հավասարակշռող սարք՝ այն կարող է լինել հապրոքսի, nginx, nginx+ և այլն: Խորանարդի դեպքում այս լրացուցիչ հայեցակարգը պետք չէ առանձին ներկայացնել։ Այնուամենայնիվ, եթե ներքուստ նայեք Ingress-ին, այն կա՛մ nginx է, կա՛մ հապրոքսի, կա՛մ traefik, բայց մի տեսակ ներկառուցված է Kubernetes-ում:

Իմ նկարագրած բոլոր հասկացությունները, ըստ էության, ռեսուրսներ են, որոնք գոյություն ունեն Kubernetes կլաստերի ներսում: Դրանք խորանարդի մեջ նկարագրելու համար օգտագործվում է yaml ֆորմատ, որն ավելի ընթեռնելի և ծանոթ է, քան HCL ֆայլերը Nomad-ի դեպքում։ Բայց կառուցվածքային առումով նույն բանն են նկարագրում, օրինակ, պատիճի դեպքում։ Ասում են՝ ես ուզում եմ այնտեղ տեղակայել այսինչ պատիճները՝ այսինչ պատկերներով, այսինչ քանակությամբ։

Բացի այդ, մենք հասկացանք, որ չենք ցանկանում ձեռքով ստեղծել յուրաքանչյուր առանձին ռեսուրս՝ տեղակայում, ծառայություններ, Ingress և այլն: Փոխարենը, մենք ցանկանում էինք նկարագրել մեր համակարգերից յուրաքանչյուրը Kubernetes-ով տեղակայման ժամանակ, որպեսզի մենք ստիպված չլինենք ձեռքով վերստեղծել բոլոր անհրաժեշտ ռեսուրսների կախվածությունը ճիշտ հերթականությամբ: Հելմը ընտրվեց որպես համակարգ, որը թույլ տվեց մեզ դա անել:

Հիմնական հասկացությունները Helm-ում

Սաղավարտն է փաթեթի կառավարիչ Կուբերնետեսի համար: Դա շատ նման է այն բանին, թե ինչպես են աշխատում ծրագրավորման լեզուներով փաթեթների կառավարիչները: Դրանք թույլ են տալիս պահել ծառայությունը, որը բաղկացած է, օրինակ, տեղակայման nginx-ից, տեղակայման php-fpm-ից, կոնֆիգուրից Ingress-ի համար, configmaps-ից (սա մի կառույց է, որը թույլ է տալիս սահմանել env և այլ պարամետրեր ձեր համակարգի համար) այսպես. կոչվում են գծապատկերներ: Միևնույն ժամանակ Հելմ վազում է Կուբերնետեսի գագաթին. Այսինքն, սա մի կողմ կանգնած համակարգ չէ, այլ ընդամենը մեկ այլ ծառայություն, որը գործարկվել է խորանարդի ներսում: Դուք շփվում եք դրա հետ իր API-ի միջոցով՝ վահանակի հրամանի միջոցով: Դրա հարմարավետությունն ու գեղեցկությունն այն է, որ նույնիսկ եթե ղեկը կոտրվի կամ դուք այն հանեք կլաստերից, ձեր ծառայությունները չեն անհետանա, քանի որ ղեկը հիմնականում ծառայում է միայն համակարգը գործարկելու համար: Այնուհետև Kubernetes-ն ինքն է պատասխանատու ծառայությունների կատարման և վիճակի համար:

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

Հելմը մեզ համար ավելացնում է ևս մի քանի հասկացություն:

Աղյուսակ - սա ձեր ծառայության նկարագրությունն է: Փաթեթի այլ կառավարիչներում այն ​​կկոչվի փաթեթ, փաթեթ կամ նման այլ բան: Այստեղ այն կոչվում է գծապատկեր:

Արժեքներն այն փոփոխականներն են, որոնք ցանկանում եք օգտագործել ձեր կոնֆիգուրացիաները ձևանմուշներից կառուցելու համար:

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

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

Գործնականում մենք որոշեցինք ամեն ինչ անել մի փոքր այլ կերպ, քան Nomad-ի հետ: Եթե ​​Nomad-ում և՛ տեղակայման կոնֆիգուրացիաները, և՛ n-փոփոխականները, որոնք անհրաժեշտ էին մեր ծառայությունը տեղակայելու համար, պահվում էին մեկ պահեստում, այստեղ մենք որոշեցինք դրանք բաժանել երկու առանձին պահեստների: «deploy» պահոցը պահում է միայն n-փոփոխականներ, որոնք անհրաժեշտ են տեղակայման համար, իսկ «helm» պահոցը պահում է կազմաձևեր կամ գծապատկերներ:

Ի՞նչ տվեց սա մեզ:

Չնայած այն հանգամանքին, որ մենք իրականում զգայուն տվյալներ չենք պահում հենց կազմաձևման ֆայլերում: Օրինակ՝ տվյալների բազաների գաղտնաբառերը: Դրանք պահվում են որպես գաղտնիք Kubernetes-ում, բայց, այնուամենայնիվ, այնտեղ դեռ կան որոշ բաներ, որոնք մենք չենք ցանկանում բոլորին հասանելի դարձնել: Հետևաբար, մուտքը դեպի «տեղակայման» պահոց ավելի սահմանափակ է, և «ղեկի» պահոցը պարզապես պարունակում է ծառայության նկարագրությունը: Այդ իսկ պատճառով, այն կարող է ապահով մուտք գործել մարդկանց ավելի լայն շրջանակի համար:

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

Յուրաքանչյուր պահեստի ներսում մենք թողեցինք բաժանում յուրաքանչյուր ծառայության համար առանձին գրացուցակների: Այսինքն՝ յուրաքանչյուր գրացուցակի ներսում կան կաղապարներ՝ կապված համապատասխան գծապատկերի հետ և նկարագրում են ռեսուրսները, որոնք պետք է տեղակայվեն մեր համակարգը գործարկելու համար: Մենք թողել ենք միայն envs «deploy» պահոցում: Այս դեպքում մենք չենք օգտագործել կաղապար՝ օգտագործելով jinja, քանի որ helm-ն ինքն է ապահովում կաղապարը տուփից դուրս. սա նրա հիմնական գործառույթներից մեկն է:

Մենք թողեցինք տեղակայման սկրիպտ՝ deploy.sh, որը պարզեցնում և ստանդարտացնում է գործարկումը՝ օգտագործելով ղեկը: Այսպիսով, յուրաքանչյուրի համար, ով ցանկանում է տեղակայել, տեղակայման միջերեսը ճիշտ նույն տեսքն ունի, ինչ Nomad-ի միջոցով տեղակայվելիս: Նույն deploy.sh-ը, ձեր ծառայության անվանումը և որտեղ եք ցանկանում տեղադրել այն: Սա հանգեցնում է նրան, որ ղեկը սկսում է ներսից: Այն, իր հերթին, հավաքում է կոնֆիգուրացիաներ կաղապարներից, տեղադրում է անհրաժեշտ արժեքների ֆայլերը դրանց մեջ, այնուհետև տեղակայում դրանք՝ գործարկելով Kubernetes-ում։

Արդյունքները

Թվում է, թե Kubernetes ծառայությունն ավելի բարդ է, քան Nomad-ը:

Այստեղ ելքային տրաֆիկը գալիս է Ingress-ին: Սա պարզապես առջևի վերահսկիչն է, որը վերցնում է բոլոր հարցումները և հետագայում դրանք ուղարկում հարցումների տվյալներին համապատասխան ծառայություններ: Այն որոշում է դրանք՝ հիմնվելով կազմաձևերի վրա, որոնք մաս են կազմում ձեր հավելվածի նկարագրությանը, և որոնք մշակողները ինքնուրույն են սահմանում: Ծառայությունը հարցումներ է ուղարկում իր pods, այսինքն՝ հատուկ կոնտեյներներ՝ հավասարակշռելով մուտքային երթևեկությունը բոլոր բեռնարկղերի միջև, որոնք պատկանում են այս ծառայությանը: Եվ, իհարկե, մենք չպետք է մոռանանք, որ մենք չպետք է որևէ տեղ գնանք ցանցի մակարդակով անվտանգությունից: Հետևաբար, հատվածավորումն աշխատում է Kubernetes կլաստերում, որը հիմնված է հատկորոշման վրա։ Բոլոր ծառայություններն ունեն որոշակի պիտակներ, որոնց հետ կապված են ծառայությունների մուտքի իրավունքները որոշակի արտաքին/ներքին ռեսուրսների՝ կլաստերի ներսում կամ դրսում:

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

Նման օգտագործման օրինակ է Պրոմեթևսը, որն աշխատում է մեր Kubernetes կլաստերի ներսում: Որպեսզի այն սկսի որոշակի ծառայությունից չափումներ հավաքել, մենք պետք է ծառայության նկարագրությանը ավելացնենք լրացուցիչ տեսակի ռեսուրս, այսպես կոչված, ծառայության մոնիտոր: Պրոմեթևսը, քանի որ այն կարող է կարդալ հատուկ ռեսուրսի տեսակը Kubernetes-ում գործարկվելիս, ավտոմատ կերպով սկսում է նոր համակարգից չափումներ հավաքել: Դա բավականին հարմար է։

Առաջին տեղակայումը Kubernetes-ում կատարվեց 2018 թվականի մարտին: Եվ այս ընթացքում մենք երբեք դրա հետ կապված որևէ խնդիր չենք ունեցել։ Այն աշխատում է բավականին կայուն, առանց էական սխալների: Բացի այդ, մենք կարող ենք այն ավելի ընդլայնել: Այսօր մենք ունենք բավականաչափ հնարավորություններ, որոնք նա ունի, և մեզ շատ է դուր գալիս Kubernetes-ի զարգացման տեմպերը: Ներկայումս Կուբերնետեսում ավելի քան 3000 կոնտեյներ է։ Կլաստերը զբաղեցնում է մի քանի հանգույց։ Միևնույն ժամանակ այն սպասարկելի է, կայուն և շատ կառավարելի։

Source: www.habr.com