🥇Werf коллекторунда мазмунга негизделген тег: эмне үчүн жана кантип иштейт?

werf тиркемелерди куруу жана Kubernetesке жеткирүү үчүн биздин ачык булак GitOps CLI утилитабыз. IN v1.1 чыгаруу Сүрөт жыйноочуга жаңы функция киргизилди: сүрөттөрдү мазмуну боюнча белгилөө же мазмунга негизделген белгилөө. Ушул убакка чейин werfтеги типтүү тегдөө схемасы Git теги, Git филиалы же Git commit аркылуу Docker сүрөттөрүн белгилөөнү камтыган. Бирок бул схемалардын бардыгынын кемчиликтери бар, алар жаңы белгилөө стратегиясы менен толугу менен чечилет. Бул тууралуу кенен маалымат жана эмне үчүн ал мынчалык жакшы экени кыскартылган.

Бир Git репозиторийинен микросервистердин топтомун чыгаруу

Кырдаал көп учурда колдонмо аздыр-көптүр көз карандысыз кызматтарга бөлүнгөндө пайда болот. Бул кызматтардын релиздери өз алдынча болушу мүмкүн: бир же бир нече кызматтарды бир убакта чыгарууга болот, калгандары эч кандай өзгөрүүсүз иштей бериши керек. Бирок кодду сактоо жана долбоорду башкаруу көз карашынан алганда, мындай тиркеме кызматтарын бирдиктүү репозиторийде сактоо ыңгайлуу.

Кызматтар чындап эле көз карандысыз жана бир тиркеме менен байланышпаган учурлар бар. Бул учурда, алар өзүнчө долбоорлордо жайгаштырылат жана аларды чыгаруу долбоорлордун ар биринде өзүнчө CI/CD процесстери аркылуу ишке ашырылат.

Бирок, чындыгында, иштеп чыгуучулар көп учурда бир тиркемени бир нече микросервистерге бөлүшөт, бирок ар бири үчүн өзүнчө репозиторий жана долбоорду түзүү... анык ашыкча. Дал ушул жагдай андан ары талкууланат: бир нече мындай микросервистер бир долбоордун репозиторийинде жайгашкан жана чыгаруулар CI/CDдеги бир процесс аркылуу ишке ашат.

Git филиалы жана Git теги боюнча тегдөө

Келгиле, эң кеңири таралган белгилөө стратегиясы колдонулат дейли - тег же бутак. Гит бутактары үчүн сүрөттөр филиалдын аты менен белгиленет, бир эле учурда бир бутак үчүн ошол бутактын аты менен бир гана жарыяланган сүрөт бар. Git тегдери үчүн сүрөттөр тег атына ылайык белгиленет.

Жаңы Git теги түзүлгөндө, мисалы, жаңы версия чыкканда, Докер реестриндеги бардык долбоордун сүрөттөрү үчүн жаңы Docker теги түзүлөт:

myregistry.org/myproject/frontend:v1.1.10
myregistry.org/myproject/myservice1:v1.1.10
myregistry.org/myproject/myservice2:v1.1.10
myregistry.org/myproject/myservice3:v1.1.10
myregistry.org/myproject/myservice4:v1.1.10
myregistry.org/myproject/myservice5:v1.1.10
myregistry.org/myproject/database:v1.1.10

Бул жаңы сүрөт аттары Helm үлгүлөрү аркылуу Kubernetes конфигурациясына өткөрүлөт. буйрук менен жайгаштырууну баштаганда werf deploy талаа жаңыланууда image Kubernetes ресурсундагы манифесттер жана өзгөртүлгөн сүрөттүн аталышына байланыштуу тиешелүү ресурстарды кайра иштетүү.

маселе: чындыгында сүрөттүн мазмуну мурунку жайылтуудан бери өзгөрбөсө (Git теги), бирок анын Докер теги гана болсо, бул болот ашыкча бул колдонмону кайра баштоо жана, демек, кээ бир иштебей калуу мүмкүн. Бул кайра иштетүү үчүн эч кандай реалдуу себеп жок болсо да.

Натыйжада, учурдагы тегдөө схемасы менен бир нече өзүнчө Git репозиторийлерин тосуу керек жана бул бир нече репозиторийлердин жайылышын уюштуруу маселеси келип чыгат. Жалпысынан алганда, мындай схема ашыкча жана татаал болуп чыгат. Көптөгөн кызматтарды бир репозиторийге бириктирип, керексиз кайра иштетүүлөр болбошу үчүн Docker тэгдерин түзүү жакшыраак.

Git commit тарабынан белгилөө

werf ошондой эле Git commits менен байланышкан белгилөө стратегиясына ээ.

Git-commit бул Git репозиторийинин мазмунунун идентификатору жана Git репозиторийиндеги файлдардын түзөтүү тарыхынан көз каранды, ошондуктан аны Docker реестриндеги сүрөттөрдү белгилөө үчүн колдонуу логикалык көрүнөт.

Бирок, Git commit тарабынан тег коюунун Git бутактары же Git тегдери менен тегдөө сыяктуу кемчиликтери бар:

Эч кандай файлдарды өзгөртпөгөн бош тапшырма түзүлүшү мүмкүн, бирок сүрөттүн Docker теги өзгөрөт.
Файлдарды өзгөртпөгөн бириктирүү тапшырмасы түзүлүшү мүмкүн, бирок сүрөттүн Docker теги өзгөрөт.
Сүрөткө импорттолбогон Git файлдарын өзгөртүү боюнча милдеттенме кабыл алынышы мүмкүн жана сүрөттүн Docker теги кайра өзгөртүлөт.

Гит филиалынын аталышын тегдөө сүрөттүн версиясын чагылдырбайт

Git бутактары үчүн белгилөө стратегиясы менен байланышкан дагы бир көйгөй бар.

Тармактын аталышы боюнча белгилөө ошол бутак боюнча милдеттенмелер хронологиялык тартипте ырааттуу чогултулганда иштейт.

Эгерде учурдагы схемада колдонуучу белгилүү бир бутак менен байланышкан эски милдеттенмени калыбына келтире баштаса, анда werf эски милдеттенме үчүн сүрөттүн жаңы курулган версиясы менен тиешелүү Docker теги менен сүрөттү кайра жазат. Мындан ары бул тегди колдонгон жайылтуулар подкасттарды кайра иштетүүдө сүрөттүн башка версиясын тартып алуу коркунучун жаратат, натыйжада биздин тиркеме CI системасы менен байланышын жоготуп, синхрондолуп калат.

Кошумчалай кетсек, алардын ортосундагы кыска убакыт аралыгы менен бир бутакка ырааттуу түртүүлөр менен, эски милдеттенме жаңысына караганда кечирээк түзүлүшү мүмкүн: сүрөттүн эски версиясы Git бутагынын тегин колдонуу менен жаңысынын үстүнөн жазат. Мындай көйгөйлөрдү CI/CD системасы менен чечсе болот (мисалы, GitLab CIде акыркысынын түтүгү бир катар тапшырмалар үчүн ишке киргизилген). Бирок, бардык системалар муну колдой бербейт жана мындай фундаменталдуу көйгөйдү алдын алуунун ишенимдүү жолу болушу керек.

Мазмунга негизделген белгилөө деген эмне?

Ошентип, мазмунга негизделген тег деген эмне - сүрөттөрдү мазмун боюнча белгилөө.

Докер тегдерин түзүү үчүн Git примитивдери (Git бутагы, Git теги...) эмес, төмөнкүгө байланыштуу текшерүү суммасы колдонулат:

сүрөттүн мазмуну. Сүрөт ID теги анын мазмунун чагылдырат. Жаңы версияны курууда бул идентификатор эгер сүрөттөгү файлдар өзгөрбөсө өзгөрбөйт;
Гитте бул сүрөттү түзүү тарыхы. Ар кандай Git бутактары жана werf аркылуу ар кандай куруу тарыхы менен байланышкан сүрөттөрдө ар кандай ID тэгдери болот.

Мындай идентификатор теги деп аталган сүрөт баскычынын кол тамгасы.

Ар бир сүрөт бир нече этаптан турат: from, before-install, git-archive, install, imports-after-install, before-setup, ... git-latest-patch жана башкалар. Ар бир этапта анын мазмунун чагылдырган идентификатор бар сахналык кол коюу (этап кол коюу).

Бул этаптардан турган акыркы сүрөт, бул этаптардын жыйындысы деп аталган кол тамга менен белгиленет - кол коюу этаптары, - сүрөттүн бардык баскычтары үчүн жалпылоочу.

Конфигурациядагы ар бир сүрөт үчүн werf.yaml жалпы учурда, өзүнүн колтамгасы жана ошого жараша Docker теги болот.

Этап кол бул көйгөйлөрдүн баарын чечет:

Бош Git милдеттенмелерине туруктуу.
Git'ке туруштук берүү, сүрөткө тиешеси жок файлдарды өзгөртүүгө милдеттүү.
Филиалдын эски Git тапшырмалары үчүн түзүүнү кайра баштоодо сүрөттүн учурдагы версиясын оңдоо көйгөйүнө алып келбейт.

Бул азыр сунушталган белгилөө стратегиясы жана бардык CI системалары үчүн werfде демейки болуп саналат.

werfте кантип иштетүү жана колдонуу керек

Эми команданын тиешелүү варианты бар werf publish: --tag-by-stages-signature=true|false

CI системасында белгилөө стратегиясы буйрук тарабынан аныкталат werf ci-env. Буга чейин ал үчүн параметр аныкталган werf ci-env --tagging-strategy=tag-or-branch. Эми, тактап берсеңиз werf ci-env --tagging-strategy=stages-signature же бул параметрди көрсөтпөсөңүз, werf демейки боюнча тегдөө стратегиясын колдонот stages-signature. Command werf ci-env автоматтык түрдө буйрук үчүн керектүү желектерди орнотот werf build-and-publish (же werf publish), ошондуктан бул буйруктар үчүн кошумча опцияларды көрсөтүүнүн кереги жок.

Мисалы, буйрук:

werf publish --stages-storage :local --images-repo registry.hello.com/web/core/system --tag-by-stages-signature

... төмөнкү сүрөттөрдү түзө алат:

registry.hello.com/web/core/system/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d
registry.hello.com/web/core/system/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6

бул 4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d - бул сүрөттүн этаптарынын кол тамгасы backendжана f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6 - сүрөт этаптарына кол коюу frontend.

Атайын функцияларды колдонууда werf_container_image и werf_container_env Helm шаблондорунда эч нерсени өзгөртүүнүн кереги жок: бул функциялар автоматтык түрдө туура сүрөт аталыштарын жаратат.

CI системасындагы конфигурациянын мисалы:

type multiwerf && source <(multiwerf use 1.1 beta)
type werf && source <(werf ci-env gitlab)
werf build-and-publish|deploy

Конфигурация боюнча көбүрөөк маалымат документацияда бар:

жалпы

Жаңы опция werf publish --tag-by-stages-signature=true|false.
Жаңы опциянын мааниси werf ci-env --tagging-strategy=stages-signature|tag-or-branch (эгер көрсөтүлбөсө, демейки болот stages-signature).
Эгер сиз мурда Git commits үчүн белгилөө опцияларын колдонгон болсоңуз (WERF_TAG_GIT_COMMIT же опция werf publish --tag-git-commit COMMIT), анда белгилөө стратегиясына өтүүнү унутпаңыз этаптары-кол коюу.
Жаңы долбоорлорду жаңы белгилөө схемасына дароо которуу жакшы.
werf 1.1ге өтүүдө эски долбоорлорду жаңы белгилөө схемасына которуу сунушталат, бирок эски тег же бутак дагы эле колдоого алынат.

Мазмунга негизделген белгилөө макалада каралган бардык маселелерди чечет:

Docker теги бош Git тапшырмаларына каршылык көрсөтүү.
Докер тегинин аталышынын Gitке туруктуулугу сүрөткө тиешеси жок файлдарды өзгөртүүгө мүмкүндүк берет.
Git бутактары үчүн эски Git милдеттенмелери үчүн түзүүнү кайра баштоодо, сүрөттүн учурдагы версиясын оңдоо көйгөйүнө алып келбейт.

Аны колдон! Жана бизге келүүнү унутпаңыз GitHubмаселени түзүү же учурдагыны табуу, плюс кошуу, PR түзүү же жөн гана долбоордун өнүгүшүн көрүү.

PS

Биздин блогдон дагы окуңуз:

Source: www.habr.com

werf куруучудагы мазмунга негизделген тег: эмне үчүн жана кантип иштейт?