Вече можете да създавате Docker изображения в werf, като използвате обикновен Dockerfile

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

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

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

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

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

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

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

1. Необходимостта от сглобяване на типични малки уеб приложения съгласно следната стандартна схема:
   • инсталирайте системните зависимости на приложението,
   • инсталирайте пакет от библиотеки за зависимост на приложението,
   • събира активи,
   • и най-важното, актуализирайте кода в изображението бързо и ефективно.
2. Когато се правят промени във файловете на проекта, създателят трябва бързо да създаде нов слой, като коригира променените файлове.
3. Ако някои файлове са променени, тогава съответният зависим етап трябва да бъде изграден отново.

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

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

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

Действителна конфигурация за werf на YAML

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

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

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

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

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

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

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

По-пълен списък може да бъде намерен на страница на проекта.

Така че, ако по-рано предложихме пренаписване на Dockerfile в нашата конфигурация, сега сме щастливи да кажем: „Нека werf изгради вашите Dockerfiles!“

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

Пълното изпълнение на тази функция се появи в изданието 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 за създаване на няколко изображения наведнъж от различни Docker файлове:

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 в своята инфраструктура. Какво означава това?

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

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

• Процес на публикуване;
• Интеграция с процеса на внедряване в Kubernetes;
• Процес на почистване.

Бележки и предпазни мерки

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

Използването на външен URL адрес в директива в момента не се поддържа. ADD. Werf няма да задейства повторно изграждане, когато ресурс на посочения URL се промени. Тази функция се планира да бъде добавена скоро.

2. Не можете да добавите .git към изображение

Най-общо казано, добавяне на директория .git в изображение е порочна лоша практика и ето защо:

1. ако .git остава в крайния образ, това нарушава принципите 12 факторно приложение: тъй като полученото изображение трябва да бъде свързано с един комит, не би трябвало да е възможно да се направи git checkout произволен ангажимент.
2. .git увеличава размера на изображението (хранилището може да е голямо поради факта, че големи файлове веднъж са били добавени към него и след това изтрити). Размерът на работното дърво, свързано само с конкретен комит, няма да зависи от историята на операциите в Git. В този случай добавянето и последващото премахване .git от крайното изображение няма да работи: изображението все още ще придобие допълнителен слой - така работи Docker.
3. Docker може да задейства ненужно повторно изграждане, дори ако един и същи ангажимент се изгражда от различни работни дървета. Например 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-колекторът върши работата си перфектно.

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

Така че, ако внезапно имате няколко Docker файла, разположени наоколо... Опитвам werf!

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

• Ръководства за бърз старт;
• конфигурации на създателя на dockerfile;
• етапи устройство в werf;
• Процес на публикуване на изображения;
• Интеграция с процеса на внедряване в Kubernetes;
• Процес на почистване;
• Stapel builder като алтернатива на Dockerfile.

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

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