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

Bolje ikad nego nikad. Ili kako smo zamalo napravili ozbiljnu grešku jer nismo imali podršku za obične Dockerfiles za pravljenje slika aplikacije.

Biće o tome werf — GitOps uslužni program koji se integrira sa bilo kojim CI/CD sistemom i upravlja cijelim životnim ciklusom aplikacije, omogućavajući vam:

• prikupiti i objaviti slike,
• implementirati aplikacije na Kubernetes,
• izbrišite nekorištene slike pomoću posebnih pravila.

Filozofija projekta je prikupljanje alata niskog nivoa u jedinstveni sistem koji DevOps inženjerima daje kontrolu nad aplikacijama. Ako je moguće, treba koristiti postojeće uslužne programe (kao što su Helm i Docker). Ako nema rješenja za problem, možemo kreirati i podržati sve što je potrebno za to.

Pozadina: vaš vlastiti kolekcionar slika

Ovo se dogodilo sa programom za izgradnju slika u werfu: nedostajao nam je uobičajeni Dockerfile. Ako nakratko zaronite u povijest projekta, onda se ovaj problem očitovao već u prvim verzijama werfa (tada poznat kao dapp).

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

1. Potreba za sastavljanjem tipičnih malih web aplikacija prema sljedećoj standardnoj shemi:
   • instalirati sistemske zavisnosti aplikacije,
   • instalirajte skup biblioteka ovisnosti aplikacije,
   • prikupiti imovinu,
   • i što je najvažnije, ažurirajte kod na slici brzo i efikasno.
2. Kada se izvrše promjene u projektnim datotekama, graditelj mora brzo kreirati novi sloj tako što će zakrpiti promijenjene datoteke.
3. Ako su se određene datoteke promijenile, tada se odgovarajuća zavisna faza mora ponovo izgraditi.

Danas postoje mnoge druge mogućnosti u našoj slavini, ali početne želje i porivi su bili sljedeći.

Generalno, bez razmišljanja, naoružali smo se programskim jezikom koji smo koristili (vidi dolje) i krenuti na put - implementirati vlastiti DSL! U skladu sa postavljenim zadacima, trebalo je opisati proces izgradnje po fazama i odrediti zavisnosti ovih faza od fajlova. I dopunio ga vlastita slavina, koji je DSL pretvorio u konačni cilj - sastavljenu sliku. Isprva je DSL bio u Rubyju, ali kao prelazak na Golang - konfiguracija našeg kolektora je počela da se opisuje u YAML datoteci.

Stara konfiguracija za dapp u Rubyju

Stvarna konfiguracija za werf na YAML-u

Vremenom se mijenjao i mehanizam kolektora. U početku smo jednostavno generirali neki privremeni Dockerfile iz naše konfiguracije u hodu, a zatim smo počeli izvoditi upute za izgradnju u privremenim kontejnerima i praviti urezivanje.

NB: Trenutno se naš builder, koji radi sa vlastitom konfiguracijom (u YAML) i zove se Stapel builder, već razvio u prilično moćan alat. Njegov detaljan opis zaslužuje posebne članke, a glavni detalji se mogu naći u dokumentaciju.

Svest o problemu

Ali shvatili smo, i to ne odmah, da smo napravili jednu grešku: nismo dodali sposobnost izgraditi slike kroz standardni Dockerfile i integrirati ih u istu infrastrukturu za upravljanje aplikacijama od kraja do kraja (tj. prikupljanje slika, postavljanje i čišćenje). Kako možete napraviti alat za implementaciju u Kubernetesu, a ne implementirati podršku za Dockerfile, tj. standardni način opisivanja slika za većinu projekata?..

Umjesto odgovora na takvo pitanje, mi nudimo njegovo rješenje. Šta ako već imate Dockerfile (ili skup Dockerfile) i želite koristiti werf?

NB: Uzgred, zašto biste uopće htjeli koristiti werf? Glavne karakteristike se svode na sljedeće:

• puni ciklus upravljanja aplikacijom uključujući čišćenje slika;
• mogućnost upravljanja sastavljanjem nekoliko slika odjednom iz jedne konfiguracije;
• poboljšan proces implementacije za Helm kompatibilne karte.

Potpuniju listu možete pronaći na stranica projekta.

Dakle, ako smo ranije predlagali prepisivanje Dockerfile-a u našu konfiguraciju, sada sa zadovoljstvom možemo reći: “Neka werf napravi vaše Dockerfile!”

Kako koristiti?

Potpuna implementacija ove funkcije pojavila se u izdanju werf v1.0.3-beta.1. Opšti princip je jednostavan: korisnik specificira putanju do postojeće Dockerfile u werf konfiguraciji, a zatim pokreće naredbu werf build... i to je to - werf će izgraditi sliku. Razmotrimo jedan apstraktan primjer.

Najavimo sljedeće Dockerfile u osnovi projekta:

FROM ubuntu:18.04
RUN echo Building ...

I mi ćemo objaviti werf.yamlkoji ovo koristi Dockerfile:

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

Sve! lijevo trči werf build:

Osim toga, možete deklarirati sljedeće werf.yaml da napravite nekoliko slika odjednom iz različitih Docker fajlova:

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

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

Как это работает?

Tokom procesa izgradnje, standardna keš memorija lokalnih slojeva u Dockeru funkcionira. Međutim, što je važno, werf također integrira Dockerfile konfiguraciju u svoju infrastrukturu. Šta to znači?

1. Svaka slika napravljena od Dockerfile-a sastoji se od jedne faze tzv dockerfile (više o tome koje su faze u werfu možete pročitati ovdje).
2. Za pozornicu dockerfile werf izračunava potpis koji zavisi od sadržaja Dockerfile konfiguracije. Promjenom konfiguracije Dockerfile-a mijenja se potpis pozornice dockerfile i werf će pokrenuti ponovnu izgradnju te faze sa novom konfiguracijom Dockerfile-a. Ako se potpis ne promijeni, werf preuzima sliku iz keša (više o upotrebi potpisa u werf-u je opisano u ovaj izvještaj).
3. Nadalje, prikupljene slike se mogu objaviti pomoću naredbe werf publish (ili werf build-and-publish) i koristite ga za implementaciju u Kubernetes. Objavljene slike u Docker Registry će biti očišćene standardnim werf alatima za čišćenje, tj. doći će do automatskog čišćenja starih slika (starijih od N dana), slika povezanih s nepostojećim Git granama i drugih pravila.

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

• Proces objavljivanja;
• Integracija sa procesom implementacije u Kubernetesu;
• Proces čišćenja.

Napomene i mjere opreza

1. Vanjski URL u ADD nije podržan

Upotreba vanjskog URL-a u direktivi trenutno nije podržana. ADD. Werf neće pokrenuti ponovnu izgradnju kada se promijeni resurs na navedenom URL-u. Planirano je da se ova funkcija uskoro doda.

2. Ne možete dodati .git na sliku

Uopšteno govoreći, dodavanje imenika .git pretvaranje slike je opaka loša praksa, a evo zašto:

1. ako .git ostaje u konačnoj slici, ovo krši principe 12 faktor app: budući da rezultirajuća slika mora biti povezana s jednim urezivanjem, to ne bi trebalo biti moguće učiniti git checkout proizvoljno urezivanje.
2. .git povećava veličinu slike (spremište može biti veliko zbog činjenice da su velike datoteke jednom dodane u njega, a zatim izbrisane). Veličina radnog stabla povezanog samo sa određenim urezivanjem neće zavisiti od istorije 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.
3. Docker može pokrenuti nepotrebnu rekonstrukciju čak i ako se isto urezivanje gradi iz različitih stabala rada. Na primjer, GitLab kreira zasebne klonirane direktorije u /home/gitlab-runner/builds/HASH/[0-N]/yourproject sa omogućenom paralelnom montažom. Dodatna rekonstrukcija će biti zbog činjenice da je imenik .git različito u različitim kloniranim verzijama istog spremišta, čak i ako je izgrađeno isto urezivanje.

Poslednja tačka takođe ima posledice kada se koristi werf. Werf zahtijeva da ugrađeni keš bude prisutan prilikom pokretanja nekih naredbi (na primjer, werf deploy). Tokom izvršavanja takvih naredbi, werf izračunava potpise faze za slike navedene u werf.yaml, i moraju biti u kešu izgradnje, inače naredba neće moći da se nastavi. Ako potpis faza zavisi od sadržaja .git, tada dobijamo keš memoriju koja je nestabilna na promjene u nebitnim datotekama, a werf neće moći oprostiti takav previd (za više detalja pogledajte dokumentaciju).

Uopšte dodavanje samo određenih potrebnih fajlova kroz uputstva ADD u svakom slučaju povećava efikasnost i pouzdanost napisanog Dockerfile, a također poboljšava stabilnost keš memorije prikupljene ovim Dockerfile, na irelevantne promjene u Gitu.

Rezultat

Naš početni put s pisanjem vlastitog graditelja za specifične potrebe bio je težak, iskren i jasan: umjesto da koristimo štake na vrhu standardnog Dockerfile-a, napisali smo vlastito rješenje s prilagođenom sintaksom. I to je dalo svoje prednosti: Stapel-kolektor savršeno radi svoj posao.

Međutim, u procesu pisanja našeg vlastitog buildera, izgubili smo iz vida podršku za već postojeće Dockerfiles. Sada je ovaj nedostatak popravljen, a u budućnosti planiramo da razvijemo podršku za Dockerfile zajedno sa našim prilagođenim Stapel graditeljem za distribuirane gradnje i za izgradnju koristeći Kubernetes (tj. izgradnju na trkačima unutar Kubernetesa, kao što se radi u kaniku).

Dakle, ako odjednom imate nekoliko Docker fajlova koji leže okolo... probaj werf!

PS Spisak dokumentacije na temu

• Vodiči za brzi početak;
• konfiguracije dockerfile buildera;
• faze uređaj u werf;
• Proces objavljivanja slika;
• Integracija sa procesom implementacije u Kubernetesu;
• Proces čišćenja;
• Stapel builder kao alternativa Dockerfileu.

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

izvor: www.habr.com