- Наша GitOps CLI-ўтыліта з адкрытым кодам для зборкі і дастаўкі прыкладанняў у Kubernetes. Як і абяцалі, азначаў пачатак дадання ў werf новых магчымасцяў і перагляду звыклых падыходаў. Цяпер мы рады прадставіць рэліз v1.1, які з'яўляецца вялікім крокам у развіцці і задзелам на будучыню зборшчыка werf. Версія даступна на дадзены момант у .
Аснова рэлізу - гэта новая архітэктура сховішчы стадый і аптымізацыя працы абодвух зборшчыкаў (для Stapel і Dockerfile). Новая архітэктура сховішча адкрывае магчымасці да рэалізацыі размеркаваных зборак з некалькіх хастоў і паралельных зборак на адным хасце.
Аптымізацыя працы ўключае ў сябе збавенне ад лішніх вылічэнняў на этапе разліку сігнатур стадый і змены механізмаў разліку кантрольных сум файлаў на больш эфектыўныя. Гэтая аптымізацыя памяншае сярэдні час зборак праекту з дапамогай werf. І халастыя зборкі, калі ўсе стадыі існуюць у кэшы stages-storage, зараз сапраўды хуткія. У большасці выпадкаў паўторны запуск зборкі пройдзе хутчэй за 1 секунду! Гэта таксама датычыцца і працэдур верыфікацыі стадый у працэсе работы каманд werf deploy и werf run.
Таксама ў дадзеным рэлізе з'явілася стратэгія тэгавання вобразаў па змесціве. content-based tagging, якая зараз уключана па змаўчанні і з'яўляецца адзінай рэкамендуемай.
Разгледзім падрабязней ключавыя новаўвядзенні ў werf v1.1, а заадно раскажам аб планах на будучыню.
Што змянілася ў werf v1.1?
Новы фармат наймення стадый і алгарытм падбору стадый з кэша
Новае правіла генерацыі імя стадыі. Цяпер кожная зборка стадыі генеруе унікальнае імя стадыі, якое складаецца з 2-х частак: сігнатура (як было ў v1.0) плюс унікальны часавы ідэнтыфікатар.
Напрыклад, поўнае імя выявы стадыі можа выглядаць так:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
… ці ў агульным выглядзе:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Тут:
-
SIGNATURE- Гэта сігнатура стадыі, якая ўяўляе ідэнтыфікатар змесціва стадыі і залежыць ад гісторыі правак у Git, якія прывялі да дадзенага змесціва; -
TIMESTAMP_MILLISEC— гэта гарантавана ўнікальны ідэнтыфікатар выявы, які генеруецца ў момант зборкі новай выявы.
Алгарытм падбору стадый з кэша заснаваны на праверцы сваяцтва Git-камітаў:
- Werf разлічвае сігнатуру некаторай стадыі.
- В stages-storage можа існаваць некалькі стадый па дадзенай сігнатуры. Werf выбірае ўсе прыдатныя па сігнатуры стадыі.
- Калі бягучая стадыя звязана з Git (git-archive, карыстацкая стадыя з Git-патчамі:
install,beforeSetup,setup; ці git-latest-patch), то werf выбірае толькі тыя стадыі, якія злучаны з комітам, якія з'яўляюцца продкам бягучага коммита (для якога выклікана зборка). - З астатніх падыходных стадый выбіраецца адна - найстарэйшая па даце стварэння.
Стадыя для розных Git-галінак можа мець адну і тую ж сігнатуру. Але werf прадухіліць выкарыстанне кэша, звязанага з рознымі галінкамі, паміж гэтых галінак, нават калі сігнатуры супалі.
.
Новы алгарытм стварэння і захавання стадый у сховішчы стадый
Калі падчас падбору стадый з кэша werf не знаходзіць падыходнай стадыі, тое ініцыюецца працэс зборкі новай стадыі.
Заўважым, што некалькі працэсаў (на адным ці некалькіх хастах) могуць пачаць зборку адной і той жа стадыі ў прыкладна адно і тое ж час. Werf выкарыстоўвае алгарытм аптымістычнага блакавання stages-storage у момант захавання свежасабранай выявы ў stages-storage. Такім чынам, калі зборка новай стадыі гатова, werf блакуе stages-storage і захоўвае туды свежазабраная выява толькі ў выпадку, калі там ужо не існуе падыходнай выявы (па сігнатуры і іншым параметрам - гл. новы алгарытм падбору стадый з кэша).
Свежазабраны вобраз гарантавана будзе мець унікальны ідэнтыфікатар па TIMESTAMP_MILLISEC (гл. новы фармат наймення стадый). У выпадку, калі ў stages-storage будзе знойдзены прыдатны вобраз, werf адкіне свежазабраны вобраз і будзе выкарыстоўваць вобраз з кэша.
Іншымі словамі: першы працэс, які скончыць збіраць выяву (самы хуткі), атрымае права захаваць яго ў stages-storage (і затым менавіта гэта адзіная выява будзе выкарыстоўвацца для ўсіх зборак). Павольны ж працэс зборкі ніколі не будзе блакаваць хутчэйшы працэс ад захавання вынікаў зборкі бягучай стадыі і пераходу да зборкі наступнай.
.
Палепшана прадукцыйнасць зборшчыка Dockerfile
На дадзены момант канвеер стадый для выявы, які збіраецца з Dockerfile, складаецца з адной стадыі. dockerfile. Пры вылічэнні сігнатуры лічыцца кантрольная сума файлаў context, Што будуць выкарыстоўвацца пры зборцы. Да гэтага паляпшэння werf рэкурсіўна праходзіў па ўсіх файлах і атрымліваў кантрольную суму, прасумаваўшы кантэкст і мод кожнага файла. Пачынальна з версій v1.1, werf можа выкарыстаць разлічаныя кантрольныя сумы, якія захоўваюцца ў Git-рэпазітары.
У аснове алгарытму - . Алгарытм улічвае запісы ў .dockerignore і праходзіць рэкурсіўна па дрэве файлаў толькі пры неабходнасці. Такім чынам, мы адвязаліся ад чытання файлавай сістэмы, а залежнасць алгарытму ад памеру context не зяўляецца істотнай.
Таксама алгарытм правярае untracked-файлы і пры неабходнасці ўлічвае іх у кантрольнай суме.
Палепшана прадукцыйнасць пры імпартаванні файлаў
У версіях werf v1.1 выкарыстоўваецца rsync-сервер пры . Раней імпартаванне выконвалася за два крокі з выкарыстаннем мантавання дырэкторыі з хост-сістэмы.
Прадукцыйнасць імпартаў у macOS больш не абмяжоўваецца Docker volumes, а імпарты выконваюцца за той жа час, што і ў Linux і Windows.
Content-based tagging
Werf v1.1 падтрымлівае так званае тэгаванне па змесціва выявы content-based tagging. Тэгі выніковых Docker-вобразаў залежаць ад зместу гэтых вобразаў.
Пры запуску каманды werf publish --tags-by-stages-signature або werf ci-env --tagging-strategy=stages-signature будуць пратэгаваныя публікуемыя вобразы так званай сігнатурай стадый ладу. Кожная выява тэгуецца сваёй уласнай сігнатурай стадый гэтай выявы, якая разлічваецца па тых жа правілах, што і рэгулярная сігнатура кожнай са стадый у асобнасці, але з'яўляецца абагульняючым ідэнтыфікатарам выявы.
Сігнатура стадый выявы залежыць ад:
- змесціва гэтай выявы;
- гісторыі правак у Git, якія прывялі да гэтага змесціва.
У Git-рэпазітары заўсёды ёсць халастыя коміты, якія не змяняюць змесціва файлаў выявы. Напрыклад, коміты толькі з каментарамі ці merge-каміты, ці коміты, якія змяняюць тыя файлы ў Git, што не будуць імпартаваныя ў выяву.
Пры выкарыстанні content-based tagging вырашаюцца праблемы лішніх перазапускаў pod'аў прыкладанні ў Kubernetes з-за змен імя выявы выявы, нават калі змесціва выявы не памянялася. Дарэчы, гэта з'яўляецца адной з прычын, якія перашкаджаюць захоўваць мноства мікрасэрвісаў аднаго дадатку ў адзіным Git-рэпазітары.
Таксама content-based tagging з'яўляецца больш надзейным метадам тэгавання, чым тэгіраванне па Git-галінках, таму што змесціва выніковых выяў не залежыць ад парадку выканання pipeline'аў у CI-сістэме для зборкі некалькіх коммітаў адной і той жа галінкі.
Важна: пачынаючы з бягучага моманту stages-signature - Гэта адзіная рэкамендуемая стратэгія тэгавання. Менавіта яна будзе выкарыстоўвацца па змаўчанні ў камандзе werf ci-env (калі відавочна не паказаць іншую схему тэгавання).
. Гэтай фічы будзе таксама прысвечана асобная публікацыя. АБНОЎЛЕНА (3 красавіка): Артыкул з падрабязнасцямі .
Узроўні лагавання
У карыстальніка з'явілася магчымасць кантраляваць выснову, задаваць узровень лагіравання і працаваць з адладкавай інфармацыяй. Дададзеныя опцыі --log-quiet, --log-verbose, --log-debug.
Па змаўчанні ў выснове змяшчаецца мінімум інфармацыі:
Пры выкарыстанні падрабязнай высновы (--log-verbose) можна прасачыць, як працуе werf:
Дэталёвая выснова (--log-debug), акрамя адладкавай інфармацыі werf, таксама змяшчае логі выкарыстоўваных бібліятэк. Напрыклад, можна ўбачыць, як адбываецца ўзаемадзеянне з Docker Registry, а таксама зафіксаваць месцы, у якіх марнуецца істотная колькасць часу:
Далейшыя планы
Увага! Апісаныя далей магчымасці з паметкай v1.1 стануць даступныя ўжо ў гэтай версіі, многія з іх - у бліжэйшы час. Абнаўленні прыйдуць праз аўтаапдэйты . Гэтыя магчымасці не закранаюць стабільную частку функцый v1.1, іх з'яўленне не запатрабуе ручнога ўмяшання карыстача ва ўжо існыя канфігурацыі.
Поўная падтрымка розных рэалізацый Docker Registry (НОВЫ)
- Версія: v1.1
- Тэрміны: сакавік
Мэта - карыстач павінен выкарыстоўваць адвольную рэалізацыю без абмежаванняў пры выкарыстанні werf.
На дадзены момант мы вылучылі наступны набор рашэнняў, для якіх збіраемся гарантаваць поўную падтрымку:
- Default (library/registry)*,
- AWS ECR,
- Azure*,
- Docker Hub,
- GCR*,
- GitHub Packages,
- GitLab Registry*,
- Harbor*,
- Quay.
Зорачкай адзначаны рашэнні, якія на бягучы момант ужо цалкам падтрымліваюцца werf. Для астатніх ёсць падтрымка, але з абмежаваннямі.
Можна вылучыць дзве асноўныя праблемы:
- Некаторыя рашэнні не падтрымліваюць выдаленне тэгаў з дапамогай Docker Registry API, што не дазваляе карыстачам выкарыстоўваць аўтаматычную ачыстку, рэалізаваную ў werf. Гэта справядліва для AWS ECR, Docker Hub і GitHub Packages.
- Частка рашэнняў не падтрымліваюць, так званыя, nested repositories (Docker Hub, GitHub Packages і Quay) ці падтрымліваюць, але карыстач павінен ствараць іх уручную, выкарыстаючы UI або API (AWS ECR).
Гэтыя і астатнія праблемы мы збіраемся вырашаць з выкарыстаннем натыўных API у рашэнняў. У гэтую задачу таксама ўваходзіць пакрыццё цестамі поўнага цыклу працы werf для кожнага з іх.
Размеркаваная зборка вобразаў (↑)
- Версія: v1.2 v1.1 (прыярытэт па рэалізацыі дадзенай магчымасці быў павялічаны)
- Тэрміны: сакавік-красавік сакавік
На дадзены момант, werf v1.0 і v1.1 можна выкарыстоўваць толькі на адным выдзеленым хасце для аперацый зборкі і публікацыі вобразаў і дэплою прыкладання ў Kubernetes.
Каб адкрыць магчымасці размеркаванай працы werf, калі зборка і дэплой прыкладанняў у Kubernetes запускаюцца на некалькіх адвольных хастах і гэтыя хасты не захоўваюць свой стан паміж зборкамі (часовыя runner'ы), ад werf патрабуецца рэалізацыя магчымасці выкарыстання Docker Registry у якасці сховішчы стадый.
Раней, калі праект werf яшчэ зваўся dapp, у ім была такая магчымасць. Аднак мы сутыкнуліся з шэрагам праблем, якія неабходна ўлічыць пры рэалізацыі гэтай функцыі ў werf.
Заўвага. Дадзеная магчымасць не мяркуе працу зборшчыка ўсярэдзіне pod'ов Kubernetes, т.к. для гэтага неабходна пазбавіцца ад залежнасці ад лакальнага Docker-сервера (у pod'е Kubernetes няма доступу да лакальнага Docker-серверу, таму што сам працэс запушчаны ў кантэйнеры, а працу з Docker-серверам па сетцы werf не падтрымлівае і не будзе падтрымліваць). Падтрымка працы ў Kubernetes будзе рэалізавана асобна.
Афіцыйная падтрымка GitHub Actions (НОВЫ)
- Версія: v1.1
- Тэрміны: сакавік
Уключае ў сябе дакументацыю werf (часткі спасылка и кіраўніцтва), а таксама афіцыйны GitHub Action для працы з werf.
Акрамя таго, дазволіць працаваць werf на эфемерных runner'ах.
Механіка ўзаемадзеяння карыстальніка з CI-сістэмай будзе заснавана на выстаўленні label'аў на pull-request'ы для ініцыявання вызначаных дзеянняў па зборцы/выкаце прыкладання.
Лакальная распрацоўка і разгортванне прыкладанняў з werf (↓)
- Версія: v1.1
- Тэрміны: студзень-люты красавік
Галоўная мэта - дамагчыся адзінага ўніфікаванага канфігу для разгортвання прыкладанняў як лакальна, так і ў production, без складаных дзеянняў, са скрынкі .
Ад werf таксама патрабуецца такі рэжым працы, у якім будзе зручна рэдагаваць код прыкладання і імгненна атрымліваць зваротную сувязь ад працавальнага прыкладання для дэбага.
Новы алгарытм ачысткі (НОВАЕ)
- Версія: v1.1
- Тэрміны: красавік
У бягучай версіі werf v1.1 у працэдуры cleanup не прадугледжана ачыстка выяў для схемы тэгавання па змесціва (content-based tagging) - дадзеныя выявы будуць запасіцца.
Таксама ў бягучай версіі werf (v1.0 і v1.1) выкарыстоўваюцца розныя палітыкі ачысткі для вобразаў, апублікаваных па схемах тэгавання: Git-галінка, Git-тэг або Git-комміт.
Прыдуманы новы ўніфікаваны для ўсіх схем тэгавання алгарытм ачысткі выяў на аснове гісторыі коммітаў у Git:
- Захоўваць не больш, чым N1 выяў, злучаных з N2 апошнімі комитами для кожнага з git HEAD (галінкі і тэгі).
- Захоўваць не больш, чым N1 выяў-стадый, злучаных з N2 апошнімі комитами для кожнага з git HEAD (галінкі і тэгі).
- Захоўваць усе выявы, якія выкарыстоўваюцца ў якіх-небудзь рэсурсах кластара Kubernetes (скануюцца ўсе kube-кантэксты файла канфігурацыі і namespace'ы; можна абмежаваць такія паводзіны адмысловымі опцыямі).
- Захоўваць усе выявы, якія выкарыстоўваюцца ў маніфестах канфігурацыі рэсурсаў, захаваных у Helm-рэлізах.
- Выява можа быць выдалены, калі ён не злучаны ні з адным HEAD з git (напрыклад, таму што сам які адпавядае HEAD быў выдалены) і не выкарыстоўваецца ні ў адным з маніфестаў у кластары Kubernetes і ў рэлізах Helm.
Раўналежная зборка выяў (↓)
- Версія: v1.1
- Тэрміны: студзень-люты красавік*
Бягучая версія werf збірае выявы і артэфакты, апісаныя ў werf.yaml, паслядоўна. Неабходна распаралеліць працэс зборкі незалежных стадый вобразаў і артэфактаў, а таксама забяспечыць зручную і інфарматыўную выснову.
* Заўвага: тэрмін ссунуты з-за павышэння прыярытэту па рэалізацыі размеркаванай зборкі, якая дадасць больш магчымасцяў па гарызантальным маштабаванні, а таксама выкарыстанню werf з GitHub Actions. Паралельная ж зборка з'яўляецца наступным крокам аптымізацыі, які дае вертыкальную маштабаванасць пры зборцы аднаго праекта.
Пераход на Helm 3 (↓)
- Версія: v1.2
- Тэрміны: люты-сакавік май*
Уключае ў сябе пераход на новую кодавую базу і правераны, зручны спосаб міграцыі існуючых установак.
* Заўвага: пераход на Helm 3 не дадасць істотных магчымасцяў у werf, таму што ўсе ключавыя фічы Helm 3 (3-way-merge і адсутнасць tiller) ужо рэалізаваны ў werf. Больш за тое, werf мае апроч паказаных. Аднак гэты пераход застаецца ў нашых планах і будзе ажыццёўлены.
Jsonnet для апісання канфігурацыі Kubernetes (↓)
- Версія: v1.2
- Тэрміны: студзень-люты красавік-травень
Werf будзе падтрымліваць апісанне канфігурацыі для Kubernetes у фармаце Jsonnet. Пры гэтым werf застанецца сумяшчальным з Helm і будзе магчымасць выбару фармату апісання.
Чыннікам служыць той факт, што шаблоны мовы Go, па адзнацы мноства людзей, маюць вялікі парог уваходжання, і зразумеласць кода гэтых шаблонаў таксама пакутуе.
Таксама разглядаецца магчымасць укаранення і іншых сістэм апісання канфігурацыі Kubernetes (напрыклад, Kustomize).
Праца ўнутры Kubernetes (↓)
- Версія: v1.2
- Тэрміны: красавік-май май-чэрвень
Мэта: забяспечыць зборку выяў і дастаўку прыкладання з выкарыстаннем runner'аў у Kubernetes. Г.зн. зборка новых выяў, іх публікацыя, ачыстка і дэплой можа адбывацца прама з pod'ов Kubernetes.
Каб рэалізаваць гэтую магчымасць, спачатку патрабуецца магчымасць размеркаванай зборкі выяў (гл. пункт вышэй).
Таксама патрабуецца падтрымка рэжыму працы зборшчыка без Docker-сервера (г.зн. Kaniko-падобная зборка ці зборка ў userspace).
Werf будзе падтрымліваць зборку ў Kubernetes не толькі з дапамогай Dockerfile, але і з дапамогай свайго зборшчыка Stapel з інкрыментальнымі перазборкамі і Ansible.
Крок у бок адкрытай распрацоўкі
Мы любім нашу супольнасць (, ) і хочам, каб усё больш людзей дапамагалі рабіць werf лепш, разумелі, у якім напрамку мы рухаемся, і ўдзельнічалі ў распрацоўцы.
Зусім нядаўна было вырашана перайсці на для таго, каб прыадкрыць працоўны працэс нашай каманды. Цяпер можна паглядзець бліжэйшыя планы, а таксама бягучыя работы па наступных напрамках:
- ;
- ;
- ;
- .
Праведзена вялікая праца з issues:
- Выдалены неактуальныя.
- Існыя прыведзены да адзінага фармату, дастатковай колькасці дэталяў і падрабязнасцяў.
- Дададзены новыя issues з ідэямі і прапановамі.
Як уключыць версію v1.1
Версія даступна на дадзены момант у (у каналах стабільны и скалісты рэлізы з'явяцца па меры стабілізацыі, аднак ea сама па сабе ўжо дастаткова стабільная для выкарыстання, т.я. прайшла праз каналы альфа и бэта). Актывуецца наступным спосабам:
source $(multiwerf use 1.1 ea)
werf COMMAND ...Заключэнне
Новая архітэктура сховішча стадый і аптымізацыя працы зборшчыка для Stapel і Dockerfile зборшчыкаў адчыняюць магчымасці рэалізаваць размеркаваныя і раўналежныя зборкі ў werf. Дадзеныя магчымасці неўзабаве з'явяцца ў тым жа рэлізе v1.1 і стануць аўтаматычна даступныя праз механізм аўтаабнаўленняў (для карыстальнікаў ).
У дадзеным рэлізе была дададзена стратэгія тэгавання па зместу вобразаў. content-based tagging, - Якая стала стратэгіяй па змаўчанні. А таксама быў перапрацаваны лог асноўных каманд: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
Наступным істотным крокам стане дабаўленне размеркаваных зборак. Размеркаваныя зборкі з часу v1.0 сталі больш прыярытэтнай задачай, чым раўналежныя зборкі, таму што дадаюць больш каштоўнасці werf: вертыкальнае маштабаванне зборшчыкаў і падтрымка эфемерных зборшчыкаў у розных CI/CD-сістэмах, а таксама магчымасць зрабіць афіцыйную падтрымку GitHub Actions. Таму тэрміны рэалізацыі паралельных зборак былі ссунуты. Аднак мы працуем над тым, каб хутчэй рэалізаваць абедзве магчымасці.
Сачыце за навінамі! І не забывайце зазіраць да нас у , Каб стварыць issue, знайсці ўжо існуючы і паставіць плюс, стварыць PR ці проста паназіраць за развіццём праекта.
PS
Чытайце таксама ў нашым блогу:
- «»
- «»;
- Цыкл нататак аб новаўвядзеннях у werf:
- «»;
- «»;
- «»;
- «.
Крыніца: habr.com