🥇Релиз 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 пачове: инсталиране, предиНастройка, настройка; или 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. При изчисляване на сигнатурата се счита контролната сума на файловете контекст, които ще се използват при сглобяването. Преди това подобрение werf рекурсивно минаваше през всички файлове и получаваше контролната сума, сумирайки контекста и модификацията на всеки файл. Започвайки от версии v1.1, werf може да използва изчислените контролни суми, съхранявани в Git-репозитория.

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

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

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

В версиите на 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, които няма да бъдат импортирани в образа.

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

Също така, 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 ще станат налични в тази версия, много от тях — в най-близко време. Актуализациите ще дойдат чрез автообновления при използване на 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'а на Kubernetes няма достъп до локалния Docker-сървър, тъй като самият процес е стартиран в контейнер, а работата с Docker-сървъра по мрежа werf не поддържа и няма да поддържа). Поддръжката на работа в Kubernetes ще бъде реализирана отделно.

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

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

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

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

Механиката на взаимодействие на потребителя с CI-системата ще бъде основана на поставяне на етикети на 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, Телеграм) и искаме все повече хора да помогнат да направят werf по-добър, да разберат в каква посока се движим и да участват в разработката.

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

Извършена е значителна работа с issues:

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

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

Версията е налична в момента в канал 1.1 ea (в каналите . Ако се е появила грешка с клъстера на канала, може да го превключите на и с rock-solid релизите ще се появяват, докато стабилизираме, но stable сама по себе си вече е достатъчно стабилна за използване, тъй като е преминала през каналите alpha и beta). Активира се чрез 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 или просто да наблюдавате развитието на проекта.