Մոնո-պահեստի թեման մեկ անգամ չէ, որ քննարկվել է և, որպես կանոն, շատ ակտիվ հակասություններ է առաջացնում։ Ստեղծելով որպես բաց կոդով գործիք, որը նախատեսված է Git-ից մինչև Docker պատկերներ կիրառական կոդի ստեղծման գործընթացը բարելավելու համար (և այնուհետև դրանք Kubernetes հասցնելու համար), մենք շատ չենք մտածում, թե որն է լավագույն ընտրությունը: Մեզ համար առաջնային է ապահովել այն ամենն, ինչ անհրաժեշտ է տարբեր կարծիքների կողմնակիցների համար (եթե դա, իհարկե, չի հակասում ողջախոհությանը)։
werf-ի վերջին մոնո-ռեպո աջակցությունը դրա լավ օրինակն է: Բայց նախ, եկեք պարզենք, թե ինչպես է այս աջակցությունը ընդհանուր առմամբ կապված werf-ի օգտագործման հետ և ինչ կապ ունի Docker Registry-ը դրա հետ…
Հարցեր
Պատկերացնենք այսպիսի իրավիճակ. Ընկերությունն ունի բազմաթիվ զարգացման թիմեր, որոնք աշխատում են անկախ նախագծերի վրա: Հավելվածների մեծ մասն աշխատում է Kubernetes-ում և, հետևաբար, կոնտեյներացված է: Տարաներ, պատկերներ պահելու համար անհրաժեշտ է ռեեստր (ռեգիստր): Որպես այդպիսի ռեգիստր, ընկերությունն օգտագործում է Docker Hub-ը մեկ հաշվի հետ COMPANY. Աղբյուրի կոդերի պահպանման համակարգերի մեծ մասի նման, Docker Hub-ը թույլ չի տալիս ներկառուցված պահեստի հիերարխիա, ինչպիսիք են COMPANY/PROJECT/IMAGE. Այդ դեպքում… ինչպե՞ս կարող եք ռեեստրում պահել ոչ միաձույլ հավելվածները այս սահմանափակումով՝ առանց յուրաքանչյուր նախագծի համար առանձին հաշիվ ստեղծելու:
Թերևս նկարագրված իրավիճակը ինչ-որ մեկին ծանոթ է առաջին ձեռքից, բայց եկեք դիտարկենք ընդհանուր առմամբ հավելվածների պահեստավորման կազմակերպման հարցը, այսինքն. առանց վերը նշված օրինակին և Docker Hub-ին հղում կատարելու:
Լուծումներ
Եթե դիմումը միաձույլ, գալիս է մեկ պատկերով, այնուհետև հարցեր չկան, և մենք պարզապես պատկերները պահպանում ենք նախագծի կոնտեյների ռեեստրում։
Երբ հավելվածը ներկայացվում է որպես բազմաթիվ բաղադրիչներ, միկրոծառայություններ, ապա որոշակի մոտեցում է պահանջվում։ Երկու պատկերից բաղկացած տիպիկ վեբ հավելվածի օրինակով. frontend и backend - հնարավոր տարբերակներն են.
- Պահպանեք պատկերները առանձին տեղադրված պահոցներում.
- Պահպանեք ամեն ինչ մեկ պահոցում և պատկերի անունը դիտարկեք թեգում, օրինակ, հետևյալ կերպ.
NBՓաստորեն, կա ևս մեկ տարբերակ տարբեր պահեստներում պահելու հետ, PROJECT-frontend и PROJECT-backend, բայց մենք դա չենք դիտարկի օգտվողների միջև աջակցության, կազմակերպման և իրավունքների բաշխման բարդության պատճառով:
werf աջակցություն
Ի սկզբանե, werf-ը սահմանափակվում էր միայն տեղադրված պահոցներով. բարեբախտաբար, ռեեստրների մեծ մասն աջակցում է այս հատկությանը: Սկսած տարբերակից , ավելացրել է աշխատանք ռեեստրների հետ, որոնցում nesting-ը չի ապահովվում, և Docker Hub-ը նրանցից մեկն է: Այդ պահից սկսած, օգտվողն ունի ընտրության հնարավորություն, թե ինչպես պահել հավելվածի պատկերները:
Իրականացումը հասանելի է տարբերակի ներքո --images-repo-mode=multirepo|monorepo (կանխադրված multirepo, այսինքն. Պահպանում տեղադրված պահեստներում): Այն սահմանում է օրինաչափությունները, որոնցով պատկերները պահվում են ռեեստրում: Բավական է հիմնական հրամաններն օգտագործելիս ընտրել ցանկալի ռեժիմը, իսկ մնացած ամեն ինչ կմնա անփոփոխ։
Քանի որ werf տարբերակների մեծ մասը կարող է սահմանվել շրջակա միջավայրի փոփոխականներ, CI/CD համակարգերում պահեստավորման ռեժիմը սովորաբար հեշտ է գլոբալ սահմանել ամբողջ նախագծի համար: Օրինակ, GitLab-ի դեպքում պարզապես ծրագրի կարգավորումներում ավելացրեք շրջակա միջավայրի փոփոխական. Կարգավորումներ -> CI / CD -> Փոփոխականներ. WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Եթե մենք խոսում ենք պատկերների հրապարակման և հավելվածների տարածման մասին (այս գործընթացների մասին մանրամասն կարող եք կարդալ համապատասխան փաստաթղթերի հոդվածներում. и ), այնուհետև ռեժիմը միայն որոշում է այն ձևանմուշը, որով կարող եք աշխատել պատկերի հետ:
Սատանան մանրամասների մեջ է
Տարբերությունը և հիմնական դժվարությունը պահեստավորման նոր մեթոդ ավելացնելիս ռեեստրի մաքրման գործընթացում է (werf-ի կողմից աջակցվող մաքրման գործառույթների համար տե՛ս ).
Մաքրելիս werf-ը հաշվի է առնում Kubernetes կլաստերներում օգտագործվող պատկերները, ինչպես նաև օգտագործողի կողմից կազմաձևված կանոնները։ Քաղաքականությունը հիմնված է պիտակների ռազմավարությունների բաժանման վրա: Ներկայումս աջակցվող ռազմավարություններ.
- 3 ռազմավարություն, որոնք կապված են Git պրիմիտիվների միջոցով, ինչպիսիք են պիտակը, ճյուղը և պարտավորությունը;
- 1 ռազմավարություն կամայական մաքսային պիտակների համար:
Մենք պահպանում ենք պիտակի ռազմավարության մասին տեղեկատվությունը վերջնական պատկերի պիտակներում պատկերը հրապարակելիս: Իմաստն ինքնին այսպես կոչված է մետա թեգ - Պահանջվում է կիրառել որոշ քաղաքականություններ: Օրինակ, երբ ջնջում եք մասնաճյուղ կամ պիտակ Git պահոցից, տրամաբանական է ջնջել առնչվող չօգտագործված պատկերներ գրանցամատյանից, որը ծածկված է մեր քաղաքականության մի մասով:
Երբ պահվում է մեկ պահոցում (monorepo), պատկերի թեգում, մետա թեգից բացի, կարող է պահպանվել նաև պատկերի անունը. PROJECT:frontend-META-TAG. Դրանք առանձնացնելու համար մենք չենք ներկայացրել որևէ կոնկրետ տարանջատիչ, այլ պարզապես հրապարակելիս վերջնական պատկերի պիտակի վրա ավելացրել ենք անհրաժեշտ արժեքը։
NBԵթե դուք հետաքրքրված եք դիտել այն ամենը, ինչ նկարագրված է werf-ի սկզբնաղբյուրում, ապա սկզբնական կետը կարող է լինել .
Այս հոդվածում մենք ավելի շատ ուշադրություն չենք դարձնի մեր մոտեցման խնդիրներին և հիմնավորմանը՝ պիտակավորման ռազմավարությունների, պիտակներում տվյալների պահպանման և ընդհանուր առմամբ հրապարակման գործընթացի մասին, այս ամենը մանրամասն նկարագրված է Դմիտրի Ստոլյարովի վերջին զեկույցում..
Ամփոփելով
Չներկայացված ռեգիստրների աջակցության բացակայությունը մեզ կամ մեզ հայտնի werf օգտատերերի համար արգելափակող գործոն չէր. ի վերջո, դուք միշտ կարող եք ստեղծել առանձին պատկերների ռեեստր (կամ անցնել պայմանական Container Registry-ին Google Cloud-ում)... Այնուամենայնիվ, Նման սահմանափակումը հեռացնելը տրամաբանական էր թվում, որպեսզի գործիքն ավելի հարմար լինի DevOps-ի ավելի լայն համայնքի համար: Իրականացնելով այն՝ մենք հանդիպեցինք կոնտեյներների ռեեստրի մաքրման մեխանիզմի վերամշակման հիմնական դժվարությանը: Այժմ, երբ ամեն ինչ պատրաստ է, հաճելի է գիտակցել, որ ինչ-որ մեկի համար դա ավելի հեշտ է դարձել, և մենք (որպես նախագծի հիմնական մշակողներ) որևէ նկատելի դժվարություն չենք ունենա այս գործառույթը հետագայում աջակցելու համար:
Մնացեք մեզ հետ և շատ շուտով մենք ձեզ կպատմենք այլ նորամուծությունների մասին !
PS
Կարդացեք նաև մեր բլոգում.
- «";
- «.
Source: www.habr.com