Версия на werf 1.1: подобрения в създателя днес и планове за бъдещето

werf е нашата помощна програма GitOps CLI с отворен код за изграждане и доставяне на приложения до Kubernetes. Както е обещано, издание на версия v1.0 отбеляза началото на добавяне на нови функции към werf и преразглеждане на традиционните подходи. Сега имаме удоволствието да ви представим издание v1.1, което е голяма стъпка в развитието и основа за бъдещето колектор werf. В момента версията е достъпна в канал 1.1 бр.

Основата на изданието е новата архитектура на сценичното съхранение и оптимизирането на работата на двата колектора (за 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 е етапен подпис, който представлява идентификатора на етапното съдържание и зависи от хронологията на редакциите в Git, довели до това съдържание;
• TIMESTAMP_MILLISEC е гарантиран уникален идентификатор на изображение, който се генерира по време на изграждането на ново изображение.

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

1. Werf изчислява сигнатурата на определен етап.
2. В етапи-склад Може да има няколко етапа за даден подпис. Werf избира всички етапи, които отговарят на подписа.
3. Ако текущият етап е свързан с Git (git-архив, потребителски етап с Git пачове: install, beforeSetup, setup; или git-latest-patch), тогава werf избира само онези етапи, които са свързани с ангажимент, който е предшественик на текущия комит (за който се извиква компилацията).
4. От останалите подходящи етапи се избира един - най-старият по дата на създаване.

Етап за различни клонове на Git може да има еднакъв подпис. Но werf ще попречи на кеша, свързан с различни клонове, да се използва между тези клонове, дори ако подписите съвпадат.

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

Нов алгоритъм за създаване и запазване на етапи в хранилището на етапа

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

Сигнатурата на етапите на изображението зависи от:

1. съдържанието на това изображение;
2. истории на промените в Git, довели до това съдържание.

Хранилището на Git винаги има фиктивни ангажименти, които не променят съдържанието на файловете с изображения. Например ангажименти само с коментари или ангажименти за сливане, или ангажименти, които променят онези файлове в Git, които няма да бъдат импортирани в изображението.

При използване на маркиране, базирано на съдържание, проблемите с ненужно рестартиране на пакети на приложения в Kubernetes поради промени в името на изображението се решават, дори ако съдържанието на изображението не се е променило. Между другото, това е една от причините, които предотвратяват съхраняването на много микроуслуги на едно приложение в едно Git хранилище.

Също така, базираното на съдържание маркиране е по-надежден метод за маркиране от маркирането на клонове на Git, тъй като съдържанието на получените изображения не зависи от реда, в който се изпълняват конвейери в CI системата за сглобяване на множество ангажименти на един и същи клон.

Важно е: от сега етапи-подпис - единствената препоръчителна стратегия за маркиране. Той ще се използва по подразбиране в командата werf ci-env (освен ако изрично не посочите различна схема за маркиране).

→ Документация. На тази функция ще бъде посветена и отделна публикация. АКТУАЛИЗИРАНО (3 април): Статия с подробности публикувано.

Нива на регистриране

Потребителят вече има възможност да контролира изхода, да зададе нивото на регистриране и да работи с информация за отстраняване на грешки. Добавени опции --log-quiet, --log-verbose, --log-debug.

По подразбиране изходът съдържа минималната информация:

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

Подробен изход (--log-debug), в допълнение към информацията за отстраняване на грешки на werf, съдържа и регистрационни файлове на използвани библиотеки. Например можете да видите как се осъществява взаимодействието с регистъра на Docker и също така да запишете местата, където се прекарва значително време:

По-нататъшни планове

Внимание! Опциите, описани по-долу, са маркирани v1.1 ще станат достъпни в тази версия, много от тях в близко бъдеще. Актуализациите ще идват чрез автоматични актуализации когато използвате multiwerf. Тези функции не засягат стабилната част на функциите v1.1; появата им няма да изисква ръчна намеса на потребителя в съществуващите конфигурации.

Пълна поддръжка за различни реализации на Docker Registry (НОВО)

• Версия: v1.1
• Дати: март
• Издаване

Целта е потребителят да използва персонализирана реализация без ограничения, когато използва werf.

В момента сме идентифицирали следния набор от решения, за които ще гарантираме пълна поддръжка:

• По подразбиране (библиотека/регистър)*,
• AWS ECR
• лазурно*,
• Docker Hub
• GCR*,
• GitHub пакети
• Регистър на GitLab*,
• пристанище*,
• Кей.

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

Могат да бъдат идентифицирани два основни проблема:

• Някои решения не поддържат премахване на тагове с помощта на API на регистъра на Docker, което не позволява на потребителите да използват автоматичното почистване на werf. Това важи за пакетите AWS ECR, Docker Hub и GitHub.
• Някои решения не поддържат така наречените вложени хранилища (Docker Hub, GitHub Packages и Quay) или поддържат, но потребителят трябва да ги създаде ръчно с помощта на потребителския интерфейс или API (AWS ECR).

Ние ще разрешим тези и други проблеми, като използваме собствените API на решенията. Тази задача включва и покриване на пълния цикъл на работа на werf с тестове за всеки от тях.

Изграждане на разпределено изображение (↑)

• Версия: v1.2 v1.1 (приоритетът за прилагане на тази функция е увеличен)
• Дати: март-април март
• Издаване

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

За да се отворят възможностите за разпределена работа на werf, когато изграждането и внедряването на приложения в Kubernetes се стартират на няколко произволни хоста и тези хостове не запазват състоянието си между компилациите (временни изпълняващи се), werf се изисква да реализира възможността за използване регистъра на Docker като място за съхранение.

Преди това, когато проектът werf все още се наричаше dapp, имаше такава възможност. Въпреки това се натъкнахме на редица проблеми, които трябва да бъдат взети под внимание при внедряването на тази функционалност в werf.

Внимание. Тази функция не изисква колекторът да работи в Kubernetes pods, защото За да направите това, трябва да се отървете от зависимостта от локалния Docker сървър (в Kubernetes pod няма достъп до локалния Docker сървър, защото самият процес се изпълнява в контейнер, а werf не поддържа и няма да поддържа работа с Docker сървъра през мрежата). Поддръжката за работа с Kubernetes ще бъде внедрена отделно.

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

• Версия: v1.1
• Дати: март
• Издаване

Включва werf документация (секции справка и ръководи), както и официалното GitHub действие за работа с werf.

В допълнение, това ще позволи на werf да работи върху ефимерни бегачи.

Механиката на взаимодействие на потребителя с CI системата ще се основава на поставяне на етикети върху заявки за изтегляне, за да се инициират определени действия за изграждане/разгръщане на приложението.

Локално разработване и внедряване на приложения с werf (↓)

• Версия: v1.1
• Дати: януари-февруари април
• Издаване

Основната цел е да се постигне единна унифицирана конфигурация за внедряване на приложения както локално, така и в производство, без сложни действия, извън кутията.

werf също трябва да има режим на работа, в който ще бъде удобно да редактирате кода на приложението и незабавно да получавате обратна връзка от работещото приложение за отстраняване на грешки.

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

• Версия: v1.1
• Дати: април
• Издаване

В текущата версия на werf v1.1 в процедурата cleanup Няма разпоредба за почистване на изображения за базираната на съдържание схема за маркиране - тези изображения ще се натрупват.

Също така текущата версия на werf (v1.0 и v1.1) използва различни правила за почистване за изображения, публикувани под схеми за маркиране: Git клон, Git tag или Git commit.

Изобретен е нов алгоритъм за почистване на изображения, базиран на историята на комитите в Git, унифициран за всички схеми за маркиране:

• Съхранявайте не повече от N1 изображения, свързани с най-новите ангажименти N2 за всеки git HEAD (клонове и тагове).
• Съхранявайте не повече от N1 етапни изображения, свързани с N2 най-скорошни ангажименти за всеки git HEAD (клонове и тагове).
• Съхранявайте всички изображения, които се използват във всички ресурси на клъстер на Kubernetes (всички контексти на kube на конфигурационния файл и пространства от имена се сканират; можете да ограничите това поведение със специални опции).
• Съхранявайте всички изображения, които се използват в манифести за конфигурация на ресурси, запазени в изданията на Helm.
• Изображение може да бъде изтрито, ако не е свързано с нито един HEAD от git (например, защото самият съответен HEAD е изтрит) и не се използва в никакви манифести в клъстера на Kubernetes и в изданията на Helm.

Паралелно изграждане на изображение (↓)

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

Текущата версия на werf събира изображенията и артефактите, описани в werf.yaml, последователно. Необходимо е да се паралелизира процесът на сглобяване на независими етапи от изображения и артефакти, както и да се осигури удобен и информативен изход.

* Забележка: крайният срок е изместен поради увеличения приоритет за внедряване на разпределено асемблиране, което ще добави повече възможности за хоризонтално мащабиране, както и използването на werf с GitHub Actions. Паралелното сглобяване е следващата стъпка на оптимизация, осигуряваща вертикална мащабируемост при сглобяването на един проект.

Преход към Helm 3 (↓)

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

Включва миграция към нова кодова база Шлем 3 и доказан, удобен начин за мигриране на съществуващи инсталации.

* Забележка: преминаването към Helm 3 няма да добави значителни функции към werf, тъй като всички ключови характеристики на Helm 3 (3-посочно сливане и без управление) вече са внедрени в werf. Освен това werf има допълнителни функции в допълнение към посочените. Този преход обаче остава в нашите планове и ще бъде осъществен.

Jsonnet за описание на конфигурацията на Kubernetes (↓)

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

Werf ще поддържа описания на конфигурацията за Kubernetes във формат Jsonnet. В същото време werf ще остане съвместим с Helm и ще има избор на формат на описание.

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

Обмисля се и възможността за въвеждане на други системи за описание на конфигурацията на Kubernetes (например Kustomize).

Работа в Kubernetes (↓)

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

Цел: Уверете се, че изображенията са създадени и приложението се доставя с помощта на runners в Kubernetes. Тези. Нови изображения могат да се изграждат, публикуват, почистват и внедряват директно от Kubernetes pods.

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

Той също така изисква поддръжка за режим на работа на строителя без Docker сървър (т.е. компилация, подобна на Kaniko или компилация в потребителско пространство).

Werf ще поддържа изграждането на Kubernetes не само с Dockerfile, но и със своя Stapel builder с постепенни реконструкции и Ansible.

Стъпка към отворено развитие

Обичаме нашата общност (GitHub, Telegram) и искаме все повече и повече хора да помагат за подобряването на werf, да разбират посоката, в която се движим, и да участват в разработката.

Съвсем наскоро беше решено да се премине към Платки за проекти GitHub за да разкрием работния процес на нашия екип. Сега можете да видите непосредствените планове, както и текущата работа в следните области:

• Документация и сайт;
• Тестване;
• Грешки и лош UX;
• 1.1.

Беше свършена много работа по проблемите:

• Премахнати са неуместните.
• Съществуващите се привеждат в единен формат, с достатъчен брой детайли и подробности.
• Добавени са нови проблеми с идеи и предложения.

Как да активирам версия v1.1

В момента версията е достъпна в канал 1.1 бр (в каналите стабилен и здрав като скала изданията обаче ще се появят при настъпване на стабилизация ea сам по себе си вече е достатъчно стабилен за употреба, т.к премина през каналите алфа и бета). Активиран чрез multiwerf по следния начин:

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

Заключение

Новата архитектура за съхранение на сцената и оптимизациите на компилатора за Stapel и Dockerfile builder отварят възможността за внедряване на разпределени и паралелни компилации в werf. Тези функции скоро ще се появят в същата версия v1.1 и ще станат автоматично достъпни чрез механизма за автоматично актуализиране (за потребители multiwerf).

В тази версия е добавена стратегия за маркиране, базирана на съдържание на изображение - маркиране, базирано на съдържание, което се превърна в стратегия по подразбиране. Основният дневник на командите също е преработен: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

Следващата важна стъпка е добавянето на разпределени сборки. Разпределените компилации се превърнаха в по-висок приоритет от паралелните компилации след v1.0, тъй като те добавят повече стойност към werf: вертикално мащабиране на конструктори и поддръжка за краткотрайни конструктори в различни CI/CD системи, както и възможност за официална поддръжка за GitHub Actions . Поради това сроковете за изпълнение на паралелните монтажи бяха изместени. Ние обаче работим за прилагането на двете възможности възможно най-скоро.

Следете новините! И не забравяйте да ни посетите на GitHubда създадете проблем, да намерите съществуващ и да добавите плюс, да създадете PR или просто да наблюдавате развитието на проекта.

PS

Прочетете също в нашия блог:

• «Представяне на werf 1.0 stable: какво общо има GitOps с него, статус и планове»
• «werf - нашият инструмент за CI / CD в Kubernetes (общ преглед и видео отчет)»;
• Поредица от бележки за иновациите в werf:
  • «3-посочно сливане към werf: внедряване в Kubernetes с Helm „на стероиди“»;
  • «Използване на werf за внедряване на сложни диаграми на Helm»;
  • «Поддръжка за monorepo и multirepo в werf и какво общо има Docker Registry с това»;
  • «Вече можете да създавате Docker изображения в werf, като използвате обикновен Dockerfile".

Източник: www.habr.com