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

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

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

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

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

Предистория: собствен сборщик на образи

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

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

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

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

В общи линии, без много да се замисляме, се въоръжихме с използвания език за програмиране (вж. по-долу) и се отправихме по пътя — да реализираме собствен DSL! В съответствие с поставените задачи, той беше предназначен за описване на процеса на изграждане по стъпки и определяне на зависимостите на тези стъпки от файловете. А допълваше го собствен сборщик, който превръщаше DSL в крайна цел — събрания образ. Първоначално DSL беше на Ruby, а с преминаването на Golang — конфигурацията на нашия сборщик започна да се описва в YAML файл. — конфиг нашего сборщика стал описываться в 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 факторно приложение: тъй като крайният образ трябва да бъде свързан с един комит, не би трябвало да има възможност за извършване на git checkout произволен комит.
.git увеличава размера на образа (репозиторият може да е голям заради това, че преди време в него са били добавени големи файлове, а след това са изтрити). Размерът на work-tree, свързано само с определен комит, не зависи от историята на операциите в 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!

P.S. Списък с документация по темата

Прочетете също в нашия блог: «werf — наш инструмент за CI/CD в Kubernetes (обзор и видео доклад)».

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