🥇Nüüd on werf'is võimalik koguda Docker-pilte ka tavaliste Dockerfile'ide põhjal

Parema hiljem kui kunagi varem. Või kuidas me peaaegu tegime tõsise vea, kui meil polnud tavaliste Dockerfile'ide tuge rakenduse piltide koostamiseks.

Räägime werf — GitOps-utility, mis integreerub igasuguste CI/CD-süsteemidega ja tagab rakenduse kogu elutsükli haldamise, võimaldades:

piltide koostamist ja avaldamist,
rakenduste seadistamist Kuberneteses,
jaotamata pilte eemaldamist spetsiaalsete poliitikate abil.

Projekti filosoofia on kokku koguda madala taseme tööriistad ühte ühtsesse süsteemi, andes DevOps-inseneridele kontrolli rakenduste üle. Kui võimalik, tuleks kasutada juba olemasolevaid tööriistu (nagu Helm ja Docker). Kui aga konkreetse ülesande lahendust pole — saame luua ja toetada kogu vajalikku selle jaoks.

Eelajalugu: oma pildikogumisseade

Nii juhtuski, et werfi pildikogumisseadmest jäi tavaline Dockerfile puudu. Kui vaadata projekti ajalugu, siis see probleem ilmus juba werfi varastes versioonides (tol ajal veel teadaolev kui dapp).

Koostades tööriista rakenduste ehitamiseks Docker-piltideks, saime kiiresti aru, et Dockerfile ei sobi meile teatud spetsiifiliste ülesannete jaoks:

Vajadus koguda tüüpilisi väikeseid veebirakendusi järgmise standardse skeemi järgi:
- paigaldada rakenduse süsteemilised sõltuvused,
- paigaldada rakenduse sõltuvuste bundel,
- koguda varasid,
- ja mis kõige tähtsam — värskendada koodi pildis kiiresti ja tõhusalt.
Projektifailide muudatuste korral peab kogumismoodul kiiresti looma uue kihi, rakendades muudatuste failidele patši.
Kui teatud failid on muutunud, tuleb vastav sõltuvus taas kokku panna.

Tänaseks on meie kogumismoodulis veel palju muid funktsioone, kuid algsed soovid ja vajadused olid sellised.

Ühesõnaga, mõtlemata kaua, haarasime kasutatava programmeerimiskeele (vt allpool) ja asusime teele — ellu viima oma DSL! Vastavalt seatud ülesannetele oli see mõeldud kogumisprotsessi etappide kirjeldamiseks ja nende etappide sõltuvuste määratlemiseks failidest. Seda täiendas oma kogumismoodul, mis muutis DSL-i lõppeesmärgiks - kogutud pildi. Alguses oli DSL Ruby põhine, kuid aja jooksul toimus üleminek Golangi — meie kogujate konfiguratsioon hakkas olema kirjeldatud YAML-failis.

Vana konfiguratsioon dapp jaoks Ruby

Praegune konfiguratsioon werf jaoks YAML

Kogujamehhanism on samuti aja jooksul muutunud. Alguses genereerisime vaid temporaarse Dockerfile meie konfiguratsioonist, kuid seejärel hakkasime käivitama kogimisjuhiseid ajutistes konteinerites ja tegema commit'e.

NB: Praeguseks on meie kogija, mis töötab oma YAML konfiguratsiooniga ja nimega Stapel-kogija, juba arenenud piisavalt võimsaks tööriistaks. Selle põhjalik kirjeldus väärib eraldi artikleid, kuid peamised üksikasjad saab teada dokumentatsioonis.

Probleemi teadvustamine

Kuid me mõistsime, kuigi mitte kohe, et tegime ühe vea: ei lisanud võimalust koguda pilte standardse Dockerfile'i kaudu ja integreerida need samasse rakenduse haldamise infrastruktuuri (st koguda pilte, neid kasutada ja puhastada). Kuidas oli võimalik luua tööriist Kubernetesis kasutamiseks ja mitte rakendada Dockerfile toe, st standardset viisi piltide kirjeldamiseks enamiku projektide jaoks?

Küsimusele vastamise asemel pakume välja lahenduse. Mida teha, kui teil on juba Dockerfile (või komplekt Dockerfile'ide) ja soovite kasutada werf'i?

NB: Üks oluline küsimus: miks üldse sooviksite werf'i kasutada? Peamised funktsioonid on järgmised:

täielik rakenduse haldusprotsess, sealhulgas pildihaldus;
võime hallata mitme pildi koostamist ühes ja samas konfiguratsioonis;
parandatud chartide deployimise protsess, mis on ühilduv Helm'iga.

Täieliku loendi nendest funktsioonidest leiate projekti lehelt.

Nii et kui varem oleksime soovitanud Dockerfile ümber kirjutada meie konfiguratsiooniks, siis nüüd saame rõõmuga öelda: "Laske werf'il koguda teie Dockerfile'id!"

Kuidas kasutada?

Selle funktsioonide täielik rakendamine sai teoks versioonis werf v1.0.3-beta.1. Üldine põhimõte on lihtne: kasutaja märgib werf'i konfiguratsioonis olemasoleva Dockerfile'i tee ja seejärel käivitab käsu. werf build… ja kõik — werf kogub pildi. Vaatame seda abstraktse näite kaudu.

Dekleeri järgmine Dockerfile projekti juures:

FROM ubuntu:18.04
RUN echo Ehitan ...

Ja deklareerime werf.yaml, mis kasutab seda Dockerfile:

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

Kõik! Jäänud on alustada werf build:

Lisaks saab deklareerida järgmise werf.yaml mitme pildi ehitamiseks erinevatest Dockerfile'idest:

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

Lõpuks toetatakse ka täiendavate ehitusparameetrite edastamist — näiteks --build-arg ja --add-host — läbi werf konfiguratsiooni. Täielik kirjelduse konfiguratsioon Dockerfile pildist on saadaval dokumentatsiooni lehel.

Kuidas see töötab?

Ehitusprotsessi käigus töötab Dockeris standardne kohalike kihtide vahemälu. Siiski, mis on oluline, werf ka integreerib Dockerfile konfiguratsiooni oma infrastruktuuri. Mida see tähendab?

Iga pilt, mis on ehitatud Dockerfile'ist, koosneb ühest staadiumist nimega dockerfile (rohkem stage'ide kohta werfis saab lugeda siit).
Stage'i puhul dockerfile werf arvutab allkirja, mis sõltub Dockerfile konfiguratsiooni sisust. Kui Dockerfile konfiguratsiooni muudetakse, muutub ka staadiumi allkiri. dockerfile werf käivitab selle etapi uuesti uue Dockerfile konfiguratsiooniga. Kui allkiri ei muutu, siis võtab werf pildi vahemälust. (allkirjade kasutamisest werfis on räägitud selles esituses).
Kokku kogutud pilte saab avaldada käsuga werf publish (või werf build-and-publish) ja kasutada Kubernetesis juurutamiseks. Avaldatud pildid Docker Registry's puhastatakse werfi standardsed puhastusmeetodid, st vanemad pildid (vanemad kui N päeva), pildid, mis on seotud mittesoodsa Git harudega, ja muude poliitikate alusel.

Koos siin kirjeldatud punktide kohta saab rohkem teavet dokumentatsioonist:

Märkused ja ettevaatusabinõud

1. Väline URL ADD-i sees ei ole toetatud.

Praegu ei toetata välist URL-i direktiivis ADD. Werf ei käivita uuesti koostamist, kui ressurss muutub antud URL-il. Alates sellest ajast on plaanis selle võimaluse lisamine.

2. .git ei tohi pildi sisse lisada.

Üldiselt on direktooriumi lisamine .git pildi sisse halb praktika ja siin on põhjused:

Kui .git jääb lõplikku kujusse, see rikub põhimõtteid 12 factor app: kuna lõplikku kujundust peab seostama ühe commit'iga, ei tohi olla võimalust teha git checkout töö käigus tehtud commit'i.
.git suurendab kujundi suurust (repo võib olla suur, kuna sinna on kunagi lisatud suuri faile ja hiljem need eemaldatud). Seotud commit'iga work-tree suurus ei sõltu aga Git'i tegevuste ajaloost. Sel juhul lisamine ja järgneva eemaldamine .git lõplikku kujundust ei toimi: kujund omandab ikkagi üleliigse kihi — nii töötab Docker.
Docker võib algatada üleliigse uuesti koostamise, isegi kui koostamine käib sama commit'i peal, kuid erinevatest work-tree'dest. Näiteks loob GitLab eraldi kloonitud katalooge /home/gitlab-runner/builds/HASH/[0-N]/yourproject kui paralleelne koostamine on lubatud. Üleliigne uuesti koostamine on seotud sellega, et kataloog .git erineb erinevates kloonitud versioonides samast repositooriumist, isegi kui kokku pannakse sama commit.

Viimasel punktid on tagajärg ka werfi kasutamisel. Werf nõuab, et koostatud vahemälu oleks olemas mõnede käskude käivitamisel (näiteks, werf deploy). Käsklusi täitmise ajal arvutab werf etappide signatuurid määratud image’ide jaoks, werf.yaml, ning need peavad olema ehitusmälus — vastasel juhul ei saa käsk jätkata. Kui aga etappide signatuur sõltub sisu, .git, saame me ebastabiilse vahemälu, mis ei ole muutuste suhtes irrelevantsetes failides ja werf ei suuda sellist eksimust andestada (vaata lähemalt dokumentatsioonis).

Üldiselt ainult vajalike failide lisamine instruktsiooni kaudu ADD kõigis olukordades parandab kirjutatu tõhusust ja usaldusväärsust Dockerfile, samuti parandab valmistamise vahemälu jäikust seoses Dockerfile, mitte-relevantsete muutustega Git’is.

Kokkuvõte

Meie esialgne tee oma ehitaja kirjutamiseks kindlate vajaduste jaoks oli keeruline, aus ja otsekohene: tavalise Dockerfile'i peal kiilude kasutamise asemel kirjutasime oma lahenduse kohandatud süntaksiga. See tõi kaasa plusse: Stapel-ehitaja täidab oma ülesandid suurepäraselt.

Kuid omaenda kogujat kirjutades unustasime juba olemasolevate Dockerfile'ide toe. Praegu on see puudus kõrvaldatud ja tulevikus plaanime arendada Dockerfile toe koos meie kohandatud koguja Stapeliga hajutatud kogumise ja Kubernetesega kogumise jaoks (st kogumine Kubernetes'i sees olevates runner'ites, nagu seda teeb kaniko).

Seega, kui teil on mõni Dockerfile vedelemas... proovige werf!