Մեր բլոգը կսկսենք մեր տեխնիկական տնօրենի վերջին ելույթների հիման վրա հրապարակումներով (Դմիտրի Ստոլյարով). Դրանք բոլորը տեղի են ունեցել 2016 թվականին տարբեր մասնագիտական միջոցառումների ժամանակ և նվիրված են եղել DevOps-ի և Docker-ի թեմային։ Մեկ տեսանյութ Badoo-ի գրասենյակում Docker Moscow հանդիպումից, մենք արդեն ունենք Առցանց. Նորերը կուղեկցվեն զեկույցների էությունը հաղորդող հոդվածներով։ Այսպիսով…
մայիսի 31-ին համաժողովում «Ռուսական ինտերնետ տեխնոլոգիաներ» փառատոնի շրջանակներում (RIT++ 2016), «Շարունակական տեղակայում և տեղակայում» բաժինը բացվեց «Դոկերի հետ շարունակական առաքման լավագույն փորձը» զեկույցով։ Այն ամփոփել և համակարգել է Docker-ի և բաց կոդով այլ արտադրանքների օգտագործմամբ շարունակական առաքման (CD) գործընթաց ստեղծելու լավագույն փորձը: Մենք աշխատում ենք այս լուծումներով արտադրության մեջ, ինչը թույլ է տալիս ապավինել գործնական փորձին:
Եթե հնարավորություն ունեք մեկ ժամ անցկացնելու , խորհուրդ ենք տալիս դիտել ամբողջությամբ։ Հակառակ դեպքում, ստորև ներկայացված է հիմնական ամփոփումը տեքստային ձևով:
Շարունակական առաքում Docker-ի հետ
Under Շարունակական Առաքում մենք հասկանում ենք իրադարձությունների շղթան, որի արդյունքում Git պահոցից դիմումի կոդը սկզբում գալիս է արտադրության, այնուհետև հայտնվում է արխիվում: Այն կարծես այսպիսին է. Git → Build → Test → Release → Operate.
Զեկույցի մեծ մասը նվիրված է կառուցման փուլին (հավելվածի հավաքում), իսկ թողարկման և գործողության թեմաները հակիրճ շոշափվում են: Մենք կխոսենք խնդիրների և օրինաչափությունների մասին, որոնք թույլ են տալիս լուծել դրանք, և այդ օրինաչափությունների կոնկրետ իրականացումները կարող են տարբեր լինել:
Ինչու՞ է այստեղ ընդհանրապես անհրաժեշտ Docker-ը: Իզուր չէ, որ մենք որոշեցինք խոսել շարունակական առաքման պրակտիկայի մասին այս բաց կոդով գործիքի համատեքստում: Չնայած ամբողջ զեկույցը նվիրված է դրա օգտագործմանը, բազմաթիվ պատճառներ են բացահայտվում, երբ դիտարկվում է հավելվածի ծածկագրի ներդրման հիմնական օրինակը:
Հիմնական թողարկման օրինակը
Այսպիսով, երբ մենք թողարկում ենք հավելվածի նոր տարբերակները, մենք, անշուշտ, բախվում ենք պարապուրդի խնդիր, ստեղծվել է արտադրության սերվերի միացման ժամանակ։ Հավելվածի հին տարբերակից նորի երթևեկությունը չի կարող ակնթարթորեն անցնել. նախ մենք պետք է համոզվենք, որ նոր տարբերակը ոչ միայն հաջողությամբ ներբեռնվի, այլև «ջերմացվի» (այսինքն՝ լիովին պատրաստ է սպասարկել հարցումները):
Այսպիսով, որոշ ժամանակ հավելվածի երկու տարբերակները (հին և նոր) կաշխատեն միաժամանակ։ Ինչն ինքնաբերաբար հանգեցնում է ընդհանուր ռեսուրսների կոնֆլիկտՑանց, ֆայլային համակարգ, IPC և այլն: Docker-ի հետ այս խնդիրը հեշտությամբ լուծվում է հավելվածի տարբեր տարբերակները գործարկելով առանձին կոնտեյներներում, որոնց համար ռեսուրսի մեկուսացումը երաշխավորված է նույն հոսթի (սերվերի/վիրտուալ մեքենայի) ներսում։ Իհարկե, որոշ հնարքներով կարելի է գլուխ հանել ընդհանրապես առանց մեկուսացման, բայց եթե կա պատրաստի ու հարմար գործիք, ապա կա հակառակ պատճառը՝ չանտեսել այն։
Կոնտեյներացումն ապահովում է բազմաթիվ այլ առավելություններ, երբ տեղակայվում է: Ցանկացած դիմում կախված է կոնկրետ տարբերակ (կամ տարբերակի տիրույթ) թարգմանիչ, մոդուլների/ընդլայնումների առկայությունը և այլն, ինչպես նաև դրանց տարբերակները։ Եվ դա վերաբերում է ոչ միայն անմիջական գործարկվող միջավայրին, այլ նաև ողջ միջավայրին, այդ թվում՝ համակարգի ծրագրային ապահովում և դրա տարբերակը (մինչև օգտագործված Linux բաշխումը): Շնորհիվ այն բանի, որ բեռնարկղերը պարունակում են ոչ միայն կիրառական ծածկագիր, այլև նախապես տեղադրված համակարգ և անհրաժեշտ տարբերակների կիրառական ծրագրեր, դուք կարող եք մոռանալ կախվածության հետ կապված խնդիրների մասին:
Եկեք ամփոփենք հիմնական թողարկման օրինակը նոր տարբերակներ՝ հաշվի առնելով հետևյալ գործոնները.
- Սկզբում հավելվածի հին տարբերակը աշխատում է առաջին կոնտեյներով:
- Նոր տարբերակը այնուհետև գլորվում է և «տաքացվում» երկրորդ տարայի մեջ: Հատկանշական է, որ այս նոր տարբերակն ինքնին կարող է կրել ոչ միայն թարմացված հավելվածի կոդը, այլև դրա ցանկացած կախվածություն, ինչպես նաև համակարգի բաղադրիչներ (օրինակ՝ OpenSSL-ի նոր տարբերակը կամ ամբողջ բաշխումը):
- Երբ նոր տարբերակը լիովին պատրաստ է սպասարկելու հարցումները, երթևեկությունը առաջին կոնտեյներից անցնում է երկրորդին:
- Հին տարբերակը այժմ կարող է դադարեցվել:
Հավելվածի տարբեր տարբերակները առանձին բեռնարկղերում տեղակայելու այս մոտեցումը ևս մեկ հարմարություն է տալիս. արագ հետադարձ հին տարբերակին (ի վերջո, բավական է երթևեկությունը տեղափոխել ցանկալի կոնտեյներ):
Վերջին առաջին առաջարկությունը կարծես մի բան է, որի մեջ նույնիսկ կապիտանը չէր կարող թերություն գտնել.[Docker-ի հետ շարունակական առաքում կազմակերպելիս] Օգտագործեք Docker-ը [և հասկանալ, թե ինչ է դա տալիս]« Հիշեք, որ սա ոչ թե արծաթյա փամփուշտ է, որը կլուծի յուրաքանչյուր խնդիր, այլ գործիք, որն ապահովում է հիանալի հիմք։
Վերարտադրելիություն
«Վերարտադրելիություն» ասելով մենք հասկանում ենք խնդիրների ընդհանրացված մի շարք, որոնք հանդիպում են հավելվածների շահագործման ժամանակ: Խոսքը նման դեպքերի մասին է.
- Բեմադրության համար որակի բաժնի կողմից ստուգված սցենարները պետք է ճշգրիտ վերարտադրվեն արտադրության մեջ:
- Հավելվածները հրապարակվում են սերվերների վրա, որոնք կարող են փաթեթներ ստանալ տարբեր պահեստային հայելիներից (ժամանակի ընթացքում դրանք թարմացվում են, և դրանց հետ միասին՝ տեղադրված հավելվածների տարբերակները)։
- «Ինձ մոտ ամեն ինչ աշխատում է տեղում»: (...և մշակողներին թույլ չեն տալիս արտադրել:)
- Դուք պետք է ինչ-որ բան ստուգեք հին (արխիվացված) տարբերակում:
- ...
Դրանց ընդհանուր էությունը հանգում է նրան, որ անհրաժեշտ է օգտագործվող միջավայրերի լիարժեք համապատասխանությունը (ինչպես նաև մարդկային գործոնի բացակայությունը): Ինչպե՞ս կարող ենք երաշխավորել վերարտադրելիությունը: Ստեղծեք Docker պատկերներ հիմնվելով Git-ի կոդի վրա, այնուհետև օգտագործել դրանք ցանկացած առաջադրանքի համար՝ թեստային վայրերում, արտադրության մեջ, ծրագրավորողների տեղական մեքենաների վրա... Միևնույն ժամանակ, կարևոր է նվազագույնի հասցնել կատարվող գործողությունները։ այն բանից հետո պատկերի հավաքում. որքան պարզ է, այնքան քիչ հավանական է, որ սխալներ լինեն:
Ենթակառուցվածքը կոդ է
Եթե ենթակառուցվածքի պահանջները (սերվերի ծրագրաշարի առկայությունը, դրա տարբերակը և այլն) ձևակերպված և «ծրագրավորված» չեն, ապա ցանկացած հավելվածի թարմացում կարող է հանգեցնել աղետալի հետևանքների: Օրինակ, բեմադրման ժամանակ դուք արդեն անցել եք PHP 7.0-ին և համապատասխանաբար վերաշարադրել եք կոդը, այնուհետև դրա հայտնվելը արտադրության մեջ ինչ-որ հին PHP-ով (5.5) անշուշտ ինչ-որ մեկին կզարմացնի: Դուք չեք կարող մոռանալ թարգմանիչ տարբերակի մեծ փոփոխության մասին, բայց «սատանան մանրամասների մեջ է». անակնկալը կարող է լինել ցանկացած կախվածության աննշան թարմացում:
Այս խնդրի լուծման մոտեցումը հայտնի է որպես IaC (Ենթակառուցվածքը որպես կոդ, «ենթակառուցվածքը որպես ծածկագիր») և ներառում է ենթակառուցվածքի պահանջների պահպանում հավելվածի կոդի հետ միասին: Օգտագործելով այն՝ մշակողները և DevOps-ի մասնագետները կարող են աշխատել նույն Git հավելվածի պահեստի հետ, բայց դրա տարբեր մասերում։ Այս կոդից Git-ում ստեղծվում է Docker պատկեր, որում հավելվածը տեղակայվում է՝ հաշվի առնելով ենթակառուցվածքի բոլոր առանձնահատկությունները։ Պարզ ասած՝ պատկերների հավաքման սկրիպտները (կանոնները) պետք է լինեն սկզբնաղբյուրի հետ նույն պահոցում և միաձուլվեն։
Բազմաշերտ կիրառական ճարտարապետության դեպքում, օրինակ, կա nginx, որը կանգնած է Docker կոնտեյների ներսում արդեն աշխատող հավելվածի դիմաց. Docker պատկերները պետք է ստեղծվեն Git-ի կոդից յուրաքանչյուր շերտի համար: Այնուհետև առաջին պատկերը կպարունակի հավելված թարգմանիչով և այլ «մոտ» կախվածություններով, իսկ երկրորդ պատկերը կպարունակի վերընթաց nginx:
Docker պատկերներ, հաղորդակցություն Git-ի հետ
Մենք Git-ից հավաքված բոլոր Docker պատկերները բաժանում ենք երկու կատեգորիայի՝ ժամանակավոր և թողարկված: Ժամանակավոր պատկերներ Git-ում պիտակավորված մասնաճյուղի անունով, կարող է վերագրվել հաջորդ commit-ով և թողարկվել միայն նախադիտման համար (ոչ արտադրության համար): Սա է նրանց հիմնական տարբերությունը թողարկվողներից. երբեք չգիտես, թե կոնկրետ որ պարտավորությունն է դրանցում:
Իմաստ ունի հավաքել ժամանակավոր պատկերների մեջ՝ գլխավոր մասնաճյուղ (կարող եք այն ավտոմատ կերպով տարածել առանձին կայք՝ վարպետի ընթացիկ տարբերակը մշտապես տեսնելու համար), թողարկումներով մասնաճյուղեր, հատուկ նորարարությունների ճյուղեր:
Այն բանից հետո, երբ ժամանակավոր պատկերների նախադիտումը գալիս է արտադրության մեջ թարգմանելու անհրաժեշտությանը, մշակողները դնում են որոշակի պիտակ: Ավտոմատ հավաքագրվում է ըստ պիտակի ազատ արձակել պատկերը (դրա պիտակը համապատասխանում է Git-ի պիտակին) և դուրս է բերվում բեմականացման համար: Եթե այն հաջողությամբ ստուգվում է որակի բաժնի կողմից, գնում է արտադրության:
դափ
Նկարագրված ամեն ինչ (տեղադրում, պատկերի հավաքում, հետագա սպասարկում) կարող է իրականացվել ինքնուրույն՝ օգտագործելով Bash սկրիպտները և այլ «իմպրովիզացված» գործիքներ: Բայց եթե դուք դա անեք, ապա ինչ-որ պահի իրականացումը կհանգեցնի մեծ բարդության և վատ վերահսկելիության: Հասկանալով սա՝ մենք եկանք ստեղծելու մեր սեփական մասնագիտացված Workflow ծրագիրը՝ CI/CD կառուցելու համար. դափ.
Դրա սկզբնական կոդը գրված է Ruby-ով, բաց կոդով և հրապարակված է . Ցավոք, փաստաթղթերը ներկայումս գործիքի ամենաթույլ կողմն են, բայց մենք աշխատում ենք դրա վրա: Իսկ դափի մասին մեկ անգամ չէ, որ կգրենք ու կխոսենք, քանի որ... Մենք անկեղծորեն չենք կարող սպասել, որպեսզի կիսվի դրա հնարավորություններով ողջ շահագրգիռ համայնքի հետ, բայց միևնույն ժամանակ ուղարկեք ձեր խնդիրները և խնդրանքները և/կամ հետևեք GitHub-ում նախագծի զարգացմանը:
Թարմացվել է 13 թվականի օգոստոսի 2019-ին. ներկայումս նախագիծ է դափ վերանվանվել է , նրա կոդը ամբողջությամբ վերաշարադրվել է Go-ում, և դրա փաստաթղթավորումը զգալիորեն բարելավվել է։
Կուբերնետես
Մեկ այլ պատրաստ Open Source գործիք, որն արդեն զգալի ճանաչում է ստացել մասնագիտական միջավայրում Կուբերնետես, Docker կառավարման կլաստեր: Docker-ի վրա կառուցված նախագծերի շահագործման մեջ դրա օգտագործման թեման դուրս է զեկույցի շրջանակներից, ուստի ներկայացումը սահմանափակվում է որոշ հետաքրքիր առանձնահատկությունների ակնարկով:
Տեղադրման համար Kubernetes-ն առաջարկում է.
- պատրաստակամության զոնդ — ստուգում է հավելվածի նոր տարբերակի պատրաստվածությունը (տրաֆիկը դրան անցնելու համար);
- շարժակազմի թարմացում - պատկերի հաջորդական թարմացում բեռնարկղերի կլաստերում (անջատում, թարմացում, մեկնարկի նախապատրաստում, երթևեկության միացում);
- համաժամանակյա թարմացում - պատկերի թարմացում կլաստերի մեջ այլ մոտեցմամբ. սկզբում բեռնարկղերի կեսի վրա, այնուհետև մնացածի վրա.
- դեղձանիկի թողարկումներ - նոր պատկերի ստեղծում սահմանափակ (փոքր) թվով բեռնարկղերի վրա՝ անոմալիաները վերահսկելու համար:
Քանի որ Continuous Delivery-ը միայն նոր տարբերակի թողարկում չէ, Kubernetes-ն ունի մի շարք հնարավորություններ հետագա ենթակառուցվածքի պահպանման համար՝ ներկառուցված մոնիտորինգ և գրանցում բոլոր բեռնարկղերի համար, ավտոմատ մասշտաբավորում և այլն: իրականացում ձեր գործընթացներում:
Վերջնական առաջարկություններ
- Օգտագործեք Docker-ը:
- Ստեղծեք հավելվածների Docker պատկերներ ձեր բոլոր կարիքների համար:
- Հետևեք «Ենթակառուցվածքը կոդ է» սկզբունքին:
- Կապեք Git-ը Docker-ին:
- Կարգավորեք թողարկման կարգը:
- Օգտագործեք պատրաստի հարթակ (Kubernetes կամ այլ):
Տեսանյութեր և սլայդներ
Տեսանյութ ներկայացումից (մոտ մեկ ժամ) (զեկույցն ինքնին սկսվում է 5-րդ րոպեից - այս պահից խաղալու համար անցեք հղմանը).
Զեկույցի ներկայացում.
PS
Թեմայի վերաբերյալ այլ զեկույցներ մեր բլոգում.
- «» (Դմիտրի Ստոլյարով; 27 թվականի մայիսի 2019-ին DevOpsConf-ում);
- «» (Դմիտրի Ստոլյարով; նոյեմբերի 8, 2018 HighLoad++-ում);
- «» (Դմիտրի Ստոլյարով; նոյեմբերի 7, 2017 HighLoad++-ում);
- «» (Դմիտրի Ստոլյարով; 6 թվականի հունիսի 2017-ին RootConf-ում).
Source: www.habr.com