🥇Събирайте Docker изображения в werf сега можете и по обикновен Dockerfile

По-добре късно, отколкото никога. Или как едва не допуснахме сериозна грешка, без да имаме поддръжка за обикновени Dockerfiles при изграждането на приложения.

Става въпрос за werf — GitOps инструмент, който се интегрира с всяка CI/CD система и осигурява управление на целия жизнен цикъл на приложението, позволявайки:

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

Философията на проекта е да обединим ниско ниво инструменти в единна унифицирана система, давайки на DevOps инженерите контрол над приложенията. Където е възможно, трябва да се използват вече съществуващи инструменти (като Helm и Docker). Ако обаче няма готово решение за определен проблем, можем да създадем и поддържаме всичко необходимо за това.

Предистория: нашият сборчик на образи

Така се случи със сборчика на образи в werf: обичайният Dockerfile не ни достигаше. Ако погледнем бързо в историята на проекта, този проблем се прояви още в първите версии на werf (тогава все още известен като dapp).

Създавайки инструмент за изграждане на приложения в Docker образи, бързо осъзнахме, че Dockerfile не е подходящ за някои конкретни задачи:

Необходимостта да изграждаме типични малки уеб приложения по следния стандартен модел:
- да инсталираме общосистемни зависимости на приложението,
- да инсталираме пакет от зависимости на приложението,
- да изградим активи,
- и най-важното — да обновяваме кода в образа бързо и ефективно.
При промени във файловете на проекта сборчикът трябва бързо да създаде нов слой, налагайки пач на променените файлове.
Ако са променени определени файлове, е необходимо да се пререгистрира съответната зависима фаза.

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

Накратко, без много да се замисляме, въоръжихме се с използвания език за програмиране (вж. по-долу) и поехме по пътя — да реализираме собствен DSL! Съответствайки на поставените задачи, той беше предназначен за описание на процеса на изграждане по фази и определяне на зависимостите на тези фази от файловете. А го допълваше собствен сборчик, който превръщаше DSL в крайна цел — сглобен образ. Първоначално DSL беше на Ruby, а с преминаването към Golang — конфигурацията на нашия сборчик започна да се описва в YAML файл.

Старият конфиг за dapp на Ruby

Актуалният конфиг за werf на YAML

Механизмът на работа на сборщика също се е променял с времето. Първоначално просто генерирахме на момента някакъв временен Dockerfile от нашата конфигурация, а после започнахме да изпълняваме сборочни инструкции във временни контейнери и да правим commit.

NB: В момента нашият сборщик, който работи с собствен конфиг (в YAML) и се нарича Stapel-сборщик, вече се е развил в доста мощен инструмент. Неговото подробно описание заслужава отделни статии, а основните подробности можете да научите от документацията.

Осъзнаване на проблема

Но разбрахме, и не веднага, че направихме една грешка: не добавихме възможността да се събират образи чрез стандартен Dockerfile и да ги интегрираме в същата инфраструктура на комплексно управление на приложения (т.е. да събираме образи, да ги деплоим и да ги почистваме). Как можехме да направим инструмент за деплой в Kubernetes и да не реализираме поддръжка за Dockerfile, т.е. стандартния начин за описание на образите за повечето проекти?..

Вместо отговор на такъв въпрос предлагаме решението му. Какво да правите, ако вече имате Dockerfile (или набор от Dockerfile'и) и искате да използвате werf?

NB: Между другото, защо изобщо бихте искали да използвате werf? Основните му функции включват:

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

С по-пълния им списък можете да се запознаете на страницата на проекта.

И така, ако преди бихме предложили да пренапишете Dockerfile на нашия конфиг, то сега с радост ще кажем: "Позволете на werf да събере вашите Dockerfile'и!"

Как да я използвате?

Пълната реализация на тази възможност се появи в релиза werf v1.0.3-beta.1. Общият принцип е прост: потребителят посочва пътя до съществуващия Dockerfile в конфига на werf, след което стартира командата werf build… и всичко — werf ще събере образа. Нека разгледаме на абстрактен пример.

Декларираме следния Dockerfile в корена на проекта:

FROM ubuntu:18.04
RUN echo Building ...

И декларираме werf.yaml, който използва този Dockerfile:

configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: .\/Dockerfile

Всичко! Остава да стартира werf build:

Освен това, можете да декларирате следния werf.yaml за сборка на няколко образа от различни Dockerfile'и:

configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: .\/dockerfiles\/Dockerfile-backend
---
image: frontend
dockerfile: .\/dockerfiles\/Dockerfile-frontend

Накрая, се поддържа и предаването на допълнителни параметри за сборка — като --build-arg и --add-host — чрез конфигурацията на werf. Пълното описание на конфигурацията на образа Dockerfile е налично на страницата с документация.

Как работи това?

В процеса на изграждане функционира стандартният кеш на локалните слоеве в Docker. Важно е, че werf също интегрира конфигурацията на Dockerfile в своята инфраструктура. Какво означава това?

Всеки образ, събран от Dockerfile, се състои от един етап на име dockerfile (повече за това какво представляват етапите в werf можете да прочетете тук.).
За етапа dockerfile werf изчислява подпис, който зависи от съдържанието на конфигурацията на Dockerfile. При промяна на конфигурацията на Dockerfile се променя подписът на етапа dockerfile и werf инициира ново изграждане на този етап с новата конфигурация на Dockerfile. Ако обаче подписът не се променя, werf взема образа от кеша (повече за използването на подписи в werf беше споменато в този доклад).
След това събраните образи могат да бъдат публикувани с командата werf publish (или werf build-and-publish) и да бъдат използвани за разгръщане в Kubernetes. Публикуваните образи в Docker Registry ще бъдат чистени с помощта на стандартни средства за почистване на werf, т.е. ще се извърши автоматично почистване на стари образи (по-стари от N дни), образи, свързани с несъществуващи Git клонове, и по други политики.

Повече относно описаните тук моменти можете да научите от документацията:

Бележки и предупреждения

1. Външен URL в ADD не се поддържа

В момента не се поддържа използването на външен URL в директивата ADD. Werf няма да инициира ново изграждане при промяна на ресурса по указан URL. В скоро време се планира добавяне на тази възможност.

2. Не може да се добавя .git в образа

Общо взето, добавянето на директория .git в образа е лоша практика и ето защо:

Ако .git остава в крайния образ, което нарушава принципите 12 factor app: тъй като крайният образ трябва да бъде свързан с един комит, не трябва да има възможност да се направи git checkout на произволен комит.
.git увеличава размера на образа (репозитория може да е голям, тъй като в него някога са били добавени големи файлове, а след това са били изтрити). Размерът на работното дърво, свързано само с определен комит, няма да зависи от историята на операциите в Git. При това добавянето и последващото изтриване .git От финалния образ няма да сработи: образът все пак ще получи излишен слой — така работи Docker.
Docker може да инициира излишно повторно изграждане, дори ако става въпрос за изграждане на същото комит, но от различни work-tree. Например, GitLab създава отделни клонирани директории в /home/gitlab-runner/builds/HASH/[0-N]/yourproject при включено паралелно изграждане. Излишното повторно изграждане ще бъде свързано с това, че директорията .git се различава в различните клонирани версии на едно и също хранилище, дори ако се изгражда същият комит.

Последният пункт има последствие и при използването на werf. Werf изисква, за да е налична изграденият кеш при стартиране на определени команди (например, werf deploy). По време на изпълнението на такива команди werf изчислява подписите на етапите за образите, указани в werf.yaml, и те трябва да бъдат в изградения кеш — в противен случай командата не може да продължи работа. Ако обаче подписът на етапите зависи от съдържанието .git, получаваме нестабилен кеш, устойчив на промени в нерелевантни файлове, и werf няма да може да прости такова пропускане (повече информация можете да намерите в документацията).

В обобщение добавяне само на определени необходими файлове чрез инструкция ADD във всеки случай повишава ефективността и надеждността на написаното Dockerfile, а също така подобрява устойчивостта на кеша, събран по данен Dockerfile, на нерелевантни промени в Git.

Резюме

Нашият първоначален път с написването на собствен билдър за определени нужди беше труден, честен и директен: вместо да използваме опорни точки върху стандартния Dockerfile, написахме собствено решение с персонализиран синтаксис. И това даде своите плюсове: Stapel билдърът отлично се справя със задачата си.

Въпреки това, в процеса на написване на собствен билдър, пропуснахме да добавим поддръжка за вече съществуващи Dockerfile. Сега този недостатък е отстранен, а в бъдеще планираме да развиваме поддръжката на Dockerfile наред с нашия персонализиран билдър Stapel за разпределено изграждане и за изграждане с използване на Kubernetes (т.е. изграждане на runner-и вътре в Kubernetes, както е направено в kaniko).

Така че, ако случайно имате няколко Dockerfile-ови... опитайте werf!