Сада можете да правите Доцкер слике у верф-у користећи обичан Доцкерфиле

Боље икад него никад. Или како смо замало направили озбиљну грешку што нисмо имали подршку за обичне Доцкерфиле за прављење слика апликације.

причаћемо о верф — ГитОпс услужни програм који се интегрише са било којим ЦИ/ЦД системом и обезбеђује управљање читавим животним циклусом апликације, омогућавајући:

• прикупља и објављује слике,
• примени апликације у Кубернетес-у,
• избришите некоришћене слике помоћу посебних смерница.

Филозофија пројекта је прикупљање алата ниског нивоа у јединствени систем који ДевОпс инжењерима даје контролу над апликацијама. Ако је могуће, треба користити постојеће услужне програме (као што су Хелм и Доцкер). Ако нема решења за проблем, можемо креирати и подржати све што је потребно за то.

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

Ево шта се десило са колектором слика у верф-у: уобичајени Доцкерфиле нам није био довољан. Ако брзо погледате историју пројекта, овај проблем се појавио већ у првим верзијама верф-а (тада још увек познат као дапп).

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

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

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

Генерално, без размишљања, наоружали смо се програмским језиком који смо користили (види доле) и кренуо на пут за спровођење сопствени ДСЛ! У складу са циљевима, требало је да се процес склапања опише по фазама и да се утврде зависности ових фаза од фајлова. И допунио га сопствени колекционар, што је ДСЛ претворило у коначни циљ – састављену слику. У почетку је ДСЛ био у Руби-у, али као прелазак на Голанг — конфигурација нашег колектора је почела да се описује у ИАМЛ датотеци.

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

Тренутна конфигурација за верф на ИАМЛ-у

Временом се мењао и механизам колектора. У почетку смо једноставно генерисали привремени Доцкерфиле из наше конфигурације, а затим смо почели да покрећемо упутства за склапање у привременим контејнерима и урезујемо.

NB: Тренутно се наш колектор, који ради са сопственом конфигурацијом (у ИАМЛ) и зове се Стапел колектор, већ развио у прилично моћан алат. Његов детаљан опис заслужује посебне чланке, а основни детаљи се могу наћи у документација.

Свест о проблему

Али схватили смо, и то не одмах, да смо направили једну грешку: нисмо додали способност правите слике преко стандардног Доцкерфиле-а и интегрисати их у исту инфраструктуру за управљање апликацијама од краја до краја (тј. прикупљање слика, постављање и чишћење). Како је могуће направити алатку за имплементацију у Кубернетес, а не имплементирати Доцкерфиле подршку, тј. стандардни начин за описивање слика за већину пројеката?..

Уместо одговора на ово питање, ми нудимо решење. Шта ако већ имате Доцкерфиле (или скуп Доцкерфиле) и желите да користите верф?

NB: Узгред, зашто бисте уопште желели да користите верф? Главне карактеристике се своде на следеће:

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

Потпунију листу њих можете пронаћи на страница пројекта.

Дакле, ако бисмо раније понудили да препишемо Доцкерфиле у нашој конфигурацији, сада ћемо са задовољством рећи: „Нека верф направи ваше Доцкерфилес!“

Како користити?

Потпуна имплементација ове функције појавила се у издању верф в1.0.3-бета.1. Општи принцип је једноставан: корисник одређује путању до постојећег Доцкерфиле-а у верф конфигурацији, а затим покреће команду werf build... и то је то - верф ће саставити слику. Погледајмо један апстрактан пример.

Хајде да најавимо следећу Dockerfile у корену пројекта:

FROM ubuntu:18.04
RUN echo Building ...

И објавићемо werf.yamlкоји ово користи Dockerfile:

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

Све! Лево трцати werf build:

Поред тога, можете изјавити следеће werf.yaml да направите неколико слика из различитих Доцкер фајлова одједном:

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

Коначно, такође подржава преношење додатних параметара изградње, као што су --build-arg и --add-host - преко верф конфигурације. Комплетан опис конфигурације Доцкерфиле слике доступан је на страница документације.

Како то функционише?

Током процеса изградње, стандардна кеш меморија локалних слојева у Доцкер-у функционише. Међутим, оно што је важно је и то верф интегрише Доцкерфиле конфигурацију у своју инфраструктуру. Шта ово значи?

1. Свака слика направљена од Доцкерфиле-а састоји се од једне фазе тзв dockerfile (можете прочитати више о томе које су фазе у верф овде).
2. За сцену dockerfile верф израчунава потпис који зависи од садржаја конфигурације Доцкерфиле-а. Када се промени конфигурација Доцкерфиле-а, мења се потпис позорнице dockerfile а верф покреће реконструкцију ове фазе са новом конфигурацијом Доцкерфиле-а. Ако се потпис не промени, верф преузима слику из кеша (више детаља о употреби потписа у верф је описано у овај извештај).
3. Затим се прикупљене слике могу објавити командом werf publish (Или werf build-and-publish) и користите га за примену у Кубернетес. Објављене слике у Доцкер регистру биће очишћене помоћу стандардних верф алата за чишћење, тј. Старе слике (старије од Н дана), слике повезане са непостојећим Гит гранама и друге смернице биће аутоматски очишћене.

Више детаља о тачкама описаним овде можете пронаћи у документацији:

• Процес објављивања;
• Интеграција са процесом имплементације Кубернетеса;
• Процес чишћења.

Напомене и мере предострожности

1. Спољни УРЛ није подржан у АДД

Тренутно није подржано коришћење спољне УРЛ адресе у директиви ADD. Верф неће покренути поновну изградњу када се ресурс на наведеној УРЛ адреси промени. Планирамо да ускоро додамо ову функцију.

2. Не можете додати .гит на слику

Уопштено говорећи, додавање именика .git на слици - опака лоша пракса и ево зашто:

1. Ако .git остаје у коначној слици, ово крши принципе 12 фактор апп: Пошто коначна слика мора бити повезана са једним урезивањем, то не би требало бити могуће урадити git checkout произвољно извршење.
2. .git повећава величину слике (спремиште може бити велико због чињенице да су му једном додане велике датотеке, а затим избрисане). Величина радног стабла повезаног само са одређеним урезивањем неће зависити од историје операција у Гиту. У овом случају, додавање и накнадно уклањање .git са коначне слике неће функционисати: слика ће и даље добити додатни слој - овако функционише Доцкер.
3. Доцкер може покренути непотребну реконструкцију, чак и ако се гради исто урезивање, али са различитих стабала рада. На пример, ГитЛаб креира засебне клониране директоријуме у /home/gitlab-runner/builds/HASH/[0-N]/yourproject када је омогућено паралелно склапање. Додатно поновно састављање ће бити због чињенице да је директоријум .git се разликује у различитим клонираним верзијама истог спремишта, чак и ако је изграђено исто урезивање.

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

У принципу, додајући само одређене неопходне датотеке кроз упутства ADD у сваком случају повећава ефикасност и поузданост писаног Dockerfile, а такође побољшава стабилност кеша прикупљеног за ово Dockerfile, до ирелевантних промена у Гиту.

Укупан

Наш почетни пут до писања сопственог градитеља за специфичне потребе био је тежак, искрен и директан: уместо да користимо штаке на врху стандардног Доцкерфиле-а, написали смо наше решење са прилагођеном синтаксом. И ово је имало своје предности: Стапел колекционар савршено се носи са својим задатком.

Међутим, у процесу писања сопственог градитеља, изгубили смо из вида подршку за постојеће Доцкерфилес. Ова мана је сада исправљена, а у будућности планирамо да развијемо подршку за Доцкерфиле заједно са нашим прилагођеним Стапел градитељем за дистрибуирано састављање и за састављање помоћу Кубернетес-а (тј. састављање на покретачима унутар Кубернетеса, као што се ради у канико-у).

Дакле, ако одједном имате неколико Доцкер фајлова који леже около... пробај верф!

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

• Водичи за брзи почетак;
• конфигурације доцкерфиле буилдера;
• Фазе уређај у верф;
• Процес објављивања слика;
• Интеграција са процесом имплементације Кубернетеса;
• Процес чишћења;
• Стапел буилдер као алтернатива Доцкерфиле-у.

Прочитајте и на нашем блогу: „верф - наш алат за ЦИ / ЦД у Кубернетес-у (преглед и видео извештај)'.

Извор: ввв.хабр.цом