Մշակում և փորձարկման գործընթաց Docker-ի և Gitlab CI-ի հետ

Առաջարկում եմ կարդալ Inventos-ից Ալեքսանդր Սիգաչևի զեկույցի սղագրությունը «Զարգացում և փորձարկում Docker + Gitlab CI-ի հետ»

Նրանք, ովքեր նոր են սկսում իրականացնել Docker + Gitlab CI-ի վրա հիմնված զարգացման և փորձարկման գործընթացը, հաճախ տալիս են հիմնական հարցեր: Որտեղի՞ց սկսել: Ինչպե՞ս կազմակերպել: Ինչպե՞ս փորձարկել:

Այս զեկույցը լավն է, քանի որ այն կառուցվածքային կերպով խոսում է Docker և Gitlab CI-ի օգտագործմամբ մշակման և փորձարկման գործընթացի մասին: Զեկույցն ինքնին 2017թ. Կարծում եմ, որ այս զեկույցից դուք կարող եք քաղել հիմունքները, մեթոդաբանությունը, գաղափարը և օգտագործման փորձը:

Ո՞վ է մտածում, խնդրում եմ կատվի տակ:

Ես Ալեքսանդր Սիգաչովն եմ։ Ես աշխատում եմ Inventos-ում։ Ես ձեզ կպատմեմ Docker-ի օգտագործման իմ փորձի և այն մասին, թե ինչպես ենք մենք աստիճանաբար իրականացնում այն ​​ընկերության նախագծերում:

Զեկույցի թեման՝ Docker-ի և Gitlab CI-ի օգտագործմամբ մշակման գործընթաց:

Սա իմ երկրորդ խոսակցությունն է Docker-ի մասին: Առաջին զեկույցի ժամանակ մենք Docker-ն օգտագործում էինք միայն «Developer»-ում մշակողների մեքենաներում: Docker-ից օգտվող աշխատակիցների թիվը մոտ 2-3 մարդ էր։ Աստիճանաբար փորձ ձեռք բերվեց, և մենք մի փոքր առաջ շարժվեցինք։ Հղում դեպի մեր առաջին զեկույցը.

Ի՞նչ կլինի այս զեկույցում: Կկիսվենք մեր փորձով, թե ինչ փոցխներ ենք հավաքել, ինչ խնդիրներ ենք լուծել։ Ամենուր գեղեցիկ չէր, բայց դա մեզ թույլ տվեց առաջ գնալ:

Մեր կարգախոսն է՝ դավաճանել այն ամենը, ինչ մենք ձեռք ենք բերում:

Ի՞նչ խնդիրներ ենք մենք լուծում։

Երբ ընկերությունն ունի մի քանի թիմ, ծրագրավորողը ընդհանուր ռեսուրս է: Կան փուլեր, երբ ծրագրավորողին հանում են մի նախագծից և որոշ ժամանակով տալիս մեկ այլ նախագծի:

Որպեսզի ծրագրավորողն արագ հասկանա, նա պետք է ներբեռնի նախագծի սկզբնական կոդը և հնարավորինս արագ գործարկի միջավայր, որը թույլ կտա նրան հետագայում առաջադիմել այս նախագծի խնդիրների լուծման գործում:

Սովորաբար, եթե դուք սկսում եք զրոյից, նախագծում քիչ փաստաթղթեր կան: Միայն հնաբնակները տեղեկություններ ունեն այն կարգավորելու մասին: Աշխատակիցները մեկ-երկու օրվա ընթացքում ինքնուրույն են սարքում իրենց աշխատավայրը։ Դա արագացնելու համար մենք օգտագործեցինք Docker-ը:

Հաջորդ պատճառը Development-ում կարգավորումների ստանդարտացումն է: Իմ փորձով, մշակողները միշտ նախաձեռնող են: Ամեն հինգերորդ դեպքում մուտքագրվում է հատուկ տիրույթ, օրինակ vasya.dev։ Կողքիս նստած է իմ հարեւան Պետյան, որի տիրույթը petya.dev է։ Նրանք մշակում են կայք կամ համակարգի որոշ բաղադրիչ՝ օգտագործելով այս տիրույթի անունը:

Երբ համակարգը մեծանում է, և այս տիրույթի անունները սկսում են ներառվել կազմաձևման մեջ, Զարգացման միջավայրերում կոնֆլիկտ է առաջանում և կայքի ուղին վերագրվում է:

Նույնը տեղի է ունենում տվյալների բազայի կարգավորումների դեպքում: Որոշ մարդիկ չեն անհանգստանում անվտանգության հետ և աշխատում են դատարկ արմատային գաղտնաբառով: Տեղադրման փուլում MySQL-ն ինչ-որ մեկից գաղտնաբառ խնդրեց, և գաղտնաբառը 123 էր: Հաճախ է պատահում, որ տվյալների բազայի կազմաձևը անընդհատ փոխվում էր՝ կախված մշակողի պարտավորությունից: Ինչ-որ մեկը ուղղել է, ինչ-որ մեկը չի ուղղել կոնֆիգուրը: Կային հնարքներ, երբ մենք դրեցինք որոշ թեստային կազմաձևեր .gitignore և յուրաքանչյուր մշակող պետք է տեղադրեր տվյալների բազան: Սա ավելի դժվարացրեց մեկնարկային գործընթացը: Ի թիվս այլ բաների, դուք պետք է հիշեք տվյալների բազայի մասին: Տվյալների բազան պետք է նախաստորագրվի, պետք է գրանցվի գաղտնաբառ, գրանցվի օգտվող, ստեղծվի նշան և այլն։

Մեկ այլ խնդիր գրադարանների տարբեր տարբերակներն են: Հաճախ է պատահում, որ մշակողը աշխատում է տարբեր նախագծերի վրա։ Գոյություն ունի Legacy նախագիծը, որը սկսվել է հինգ տարի առաջ (2017 թվականից - խմբագրի նշում)։ Սկզբում մենք սկսեցինք MySQL 5.5-ով: Կան նաև ժամանակակից նախագծեր, որտեղ մենք փորձում ենք իրականացնել MySQL-ի ավելի ժամանակակից տարբերակներ, օրինակ՝ 5.7 կամ ավելի հին (2017թ.- խմբագրի նշում)

Յուրաքանչյուր ոք, ով աշխատում է MySQL-ով, գիտի, որ այս գրադարանները ունեն կախվածություն: Բավականին խնդրահարույց է 2 տվյալների բազա միասին գործարկելը։ Առնվազն խնդրահարույց է հին հաճախորդներին միացնել նոր տվյալների բազան: Սա իր հերթին առաջացնում է մի շարք խնդիրներ։

Հաջորդ խնդիրն այն է, երբ մշակողը աշխատում է տեղական մեքենայի վրա, նա օգտագործում է տեղական ռեսուրսներ, տեղական ֆայլեր, տեղական RAM: Խնդիրների լուծման մշակման պահին բոլոր փոխազդեցությունն իրականացվում է այն բանի շրջանակներում, որ այն աշխատում է մեկ մեքենայի վրա: Օրինակ կարող է լինել, երբ մենք ունենք «backend» սերվերներ Production 3-ում, և ծրագրավորողը ֆայլերը պահում է արմատական ​​գրացուցակում և այնտեղից nginx-ը վերցնում է ֆայլերը՝ պատասխանելու հարցումին: Երբ նման կոդը մտնում է Production, պարզվում է, որ ֆայլը առկա է 3 սերվերներից մեկում։

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

Frontend ծրագրավորողը, որը զարգանում է JS-ում, գործնականում ոչ մի ազդեցություն չունի հետնամասի վրա: Backend-ի մշակողն իր հերթին զարգացնում է, մեր դեպքում, Ruby on Rails-ը և չի խանգարում Frondend-ին։ Փոխազդեցությունն իրականացվում է API-ի միջոցով:

Որպես բոնուս, Docker-ի միջոցով մենք կարողացանք վերամշակել ռեսուրսները Staging-ում: Յուրաքանչյուր նախագիծ, ելնելով իր առանձնահատկություններից, պահանջում էր որոշակի կարգավորումներ: Ֆիզիկապես անհրաժեշտ էր հատկացնել կամ վիրտուալ սերվեր և կարգավորել դրանք առանձին, կամ բաժանել ինչ-որ փոփոխական միջավայր, և նախագծերը կարող էին ազդել միմյանց վրա՝ կախված գրադարանների տարբերակից:

Գործիքներ. Ինչ ենք մենք օգտագործում:

• Ինքը՝ Docker-ը: Dockerfile-ը նկարագրում է մեկ հավելվածի կախվածությունը:
• Docker-compose-ը մի փաթեթ է, որը միավորում է մեր Docker հավելվածներից մի քանիսը:
• Մենք օգտագործում ենք GitLab-ը աղբյուրի կոդը պահելու համար:
• Համակարգի ինտեգրման համար մենք օգտագործում ենք GitLab-CI:

Զեկույցը բաղկացած է երկու մասից.

Առաջին մասը ձեզ կպատմի, թե ինչպես գործարկել Docker-ը մշակողների մեքենաների վրա:

Երկրորդ մասում կխոսվի GitLab-ի հետ փոխազդեցության մասին, թե ինչպես ենք անցկացնում թեստերը և ինչպես ենք անցնում Staging-ին:

Docker-ը տեխնոլոգիա է, որը թույլ է տալիս (օգտագործելով դեկլարատիվ մոտեցում) անհրաժեշտ բաղադրիչները նկարագրել: Սա Dockerfile-ի օրինակ է: Այստեղ մենք հայտարարում ենք, որ մենք ժառանգում ենք Ruby-ի պաշտոնական Docker պատկերը:2.3.0: Այն պարունակում է տեղադրված Ruby տարբերակը 2.3: Մենք տեղադրում ենք անհրաժեշտ հավաքման գրադարանները և NodeJS-ը: Մենք նկարագրում ենք, որ մենք ստեղծում ենք գրացուցակ /app. Մենք ծրագրի գրացուցակը նշանակում ենք որպես աշխատանքային գրացուցակ: Այս գրացուցակում մենք տեղադրում ենք անհրաժեշտ նվազագույն Gemfile և Gemfile.lock: Այնուհետև մենք կառուցում ենք նախագծեր, որոնք տեղադրում են կախվածության այս պատկերը: Մենք նշում ենք, որ կոնտեյները պատրաստ կլինի լսել արտաքին 3000 պորտին: Վերջին հրամանը հրամանն է, որն ուղղակիորեն գործարկում է մեր հավելվածը: Եթե ​​մենք կատարենք project run հրամանը, ապա հավելվածը կփորձի գործարկել և գործարկել նշված հրամանը։

Սա docker-compose ֆայլի նվազագույն օրինակ է: Այս դեպքում մենք ցույց ենք տալիս, որ կապ կա երկու տարաների միջև: Սա անմիջապես տվյալների բազայի ծառայության և վեբ ծառայության մեջ է: Մեր վեբ հավելվածները շատ դեպքերում պահանջում են տվյալների շտեմարան՝ որպես տվյալների պահպանման հիմք: Քանի որ մենք օգտագործում ենք MySQL, օրինակը MySQL-ի հետ է, բայց ոչինչ չի խանգարում մեզ օգտագործել այլ տվյալների բազա (PostgreSQL, Redis):

Մենք վերցնում ենք MySQL 5.7.14 պատկերն առանց փոփոխությունների պաշտոնական աղբյուրից Docker hub-ից: Մենք հավաքում ենք պատկերը, որը պատասխանատու է մեր վեբ հավելվածի համար ընթացիկ գրացուցակից: Առաջին մեկնարկի ժամանակ նա մեզ համար պատկեր է հավաքում։ Այնուհետև այն գործարկում է հրամանը, որը մենք կատարում ենք այստեղ: Եթե ​​հետ գնանք, կտեսնենք, որ գործարկման հրամանը սահմանվել է Puma-ի միջոցով։ Puma-ն Ռուբիով գրված ծառայություն է։ Երկրորդ դեպքում մենք անտեսում ենք: Այս հրամանը կարող է կամայական լինել՝ կախված մեր կարիքներից կամ խնդիրներից:

Մենք նաև նկարագրում ենք, որ մենք պետք է տեղափոխենք նավահանգիստը մեր ծրագրավորող հյուրընկալող մեքենայի վրա 3000-ից մինչև 3000 կոնտեյներային նավահանգիստ: Դա արվում է ավտոմատ կերպով՝ օգտագործելով iptables-ը և սեփական մեխանիզմը, որն ուղղակիորեն ներկառուցված է Docker-ում:

Մշակողը կարող է, ինչպես նախկինում, մուտք գործել ցանկացած հասանելի IP հասցե, օրինակ՝ մեքենայի տեղական կամ արտաքին IP հասցե 127.0.0.1:

Վերջին տողում ասվում է, որ վեբ կոնտեյները կախված է db կոնտեյներից: Երբ մենք կանչում ենք վեբ կոնտեյները գործարկելու համար, docker-compose-ը նախ մեզ համար կգործարկի տվյալների բազան: Արդեն տվյալների բազայի մեկնարկից հետո (իրականում, կոնտեյների գործարկումից հետո: Սա չի երաշխավորում տվյալների բազայի պատրաստակամությունը) այն կգործարկի մեր հավելվածը, մեր backend-ը:

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

Ի՞նչ է մեզ տալիս նախագծի վրա տվյալների բազայի դոկերացման օգտագործումը: Մենք ձայնագրում ենք MySQL տարբերակը բոլոր մշակողների համար: Սա թույլ է տալիս խուսափել որոշ սխալներից, որոնք կարող են առաջանալ, երբ տարբերակները տարբերվում են, երբ փոխվում են շարահյուսությունը, կազմաձևումը և լռելյայն կարգավորումները: Սա թույլ է տալիս նշել տվյալների բազայի ընդհանուր հոսթի անուն, մուտք, գաղտնաբառ: Մենք հեռանում ենք անունների կենդանաբանական այգուց և կոնֆիգուրացիայի ֆայլերի կոնֆլիկտներից, որոնք նախկինում կային:

Մենք հնարավորություն ունենք Զարգացման միջավայրի համար օգտագործել ավելի օպտիմալ կոնֆիգուրացիա, որը կտարբերվի լռելյայնից։ MySQL-ը լռելյայն կազմաձևված է թույլ մեքենաների համար, և դրա արդյունավետությունը շատ ցածր է:

Docker-ը թույլ է տալիս օգտագործել ցանկալի տարբերակի Python, Ruby, NodeJS, PHP թարգմանիչը։ Մենք ազատվում ենք ինչ-որ տարբերակի կառավարիչ օգտագործելու անհրաժեշտությունից: Նախկինում Ruby-ի համար օգտագործվում էր rpm փաթեթ, որը թույլ էր տալիս փոխել տարբերակը՝ կախված նախագծից։ Docker կոնտեյների շնորհիվ սա նաև թույլ է տալիս սահուն կերպով տեղափոխել կոդը և տարբերակել այն կախվածությունների հետ միասին: Մենք խնդիր չունենք հասկանալու թե՛ թարգմանչի, թե՛ ծածկագրի տարբերակը։ Տարբերակը թարմացնելու համար հարկավոր է իջեցնել հին տարան և բարձրացնել նոր տարան։ Եթե ​​ինչ-որ բան սխալ է, մենք կարող ենք իջեցնել նոր տարան, բարձրացնել հին տարան:

Պատկերը կառուցելուց հետո կոնտեյներները և՛ զարգացման, և՛ արտադրության մեջ կլինեն նույնը: Սա հատկապես ճիշտ է մեծ տեղակայանքների համար:

Frontend-ում մենք օգտագործում ենք JavaScipt և NodeJS:

Այժմ մենք ունենք մեր վերջին նախագիծը ReacJS-ում: Մշակողը գործարկեց ամեն ինչ կոնտեյներով և զարգացրեց՝ օգտագործելով hot-reload:

Այնուհետև գործարկվում է JavaScipt-ի հավաքման առաջադրանքը և ստատիկ կերպով հավաքված կոդը ուղարկվում է nginx-ի միջոցով՝ խնայելով ռեսուրսները:

Այստեղ ես ներկայացրել եմ մեր վերջին նախագծի դիագրամը:

Ի՞նչ խնդիրներ եք լուծել։ Մենք կարիք ունեինք կառուցելու մի համակարգ, որի հետ շարժական սարքերը փոխազդում են: Նրանք ստանում են տվյալներ։ Հնարավորություններից մեկն այս սարքին push ծանուցումներ ուղարկելն է։

Ի՞նչ ենք մենք արել սրա համար։

Հավելվածը բաժանեցինք հետևյալ բաղադրիչների՝ ադմինիստրատորի մաս JS-ում, հետին մաս, որն աշխատում է REST ինտերֆեյսի միջոցով Ruby on Rails-ի ներքո: Backend-ը փոխազդում է տվյալների բազայի հետ: Արդյունքը, որը ստեղծվում է, տրվում է հաճախորդին: Ադմինիստրատորի վահանակը փոխազդում է հետնամասի և տվյալների բազայի հետ REST ինտերֆեյսի միջոցով:

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

Մենք մշակել ենք հետևյալ սխեման՝ բրաուզերից օպերատորը փոխազդում է ադմինիստրատորի վահանակի հետ, ադմինիստրատորի վահանակը փոխազդում է հետնամասի հետ, խնդիրն է՝ ուղարկել Push ծանուցումներ։

Push ծանուցումները փոխազդում են մեկ այլ բաղադրիչի հետ, որն իրականացվում է NodeJS-ում:

Հերթեր են կառուցվում և ծանուցումներ են ուղարկվում իրենց իսկ մեխանիզմով։

Այստեղ կազմված է երկու տվյալների բազա: Ներկայումս, օգտագործելով Docker-ը, մենք օգտագործում ենք 2 անկախ տվյալների բազա, որոնք ոչ մի կերպ կապված չեն միմյանց հետ: Բացի այն, որ նրանք ունեն ընդհանուր վիրտուալ ցանց, և ֆիզիկական տվյալները պահվում են մշակողի մեքենայի տարբեր գրացուցակներում:

Նույնը, բայց թվերով. Այստեղ կարևոր է կոդի կրկնակի օգտագործումը:

Եթե ​​ավելի վաղ մենք խոսում էինք գրադարանների տեսքով կոդի վերօգտագործման մասին, ապա այս օրինակում մեր ծառայությունը, որն արձագանքում է Push ծանուցումներին, կրկին օգտագործվում է որպես ամբողջական սերվեր: Այն ապահովում է API: Եվ մեր նոր զարգացումը փոխազդում է դրա հետ:

Այն ժամանակ մենք օգտագործում էինք NodeJS-ի 4-րդ տարբերակը։ Այժմ (2017 թվականին - խմբագրի նշում) մեր վերջին զարգացումներում մենք օգտագործում ենք NodeJS-ի 7-րդ տարբերակը: Գրադարանների նոր տարբերակները ներգրավելու նոր բաղադրիչներում խնդիր չկա:

Անհրաժեշտության դեպքում կարող եք վերամշակել և բարձրացնել Push ծանուցման ծառայության NodeJS տարբերակը:

Եվ եթե մենք կարողանանք պահպանել API-ի համատեղելիությունը, ապա այն հնարավոր կլինի փոխարինել նախկինում օգտագործված այլ նախագծերով:

Ի՞նչ է ձեզ հարկավոր Docker ավելացնելու համար: Մենք մեր պահոցում ավելացնում ենք Dockerfile, որը նկարագրում է անհրաժեշտ կախվածությունները: Այս օրինակում բաղադրիչները բաժանված են տրամաբանորեն: Սա նվազագույն փաթեթն է հետին պլանի մշակողի համար:

Նոր նախագիծ ստեղծելիս մենք ստեղծում ենք Dockerfile և նկարագրում ենք անհրաժեշտ էկոհամակարգը (Python, Ruby, NodeJS): Docker-compose-ում այն ​​նկարագրում է անհրաժեշտ կախվածությունը՝ տվյալների բազան։ Մենք նկարագրում ենք, որ մեզ անհրաժեշտ է այսինչ տարբերակի տվյալների բազա՝ այնտեղ և այնտեղ տվյալները պահելու համար։

Ստատիկ բովանդակություն սպասարկելու համար մենք օգտագործում ենք առանձին երրորդ կոնտեյներ nginx-ով: Հնարավոր է նկարներ վերբեռնել։ Backend-ը դրանք դնում է նախապես պատրաստված ծավալի մեջ, որը նույնպես տեղադրված է nginx կոնտեյների մեջ, որն ապահովում է ստատիկ տվյալներ։

Nginx-ի և mysql-ի կոնֆիգուրացիան պահելու համար մենք ավելացրել ենք Docker թղթապանակ, որտեղ մենք պահում ենք անհրաժեշտ կոնֆիգուրացիաները: Երբ ծրագրավորողը իր մեքենայի վրա ստեղծում է պահեստի git կլոն, նա արդեն ունի տեղական զարգացման համար պատրաստ նախագիծ: Հարց չկա, թե որ նավահանգիստը կամ որ կարգավորումները կիրառել:

Հաջորդը մենք ունենք մի քանի բաղադրիչ՝ admin, info-API, push notifications:

Այս ամենը գործարկելու համար մենք ստեղծեցինք մեկ այլ պահեստ, որը կոչվում է dockerized-app: Մենք ներկայումս օգտագործում ենք մի քանի պահեստներ յուրաքանչյուր բաղադրիչի համար: Նրանք պարզապես տրամաբանորեն տարբեր են. GitLab-ում այն ​​կարծես թղթապանակ լինի, բայց մշակողի մեքենայի վրա այն կարծես թղթապանակ լինի կոնկրետ նախագծի համար: Մեկ մակարդակից ցածր այն բաղադրիչներն են, որոնք կմիավորվեն:

Սա dockerized-app-ի բովանդակության օրինակ է: Այստեղ մենք նաև տեղադրում ենք Docker գրացուցակ, որտեղ լրացնում ենք բոլոր բաղադրիչների փոխազդեցության համար անհրաժեշտ կոնֆիգուրացիաները: Կա README.md, որը հակիրճ նկարագրում է, թե ինչպես սկսել նախագիծը:

Այստեղ մենք կիրառել ենք երկու docker-compose ֆայլ: Դա արվում է, որպեսզի հնարավոր լինի մեկնարկել փուլերով։ Երբ մշակողը աշխատում է միջուկի հետ, նրան Push ծանուցումներ պետք չեն, նա պարզապես գործարկում է docker-compose ֆայլը և, համապատասխանաբար, ռեսուրսները պահպանվում են։

Եթե ​​Push ծանուցումների հետ ինտեգրվելու անհրաժեշտություն կա, ապա գործարկվում են docker-compose.yaml և docker-compose-push.yaml:

Քանի որ docker-compose.yaml և docker-compose-push.yaml գտնվում են թղթապանակում, ավտոմատ կերպով ստեղծվում է մեկ վիրտուալ ցանց:

Բաղադրիչների նկարագրությունը. Սա ավելի առաջադեմ ֆայլ է, որը պատասխանատու է բաղադրիչների հավաքման համար: Ի՞նչն է ուշագրավ այստեղ: Այստեղ մենք ներկայացնում ենք հավասարակշռող բաղադրիչը:

Սա պատրաստի Docker պատկեր է, որն աշխատում է nginx-ով և հավելված, որը լսում է Docker վարդակից: Դինամիկ, քանի որ բեռնարկղերը միացվում և անջատվում են, nginx կոնֆիգուրը վերականգնվում է: Մենք բաշխում ենք բաղադրիչների կառավարումը` օգտագործելով երրորդ մակարդակի տիրույթի անունները:

Զարգացման միջավայրի համար մենք օգտագործում ենք .dev տիրույթը՝ api.informer.dev: .dev տիրույթով հավելվածները հասանելի են մշակողի տեղական մեքենայի վրա:

Այնուհետև կոնֆիգուրացիաները փոխանցվում են յուրաքանչյուր նախագծին, և բոլոր նախագծերը միաժամանակ գործարկվում են միասին:

Եթե ​​գրաֆիկորեն պատկերենք, կստացվի, որ հաճախորդը մեր բրաուզերն է կամ ինչ-որ գործիք, որով մենք հարցումներ ենք անում հավասարակշռողին։

Հավասարակշռիչը որոշում է, թե որ կոնտեյներով է անհրաժեշտ մուտք գործել՝ ելնելով տիրույթի անունից:

Սա կարող է լինել nginx-ը, որը JS է տրամադրում ադմինիստրատորի վահանակին: Դա կարելի է անել nginx-ի միջոցով, որն ապահովում է API-ն կամ ստատիկ ֆայլերը, որոնք տրամադրվում են nginx-ի կողմից՝ պատկերների բեռնման տեսքով:

Դիագրամը ցույց է տալիս, որ բեռնարկղերը միացված են վիրտուալ ցանցին և թաքնված են վստահված անձի հետևում:

Մշակողի մեքենայի վրա դուք կարող եք մուտք գործել կոնտեյներ՝ իմանալով IP-ն, բայց սկզբունքորեն մենք դա չենք օգտագործում: Գործնականում ուղղակի շփման կարիք չկա։

Ի՞նչ օրինակ պետք է նայեմ՝ իմ դիմումը հաստատելու համար: Իմ կարծիքով, լավ օրինակ է MySQL-ի պաշտոնական դոկերի պատկերը:

Դա բավականին բարդ է: Տարբերակները շատ են։ Բայց դրա ֆունկցիոնալությունը թույլ է տալիս ծածկել բազմաթիվ կարիքներ, որոնք կարող են առաջանալ հետագա զարգացման գործընթացում: Եթե ​​դուք ժամանակ հատկացնեք և հասկանաք, թե ինչպես է այդ ամենը փոխազդում, ապա կարծում եմ, որ դուք ինքներդ որևէ խնդիր չեք ունենա այն իրականացնելու համար:

Hub.docker.com-ը սովորաբար պարունակում է հղումներ դեպի github.com, որտեղ ուղղակիորեն տրամադրվում են չմշակված տվյալներ, որոնցից դուք կարող եք ինքներդ պատկեր ստեղծել:

Հետագայում այս պահոցում կա սկրիպտ docker-endpoint.sh, որը պատասխանատու է հավելվածի գործարկման սկզբնական սկզբնավորման և հետագա մշակման համար:

Նաև այս օրինակում կա կոնֆիգուրացիայի հնարավորություն՝ օգտագործելով շրջակա միջավայրի փոփոխականները: Սահմանելով շրջակա միջավայրի փոփոխական մեկ կոնտեյներ կամ docker-compose-ի միջոցով, մենք կարող ենք ասել, որ մենք պետք է դատարկ գաղտնաբառ դնենք Docker-ի համար MySQL-ում կամ ինչ ուզում ենք root-ի համար:

Կա պատահական գաղտնաբառ ստեղծելու տարբերակ: Մենք ասում ենք, որ մեզ օգտատեր է պետք, օգտվողի համար պետք է գաղտնաբառ սահմանել, և մենք պետք է ստեղծենք տվյալների բազա։

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

Սա օրինակ է, թե ինչպիսի տեսք ունի MySQL-ի կոնկրետ տարբերակը github.com-ում: Դուք կարող եք բացել Dockerfile-ը և տեսնել, թե ինչպես է տեղադրումը կատարվում այնտեղ։

docker-endpoint.sh սկրիպտը, որը պատասխանատու է մուտքի կետի համար: Սկզբնական սկզբնավորման ժամանակ պահանջվում են որոշ նախապատրաստական ​​գործողություններ, և այս բոլոր գործողությունները ներառված են սկզբնավորման սկրիպտում:

Անցնենք երկրորդ մասին։

Մենք անցանք gitlab-ին՝ աղբյուրի կոդերը պահելու համար: Սա բավականին հզոր համակարգ է, որն ունի տեսողական ինտերֆեյս:

Gitlab-ի բաղադրիչներից մեկը Gitlab CI-ն է: Այն թույլ է տալիս նկարագրել մի շարք հրամաններ, որոնք հետագայում կօգտագործվեն կոդերի առաքման համակարգ կազմակերպելու կամ ավտոմատ թեստավորում իրականացնելու համար:

Զեկույց Gitlab CI 2-ի մասին https://goo.gl/uohKjI — Ռուբի Ռոսիա ակումբի զեկույցը բավականին մանրամասն է և կարող է հետաքրքրել ձեզ:

Այժմ մենք կանդրադառնանք, թե ինչ է պահանջվում Gitlab CI-ն ակտիվացնելու համար: Gitlab CI-ն գործարկելու համար մենք պարզապես պետք է .gitlab-ci.yml ֆայլը դնենք նախագծի արմատում:

Այստեղ մենք նկարագրում ենք, որ մենք ցանկանում ենք կատարել վիճակների հաջորդականություն, ինչպիսիք են փորձարկումը, տեղակայումը:

Մենք կատարում ենք սկրիպտներ, որոնք ուղղակիորեն կանչում են մեր հավելվածի docker-compose build-ը: Սա պարզապես հետնամասի օրինակ է:

Հաջորդիվ ասում ենք, որ անհրաժեշտ է միգրացիաներ գործարկել տվյալների բազան փոխելու և թեստեր գործարկելու համար։

Եթե ​​սկրիպտները ճիշտ են կատարվում և սխալի կոդ չեն վերադարձնում, ապա համակարգը անցնում է տեղակայման երկրորդ փուլին:

Ներկայում տեղակայման փուլն իրականացվում է բեմադրության համար։ Մենք առանց ընդհատման վերագործարկում չենք կազմակերպել։

Մենք ստիպողաբար մարում ենք բոլոր տարաները, այնուհետև նորից բարձրացնում ենք բոլոր տարաները՝ հավաքված առաջին փուլում փորձարկման ժամանակ։

Եկեք գործարկենք տվյալների բազայի միգրացիաները, որոնք գրվել են մշակողների կողմից ընթացիկ փոփոխական միջավայրի համար:

Նշում կա, որ սա պետք է կիրառվի միայն գլխավոր մասնաճյուղի համար:

Չի աշխատում այլ ճյուղեր փոխելիս:

Հնարավոր է կազմակերպել տեղաբաշխումներ ճյուղերի երկայնքով:

Սա հետագայում կազմակերպելու համար մենք պետք է տեղադրենք Gitlab Runner-ը:

Այս օգտակար ծրագիրը գրված է Golang-ով: Դա մեկ ֆայլ է, ինչպես սովորական է Golang աշխարհում, որը չի պահանջում որևէ կախվածություն:

Գործարկման ժամանակ մենք գրանցում ենք Gitlab Runner-ը:

Մենք բանալին ստանում ենք Gitlab վեբ ինտերֆեյսում:

Այնուհետև մենք կանչում ենք նախնականացման հրամանը հրամանի տողում:

Gitlab Runner-ի կարգավորում երկխոսության ռեժիմում (Shell, Docker, VirtualBox, SSH)

Gitlab Runner-ի կոդը կգործարկվի յուրաքանչյուր կատարման դեպքում՝ կախված .gitlab-ci.yml կարգավորումից:

Ինչպես է այն տեսողական տեսք Gitlab-ում վեբ ինտերֆեյսի մեջ: GItlab CI-ին միացնելուց հետո մենք ունենք դրոշակ, որը ցույց է տալիս, թե ինչ վիճակում է կառուցումը տվյալ պահին:

Մենք տեսնում ենք, որ 4 րոպե առաջ կատարվել է պարտավորություն, որն անցել է բոլոր թեստերը և որևէ խնդիր չի առաջացրել։

Մենք կարող ենք ավելի մանրամասն դիտարկել շինությունները: Այստեղ մենք տեսնում ենք, որ երկու պետություն արդեն անցել է. Փորձարկման կարգավիճակը և տեղակայման կարգավիճակը բեմականացման ժամանակ:

Եթե ​​մենք սեղմենք կոնկրետ build-ի վրա, կլինեն հրամանների կոնսոլային ելք, որոնք գործարկվել են գործընթացում՝ համաձայն .gitlab-ci.yml:

Ահա թե ինչ տեսք ունի մեր արտադրանքի պատմությունը: Մենք տեսնում ենք, որ հաջող փորձեր են եղել։ Երբ թեստերը ներկայացվում են, դրանք չեն անցնում հաջորդ քայլին, և բեմականացման կոդը չի թարմացվում:

Ի՞նչ խնդիրներ լուծեցինք բեմադրության մեջ, երբ ներդրեցինք docker-ը: Մեր համակարգը բաղկացած է բաղադրիչներից, և մենք պետք է վերագործարկեինք միայն որոշ բաղադրիչներ, որոնք թարմացվել են պահեստում, և ոչ ամբողջ համակարգը:

Դա անելու համար մենք պետք է ամեն ինչ առանձնացնեինք առանձին թղթապանակների մեջ:

Դա անելուց հետո մենք խնդիր ունեցանք այն փաստի հետ, որ Docker-compose-ը ստեղծում է իր ցանցային տարածքը յուրաքանչյուր թղթապանակի համար և չի տեսնում իր հարևանի բաղադրիչները:

Շրջելու համար մենք ձեռքով ստեղծեցինք ցանցը Docker-ում: Docker-compose-ում գրված էր, որ այս նախագծի համար պետք է օգտագործել նման ցանց։

Այսպիսով, յուրաքանչյուր բաղադրիչ, որը սկսվում է այս ցանցից, տեսնում է բաղադրիչները համակարգի այլ մասերում:

Հաջորդ խնդիրը բեմադրությունը մի քանի նախագծերի միջև բաժանելն է։

Քանի որ այս ամենը գեղեցիկ տեսք ունենալու և արտադրությանը հնարավորինս մոտ լինելու համար լավ է օգտագործել 80 կամ 443 պորտը, որն օգտագործվում է WEB-ում ամենուր:

Ինչպե՞ս լուծեցինք սա: Մենք նշանակեցինք մեկ Gitlab Runner բոլոր խոշոր նախագծերին:

Gitlab-ը թույլ է տալիս գործարկել մի քանի բաշխված Gitlab Runners, որոնք ուղղակի քաոսային կարգով մեկ առ մեկ կվերցնեն բոլոր առաջադրանքները և կաշխատեն դրանք:

Տնային խնդիրներից խուսափելու համար մենք սահմանափակեցինք մեր նախագծերի խումբը մեկ Gitlab Runner-ով, որն առանց խնդիրների հաղթահարում է մեր ծավալները:

Մենք nginx-proxy-ն տեղափոխեցինք գործարկման առանձին սցենար և գրեցինք բոլոր նախագծերի ցանցերը դրանում:

Մեր նախագիծն ունի մեկ ցանց, իսկ հավասարակշռողն ունի մի քանի ցանցեր՝ հիմնված նախագծերի անվանումների վրա: Այն կարող է հետագայում վստահված լինել տիրույթի անուններով:

Մեր հարցումները գալիս են 80 նավահանգստի տիրույթի միջոցով և լուծվում են այս տիրույթը սպասարկող կոնտեյներների խմբին:

Էլ ի՞նչ խնդիրներ կային։ Սա այն է, ինչ բոլոր բեռնարկղերը լռելյայնորեն աշխատում են որպես արմատ: Սա համակարգի արմատային անհավասար արմատային տանտերն է:

Այնուամենայնիվ, եթե մուտքագրեք կոնտեյներ, այն կլինի root, և ֆայլը, որը մենք ստեղծում ենք այս կոնտեյներով, ստանում է արմատային իրավունքներ:

Եթե ​​ծրագրավորողը մտել է կոնտեյներ և այնտեղ ինչ-որ հրամաններ է կատարել, որոնք ֆայլեր են գեներացնում, այնուհետև լքել կոնտեյները, ապա իր աշխատանքային գրացուցակում նա ունի ֆայլ, որին նա մուտք չունի։

Ինչպե՞ս կարող է սա լուծվել: Դուք կարող եք ավելացնել օգտվողներ, ովքեր կլինեն կոնտեյներով:

Ի՞նչ խնդիրներ առաջացան, երբ ավելացրինք օգտվողին:

Օգտատեր ստեղծելիս խմբի ID-ն (UID) և օգտվողի ID-ն (GID) հաճախ չեն համընկնում:

Կոնտեյների մեջ այս խնդիրը լուծելու համար մենք օգտագործում ենք ID 1000 օգտվողներ:

Մեր դեպքում դա համընկավ այն փաստի հետ, որ գրեթե բոլոր մշակողները օգտագործում են Ubuntu OS: Իսկ Ubuntu OS-ում առաջին օգտատերն ունի ID 1000։

Մենք ունե՞նք ծրագրեր։

Կրկին կարդացեք Docker-ի փաստաթղթերը: Նախագիծն ակտիվորեն զարգանում է, փաստաթղթերը փոխվում են։ Երկու-երեք ամիս առաջ ստացված տվյալները կամաց-կամաց դառնում են հնացած։

Որոշ խնդիրներ, որոնք մենք լուծեցինք, միգուցե արդեն իսկ լուծված են ստանդարտ միջոցներով։

Ես իսկապես ուզում եմ առաջ շարժվել և ուղղակիորեն անցնել նվագախմբին:

Օրինակներից մեկը Docker-ի ներկառուցված մեխանիզմն է, որը կոչվում է Docker Swarm, որը դուրս է գալիս տուփից: Ես կցանկանայի Docker Swarm տեխնոլոգիայի հիման վրա ինչ-որ բան գործարկել արտադրության մեջ:

Բեռնարկղերի ձվադրումը անհարմար է դարձնում գերանների հետ աշխատելը: Այժմ գերանները մեկուսացված են: Նրանք ցրված են տարաների մեջ: Խնդիրներից մեկը վեբ ինտերֆեյսի միջոցով տեղեկամատյաններին հարմար մուտք ապահովելն է:

Source: www.habr.com