Nüüd saate luua Dockeri pilte werf-is, kasutades tavalist Dockerfile'i

Parem hilja kui mitte kunagi. Või kuidas me tegime peaaegu tõsise vea, kuna meil polnud rakenduspiltide loomiseks tavaliste Dockerfile'ide tuge.

Me räägime werf — GitOpsi utiliit, mis integreerub mis tahes CI/CD süsteemiga ja haldab kogu rakenduse elutsüklit, võimaldades:

• koguda ja avaldada pilte,
• juurutada rakendusi Kubernetes,
• kustutage kasutamata pildid spetsiaalsete reeglite abil.

Projekti filosoofia on koondada madala taseme tööriistad ühtsesse süsteemi, mis annab DevOpsi inseneridele kontrolli rakenduste üle. Võimaluse korral tuleks kasutada olemasolevaid utiliite (nt Helm ja Docker). Kui probleemile lahendust pole, saame luua ja toetada kõik selleks vajaliku.

Taust: teie enda pildikoguja

Nii juhtus werfi pildikogujaga: tavalisest Dockerfile'ist meile ei piisanud. Kui heita pilk projekti ajalukku, siis see probleem ilmnes juba werfi esimestes versioonides (siis veel tuntud kui dapp).

Rakenduste Dockeri kujutistesse ehitamise tööriista loomisel mõistsime kiiresti, et Dockerfile ei sobi meile mõne väga spetsiifilise ülesande jaoks:

1. Vajadus luua tüüpilisi väikeseid veebirakendusi vastavalt järgmisele standardskeemile:
   • installige süsteemiülesed rakendusesõltuvused,
   • installida rakenduste sõltuvusteeke,
   • koguda varasid,
   • ja mis kõige tähtsam, värskendage pildil olevat koodi kiiresti ja tõhusalt.
2. Kui projektifailides tehakse muudatusi, peab ehitaja kiiresti looma uue kihi, rakendades muudetud failidele paiga.
3. Kui teatud failid on muutunud, siis tuleb vastav sõltuv etapp uuesti üles ehitada.

Tänapäeval on meie kollektsionääril palju muid võimalusi, kuid need olid esialgsed soovid ja tungid.

Üldiselt relvastasime end kaks korda mõtlemata programmeerimiskeelega, mida kasutasime (vt allpool) ja asuda ellu viima enda DSL! Kooskõlas eesmärkidega sooviti kirjeldada komplekteerimisprotsessi etappide kaupa ja määrata nende etappide sõltuvused failidest. Ja täiendas seda oma kollektsionäär, mis muutis DSL-i lõplikuks eesmärgiks – kokkupandud pildiks. Algul oli DSL Ruby keeles, aga nagu üleminek Golangile - meie koguja konfiguratsiooni hakati kirjeldama YAML-failis.

Ruby dappi vana konfiguratsioon

Praegune werfi konfiguratsioon YAML-is

Aja jooksul muutus ka kollektori mehhanism. Alguses genereerisime lihtsalt oma konfiguratsioonist käigu pealt ajutise Dockerfile'i ja seejärel hakkasime ajutistes konteinerites koostamisjuhiseid täitma ja kinnitama.

NB: Hetkel on meie kollektor, mis töötab oma konfiguratsiooniga (YAML-is) ja kannab nime Stapeli kollektor, juba üsna võimsaks tööriistaks. Selle üksikasjalik kirjeldus väärib eraldi artikleid ja põhiandmed leiate aadressilt dokumentatsioon.

Probleemi teadvustamine

Kuid saime aru, ja mitte kohe, et olime teinud ühe vea: me ei lisanud võimekust luua pilte standardse Dockerfile'i kaudu ja integreerida need samasse rakenduste haldamise infrastruktuuri (st koguda pilte, juurutada ja puhastada). Kuidas oleks võimalik teha Kubernetesis juurutamiseks tööriist ja mitte rakendada Dockerfile'i tuge, st. tavapärane viis piltide kirjeldamiseks enamiku projektide jaoks?

Sellele küsimusele vastamise asemel pakume lahendust. Mis siis, kui teil on juba Dockerfile (või Dockerfile'i komplekt) ja soovite kasutada werfi?

NB: Muide, miks sa üldse tahad werfi kasutada? Peamised omadused taanduvad järgmistele:

• täielik rakenduste haldustsükkel, sealhulgas pildi puhastamine;
• võimalus hallata mitme pildi kokkupanekut korraga ühest konfiguratsioonist;
• Helmiga ühilduvate diagrammide täiustatud juurutamisprotsess.

Nende täielikuma nimekirja leiate aadressilt projekti leht.

Seega, kui varem oleksime pakkunud oma konfiguratsioonis Dockerfile'i ümberkirjutamist, siis nüüd ütleme rõõmsalt: "Las werf ehitab oma Dockerfailid!"

Kuidas kasutada?

Selle funktsiooni täielik rakendamine ilmus väljaandes werf v1.0.3-beeta.1. Üldpõhimõte on lihtne: kasutaja määrab werfi konfiguratsioonis tee olemasoleva Dockerfile'i juurde ja käivitab seejärel käsu werf build... ja ongi kõik – werf paneb pildi kokku. Vaatame abstraktset näidet.

Anname teada järgmise Dockerfile projekti juures:

FROM ubuntu:18.04
RUN echo Building ...

Ja me kuulutame välja werf.yamlmis seda kasutab Dockerfile:

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

Kõik! Vasakule jooksma werf build:

Lisaks saate deklareerida järgmist werf.yaml mitme kujutise loomiseks erinevatest Docker-failidest korraga:

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

Lõpuks toetab see ka täiendavate ehitusparameetrite edastamist, näiteks --build-arg и --add-host - werfi konfiguratsiooni kaudu. Dockerfile'i pildi konfiguratsiooni täielik kirjeldus on saadaval aadressil dokumentatsiooni leht.

Kuidas see toimib?

Ehitamise ajal töötab Dockeri kohalike kihtide standardne vahemälu. Tähtis on aga ka see werf integreerib Dockerfile'i konfiguratsiooni oma infrastruktuuri. Mida see tähendab?

1. Iga Dockerfile'ist ehitatud pilt koosneb ühest etapist, mida nimetatakse dockerfile (Lisateavet selle kohta, millised etapid on werfis, saate lugeda siin).
2. Lava jaoks dockerfile werf arvutab allkirja, mis sõltub Dockerfile'i konfiguratsiooni sisust. Kui Dockerfile'i konfiguratsioon muutub, muutub etapi signatuur dockerfile ja werf algatab selle etapi ümberehitamise uue Dockerfile'i konfiguratsiooniga. Kui signatuur ei muutu, võtab werf pildi vahemälust (täpsemat teavet allkirjade kasutamise kohta werfis kirjeldati artiklis see aruanne).
3. Järgmisena saab kogutud pilte käsuga avaldada werf publish (Või werf build-and-publish) ja kasutage seda Kuberneteses juurutamiseks. Dockeri registrisse avaldatud kujutised puhastatakse tavaliste werfi puhastusvahendite abil, st. Vanad pildid (vanemad kui N päeva), olematute Giti filiaalidega seotud pildid ja muud eeskirjad puhastatakse automaatselt.

Lisateavet siin kirjeldatud punktide kohta leiate dokumentatsioonist:

• Avaldamise protsess;
• Integratsioon Kubernetese juurutusprotsessiga;
• Puhastusprotsess.

Märkused ja ettevaatusabinõud

1. ADD ei toeta välist URL-i

Praegu ei toetata välise URL-i kasutamist direktiivis ADD. Werf ei algata uuesti ülesehitust, kui määratud URL-i ressurss muutub. Plaanime selle funktsiooni peagi lisada.

2. Te ei saa pildile lisada .git

Üldiselt kataloogi lisamine .git pildil – tige halb tava ja siin on põhjus:

1. kui .git jääb lõplikule pildile, see rikub põhimõtteid 12 teguri rakendus: Kuna lõplik pilt peab olema lingitud ühe sissekandmisega, ei tohiks seda teha git checkout meelevaldne toime.
2. .git suurendab pildi suurust (hoidla võib olla suur, kuna sellele lisati kunagi suured failid ja seejärel kustutati). Ainult konkreetse kohustusega seotud tööpuu suurus ei sõltu Giti toimingute ajaloost. Sel juhul lisamine ja hilisem eemaldamine .git lõplikust pildist ei tööta: pilt omandab ikkagi lisakihi – nii töötab Docker.
3. Docker võib algatada mittevajaliku ümberehituse, isegi kui ehitatakse sama commit, kuid erinevatest tööpuudest. Näiteks GitLab loob eraldi kloonitud kataloogid /home/gitlab-runner/builds/HASH/[0-N]/yourproject kui paralleelne kokkupanek on lubatud. Täiendav kokkupanek on tingitud asjaolust, et kataloog .git on sama hoidla erinevates kloonitud versioonides erinev, isegi kui on ehitatud sama tagatis.

Viimasel punktil on tagajärjed ka werfi kasutamisel. Werf nõuab sisseehitatud vahemälu olemasolu teatud käskude (nt. werf deploy). Nende käskude käitamisel arvutab werf välja etapisignatuurid punktis määratud piltidele werf.yaml, ja need peavad olema koostevahemälus – vastasel juhul ei saa käsk tööd jätkata. Kui lavasignatuur oleneb sisust .git, siis saame vahemälu, mis on ebastabiilne ebaoluliste failide muudatuste suhtes ja werf ei saa sellist möödalaskmist andestada (lisateavet vt dokumentatsioon).

Üldiselt lisades ainult teatud vajalikud failid juhiste kaudu ADD igal juhul suurendab kirjaliku efektiivsust ja usaldusväärsust Dockerfileja parandab ka selleks kogutud vahemälu stabiilsust Dockerfile, Giti ebaolulistele muudatustele.

Summaarne

Meie esialgne tee konkreetsete vajaduste jaoks oma koostaja kirjutamiseks oli raske, aus ja sirgjooneline: standardse Dockerfile'i peal karkude kasutamise asemel kirjutasime oma lahenduse kohandatud süntaksiga. Ja sellel olid oma eelised: Stapeli kollektor saab oma ülesandega suurepäraselt hakkama.

Ent oma ehitaja kirjutamise käigus kaotasime silmist olemasolevate Dockerfileside toe. See viga on nüüd parandatud ja tulevikus plaanime koos meie kohandatud Stapeli ehitajaga välja töötada Dockerfile'i toe hajutatud kokkupanemiseks ja Kubernetese abil kokkupanemiseks (st Kubernetese sees olevatele jooksikutele kokkupanemiseks, nagu seda tehakse kanikol).

Niisiis, kui teil on äkki paar Dockeri faili lebamas... proovige seda werf!

PS Teemakohaste dokumentide loetelu

• Juhendid kiireks alustamiseks;
• dockerfile'i koostaja konfiguratsioonid;
• Lavaseade werfis;
• Piltide avaldamise protsess;
• Integratsioon Kubernetese juurutusprotsessiga;
• Puhastusprotsess;
• Stapeli ehitaja alternatiivina Dockerfile'ile.

Loe ka meie blogist: “werf - meie tööriist CI / CD jaoks Kubernetesis (ülevaade ja videoaruanne)'.

Allikas: www.habr.com