🥇Sada možete graditi Docker slike u werf-u koristeći običnu Dockerfile

Bolje ikad nego nikad. Ili kako smo skoro napravili ozbiljnu pogrešku jer nismo imali podršku za obične Dockerfileove za izradu slika aplikacija.

Razgovarat ćemo o werf — GitOps uslužni program koji se integrira s bilo kojim CI/CD sustavom i pruža upravljanje cijelim životnim ciklusom aplikacije, omogućujući:

prikupljati i objavljivati slike,
implementirati aplikacije u Kubernetes,
brisanje neiskorištenih slika pomoću posebnih pravila.

Filozofija projekta je prikupljanje alata niske razine u jedan objedinjeni sustav koji DevOps inženjerima daje kontrolu nad aplikacijama. Ako je moguće, treba koristiti postojeće pomoćne programe (kao što su Helm i Docker). Ako ne postoji rješenje problema, možemo stvoriti i podržati sve što je potrebno za to.

Pozadina: vaš vlastiti sakupljač slika

To se dogodilo s kolektorom slika u werf-u: uobičajeni Dockerfile nije nam bio dovoljan. Ako bacite brz pogled na povijest projekta, ovaj se problem pojavio već u prvim verzijama werfa (tada još poznat kao dapp).

Dok smo stvarali alat za ugradnju aplikacija u Docker slike, brzo smo shvatili da nam Dockerfile nije prikladan za neke vrlo specifične zadatke:

Potreba za izgradnjom tipičnih malih web aplikacija prema sljedećoj standardnoj shemi:
- instalirajte ovisnosti o aplikaciji na razini cijelog sustava,
- instalirati paket biblioteka ovisnosti o aplikaciji,
- prikupiti imovinu,
- i što je najvažnije, brzo i učinkovito ažurirajte kod na slici.
Kada se naprave promjene u projektnim datotekama, graditelj mora brzo stvoriti novi sloj primjenom zakrpe na promijenjene datoteke.
Ako su se određene datoteke promijenile, tada je potrebno ponovno izgraditi odgovarajuću zavisnu fazu.

Danas naš kolekcionar ima mnogo drugih mogućnosti, ali to su bile početne želje i porivi.

Općenito, bez razmišljanja smo se naoružali programskim jezikom koji smo koristili (Pogledaj ispod) i krenuti na put implementacije vlastiti DSL! U skladu s ciljevima, namjeravalo se opisati proces montaže u fazama i odrediti ovisnosti tih faza o datotekama. I nadopunio ga vlastiti kolekcionar, koji je DSL pretvorio u konačni cilj - montiranu sliku. U početku je DSL bio u Rubyju, ali kao prijelaz u Golang — konfiguracija našeg kolektora počela je biti opisana u YAML datoteci.

Stara konfiguracija za dapp u Rubyju

Trenutna konfiguracija za werf na YAML-u

S vremenom se mijenjao i mehanizam kolektora. Isprva smo jednostavno generirali privremeni Dockerfile u hodu iz naše konfiguracije, a zatim smo počeli pokretati upute za sklapanje u privremenim spremnicima i predavati.

NB: Trenutačno se naš sakupljač, koji radi s vlastitom konfiguracijom (u YAML-u) i zove se Stapel collector, već razvio u prilično moćan alat. Njegov detaljan opis zaslužuje zasebne članke, a osnovne detalje možete pronaći u dokumentacija.

Svijest o problemu

Ali shvatili smo, i to ne odmah, da smo napravili jednu pogrešku: nismo dodali sposobnost izradite slike putem standardne Dockerfile datoteke te ih integrirati u istu infrastrukturu za upravljanje aplikacijama od kraja do kraja (tj. prikupiti slike, implementirati ih i očistiti). Kako je moguće napraviti alat za implementaciju u Kubernetesu, a ne implementirati Dockerfile podršku, tj. standardni način za opisivanje slika za većinu projekata?..

Umjesto odgovora na ovo pitanje nudimo rješenje. Što ako već imate Dockerfile (ili skup Dockerfileova) i želite koristiti werf?

NB: Usput, zašto biste uopće htjeli koristiti werf? Glavne značajke svode se na sljedeće:

puni ciklus upravljanja aplikacijama uključujući čišćenje slike;
mogućnost upravljanja sastavljanjem nekoliko slika odjednom iz jedne konfiguracije;
Poboljšan proces implementacije za karte kompatibilne s Helmom.

Njihov potpuniji popis možete pronaći na stranica projekta.

Dakle, ako bismo ranije ponudili da prepišemo Dockerfile u našu konfiguraciju, sada ćemo radosno reći: "Neka werf izgradi vaše Dockerfileove!"

Kako koristiti?

Potpuna implementacija ove značajke pojavila se u izdanju werf v1.0.3-beta.1. Općenito načelo je jednostavno: korisnik navodi stazu do postojeće datoteke Docker u werf konfiguraciji, a zatim pokreće naredbu werf build... i to je to - werf će složiti sliku. Pogledajmo apstraktni primjer.

Najavimo sljedeći Dockerfile u korijenu projekta:

FROM ubuntu:18.04
RUN echo Building ...

I objavit ćemo werf.yamlkoja ovo koristi Dockerfile:

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

Svi! Lijevo trčanje werf build:

Osim toga, možete izjaviti sljedeće werf.yaml za izradu nekoliko slika iz različitih Docker datoteka odjednom:

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

Konačno, također podržava prosljeđivanje dodatnih parametara izgradnje, kao što je --build-arg и --add-host - putem werf konfiguracije. Potpuni opis konfiguracije Dockerfile slike dostupan je na stranica dokumentacije.

Kako se to radi?

Tijekom procesa izgradnje, standardna predmemorija lokalnih slojeva u Dockeru funkcionira. Međutim, ono što je važno je i taj werf integrira Dockerfile konfiguraciju u svoju infrastrukturu. Što to znači?

Svaka slika izgrađena iz Dockerfilea sastoji se od jedne faze koja se zove dockerfile (možete pročitati više o tome koje su faze u werf здесь).
Za pozornicu dockerfile werf izračunava potpis koji ovisi o sadržaju konfiguracije Dockerfile. Kada se promijeni konfiguracija Dockerfilea, mijenja se potpis faze dockerfile i werf pokreće ponovnu izgradnju ove faze s novom konfiguracijom Dockerfilea. Ako se potpis ne promijeni, tada werf preuzima sliku iz predmemorije (više detalja o korištenju potpisa u werf-u opisano je u ovo izvješće).
Zatim se prikupljene slike mogu objaviti naredbom werf publish (Ili werf build-and-publish) i upotrijebite ga za implementaciju u Kubernetes. Objavljene slike u Docker registru bit će očišćene pomoću standardnih werf alata za čišćenje, tj. Stare slike (starije od N dana), slike povezane s nepostojećim Git granama i druga pravila bit će automatski očišćena.

Više detalja o ovdje opisanim točkama možete pronaći u dokumentaciji:

Napomene i mjere opreza

1. Vanjski URL nije podržan u ADD-u

Trenutačno nije podržano korištenje vanjskog URL-a u direktivi ADD. Werf neće pokrenuti ponovnu izgradnju kada se promijeni resurs na navedenom URL-u. Planiramo uskoro dodati ovu značajku.

2. Ne možete dodati .git na sliku

Općenito govoreći, dodavanje imenika .git na slici - opaka loša praksa i evo zašto:

Ako .git ostaje na konačnoj slici, time se krše načela 12 faktor app: Budući da konačna slika mora biti povezana s jednom predajom, to ne bi trebalo biti moguće učiniti git checkout proizvoljno počiniti.
.git povećava veličinu slike (repozitorij može biti velik zbog činjenice da su velike datoteke jednom dodane u njega, a zatim izbrisane). Veličina radnog stabla povezanog samo s određenom predajom neće ovisiti o povijesti operacija u Gitu. U ovom slučaju, dodavanje i naknadno uklanjanje .git od konačne slike neće raditi: slika će i dalje dobiti dodatni sloj - ovako radi Docker.
Docker može pokrenuti nepotrebnu ponovnu izgradnju, čak i ako se gradi isto predanje, ali iz različitih radnih stabala. Na primjer, GitLab stvara zasebne klonirane direktorije u /home/gitlab-runner/builds/HASH/[0-N]/yourproject kada je omogućena paralelna montaža. Dodatno ponovno sastavljanje bit će zbog činjenice da imenik .git je različit u različitim kloniranim verzijama istog spremišta, čak i ako je izgrađeno isto predanje.

Posljednja točka također ima posljedice kada koristite werf. Werf zahtijeva prisutnost ugrađene predmemorije prilikom izvođenja nekih naredbi (npr. werf deploy). Kada se ove naredbe pokrenu, werf izračunava potpise pozornice za slike navedene u werf.yaml, i oni moraju biti u predmemoriji sklopa - inače naredba neće moći nastaviti s radom. Ako scenski potpis ovisi o sadržaju .git, tada dobivamo predmemoriju koja je nestabilna na promjene u nebitnim datotekama, a werf neće moći oprostiti takav propust (za više detalja, pogledajte dokumentacija).

U cjelini, dodavanje samo određenih potrebnih datoteka kroz upute ADD u svakom slučaju povećava učinkovitost i pouzdanost napisanog Dockerfile, a također poboljšava stabilnost predmemorije prikupljene za to Dockerfile, do nebitnih promjena u Gitu.

Ukupan

Naš početni put do pisanja vlastitog graditelja za specifične potrebe bio je težak, pošten i jednostavan: umjesto korištenja štaka povrh standardne Dockerfile datoteke, svoje smo rješenje napisali s prilagođenom sintaksom. I to je imalo svoje prednosti: kolektor Stapel savršeno se nosi sa svojim zadatkom.

Međutim, u procesu pisanja našeg vlastitog graditelja, izgubili smo iz vida podršku za postojeće Dockerfiles. Ta je greška sada popravljena, au budućnosti planiramo razviti podršku za Dockerfile zajedno s našim prilagođenim Stapel builderom za distribuiranu montažu i za montažu pomoću Kubernetesa (tj. montaža na trkačima unutar Kubernetesa, kao što se radi u kaniku).

Dakle, ako odjednom imate nekoliko Dockerfileova... probati werf!

PS Popis dokumentacije o temi

Pročitajte i na našem blogu: “werf - naš alat za CI/CD u Kubernetesu (pregled i video izvješće)".

Izvor: www.habr.com

Sada možete graditi Docker slike u werf-u koristeći običnu Docker datoteku