Моно-репозиторий темасы бир нече жолу талкууланган жана, эреже катары, абдан активдүү талаш-тартыштарды жаратат. түзүү менен Gitтен Docker сүрөттөрүнө тиркеме кодун түзүү процессин өркүндөтүү үчүн иштелип чыккан ачык булак куралы катары (андан кийин аларды Kubernetesке жеткирүү), биз кайсы тандоо эң жакшы экендиги жөнүндө көп ойлонбойбуз. Биз үчүн ар кандай пикирлердин жактоочулары үчүн зарыл болгон нерселердин бардыгын камсыз кылуу биринчи орунда турат (эгер бул, албетте, акыл-эске карама-каршы келбесе).
werf жакында моно-репо колдоосу мунун жакшы мисалы болуп саналат. Бирок, адегенде, келгиле, бул колдоо жалпысынан werf колдонуу менен кандай байланышы бар экенин жана Докер реестринин ага кандай тиешеси бар экенин аныктап көрөлү ...
Маселелер
Мындай абалды элестетип көрөлү. Компаниянын көз карандысыз долбоорлордун үстүндө иштеген көптөгөн өнүктүрүү топтору бар. Көпчүлүк тиркемелер Kubernetesте иштейт жана ошондуктан контейнерде болот. Контейнерлерди, сүрөттөрдү сактоо үчүн реестр (регистр) керек. Мындай реестр катары компания Docker Hubды бир эсеп менен колдонот COMPANY. Көпчүлүк баштапкы кодду сактоо тутумдарына окшош, Docker Hub уяланган репозиторий иерархиясына жол бербейт, сыяктуу COMPANY/PROJECT/IMAGE. Андай учурда… ар бир долбоор үчүн өзүнчө эсеп түзбөй туруп, бул чектөө менен реестрде монолиттүү эмес тиркемелерди кантип сактай аласыз?
Мүмкүн, сүрөттөлгөн жагдай кимдир бирөөнө тааныш болсо керек, бирок келгиле, жалпысынан тиркемени сактоону уюштуруу маселесин карап көрөлү, б.а. жогорудагы мисалга жана Docker Hubга шилтемесиз.
Чечимдер
Колдонмо болсо монолиттүү, бир сүрөттөлүштө келет, анда эч кандай суроолор жок жана биз сүрөттөрдү долбоордун контейнер реестрине сактап коёбуз.
Колдонмо бир нече компоненттер катары берилгенде, микросервис, анда белгилүү бир мамиле талап кылынат. Эки сүрөттөн турган типтүү веб-тиркеме мисалында: frontend и backend - мүмкүн болгон варианттар:
- Сүрөттөрдү өзүнчө сакталган репозиторийлерде сактаңыз:
- Баарын бир репозиторийде сактаңыз жана тегдеги сүрөттүн атын карап көрүңүз, мисалы, төмөнкүдөй:
NB: Чынында, ар кандай репозиторийлерде сактоо менен дагы бир вариант бар, PROJECT-frontend и PROJECT-backend, бирок биз аны колдоонун, уюштуруунун жана колдонуучулардын ортосунда укуктарды бөлүштүрүүнүн татаалдыгынан улам эске албайбыз.
werf колдоо
Башында, werf уя салынган репозиторийлер менен чектелди - бактыга жараша, көпчүлүк реестрлер бул функцияны колдошот. Версиясынан баштап , кайсы реестрлер менен иштөөнү кошкон уя салуу колдоого алынбайт, жана Docker Hub алардын бири. Ошол учурдан тартып, колдонуучу колдонмонун сүрөттөрүн кантип сактоону тандап алат.
Ишке ашыруу опциясы боюнча жеткиликтүү --images-repo-mode=multirepo|monorepo (демейки multirepo, б.а. уя салынган репозиторийлерде сактоо). Ал сүрөттөр реестрде сакталган үлгүлөрдү аныктайт. Негизги буйруктарды колдонууда керектүү режимди тандоо жетиштүү, калганынын баары өзгөрүүсүз калат.
Анткени көпчүлүк werf параметрлерин коюуга болот чөйрө өзгөрмөлөрү, CI / CD тутумдарында сактоо режимин бүткүл долбоор үчүн глобалдык деңгээлде орнотуу оңой. Мисалы, GitLab учурда жөн гана долбоордун жөндөөлөрүнө чөйрө өзгөрмө кошуу: Орнотуулар -> CI / CD -> Өзгөрмөлөр: WERF_IMAGES_REPO_MODE: multirepo|monorepo.
Эгерде биз сүрөттөрдү жарыялоо жана тиркемелерди жайылтуу жөнүндө сөз кыла турган болсок (бул процесстер жөнүндө тиешелүү документация макалаларында кеңири окуй аласыз: и ), анда режим сиз сүрөт менен иштей турган шаблонду гана аныктайт.
Шайтан майда-чүйдөсүнө чейин
Жаңы сактоо ыкмасын кошууда айырма жана негизги кыйынчылык - реестрди тазалоо процессинде (werf тарабынан колдоого алынган тазалоо функциялары үчүн караңыз ).
Тазалоодо werf Kubernetes кластерлеринде колдонулган сүрөттөрдү, ошондой эле колдонуучу конфигурациялаган саясаттарды эске алат. Саясат тегдерди стратегияларга бөлүүгө негизделген. Учурда колдоого алынган стратегиялар:
- Git примитивдери менен байланышкан 3 стратегия, мисалы, тег, бутак жана ишке ашыруу;
- 1 стратегия.
Биз сүрөттү акыркы сүрөттүн этикеткаларында жарыялоодо тег стратегиясы жөнүндө маалыматты сактайбыз. Мааниси өзү деп аталат мета тег - Кээ бир саясаттарды колдонуу талап кылынат. Мисалы, Git репозиторийинен бутакты же тегди жок кылууда, ага байланыштуу жок кылуу логикага ылайыктуу пайдаланылбаган биздин саясаттарыбыздын бир бөлүгү камтылган реестрдеги сүрөттөр.
Бир репозиторийде сакталганда (monorepo), сүрөт тегинде мета тегден тышкары, сүрөттүн аталышы да сакталышы мүмкүн: PROJECT:frontend-META-TAG. Аларды бөлүү үчүн биз кандайдыр бир конкреттүү бөлгүчтү киргизген жокпуз, жөн гана жарыялоодо акыркы сүрөттүн этикеткасына керектүү маанини коштук.
NB: Эгерде сиз werf булак кодунда сүрөттөлгөн нерселердин бардыгын көргүңүз келсе, анда баштапкы чекит болушу мүмкүн .
Бул макалада биз көйгөйлөргө жана мамилебиздин негиздерине көбүрөөк көңүл бурбайбыз: стратегияларды белгилөө, маалыматтарды этикеткаларда сактоо жана жалпысынан жарыялоо процесси - мунун бардыгы Дмитрий Столяровдун жакында жасаган баяндамасында кеңири сүрөттөлгөн: "«.
Кыскача айтканда
Кыштырылбаган реестрлерди колдоонун жоктугу биз үчүн же бизге белгилүү болгон werf колдонуучулары үчүн бөгөттөөчү фактор болгон эмес - сиз ар дайым өзүнчө сүрөт реестрин түзө аласыз (же Google Булуттагы шарттуу Контейнер Реестрине которула аласыз) ... Бирок, Мындай чектөөнү алып салуу куралдын кеңири DevOps коомчулугуна ыңгайлуу болушу үчүн логикалык көрүндү. Аны ишке ашырууда биз контейнер реестрин тазалоо механизмин кайра иштеп чыгууда негизги кыйынчылыкка туш болдук. Эми баары даяр болгондон кийин, бул кимдир бирөө үчүн жеңил болуп калганын түшүнүү жагымдуу жана биз (долбоордун негизги иштеп чыгуучулары катары) бул функцияны мындан ары колдоодо эч кандай олуттуу кыйынчылыктарга дуушар болбойбуз.
Биз менен болуңуз жана жакында биз сизге башка инновациялар тууралуу айтып беребиз !
PS
Биздин блогдон дагы окуңуз:
- «";
- ««.
Source: www.habr.com