Մոնորեպոյի թեման բազմիցս քննարկվել է և, որպես կանոն, բավականին ակտիվ բանավեճերի տեղիք է տալիս։ Ստեղծելով Որպես բաց կոդով գործիք, որը նախատեսված է 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 պրիմիտիվների հետ, ինչպիսիք են tag, branch և commit;
- 1 ռազմավարություն մաքսային պիտակների համար:
Մենք պահում ենք պիտակների ռազմավարության մասին տեղեկությունները, երբ պատկերը հրապարակում ենք վերջնական պատկերի պիտակներում: Իմաստն ինքնին այսպես կոչված է մետա թեգ — անհրաժեշտ է որոշ քաղաքականությունների կիրառման համար։ Օրինակ, երբ ջնջում եք մասնաճյուղը կամ պիտակը Git պահեստից, իմաստ ունի ջնջել նաև հարակիցները։ չօգտագործված պատկերներ գրանցամատյանից, որը ծածկված է մեր քաղաքականության մի մասով:
Մեկ պահեստում պահելիս (monorepo), պատկերի պիտակում, բացի մետա թեգից, պատկերի անունը կարող է պահպանվել նաև. PROJECT:frontend-META-TAG. Դրանք առանձնացնելու համար մենք չենք ներկայացրել որևէ կոնկրետ տարանջատիչ, այլ պարզապես հրապարակելիս վերջնական պատկերի պիտակի վրա ավելացրել ենք անհրաժեշտ արժեքը։
NBԵթե ձեզ հետաքրքրում է այն ամենը, ինչ նկարագրված է werf-ի սկզբնաղբյուրում, ապա սկզբնական կետը կարող է լինել .
Այս հոդվածում մենք ավելի շատ ուշադրություն չենք դարձնի մեր մոտեցման խնդիրներին և հիմնավորմանը՝ պիտակավորման ռազմավարությունների, պիտակներում տվյալների պահպանման և ընդհանրապես հրապարակման գործընթացի մասին, այս ամենը մանրամասն նկարագրված է Դմիտրի Ստոլյարովի վերջին զեկույցում..
Ամփոփելով
Ոչ տեղադրվող ռեգիստրների աջակցության բացակայությունը մեզ կամ մեզ ծանոթ werf օգտատերերի համար արգելափակող գործոն չէր. ի վերջո, դուք միշտ կարող եք ստեղծել առանձին պատկերների գրանցամատյան (կամ անցնել պայմանական Container Registry-ին Google Cloud-ում)... Այնուամենայնիվ, այս սահմանափակումը հեռացնելը տրամաբանական էր թվում՝ գործիքը ավելի լայն DevOps համայնքի համար հարմար դարձնելու համար: Այն իրականացնելիս մենք հանդիպեցինք տարաների ռեեստրի մաքրման մեխանիզմի վերամշակման հիմնական դժվարությանը: Այժմ, երբ ամեն ինչ պատրաստ է, հաճելի է գիտակցել, որ ինչ-որ մեկը դա ավելի հեշտ է գտել, և մենք (որպես նախագծի հիմնական մշակողներ) չենք կանխատեսում որևէ էական դժվարություն այս հատկանիշի հետագա աջակցության համար:
Հետևեք, և մենք ձեզ մոտ ապագայում կպատմենք այլ նորամուծությունների մասին: !
PS
Կարդացեք նաև մեր բլոգում.
- «";
- «.
Source: www.habr.com
