Сега можете да изградите Docker слики во werf користејќи обична Dockerfile

Подобро доцна отколку никогаш. Или како за малку ќе направивме сериозна грешка со тоа што немавме поддршка за обичните Dockerfiles за да создаваме слики од апликации.

Ќе разговараме за верф — GitOps алатка која се интегрира со кој било CI/CD систем и обезбедува управување со целиот животен циклус на апликацијата, овозможувајќи:

• собира и објавува слики,
• распореди апликации во Kubernetes,
• избришете ги неискористените слики користејќи специјални политики.

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

Позадина: ваш сопствен колекционер на слики

Еве што се случи со собирачот на слики во werf: вообичаеното Dockerfile не ни беше доволно. Ако набрзина погледнете во историјата на проектот, овој проблем се појави веќе во првите верзии на werf (тогаш сè уште познат како дап).

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

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

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

Во принцип, без да размислиме двапати, се вооруживме со програмскиот јазик што го користевме (Види подолу) и тргна на патот за спроведување сопствен DSL! Во согласност со целите, требаше да се опише процесот на склопување во фази и да се одредат зависностите на овие фази од датотеките. И го надополни сопствен колекционер, што го претвори DSL во конечна цел - склопена слика. На почетокот DSL беше во Руби, но како транзиција во Голанг — конфигурацијата на нашиот колектор почна да се опишува во датотека YAML.

Стара конфигурација за dapp во Руби

Тековна конфигурација за werf на YAML

Механизмот на колекторот исто така се менуваше со текот на времето. Отпрвин, едноставно генериравме привремен Dockerfile во лет од нашата конфигурација, а потоа почнавме да ги извршуваме упатствата за склопување во привремени контејнери и да извршуваме.

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

Свесност за проблемот

Но, сфативме, и тоа не веднаш, дека направивме една грешка: не ја додадовме способноста градење слики преку стандарден Dockerfile и интегрирајте ги во истата инфраструктура за управување со апликации од крај до крај (т.е. собирајте слики, распоредете ги и исчистете ги). Како е можно да се направи алатка за распоредување во Кубернетс и да не се имплементира поддршката за Dockerfile, т.е. стандарден начин за опишување на слики за повеќето проекти?..

Наместо да одговориме на ова прашање, ние нудиме решение. Што ако веќе имате Dockerfile (или збир на Dockerfiles) и сакате да користите werf?

NB: Патем, зошто воопшто би сакале да користите werf? Главните карактеристики се сведуваат на следново:

• целосен циклус на управување со апликации, вклучувајќи чистење на слики;
• можност за управување со склопување на неколку слики одеднаш од една конфигурација;
• Подобрен процес на распоредување за графикони компатибилни со Helm.

Поцелосен список од нив може да се најде на страница на проектот.

Значи, ако порано би понудиле да го преработиме Dockerfile во нашата конфигурација, сега со задоволство ќе кажеме: „Дозволете му да ги изгради вашите 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 да изградите неколку слики од различни Dockerfiles одеднаш:

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

Конечно, поддржува и пренесување дополнителни параметри за изградба, како на пр --build-arg и --add-host - преку werf config. Целосен опис на конфигурацијата на сликата на Dockerfile е достапен на страници документи.

Како тоа функционира?

За време на процесот на градење, функционира стандардниот кеш на локални слоеви во Docker. Сепак, она што е важно е и тој верф ја интегрира конфигурацијата на Dockerfile во својата инфраструктура. Што значи тоа?

1. Секоја слика изградена од Dockerfile се состои од една фаза наречена dockerfile (можете да прочитате повеќе за тоа кои фази се во верф тука).
2. За сцената dockerfile werf пресметува потпис кој зависи од содржината на конфигурацијата на Dockerfile. Кога ќе се промени конфигурацијата на Dockerfile, се менува потписот на сцената dockerfile и werf иницира обнова на оваа фаза со нова конфигурација на Dockerfile. Ако потписот не се промени, тогаш werf ја зема сликата од кешот (повеќе детали за употребата на потписи во верф беа опишани во овој извештај).
3. Следно, собраните слики може да се објават со командата werf publish (Или werf build-and-publish) и користете го за распоредување во Кубернетес. Објавените слики во Docker Registry ќе се чистат со користење на стандардни алатки за чистење на 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. Докер може да иницира непотребна реконструкција, дури и ако се гради истото заложба, но од различни работни дрвја. На пример, GitLab создава посебни клонирани директориуми во /home/gitlab-runner/builds/HASH/[0-N]/yourproject кога е овозможено паралелно склопување. Дополнително повторно склопување ќе се должи на фактот дека директориумот .git е различен во различни клонирани верзии на истото складиште, дури и ако е изграден ист commit.

Последната точка, исто така, има последици при користење на верф. Werf бара вградениот кеш да биде присутен при извршување на некои команди (на пр. werf deploy). Кога се извршуваат овие команди, werf пресметува потписи на сцената за сликите наведени во werf.yaml, и тие мора да бидат во кешот на собранието - во спротивно командата нема да може да продолжи да работи. Ако сценскиот потпис зависи од содржината .git, тогаш добиваме кеш што е нестабилен за промени во ирелевантни датотеки и werf нема да може да прости таков превид (за повеќе детали, види документација).

Во принцип, додавајќи само одредени потребни датотеки преку инструкциите ADD во секој случај ја зголемува ефикасноста и веродостојноста на напишаното Dockerfile, а исто така ја подобрува стабилноста на кешот собран за ова Dockerfile, до ирелевантни промени во Git.

Вкупно

Нашиот почетен пат до пишување на нашиот сопствен градител за специфични потреби беше тежок, искрен и јасен: наместо да користиме патерици над стандардниот Dockerfile, го напишавме нашето решение со прилагодена синтакса. И ова имаше свои предности: колекционерот Stapel совршено се справува со својата задача.

Сепак, во процесот на пишување на нашиот сопствен градител, ја изгубивме од вид поддршката за постоечките Dockerfiles. Овој пропуст сега е поправен и во иднина планираме да ја развиеме поддршката за Dockerfile заедно со нашиот прилагоден градител на Stapel за дистрибуирани изданија и за градби што користат Kubernetes (т.е. гради на тркачи во Kubernetes, како што се прави во kaniko).

Значи, ако одеднаш ви лежат неколку Dockerfiles наоколу... обидете се верф!

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

• Водичи за брз почеток;
• конфигурации на градител на dockerfile;
• Фази уред во верф;
• Процес на објавување слики;
• Интеграција со процесот на распоредување на Kubernetes;
• Процес на чистење;
• Stapel Builder како алтернатива на Dockerfile.

Прочитајте и во нашиот блог:werf - нашата алатка за CI / CD во Kubernetes (преглед и видео извештај)".

Извор: www.habr.com