werf 1.1 релиз: куруучунун бүгүнкү жакшыртуулары жана келечекке пландар

werf 1.1 релиз: куруучунун бүгүнкү жакшыртуулары жана келечекке пландар

werf тиркемелерди куруу жана Kubernetesке жеткирүү үчүн биздин ачык булак GitOps CLI утилитабыз. Убада кылгандай, v1.0 версиясын чыгаруу werfке жаңы функцияларды кошуунун жана салттуу ыкмаларды кайра кароонун башталышын белгиледи. Эми биз өнүгүүдөгү чоң кадам жана келечекке негиз болгон v1.1-релизди тартуулоого кубанычтабыз коллекционер werf. Версия учурда жеткиликтүү канал 1.1 ea.

Чыгаруунун негизин сахнаны сактоонун жаңы архитектурасы жана эки коллекционердин ишин оптималдаштыруу (Stapel жана Dockerfile үчүн) түзөт. Жаңы сактагыч архитектурасы бир хостто бир нече хосттордон жана параллелдүү чогулуштардан бөлүштүрүлгөн жыйындарды ишке ашыруу мүмкүнчүлүгүн ачат.

Ишти оптималдаштыруу этап колдорун эсептөө стадиясында керексиз эсептөөлөрдөн арылууну жана файлдык контролдук суммаларды эсептөө механизмдерин натыйжалуураактарына өзгөртүүнү камтыйт. Бул оптималдаштыруу werf аркылуу долбоорду куруунун орточо убактысын кыскартат. Жана бардык этаптар кэште болгондо иштебей турган курулуштар этаптары-сактоо, азыр чындап эле тез. Көпчүлүк учурларда, курууну кайра баштоо 1 секундага жетпеген убакытты алат! Бул командалардын иш процессиндеги этаптарды текшерүү процедураларына да тиешелүү. werf deploy и werf run.

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

Келгиле, werf v1.1деги негизги инновацияларды кененирээк карап чыгалы жана ошол эле учурда келечектеги пландар жөнүндө айтып берели.

werf v1.1де эмне өзгөрдү?

Жаңы этаптын аталышынын форматы жана кэштен этаптарды тандоо алгоритми

Жаңы сахна атын түзүү эрежеси. Эми ар бир этап куруу 2 бөлүктөн турган уникалдуу сахна атын жаратат: кол коюу (v1.0 версиясында болгондой) жана уникалдуу убактылуу идентификатор.

Мисалы, толук сахна сүрөтүнүн аты мындай болушу мүмкүн:

werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835

...же жалпысынан:

werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC

бул жерде:

  • SIGNATURE сахналык кол тамга болуп саналат, ал сахнанын мазмунунун идентификаторун билдирет жана бул мазмунга алып келген Гитте түзөтүүлөрдүн тарыхына көз каранды;
  • TIMESTAMP_MILLISEC жаңы сүрөт курулган учурда пайда болгон кепилденген уникалдуу сүрөт идентификатору.

Кэштен этаптарды тандоо алгоритми Git милдеттеринин байланышын текшерүүгө негизделген:

  1. Werf белгилүү бир баскычтын кол эсептейт.
  2. В этаптары-сактоо Берилген кол коюу үчүн бир нече этаптар болушу мүмкүн. Werf кол коюуга дал келген бардык этаптарды тандайт.
  3. Эгерде учурдагы этап Git менен байланышкан болсо (git-архив, Git тактары менен ыңгайлаштырылган этап: install, beforeSetup, setup; же git-latest-patch), анда werf учурдагы милдеттенменин түпкү атасы болуп саналган милдеттенме менен байланышкан этаптарды гана тандайт (бул үчүн куруу деп аталат).
  4. Калган ылайыктуу этаптардан бири тандалып алынат - түзүлгөн күнү боюнча эң эскиси.

Ар кандай Гит бутактары үчүн сахна бирдей кол коюуга ээ болушу мүмкүн. Бирок werf кол тамгалар дал келсе дагы, ар кандай бутактар ​​менен байланышкан кэштин бул бутактардын ортосунда колдонулушуна жол бербейт.

→ Документация.

Сахна сактагычында этаптарды түзүү жана сактоо үчүн жаңы алгоритм

Эгерде кэштен этаптарды тандоодо werf ылайыктуу этапты таппаса, анда жаңы этапты чогултуу процесси башталат.

Бир нече процесстер (бир же бир нече хосттордо) болжол менен бир эле учурда бир эле этапты кура башташы мүмкүн экенин эске алыңыз. Werf оптимисттик бөгөттөө алгоритмин колдонот этаптары-сактоо жаңы чогултулган сүрөттү сактоо учурунда этаптары-сактоо. Ошентип, жаңы этап куруу даяр болгондо, werf блоктору этаптары-сактоо жана жаңы чогултулган сүрөттү ал жерде ылайыктуу сүрөт жок болгондо гана сактайт (кол коюу жана башка параметрлер боюнча - кэштен этаптарды тандоо үчүн жаңы алгоритмди караңыз).

Жаңы чогултулган сүрөттүн уникалдуу идентификаторуна ээ болууга кепилдик берилет TIMESTAMP_MILLISEC (этаптын жаңы форматын караңыз). болгон учурда этаптары-сактоо ылайыктуу сүрөт табылат, werf жаңы түзүлгөн сүрөттү жокко чыгарып, кэштен сүрөттү колдонот.

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

→ Документация.

Жакшыртылган Dockerfile куруучу иштеши

Азыркы учурда, Докер файлынан курулган сүрөт үчүн этаптар бир этаптан турат - dockerfile. Кол коюуну эсептөөдө файлдардын текшерүү суммасы эсептелет context, ал чогултуу учурунда колдонулат. Бул өркүндөтүүгө чейин werf рекурсивдүү түрдө бардык файлдарды кыдырып чыгып, ар бир файлдын контекстинин жана режимин жыйынтыктоо менен текшерүү суммасын алды. V1.1ден баштап, werf Git репозиторийинде сакталган эсептелген контролдук суммаларды колдоно алат.

Алгоритмдин негизинде түзүлгөн git ls-дарагы. Алгоритмде жазуулар эске алынат .dockerignore жана зарыл болгондо гана файл дарагын рекурсивдүү кесип өтөт. Ошентип, биз файлдык системаны окуудан жана алгоритмдин өлчөмүнө көз карандылыгын ажыраттык. context маанилүү эмес.

Алгоритм ошондой эле көзөмөлдөнбөгөн файлдарды текшерет жана зарыл болсо, текшерүү суммасында аларды эске алат.

Файлдарды импорттоодо жакшырды

werf v1.1 версиялары rsync серверин колдонушат артефакттардан жана сүрөттөрдөн файлдарды импорттоо. Мурда импорттоо хост тутумунан каталогду орнотуу аркылуу эки этап менен аткарылчу.

MacOS'тун импорттук көрсөткүчтөрү мындан ары Docker көлөмдөрү менен чектелбейт жана импорттоо Linux жана Windows сыяктуу эле убакытта бүтөт.

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

Werf v1.1 сүрөттүн мазмуну боюнча тэг деп аталган нерсени колдойт - мазмунга негизделген белгилөө. Натыйжадагы Docker сүрөттөрүнүн тэгдери бул сүрөттөрдүн мазмунуна көз каранды.

Команданы иштетип жатканда werf publish --tags-by-stages-signature же werf ci-env --tagging-strategy=stages-signature деп аталган сүрөттөрдү жарыялады сахналык кол коюу сүрөт. Ар бир сүрөт бул сүрөттөлүштүн этаптарынын өз кол тамгасы менен белгиленет, ал ар бир этаптын өзүнчө кадимки кол тамгасы сыяктуу эле эрежелер боюнча эсептелет, бирок сүрөттүн жалпы идентификатору болуп саналат.

Сүрөт этаптарынын кол тамгасы көз каранды:

  1. бул сүрөттүн мазмуну;
  2. бул мазмунду алып Гит өзгөрүүлөрдүн тарыхы.

Git репозиторийинде ар дайым сүрөт файлдарынын мазмунун өзгөртпөгөн жасалма милдеттенмелер бар. Мисалы, бир гана комментарийлер менен же бириктирүү милдеттенмелери менен же Gitте сүрөткө импорттолбогон файлдарды өзгөрткөн милдеттенмелер.

Мазмунга негизделген тегдерди колдонууда, сүрөттүн аталышынын өзгөрүшүнө байланыштуу Kubernetesтеги тиркеме подкасттарын керексиз кайра иштетүү көйгөйлөрү, сүрөттүн мазмуну өзгөрбөсө дагы, чечилет. Айтмакчы, бул бир Git репозиторийинде бир тиркеменин көптөгөн микросервистерин сактоого тоскоол болгон себептердин бири.

Ошондой эле, мазмунга негизделген тегдөө Git бутактарына тег салууга караганда ишенимдүү тегдөө ыкмасы болуп саналат, анткени пайда болгон сүрөттөрдүн мазмуну бир эле бутактын бир нече милдеттенмелерин чогултуу үчүн CI тутумунда трубалардын аткарылышынын тартибине көз каранды эмес.

маанилүү: азыртан баштап этаптары-кол коюу - аны жалгыз сунушталган белгилөө стратегиясы. Ал буйрукта демейки боюнча колдонулат werf ci-env (эгер сиз башка белгилөө схемасын ачык көрсөтпөсөңүз).

→ Документация. Бул өзгөчөлүккө өзүнчө басылма да арналат. ЖАҢЫРТЫЛГАН (3-апрель): чоо-жайы менен макала жарыяланган.

Каттоо деңгээли

Колдонуучу азыр чыгарууну көзөмөлдөө, журналга жазуу деңгээлин коюу жана мүчүлүштүктөрдү оңдоо маалыматы менен иштөө мүмкүнчүлүгүнө ээ. Параметрлер кошулду --log-quiet, --log-verbose, --log-debug.

Демейки боюнча, чыгаруу минималдуу маалыматты камтыйт:

werf 1.1 релиз: куруучунун бүгүнкү жакшыртуулары жана келечекке пландар

Кептик чыгарууну колдонууда (--log-verbose) werf кантип иштээрин көрө аласыз:

werf 1.1 релиз: куруучунун бүгүнкү жакшыртуулары жана келечекке пландар

Толук чыгаруу (--log-debug), werf мүчүлүштүктөрдү оңдоо маалыматынан тышкары, колдонулган китепканалардын журналдарын да камтыйт. Мисалы, сиз Docker Реестри менен өз ара аракеттенүү кандай болуп жатканын көрүп, ошондой эле убакыттын бир кыйла көлөмүн өткөргөн жерлерди жазыңыз:

werf 1.1 релиз: куруучунун бүгүнкү жакшыртуулары жана келечекке пландар

Келечектеги пландар

Эскертүү! Төмөндө сүрөттөлгөн параметрлер белгиленген v1.1 Бул версияда жеткиликтүү болот, алардын көбү жакынкы келечекте. Жаңыртуулар автоматтык жаңыртуулар аркылуу келет multiwerf колдонууда. Бул функциялар v1.1 функцияларынын туруктуу бөлүгүнө таасир этпейт, алардын көрүнүшү учурдагы конфигурацияларга колдонуучунун кол менен кийлигишүүсүн талап кылбайт.

Докер реестринин ар кандай ишке ашырууларына толук колдоо (NEW)

Максаты - колдонуучу werfти колдонууда чектөөсүз жеке ишке ашырууну колдонуу.

Учурда биз толук колдоону кепилдей турган төмөнкү чечимдердин топтомун аныктадык:

  • Демейки (китепкана/реестр)*,
  • AWS ECR
  • Azure*,
  • Docker Hub
  • GCR*,
  • GitHub пакеттери
  • GitLab реестри*,
  • Харбор*,
  • Quay.

Учурда werf тарабынан толук колдоого алынган чечимдер жылдызча менен белгиленген. Башкалар үчүн колдоо бар, бирок чектөөлөр менен.

Эки негизги көйгөйлөрдү аныктоого болот:

  • Кээ бир чечимдер Docker Registry API аркылуу тегди алып салууну колдобойт, бул колдонуучулардын werf'тин автоматтык тазалоосун колдонуусуна жол бербейт. Бул AWS ECR, Docker Hub жана GitHub пакеттерине тиешелүү.
  • Кээ бир чечимдер уя салынган репозиторийлерди (Docker Hub, GitHub пакеттери жана Quay) колдобойт же колдобойт, бирок колдонуучу аларды UI же API (AWS ECR) аркылуу кол менен түзүшү керек.

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

Бөлүштүрүлгөн сүрөт түзүү (↑)

  • Версия: v1.2 v1.1 (бул функцияны ишке ашыруунун артыкчылыктары көбөйтүлдү)
  • Даталар: март-апрель март
  • Чыгаруу

Учурда werf v1.0 жана v1.1 сүрөттөрдү куруу жана жарыялоо жана Kubernetesке тиркемени жайылтуу операциялары үчүн бир гана арналган хостто колдонулушу мүмкүн.

Кубернетестеги тиркемелерди түзүү жана жайылтуу бир нече ыктыярдуу хосттордо ишке киргизилгенде жана бул хосттор курулуштар (убактылуу жөө күлүктөр) ортосунда өз абалын сактабаса, werfтин бөлүштүрүлгөн ишинин мүмкүнчүлүктөрүн ачуу үчүн, werf колдонуу мүмкүнчүлүгүн ишке ашыруу үчүн талап кылынат. Докер реестри сахна дүкөнү катары.

Мурда werf долбоору дагы эле dapp деп аталып калганда, мындай мүмкүнчүлүк бар болчу. Бирок, биз werfте бул функцияны ишке ашырууда эске алынышы керек болгон бир катар маселелерге туш болдук.

пикир. Бул өзгөчөлүк коллектордун Kubernetes поддондорунда иштешин талап кылбайт, анткени Бул үчүн, сиз жергиликтүү Docker серверине болгон көз карандылыктан арылууңуз керек (Kubernetes подкругунда жергиликтүү Docker серверине кирүү жок, анткени процесстин өзү контейнерде иштеп жатат жана werf колдобойт жана колдобойт. тармак аркылуу Docker сервери менен иштөө). Kubernetes иштетүү үчүн колдоо өзүнчө ишке ашырылат.

GitHub Actions үчүн расмий колдоо (NEW)

werf документтерин камтыйт (бөлүмдөр маалымат и жетектөө), ошондой эле werf менен иштөө үчүн расмий GitHub Action.

Мындан тышкары, ал werfке эфемердик жөө күлүктөрдө иштөөгө мүмкүндүк берет.

Колдонуучунун CI системасы менен өз ара аракеттешүүсүнүн механикасы тиркемени түзүү/жыгып чыгаруу үчүн белгилүү иш-аракеттерди баштоо үчүн тартуу сурамдарына энбелгилерди коюуга негизделет.

Жергиликтүү иштеп чыгуу жана werf менен тиркемелерди жайылтуу (↓)

  • Версия: v1.1
  • Даталары: январь-февраль апрель
  • Чыгаруу

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

werf ошондой эле колдонмонун кодун оңдоого жана мүчүлүштүктөрдү оңдоо үчүн иштеп жаткан тиркемеден жооп кайтарууга ыңгайлуу болгон иштөө режимине ээ болушу керек.

Жаңы тазалоо алгоритми (ЖАҢЫ)

Процедурада werf v1.1 учурдагы версиясында cleanup Мазмунга негизделген белгилөө схемасы үчүн сүрөттөрдү тазалоо үчүн эч кандай шарт жок - бул сүрөттөр топтолуп калат.

Ошондой эле, werf (v1.0 жана v1.1) учурдагы версиясы тегдөө схемалары астында жарыяланган сүрөттөр үчүн ар кандай тазалоо саясаттарын колдонот: Git филиалы, Git теги же Git commit.

Гиттеги милдеттердин тарыхына негизделген сүрөттөрдү тазалоонун жаңы алгоритми, бардык белгилөө схемалары үчүн бирдиктүү ойлоп табылган:

  • Ар бир git HEAD (бутактар ​​жана тегдер) үчүн N1 эң акыркы милдеттенмелери менен байланышкан N2ден ашык эмес сүрөттөрдү сактаңыз.
  • Ар бир git HEAD (бутактар ​​жана тегдер) үчүн N1 эң акыркы милдеттенмелери менен байланышкан N2 баскычынан ашпаган сүрөттөрдү сактаңыз.
  • Бардык Kubernetes кластердик ресурстарында колдонулган бардык сүрөттөрдү сактаңыз (конфигурация файлынын бардык kube контексттери жана аттар мейкиндиктери сканерден өткөрүлөт; бул жүрүм-турумду атайын опциялар менен чектей аласыз).
  • Helm релизинде сакталган ресурс конфигурациясынын манифестеринде колдонулган бардык сүрөттөрдү сактаңыз.
  • Сүрөттү жок кылса болот, эгерде ал gitтен эч кандай HEAD менен байланыштырылбаса (мисалы, тиешелүү HEAD өзү жок кылынгандыктан) жана Kubernetes кластериндеги эч кандай манифесттерде жана Helm релиздеринде колдонулбаса.

Параллель сүрөт түзүү (↓)

  • Версия: v1.1
  • Даталар: январь-февраль апрель*

werf учурдагы версия сүрөттөлгөн сүрөттөрдү жана артефакттарды чогултат werf.yaml, ырааттуу. Сүрөттөрдүн жана артефакттардын өз алдынча этаптарын чогултуу процессин параллелдештирүү, ошондой эле ыңгайлуу жана маалыматтык чыгарууну камсыз кылуу зарыл.

* Эскертүү: горизонталдуу масштабдоо мүмкүнчүлүктөрүн, ошондой эле GitHub Аракеттери менен werfти колдонууну кошо турган бөлүштүрүлгөн жыйынды ишке ашыруунун артыкчылыктуулугунан улам мөөнөтү жылдырылды. Параллель монтаждоо - бул бир долбоорду чогултууда вертикалдык масштабдуулукту камсыз кылуучу оптималдаштыруунун кийинки кадамы.

3-турулга өтүү (↓)

  • Версия: v1.2
  • Даталар: февраль-март май*

Жаңы код базасына өтүүнү камтыйт Руль 3 жана учурдагы орнотууларды көчүрүүнүн далилденген, ыңгайлуу жолу.

* Эскертүү: Helm 3ке өтүү werfке олуттуу функцияларды кошпойт, анткени Helm 3тин бардык негизги өзгөчөлүктөрү (3-жолдуу бириктирүү жана иштебейт) werfте мурунтан эле ишке ашырылган. Мындан тышкары, werf бар кошумча мүмкүнчүлүктөр көрсөтүлгөндөрдөн тышкары. Бирок бул өткөөл биздин пландарыбызда калды жана ишке ашат.

Kubernetes конфигурациясын сүрөттөө үчүн Jsonnet (↓)

  • Версия: v1.2
  • Даталары: январь-февраль апрель-май

Werf Jsonnet форматындагы Kubernetes конфигурациясынын сүрөттөмөлөрүн колдойт. Ошол эле учурда, werf Helm менен шайкеш бойдон кала берет жана сүрөттөмө форматын тандоо болот.

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

Kubernetes конфигурациясынын башка системаларын (мисалы, Kustomize) киргизүү мүмкүнчүлүгү да каралууда.

Kubernetes ичинде иштөө (↓)

  • Версия: v1.2
  • Даталары: апрель-май-май-июнь

Максат: Сүрөттөр курулуп, колдонмо Kubernetesтеги жөө күлүктөр аркылуу жеткирилет. Ошол. Жаңы сүрөттөрдү түздөн-түз Kubernetes поддондорунан түзүүгө, жарыялоого, тазалоого жана жайгаштырууга болот.

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

Ал ошондой эле Докер сервери жок куруучунун иштөө режимин колдоону талап кылат (мисалы, Канико сыяктуу куруу же колдонуучулар мейкиндигинде куруу).

Werf Kubernetes'те курууну Dockerfile менен гана эмес, ошондой эле стапел куруучу менен кошумча калыбына келтирүү жана Ansible менен колдоого алат.

Ачык өнүгүүгө кадам

Биз коомубузду сүйөбүз (GitHub, телеграмма) жана биз барган сайын көбүрөөк адамдар werfти жакшыртууга, биз бара жаткан багытты түшүнүүгө жана өнүгүүгө катышууга жардам беришин каалайбыз.

Жакында эле өтүү чечими кабыл алынды GitHub долбоор такталары биздин коллективдин иш процессии ачып беруу учун. Эми сиз жакынкы пландарды, ошондой эле төмөнкү багыттар боюнча учурдагы иштерди көрө аласыз:

маселелер боюнча көп иштер аткарылды:

  • Маанисиздер алынып салынды.
  • Бар болгондор жетиштүү сандагы деталдар жана деталдар менен бирдиктүү форматка келтирилет.
  • Идеялар жана сунуштар менен жаңы маселелер кошулду.

v1.1 версиясын кантип иштетүү керек

Версия учурда жеткиликтүү канал 1.1 ea (каналдарда бекем и тек релиздер турукташтыруу болуп жатканда пайда болот, бирок ea өзү буга чейин колдонуу үчүн жетиштүү туруктуу, анткени каналдар аркылуу өттү Alpha и бета). Жандырылды multiwerf аркылуу төмөнкү жол менен:

source $(multiwerf use 1.1 ea)
werf COMMAND ...

жыйынтыктоо

Stapel жана Dockerfile куруучулар үчүн жаңы этап сактоо архитектурасы жана куруучунун оптималдаштыруулары werfте бөлүштүрүлгөн жана параллелдүү түзүлүштөрдү ишке ашыруу мүмкүнчүлүгүн ачат. Бул функциялар жакында ошол эле v1.1 чыгарылышында пайда болот жана автоматтык түрдө жаңыртуу механизми аркылуу автоматтык түрдө жеткиликтүү болот (колдонуучулар үчүн multiwerf).

Бул чыгарылышта сүрөттүн мазмунуна негизделген белгилөө стратегиясы кошулду - мазмунга негизделген белгилөө, демейки стратегия болуп калды. Негизги буйрук журналы да кайра иштетилди: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

Кийинки маанилүү кадам - ​​бөлүштүрүлгөн жыйындарды кошуу. Бөлүштүрүлгөн куруулар v1.0 бери параллелдүү курууларга караганда артыкчылыктуу болуп калды, анткени алар werfке көбүрөөк маани берет: куруучулардын вертикалдуу масштабдалышы жана ар кандай CI/CD системаларында убактылуу куруучуларга колдоо, ошондой эле GitHub Actions үчүн расмий колдоо көрсөтүү мүмкүнчүлүгү. . Ошондуктан, параллелдүү чогулуштарды ишке ашыруу мөөнөттөрү жылдырылды. Бирок, биз эки мүмкүнчүлүктү тең тез арада ишке ашыруунун үстүндө иштеп жатабыз.

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

PS

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

Source: www.habr.com

Комментарий кошуу