ProHoster > Blogs > Administrācija > Tagad varat izveidot Docker attēlus werf, izmantojot parasto Dockerfile

Tagad varat izveidot Docker attēlus werf, izmantojot parasto Dockerfile

Labāk vēlāk nekā nekad. Vai arī to, kā mēs gandrīz pieļāvām nopietnu kļūdu, neatbalstot parastos Dockerfiles, lai izveidotu lietojumprogrammu attēlus.

Tagad varat izveidot Docker attēlus werf, izmantojot parasto Dockerfile

Mēs runāsim par werf ā€” GitOps utilÄ«ta, kas integrējas ar jebkuru CI/CD sistēmu un nodroÅ”ina visa lietojumprogrammas dzÄ«ves cikla pārvaldÄ«bu, ļaujot:

  • vākt un publicēt attēlus,
  • izvietot lietojumprogrammas Kubernetes,
  • izdzēsiet neizmantotos attēlus, izmantojot Ä«paÅ”as politikas.


Projekta filozofija ir apkopot zema lÄ«meņa rÄ«kus vienā vienotā sistēmā, kas DevOps inženieriem ļauj kontrolēt lietojumprogrammas. Ja iespējams, jāizmanto esoŔās utilÄ«tas (piemēram, Helm un Docker). Ja problēmai nav risinājuma, varam izveidot un atbalstÄ«t visu nepiecieÅ”amo.

Fons: jūsu attēlu kolekcionārs

Tā notika ar attēlu savācēju werf: ar parasto Dockerfile mums nepietika. Ja paskatās ātri projekta vēsturē, Ŕī problēma parādÄ«jās jau pirmajās werf versijās (tad vēl pazÄ«stams kā dapp).

Veidojot rÄ«ku lietojumprogrammu veidoÅ”anai Docker attēlos, mēs ātri sapratām, ka Dockerfile mums nav piemērots dažiem ļoti specifiskiem uzdevumiem:

  1. NepiecieÅ”amÄ«ba veidot tipiskas mazas tÄ«mekļa lietojumprogrammas saskaņā ar Ŕādu standarta shēmu:
    • instalēt visas sistēmas lietojumprogrammu atkarÄ«bas,
    • instalēt lietojumprogrammu atkarÄ«bas bibliotēku komplektu,
    • savākt aktÄ«vus,
    • un pats galvenais, ātri un efektÄ«vi atjauniniet attēlā redzamo kodu.
  2. Kad projekta failos tiek veiktas izmaiņas, veidotājam ātri jāizveido jauns slānis, mainotajiem failiem uzliekot ielāpu.
  3. Ja daži faili ir mainījuŔies, ir nepiecieŔams atjaunot atbilstoŔo atkarīgo posmu.

Mūsdienās mūsu kolekcionāram ir daudz citu iespēju, taču tās bija sākotnējās vēlmes un pamudinājumi.

Kopumā, divreiz nedomājot, mēs bruņojāmies ar izmantoto programmÄ“Å”anas valodu (SkatÄ«t zemāk) un dodieties uz Ä«stenoÅ”anas ceļu savs DSL! AtbilstoÅ”i mērÄ·iem bija paredzēts aprakstÄ«t montāžas procesu pa posmiem un noteikt Å”o posmu atkarÄ«bas no failiem. Un to papildināja savs kolekcionārs, kas DSL pārvērta par gala mērÄ·i ā€“ samontētu attēlu. Sākumā DSL bija Ruby, bet kā pāreja uz Golangu ā€” YAML failā sāka aprakstÄ«t mÅ«su kolekcionāra konfigurāciju.

Tagad varat izveidot Docker attēlus werf, izmantojot parasto Dockerfile
Veca dapp konfigurācija Ruby

Tagad varat izveidot Docker attēlus werf, izmantojot parasto Dockerfile
PaÅ”reizējā werf konfigurācija vietnē YAML

Laika gaitā mainÄ«jās arÄ« kolektora mehānisms. Sākumā mēs vienkārÅ”i Ä£enerējām pagaidu Dockerfile, izmantojot mÅ«su konfigurāciju, un pēc tam sākām izpildÄ«t montāžas instrukcijas pagaidu konteineros un veikt darbÄ«bu.

NB: Å obrÄ«d mÅ«su kolekcionārs, kas darbojas ar savu konfigurāciju (YAML) un tiek saukts par Stapel kolektoru, jau ir izveidojies par diezgan jaudÄ«gu rÄ«ku. Tās detalizētais apraksts ir pelnÄ«jis atseviŔķus rakstus, un pamata informāciju var atrast dokumentācija.

Problēmas apzināŔanās

Taču mēs sapratām, un ne uzreiz, ka esam pieļāvuÅ”i vienu kļūdu: nepievienojām spēju veidojiet attēlus, izmantojot standarta Dockerfile un integrēt tos tajā paŔā visaptveroÅ”ajā lietojumprogrammu pārvaldÄ«bas infrastruktÅ«rā (t.i., apkopot attēlus, izvietot un notÄ«rÄ«t tos). Kā varētu bÅ«t iespējams uztaisÄ«t rÄ«ku izvietoÅ”anai Kubernetes un neieviest Dockerfile atbalstu, t.i. standarta veids, kā aprakstÄ«t attēlus lielākajai daļai projektu?

Tā vietā, lai atbildētu uz Å”o jautājumu, mēs piedāvājam risinājumu. Ko darÄ«t, ja jums jau ir Dockerfile (vai Dockerfiles komplekts) un vēlaties izmantot werf?

NB: Starp citu, kāpēc jÅ«s vispār vēlaties izmantot werf? Galvenās funkcijas ir Ŕādas:

  • pilns lietojumprogrammu pārvaldÄ«bas cikls, ieskaitot attēla tÄ«rÄ«Å”anu;
  • iespēja pārvaldÄ«t vairāku attēlu montāžu vienlaikus no vienas konfigurācijas;
  • Uzlabots ar Helm saderÄ«gu diagrammu izvietoÅ”anas process.

Pilnīgāku to sarakstu var atrast vietnē projekta lapa.

Tātad, ja agrāk mēs bÅ«tu piedāvājuÅ”i pārrakstÄ«t Dockerfile savā konfigurācijā, tagad mēs ar prieku teiksim: ā€œÄ»aujiet werf veidot jÅ«su Dockerfiles!ā€

Kā lietot?

PilnÄ«ga Ŕīs funkcijas ievieÅ”ana parādÄ«jās laidienā werf v1.0.3-beta.1. Vispārējais princips ir vienkārÅ”s: lietotājs norāda ceļu uz esoÅ”u Dockerfile werf konfigurācijā un pēc tam palaiž komandu werf build... un tas arÄ« viss - werf saliks attēlu. ApskatÄ«sim abstraktu piemēru.

Izziņosim nākamo Dockerfile projekta saknē:

FROM ubuntu:18.04
RUN echo Building ...

Un mēs paziņosim werf.yamlkas to izmanto Dockerfile:

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

Visi! Pa kreisi palaist werf build:

Tagad varat izveidot Docker attēlus werf, izmantojot parasto Dockerfile

Turklāt jÅ«s varat deklarēt sekojoÅ”o werf.yaml lai vienlaikus izveidotu vairākus attēlus no dažādiem Docker failiem:

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

Visbeidzot, tas atbalsta arÄ« papildu bÅ«vÄ“Å”anas parametru nodoÅ”anu, piemēram, --build-arg Šø --add-host - izmantojot werf konfigurāciju. Pilns Dockerfile attēla konfigurācijas apraksts ir pieejams vietnē dokumentācijas lapa.

Kā tas strādā?

BÅ«vÄ“Å”anas procesā darbojas Docker vietējo slāņu standarta keÅ”atmiņa. Tomēr svarÄ«gs ir arÄ« werf integrē Dockerfile konfigurāciju savā infrastruktÅ«rā. Ko tas nozÄ«mē?

  1. Katrs attēls, kas izveidots no Dockerfile, sastāv no viena posma, ko sauc dockerfile (vairāk par to, kādi posmi ir werf Å”eit).
  2. Uz skatuves dockerfile werf aprēķina parakstu, kas ir atkarÄ«gs no Dockerfile konfigurācijas satura. Mainoties Dockerfile konfigurācijai, mainās stadijas paraksts dockerfile un werf uzsāk Ŕī posma pārbÅ«vi ar jaunu Dockerfile konfigurāciju. Ja paraksts nemainās, werf paņem attēlu no keÅ”atmiņas (sÄ«kāka informācija par parakstu izmantoÅ”anu werf tika aprakstÄ«ta Å”o ziņojumu).
  3. Tālāk apkopotos attēlus var publicēt ar komandu werf publish (Vai werf build-and-publish) un izmantojiet to izvietoÅ”anai Kubernetes. Docker reÄ£istrā publicētie attēli tiks notÄ«rÄ«ti, izmantojot standarta werf tÄ«rÄ«Å”anas rÄ«kus, t.i. Vecie attēli (vecāki par N dienām), attēli, kas saistÄ«ti ar neesoŔām Git filiālēm, un citas politikas tiks automātiski notÄ«rÄ«tas.

Sīkāka informācija par Ŕeit aprakstītajiem punktiem ir atrodama dokumentācijā:

Piezīmes un piesardzības pasākumi

1. ADD netiek atbalstÄ«ts ārējais URL

PaÅ”laik direktÄ«vā netiek atbalstÄ«ta ārējā URL izmantoÅ”ana ADD. Werf nesāks pārbÅ«vi, kad mainās resurss norādÄ«tajā URL. Mēs plānojam drÄ«zumā pievienot Å”o funkciju.

2. Attēlam nevar pievienot .git

VispārÄ«gi runājot, direktorija pievienoÅ”ana .git attēlā ā€” ļauna prakse, un lÅ«k, kāpēc:

  1. Ja .git paliek galÄ«gajā attēlā, tas pārkāpj principus 12 faktoru lietotne: tā kā galÄ«gajam attēlam ir jābÅ«t saistÄ«tam ar vienu apņemÅ”anos, to nevajadzētu izdarÄ«t git checkout patvaļīga apņemÅ”anās.
  2. .git palielina attēla izmēru (repozitorijs var bÅ«t liels, jo tam kādreiz tika pievienoti lieli faili un pēc tam izdzēsti). Darba koka lielums, kas saistÄ«ts tikai ar konkrētu apņemÅ”anos, nebÅ«s atkarÄ«gs no Git darbÄ«bu vēstures. Å ajā gadÄ«jumā pievienoÅ”ana un turpmāka noņemÅ”ana .git no gala attēla nedarbosies: attēls joprojām iegÅ«s papildu slāni - Ŕādi darbojas Docker.
  3. Docker var uzsākt nevajadzÄ«gu pārbÅ«vi, pat ja tiek veidota viena un tā pati apņemÅ”anās, bet no dažādiem darba kokiem. Piemēram, GitLab izveido atseviŔķus klonētus direktorijus /home/gitlab-runner/builds/HASH/[0-N]/yourproject kad ir iespējota paralēlā montāža. Papildu montāža bÅ«s saistÄ«ta ar to, ka direktorijā .git atŔķiras dažādās vienas un tās paÅ”as krātuves klonētās versijās, pat ja ir izveidota viena un tā pati commit.

Pēdējam punktam ir arÄ« sekas, lietojot werf. Werf pieprasa, lai, izpildot dažas komandas (piem., werf deploy). Kad Ŕīs komandas tiek izpildÄ«tas, werf aprēķina stadijas parakstus attēliem, kas norādÄ«ti werf.yaml, un tiem jābÅ«t montāžas keÅ”atmiņā - pretējā gadÄ«jumā komanda nevarēs turpināt darbu. Ja skatuves paraksts ir atkarÄ«gs no satura .git, tad mēs iegÅ«stam keÅ”atmiņu, kas ir nestabila pret izmaiņām neatbilstoÅ”ajos failos, un werf nevarēs piedot Ŕādu pārkāpumu (sÄ«kāku informāciju sk. dokumentācija).

Kopumā, pievienojot tikai noteiktus nepiecieÅ”amos failus caur instrukcijām ADD jebkurā gadÄ«jumā palielina rakstÄ«tā darba efektivitāti un uzticamÄ«bu Dockerfile, kā arÄ« uzlabo Å”im nolÅ«kam savāktās keÅ”atmiņas stabilitāti Dockerfile, uz nebÅ«tiskām izmaiņām Git.

Kopsavilkums

MÅ«su sākotnējais ceļŔ, lai izveidotu savu veidotāju konkrētām vajadzÄ«bām, bija grÅ«ts, godÄ«gs un vienkārÅ”s: tā vietā, lai izmantotu kruÄ·us papildus standarta Dockerfile, mēs rakstÄ«jām savu risinājumu ar pielāgotu sintaksi. Un tam bija savas priekÅ”rocÄ«bas: Stapel kolektors lieliski tiek galā ar savu uzdevumu.

Tomēr, rakstot savu veidotāju, mēs pazaudējām no redzesloka atbalstu esoÅ”ajiem Dockerfiles. Å is trÅ«kums tagad ir novērsts, un nākotnē mēs plānojam izstrādāt Dockerfile atbalstu kopā ar mÅ«su pielāgoto Stapel veidotāju izplatÄ«tai montāžai un montāžai, izmantojot Kubernetes (t.i., montāžu uz sliedēm Kubernetes iekÅ”pusē, kā tas tiek darÄ«ts kaniko).

Tātad, ja pēkŔņi jums apkārt guļ pāris Dockerfiles... izmēģiniet to werf!

PS Dokumentācijas saraksts par Å”o tēmu

Lasi arÄ« mÅ«su emuārā: ā€œwerf - mÅ«su rÄ«ks CI / CD pakalpojumā Kubernetes (pārskats un video pārskats)'.

Avots: www.habr.com

Pievieno komentāru