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

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

Основата на изданията е новата архитектура на хранилището на етапи и оптимизацията на работата на двата сборщика (за 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 репозитория.

В основата на алгоритъма е git ls-tree. Алгоритъмът взема предвид записите в .dockerignore и преминава рекурсивно по дървото на файловете само при необходимост. Така се освободихме от четенето на файловата система, а зависимостта на алгоритъма от размера context не е съществена.

Също така алгоритъмът проверява неотслежваните файлове и при необходимост ги включва в контролната сума.

Подобрена е производителността при импортиране на файлове

В версиите на werf v1.1 се използва rsync-сервер при импортиране на файлове от артефакти и образи. По-рано импортирането се извършваше в два етапа с използването на монтиране на директория от хост-системата.

Производителността на импорти в macOS вече не се ограничава до Docker volumes, а импортирането се извършва за същото време, както в Linux и Windows.

Тагиране на базата на съдържание

Werf v1.1 поддържа така нареченото тагиране по съдържанието на образа — content-based tagging. Таговете на получените Docker-образи зависят от съдържанието на тези образи.

При стартиране на командата werf publish --tags-by-stages-signature или werf ci-env --tagging-strategy=stages-signature ще бъдат тагирани публикуваните образи с така наречената сигнатура на етапите на образа. Всеки образ се тагира със собствената си сигнатура на етапите на този образ, която се изчислява по същите правила, както и редовната сигнатура на всеки етап поотделно, но е обобщаващ идентификатор на образа.

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

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

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

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

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

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

→ Документация. На тази функция ще бъде посветена и отделна публикация. ОБНОВЕНО (3 април): Статия с подробности беше публикувана.

Нива на логване

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

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

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

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

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

Внимание! По-долу описаните възможности с бележка v1.1 ще станат достъпни в тази версия, много от тях – в най-скоро време. Актуализациите ще дойдат чрез автообновления при използване на multiwerf. Тези възможности не засягат стабилната част от функциите 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-a на Kubernetes няма достъп до локалния Docker-сървър, тъй като самият процес е стартиран в контейнер, а работата с Docker-сървъра през мрежа werf не поддържа и няма да поддържа). Поддръжката на работа в Kubernetes ще бъде реализирана отделно.

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

Версия: v1.1
Срокове: март
Проблем

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

Освен това, ще позволя да работи werf на ефемерни runner-и.

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

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

Версия: v1.1
Срокове: януари-февруари април
Проблем

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

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

* Забележка: преминаването към 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.

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

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

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

Извършена е голяма работа с issues:

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

Как да включите версия v1.1

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

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

Заключение

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

В този релиз беше добавена стратегия за означаване на съдържанието на образите — content-based tagging, — която стана стратегия по подразбиране. Също така беше преработен логът на основните команди: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

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

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