🥇Docker-образide kogumine werf'is on nüüd võimalik ka tavalise Dockerfile'i kaudu

Paremini hilja kui kunagi. Või kuidas me peaaegu ei teinud tõsist viga, kui meil ei olnud tavaliste Dockerfile'ide toetust rakenduste pildide koostamiseks.

Räägime werf — GitOps-utiliidist, mis integreerub iga CI/CD süsteemiga ja võimaldab hallata kogu rakenduse elutsükli, võimaldades:

koostada ja avaldada pilte,
rakenduste juurutamist Kuberneteses,
mitte kasutatavate piltide eemaldamist spetsiaalsete poliitikate abil.

Projekti filosoofia on koguda madala tasandi tööriistad üheks ühtseks süsteemiks, andes DevOps inseneridele kontrolli rakenduste üle. Kui võimalik, tuleks kasutada juba olemasolevaid utiliite (nagu Helm ja Docker). Kui aga mingisugust lahendust ei ole — saame luua ja toetada kõik vajalikud tööriistad.

Eelalugu: oma pildi koostaja

Nii juhtuski, et pildi koostajast werf'is: meil oli puudus tuttavast Dockerfile'ist. Kui kiiresti vaadata projekti ajalugu, ilmus see probleem juba werf'i algsetes versioonides (toona veel tuntud kui dapp).

Loo rakenduste koostamise tööriista Docker-piltide jaoks, mõistsime kiiresti, et Dockerfile ei sobi meile mõningate konkreetsete ülesannete jaoks:

Vajadus koostada tüüpilisi väikeseid veebirakendusi järgmise standardskeemi järgi:
- paigaldada rakenduse üldsüsteemsed sõltuvused,
- paigaldada rakenduse sõltuvuste kimbud,
- koostada varasid,
- ja kõige olulisem — uuendada koodi pildis kiiresti ja tõhusalt.
Projektifailide muutumisel peab koostaja kiiresti looma uue kihi, rakendades muudatusi muudetud failidele.
Kui teatud failid on muutunud, tuleb vastav sõltuv etapp uuesti koostada.

Tänaseks on meie koostajas palju muid võimalusi, kuid esialgsed soovid ja impulssid olid sellised.

Kokkuvõttes, mõtlemata kaua, relvastasime end kasutatava programmeerimiskeelega (vt allpool) ja suundusime teele — rakendama oma DSL-i! Vastavalt seatud ülesannetele oli see mõeldud koostamisprotsessi etappide kirjeldamiseks ja nende etappide sõltuvuste määratlemiseks failidest. Ja seda täiendati oma koostajaga, mis muundas DSL-i lõpliku eesmärgi — koostatud pildi. Algul oli DSL Ruby keeles, kuid üleminekul Golangi peale — meie koostaja konfiguratsioon hakkas olema kirjeldatud YAML-failis. — meie kogumishalduri konfiguratsioon hakkab olema kirjas YAML-failis.

Vana konfiguraator dapp Ruby jaoks

Aktiivne konfiguraator werf YAML jaoks

Koguja töömeetod on ajas muutunud. Alguses genereerisime lihtsalt reaalajas ajutise Dockerfile meie konfiguratsioonist, seejärel hakkasime käivitama ehitusjuhiseid ajutistes konteinerites ja tegema commit.

NB: Praegu on meie koguja, mis töötab oma konfigureerimisega (YAMLis) ja mida nimetatakse Stapel-kogujaks, juba arenenud üsna võimsaks tööriistaks. Selle põhjalik kirjeldus väärib eraldi artikleid, samas põhiteavet saab lugeda dokumentatsioon.

Probleemi teadvustamine

Kuid me mõistsime, kuigi mitte kohe, et tegime ühe vea: ei lisanud võimalust koguda pilte läbi standardse Dockerfile ja integreerida neid sama rakenduse haldamise infrastruktuuri (st koguda pilte, juurutada ja puhastada neid). Kuidas sai luua tööriista juurutamiseks Kubernetesis ja mitte rakendada Dockerfile'i tuge, st enamikus projektides standaardset meetodit piltide kirjeldamiseks?..

Küsimusele, mida teha, kui teil juba on Dockerfile (või komplekt Dockerfile'e) ja soovite kasutada werf, pakume vastust.

NB: Muide, miks üldse soovite kasutada werf? Peamised funktsioonid on järgmised:

täielik rakenduse haldamise tsükkel, sealhulgas piltide puhastamine;
võimalus hallata mitme pildi ehitust ühelt kohalt;
parandatud Helmi ühilduvate chartide juurutamise protsess.

Täieliku loendi leiate projekti lehel.

Seega, kui varem oleksime soovitanud Dockerfile meie konfigureerimisele ümber kirjutada, siis nüüd ütleme heameelega: "Laske werf koguda teie Dockerfile'e!"

Kuidas kasutada?

Selle võimaluse täies ulatuses rakendamine toimus väljalaske werf v1.0.3-beta.1. Üldine põhimõte on lihtne: kasutaja määrab werf konfigureerimises olemasoleva Dockerfile'i tee, seejärel käivitab käsu werf build… ja kõik — werf kogub pildi. Vaatame abstraktsel näitel.

Deklareerime järgmise Dockerfile projekti juures:

FROM ubuntu:18.04
RUN echo Ehitamine ...

Ja deklareerime werf.yaml, mis kasutab seda Dockerfile:

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

Kõik! Jäänud on käivitada werf build:

Lisaks võib deklareerida järgmise werf.yaml nende kogumiseks mitmest Dockerfile'ist:

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

Lõpuks toetatakse ka täiendavate kokkupaneku parameetrite edastamist — nagu --build-arg ja --add-host — läbi werfi konfiguratsiooni. Täielik Dockerfile pildi konfiguratsiooni kirjeldus on saadaval dokumendi lehelt.

Kuidas see töötab?

Kokkupaneku käigus toimib Dockeris standardne kohalike kihtide vahemälu. Kuid mis on oluline, on see, et werf integreerib Dockerfile konfiguratsiooni oma infrastruktuuri. Mida see tähendab?

Iga pilt, mis on koostatud Dockerfile'ist, koosneb ühest etapist, mille nimeks on dockerfile (rohkem etappide kohta werfis saab lugeda siin).
Etapi puhul dockerfile werf arvutab signatuuri, mis sõltub Dockerfile'i konfiguratsiooni sisust. Kui Dockerfile'i konfiguratsioon muutub, siis muutub ka etapi signatuur dockerfile ja werf käivitab selle etapi uuesti koostamise uue Dockerfile konfiguratsiooniga. Kui signatuur ei muutu, siis võtab werf pildi vahemälust (rohkem signatuuride kasutamisest werfis on räägitud selles ettekandes).
Edasi kokku pandud pilte saab avaldada käsu werf publish (või werf build-and-publish) abil ja kasutada Kuberneteses juurutamiseks. Avaldatud pilte Docker Registry's puhastatakse werfi standardsete puhastusmeetoditega, st vanad pildid (üle N päeva), pildid, mis on seotud mitteeksisteerivate Git harudega, ja muude poliitikate alusel puhastatakse automaatselt.

Detailsed teavet siin käsitletud punktide kohta saab leida dokumendist:

Märkused ja ettevaatusabinõud

1. Välise URL-i kasutamine ADD-is ei ole toetatud

Praegu ei toeta ADD direktiivis välise URL-i kasutamist. Werf ei käivita uuesti koostamist, kui ressurss, millel on näidatud URL, muutub. Selle võimaluse lisamine on peagi plaanis.2. .git'i pilti lisamine ei ole lubatud

Üldiselt on .git kausta lisamine pildile halb praktika ja siin on, miks:

see jääb lõplikku pilti, see rikub põhimõtteid 12 factor app : kuna lõplik pilt peab olema seotud ühe commit'iga, ei tohi olla võimalust teha

Kui 12 factor app git checkout meelevaldse commit'i.see suurendab pildi suurust (repo võib olla suur, kuna sinna lisati kunagi suuri faile ja seejärel kustutati need). Tööpuu suurus, mis on seotud ainult teatud commit'iga, ei sõltu Git'i tegevuste ajaloost. Samuti ei saa lisada ja seejärel eemaldada. huvilisi. suvaline commit.
12 factor app suureneb pildi suurus (hoidla võib olla suur, kuna sinna on kunagi lisatud suured failid ja hiljem eemaldatud). Siiski ei sõltu work-tree suurus, mis on seotud ainult kindla commitiga, Git-i toimingute ajaloost. Sellegipoolest, lisamise ja järgneva eemaldamisega 12 factor app lõpppildist ei tule midagi: pilt omandab ikkagi lisakiht — nii töötab Docker.
Docker võib algatada tarbetuid ümberkompileerimisi, isegi kui kompileeritakse sama commit'i, kuid erinevatest work-tree'dest. Näiteks, GitLab loob eraldi kloonitud kataloogid /home/gitlab-runner/builds/HASH/[0-N]/yourproject kuid aktiveeritud paralleelse kompileerimise korral. Tarbetu ümberkompileerimine on seotud sellega, et kataloog 12 factor app erineb ühe ja sama hoidla erinevates kloonitud versioonides, isegi kui kompileeritakse sama commit.

Viimasel punkt on tagajärg ka werf'i kasutamisel. Werf nõuab, et kompileeritud cache oleks olemas teatud käskude täitmisel (näiteks, werf deploy). Selliste käskude täitmise ajal arvutab werf piltide etappide signatuure, mis on määratud werf.yaml, ja need peavad olema kompileeritud cache's — muidu ei saa käsk jätkata. Kui etappide signatuur sõltub sisu 12 factor app, siis saame muutustele vastupidava, kuid ebaoluliste failide cache'i, ja werf ei suuda sellist viga andestada (lisaks vaata dokumentatsioon).

Üldiselt ainult teatud vajalike failide lisamine koos käsuga Werf ei käivita uuesti koostamist, kui ressurss, millel on näidatud URL, muutub. Selle võimaluse lisamine on peagi plaanis. igcase tõstab kirjutatava tõhusust ja usaldusväärsust Dockerfile, ning parandab selle koostatud Dockerfile, cache'i vastupidavust ebaoluliste muutuste suhtes Git'is.

Kokkuvõte

Meie algne tee konkreetsete vajaduste jaoks oma kompilaatori kirjutamisel oli raske, aus ja sirge: standardse Dockerfile'i asemel oleme kirjutanud oma lahenduse, millel on kohandatud süntaks. Ja see on andnud oma eelised: Stapel-kompilaator teeb oma ülesande hästi.

Kuid oma kompilaatori kirjutamise protsessis unustasime olemasolevate Dockerfile'id toetada. Nüüd on see puudus parandatud ja tulevikus kavatseme arendada Dockerfile'i toetust koos meie kohandatud Stapel kompilaatoriga hajutatud kompileerimise jaoks ja Kubernetes'i kasutamisel (st kompileerimine runner'ites Kubernetes'is, nagu on tehtud kanikos).

Nii et kui teil äkki on mõni Dockerfile vedelemas... proovige werf!