🥇Издавање на Werf 1.1: подобрувања во колекторот денес и планови за иднината

верф е нашата алатка со отворен код GitOps CLI за градење и доставување апликации до Kubernetes. Како што е ветено, издание на верзијата v1.0 го означи почетокот на додавање нови функции на werf и ревидирање на традиционалните пристапи. Сега со задоволство го претставуваме изданието v1.1, што е голем чекор во развојот и основа за иднината колекционер верф. Верзијата моментално е достапна во канал 1.1 ea.

Основата на изданието е новата архитектура за складирање на сцената и оптимизација на работата на двата колектори (за Stapel и Dockerfile). Новата архитектура за складирање ја отвора можноста за имплементација на дистрибуирани склопови од повеќе хостови и паралелни склопови на истиот домаќин.

Оптимизацијата на работата вклучува ослободување од непотребните пресметки во фазата на пресметување потписи на фаза и менување на механизмите за пресметување на контролни суми на датотеки на поефикасни. Оваа оптимизација го намалува просечното време на изработка на проекти со помош на werf. И неактивен builds, кога сите фази постојат во кешот фази-складирање, сега се навистина брзи. Во повеќето случаи, рестартирањето на изградбата ќе потрае помалку од 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 е сценски потпис, кој го претставува идентификаторот на сценската содржина и зависи од историјата на уредувањата во Git што довеле до оваа содржина;
TIMESTAMP_MILLISEC е загарантиран уникатен идентификатор на слика кој се генерира во моментот кога се создава нова слика.

Алгоритмот за избор на фази од кешот се заснова на проверка на односот на Git commits:

Верф го пресметува потписот на одредена фаза.
В фази-складирање Може да има неколку фази за даден потпис. Верф ги избира сите фази што одговараат на потписот.
Ако тековната фаза е поврзана со Git (git-архива, приспособена фаза со Git закрпи: install, beforeSetup, setup; или git-latest-patch), тогаш werf ги избира само оние фази кои се поврзани со commit што е предок на тековниот commit (за кој се нарекува изградбата).
Од преостанатите погодни фази, се избира една - најстарата по датумот на создавање.

Сцената за различни гранки на Git може да има ист потпис. Но, werf ќе спречи кешот поврзан со различни гранки да се користи помеѓу овие гранки, дури и ако потписите се совпаѓаат.

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

Нов алгоритам за креирање и зачувување фази во складиштето на сцената

Доколку, при изборот на фази од кешот, werf не најде соодветна фаза, тогаш се започнува процесот на составување на нова фаза.

Забележете дека повеќе процеси (на еден или повеќе хостови) може да започнат со градење на истата фаза во приближно исто време. Werf користи оптимистички алгоритам за блокирање фази-складирање во моментот на зачувување на свежо собраната слика во фази-складирање. На овој начин, кога е готова изградбата на новата фаза, се блокираат верфовите фази-складирање и таму зачувува свежо собрана слика само ако веќе не постои соодветна слика таму (по потпис и други параметри - видете го новиот алгоритам за избор на фази од кешот).

Свежо составената слика е загарантирана да има единствен идентификатор TIMESTAMP_MILLISEC (видете го новиот формат за именување на сцената). Во случај во фази-складирање ќе се најде соодветна слика, werf ќе ја отфрли свежо компајлираната слика и ќе ја користи сликата од кешот.

Со други зборови: првиот процес за завршување на градењето на сликата (најбрзиот) ќе добие право да ја складира во фази - складирање (а потоа оваа единствена слика ќе се користи за сите градби). Бавниот процес на градење никогаш нема да го спречи побрзиот процес да ги зачува резултатите од изградбата од тековната фаза и да продолжи кон следното градење.

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

Подобрени перформанси на градител на Dockerfile

Во моментов, цевководот на фази за слика изградена од 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 објавени слики на т.н сценски потпис слика. Секоја слика е означена со свој потпис на фазите на оваа слика, кој се пресметува според истите правила како и редовниот потпис на секоја фаза посебно, но е општ идентификатор на сликата.

Потписот на фазите на сликата зависи од:

содржината на оваа слика;
истории на промените на Git што доведоа до оваа содржина.

Складиштето на Git секогаш има лажни обврски кои не ја менуваат содржината на датотеките со слики. На пример, обврзува само со коментари или обврзници за спојување или обврзници што ги менуваат оние датотеки во Git што нема да се увезат во сликата.

Кога користите означување засновано на содржина, проблемите со непотребното рестартирање на местата на апликацијата во Kubernetes поради промените во името на сликата се решени, дури и ако содржината на сликата не е променета. Патем, ова е една од причините што спречува складирање на многу микросервиси на една апликација во едно складиште на Git.

Исто така, означувањето засновано на содржина е посигурен метод за означување од означувањето на гранките на Git, бидејќи содржината на добиените слики не зависи од редоследот по кој се извршуваат цевководи во системот CI за составување на повеќе обврзувања од иста гранка.

Важно е: почнувајќи од сега фази-потпис - Дали единствената препорачана стратегија за означување. Стандардно ќе се користи во командата werf ci-env (освен ако експлицитно не наведете друга шема за означување).

→ Документација. За оваа карактеристика ќе биде посветена и посебна публикација. АЖУРИРАНО (3 април): Статија со детали објавено.

Нивоа на евиденција

Корисникот сега има можност да го контролира излезот, да го постави нивото на логирање и да работи со информации за дебагирање. Додадени се опции --log-quiet, --log-verbose, --log-debug.

Стандардно, излезот ги содржи минималните информации:

Кога користите опширен излез (--log-verbose) можете да видите како работи верф:

Детален излез (--log-debug), покрај информациите за дебагирање на werf, содржи и дневници на користени библиотеки. На пример, можете да видите како се јавува интеракцијата со Docker Registry, а исто така да ги снимите местата каде што се троши значително време:

Идни планови

Предупредување! Опциите опишани подолу се означени v1.1 ќе станат достапни во оваа верзија, многу од нив во блиска иднина. Ажурирањата ќе доаѓаат преку автоматско ажурирање кога користите мултиверф. Овие карактеристики не влијаат на стабилниот дел од функциите v1.1; нивниот изглед нема да бара рачна интервенција на корисникот во постоечките конфигурации.

Целосна поддршка за различни имплементации на Docker Registry (НОВ)

Верзија: v1.1
Датуми: март
исходот

Целта е корисникот да користи прилагодена имплементација без ограничувања при користење на werf.

Во моментов, го идентификувавме следниот сет на решенија за кои ќе гарантираме целосна поддршка:

Стандардно (библиотека/регистар)*,
AWS ECR
Азур*,
Docker Hub
ГЦР*,
GitHub пакети
Регистар на GitLab*,
Пристаниште *,
Кеј.

Решенијата кои моментално се целосно поддржани од werf се означени со ѕвездичка. За другите има поддршка, но со ограничувања.

Може да се идентификуваат два главни проблеми:

Некои решенија не поддржуваат отстранување ознаки со користење на Docker Registry API, спречувајќи ги корисниците да користат автоматско чистење на werf. Ова важи за пакетите AWS ECR, Docker Hub и GitHub.
Некои решенија не поддржуваат таканаречени вгнездени складишта (Docker Hub, GitHub Packages и Quay), но корисникот мора да ги креира рачно користејќи UI или API (AWS ECR).

Ќе ги решиме овие и други проблеми користејќи природни API на решенијата. Оваа задача, исто така, вклучува покривање на целосниот циклус на операција на werf со тестови за секој од нив.

Дистрибуирана градба на слики (↑)

Верзија: v1.2 v1.1 (приоритетот за спроведување на оваа функција е зголемен)
Датуми: март-април март
исходот

Во моментов, werf v1.0 и v1.1 може да се користат само на еден посветен домаќин за операции за градење и објавување слики и распоредување на апликацијата на Kubernetes.

За да се отворат можностите за дистрибуирана работа на werf, кога изградбата и распоредувањето на апликациите во Kubernetes се стартуваат на неколку произволни хостови и овие хостови не ја зачувуваат својата состојба помеѓу градбите (привремени тркачи), потребно е werf да ја имплементира можноста за користење Docker Registry како продавница за сцена.

Претходно, кога проектот werf сè уште се нарекуваше dapp, имаше таква можност. Сепак, наидовме на голем број проблеми кои треба да се земат предвид при спроведување на оваа функционалност во werf.

Имајте на ум. Оваа функција не бара колекторот да работи во кубернетските подлоги, бидејќи За да го направите ова, треба да се ослободите од зависноста од локалниот сервер Docker (во подлогата Kubernetes нема пристап до локалниот сервер Docker, бидејќи самиот процес работи во контејнер, а werf не поддржува и нема да поддржува работа со серверот Docker преку мрежата). Поддршката за водење на Kubernetes ќе се имплементира посебно.

Официјална поддршка за GitHub Actions (НОВО)

Верзија: v1.1
Датуми: март
исходот

Вклучува верф документација (делови упатување и водич), како и официјалната GitHub Action за работа со werf.

Покрај тоа, ќе му овозможи на werf да работи на ефемерни тркачи.

Механиката на интеракцијата на корисникот со системот CI ќе се заснова на поставување етикети на барањата за повлекување за да се иницираат одредени активности за да се изгради/расположи апликацијата.

Локален развој и распоредување на апликации со werf (↓)

Верзија: v1.1
Термини: јануари-февруари април
исходот

Главната цел е да се постигне единствена унифицирана конфигурација за распоредување на апликации и локално и во производство, без сложени дејства, надвор од кутијата.

Од werf исто така се бара да има режим на работа во кој ќе биде погодно да се уредува кодот на апликацијата и веднаш да се добиваат повратни информации од апликацијата која работи за дебагирање.

Нов алгоритам за чистење (НОВ)

Верзија: v1.1
Датуми: април
исходот

Во тековната верзија на werf v1.1 во процедурата cleanup Не постои одредба за чистење на слики за шемата за означување базирана на содржина - овие слики ќе се акумулираат.

Исто така, тековната верзија на werf (v1.0 и v1.1) користи различни политики за чистење на слики објавени во шеми за означување: Git branch, Git tag или Git commit.

Измислен е нов алгоритам за чистење слики заснован на историјата на обврските во Git, унифициран за сите шеми за означување:

Чувајте не повеќе од N1 слики поврзани со N2 најновите обврски за секој git HEAD (гранки и ознаки).
Чувајте не повеќе од слики од фаза N1 поврзани со најновите обврски N2 за секој git HEAD (гранки и ознаки).
Складирајте ги сите слики што се користат во кои било ресурси на кластерот Кубернет (сите кубе контексти на конфигурациската датотека и просторите за имиња се скенирани; ова однесување можете да го ограничите со специјални опции).
Складирајте ги сите слики што се користат во манифестациите за конфигурација на ресурси зачувани во изданијата на Helm.
Сликата може да се избрише ако не е поврзана со ниту една HEAD од git (на пример, затоа што самата соодветна HEAD е избришана) и не се користи во ниеден манифест во кластерот Kubernetes и во изданијата на Helm.

Паралелна градба на слики (↓)

Верзија: v1.1
Термини: јануари-февруари април*

Тековната верзија на werf ги собира сликите и артефактите опишани во werf.yaml, последователно. Неопходно е да се паралелизира процесот на склопување независни фази на слики и артефакти, како и да се обезбеди удобен и информативен излез.

* Забелешка: рокот е поместен поради зголемен приоритет за имплементација на дистрибуирано склопување, што ќе додаде повеќе хоризонтални способности за скалирање, како и користење на werf со GitHub Actions. Паралелното склопување е следниот чекор на оптимизација, обезбедувајќи вертикална приспособливост при составување на еден проект.

Транзиција кон Хелм 3 (↓)

Верзија: v1.2
Термини: февруари-март мај*

Вклучува миграција во нова база на кодови Кормила 3 и докажан, удобен начин за мигрирање на постоечките инсталации.

* Забелешка: префрлањето на Helm 3 нема да додаде значајни карактеристики на werf, бидејќи сите клучни карактеристики на Helm 3 (3-насочно спојување и без молк) се веќе имплементирани во werf. Покрај тоа, верф има дополнителни карактеристики покрај наведените. Сепак, оваа транзиција останува во нашите планови и ќе се спроведе.

Jsonnet за опишување на конфигурацијата на Kubernetes (↓)

Верзија: v1.2
Термини: јануари-февруари април-мај

Werf ќе поддржува описи за конфигурација за Kubernetes во Jsonnet формат. Во исто време, werf ќе остане компатибилен со Helm и ќе има избор на формат на опис.

Причината е што Go шаблоните, според многу луѓе, имаат висока влезна бариера, а исто така страда и разбирливоста на кодот на овие шаблони.

Се разгледува и можноста за воведување на други системи за опис на конфигурацијата на Kubernetes (на пример, Kustomize).

Работа во Kubernetes (↓)

Верзија: v1.2
Термини: април-мај мај-јуни

Цел: Осигурете се дека сликите се изградени и апликацијата е испорачана со помош на тркачи во Kubernetes. Оние. Новите слики може да се градат, објавуваат, чистат и распоредуваат директно од подлогите на Kubernetes.

За да ја имплементирате оваа способност, прво треба да бидете во можност да изградите дистрибуирани слики (види точка погоре).

Исто така, бара поддршка за режимот на работа на градителот без сервер Docker (т.е. изработка или градба во корисничкиот простор сличен на Kaniko).

Werf ќе го поддржи градењето на Kubernetes не само со Dockerfile, туку и со неговиот Stapel builder со постепено обновување и Ansible.

Чекор кон отворен развој

Ја сакаме нашата заедница (GitHub, Телеграма) и сакаме се повеќе и повеќе луѓе да помогнат да се подобри верфот, да се разбере правецот во кој се движиме и да учествуваат во развојот.

Неодамна беше одлучено да се префрли на Проектни табли на GitHub со цел да го откриеме работниот процес на нашиот тим. Сега можете да ги видите непосредните планови, како и тековната работа во следните области:

Направено е многу работа со прашања:

Отстранети небитни.
Постојните се доведени во единствен формат, со доволен број детали и детали.
Додадени се нови прашања со идеи и предлози.

Како да ја овозможите верзијата v1.1

Верзијата моментално е достапна во канал 1.1 ea (во канали стабилна и камен-цврст Изданија ќе се појават како што ќе се случи стабилизацијата ea самиот е веќе доволно стабилен за употреба, бидејќи помина низ каналите алфа и бета). Активиран преку мултиверф на следниот начин:

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

Заклучок

Новата архитектура за складирање на сцената и оптимизациите на градители за градителите на Stapel и Dockerfile ја отвораат можноста за имплементација на дистрибуирани и паралелни градби во werf. Овие функции наскоро ќе се појават во истото издание v1.1 и ќе станат автоматски достапни преку механизмот за автоматско ажурирање (за корисниците мултиверф).

Во ова издание, додадена е стратегија за означување базирана на содржина на слики - означување базирано на содржина, која стана стандардна стратегија. Главниот дневник на команди исто така е преработен: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

Следниот значаен чекор е да додадете дистрибуирани склопови. Дистрибуираните градби станаа повисок приоритет од паралелните градби од v1.0 затоа што додаваат поголема вредност на werf: вертикално скалирање на градители и поддршка за ефемерни градители во различни системи CI/CD, како и можност да се направи официјална поддршка за GitHub Actions . Затоа, роковите за имплементација за паралелни склопови беа поместени. Сепак, работиме да ги спроведеме двете можности што е можно поскоро.

Следете ги вестите! И не заборавајте да не посетите на GitHubда се создаде проблем, да се најде постоечко и да се додаде плус, да се создаде ПР или едноставно да се следи развојот на проектот.

PS

Прочитајте и на нашиот блог:

Извор: www.habr.com

Верф 1.1 издание: подобрувања на градителот денес и планови за иднината