Dabar galite kurti Docker vaizdus werf naudodami įprastą Dockerfile

Geriau vėliau negu niekada. Arba kaip mes beveik padarėme rimtą klaidą nepalaikydami įprastų „Dockerfiles“ programų vaizdams kurti.

Pakalbėsime apie werf — „GitOps“ įrankis, kuris integruojamas su bet kuria CI / CD sistema ir užtikrina viso programos gyvavimo ciklo valdymą, leidžiantį:

• rinkti ir skelbti vaizdus,
• diegti programas Kubernetes,
• ištrinkite nenaudojamus vaizdus naudodami specialias taisykles.

Projekto filosofija yra surinkti žemo lygio įrankius į vieną vieningą sistemą, kuri suteikia „DevOps“ inžinieriams galimybę valdyti programas. Jei įmanoma, reikėtų naudoti esamas paslaugas (pvz., Helm ir Docker). Jei problemos sprendimo nėra, galime sukurti ir palaikyti viską, kas tam reikalinga.

Fonas: jūsų vaizdų rinkėjas

Taip atsitiko su vaizdų rinktuvu werf: įprasto Dockerfile mums nepakako. Jei greitai pažvelgsite į projekto istoriją, ši problema atsirado jau pirmosiose werf versijose (tada dar žinomas kaip dapp).

Kurdami įrankį programoms kurti į „Docker“ vaizdus, ​​greitai supratome, kad „Dockerfile“ mums netinka kai kurioms labai specifinėms užduotims atlikti:

1. Poreikis kurti tipiškas mažas žiniatinklio programas pagal šią standartinę schemą:
   • įdiegti visos sistemos taikomųjų programų priklausomybes,
   • įdiegti programų priklausomybės bibliotekų paketą,
   • rinkti turtą,
   • ir, svarbiausia, greitai ir efektyviai atnaujinkite vaizde esantį kodą.
2. Kai atliekami projekto failų pakeitimai, kūrėjas turi greitai sukurti naują sluoksnį, pritaikydamas pakeistų failų pataisą.
3. Jei pasikeitė tam tikri failai, būtina iš naujo sukurti atitinkamą priklausomą etapą.

Šiandien mūsų kolekcininkas turi daug kitų galimybių, tačiau tai buvo pirminiai norai ir potraukiai.

Apskritai, negalvodami, apsiginklavome ta programavimo kalba, kurią naudojome (žr. žemiau) ir imtis įgyvendinti savo DSL! Atsižvelgiant į tikslus, buvo numatyta surinkimo procesą aprašyti etapais ir nustatyti šių etapų priklausomybę nuo bylų. Ir jį papildė nuosavas kolekcininkas, kuris DSL pavertė galutiniu tikslu – surinktu vaizdu. Iš pradžių DSL buvo Ruby, bet kaip perėjimas į Golangą - mūsų kolektoriaus konfigūracija buvo pradėta aprašyti YAML faile.

Sena dapp konfigūracija Ruby

Dabartinė werf konfigūracija YAML

Laikui bėgant keitėsi ir kolektoriaus mechanizmas. Iš pradžių mes tiesiog sugeneravome laikiną „Dockerfile“ iš savo konfigūracijos, o tada pradėjome vykdyti surinkimo instrukcijas laikinuose konteineriuose ir įsipareigoti.

NB: Šiuo metu mūsų kolektorius, kuris veikia su savo konfigūracija (YAML) ir vadinamas Stapel kolekcionieriumi, jau išsivystė į gana galingą įrankį. Išsamus jo aprašymas nusipelno atskirų straipsnių, o pagrindinę informaciją galite rasti dokumentacija.

Problemos suvokimas

Tačiau supratome, ir ne iš karto, kad padarėme vieną klaidą: nepridėjome sugebėjimų kurti vaizdus naudojant standartinį Dockerfile ir integruoti juos į tą pačią visapusę taikomųjų programų valdymo infrastruktūrą (t. y. rinkti vaizdus, ​​įdiegti ir išvalyti). Kaip galima būtų padaryti įrankį diegimui Kubernetes ir neįdiegti Dockerfile palaikymo, t.y. standartinis daugelio projektų vaizdų apibūdinimo būdas?

Užuot atsakę į šį klausimą, siūlome sprendimą. Ką daryti, jei jau turite Dockerfile (arba Dockerfiles rinkinį) ir norite naudoti werf?

NB: Beje, kodėl tu net norėtum naudoti werf? Pagrindinės funkcijos yra šios:

• visas programų valdymo ciklas, įskaitant vaizdo valymą;
• galimybė vienu metu valdyti kelių vaizdų surinkimą iš vienos konfigūracijos;
• Patobulintas su Helm suderinamų diagramų diegimo procesas.

Išsamesnį jų sąrašą galite rasti adresu projekto puslapyje.

Taigi, jei anksčiau būtume siūlę perrašyti Dockerfile savo konfigūracijoje, dabar su džiaugsmu pasakysime: „Leiskite werf sukurti jūsų Dockerfile!

Kaip naudotis?

Visas šios funkcijos įgyvendinimas pasirodė leidime werf v1.0.3-beta.1. Bendras principas paprastas: vartotojas werf konfigūracijoje nurodo kelią į esamą Dockerfile ir paleidžia komandą werf build... ir viskas – werf surinks vaizdą. Pažvelkime į abstraktų pavyzdį.

Skelbiame kitą Dockerfile projekto šaknyje:

FROM ubuntu:18.04
RUN echo Building ...

Ir mes paskelbsime werf.yamlkuri tai naudoja Dockerfile:

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

Viskas! Kairė paleisti werf build:

Be to, galite deklaruoti toliau nurodytus dalykus werf.yaml Norėdami vienu metu sukurti kelis vaizdus iš skirtingų Docker failų:

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

Galiausiai, ji taip pat palaiko papildomų kūrimo parametrų, tokių kaip --build-arg и --add-host - per werf konfigūraciją. Išsamų Dockerfile vaizdo konfigūracijos aprašymą rasite adresu dokumentacijos puslapį.

Kaip tai veikia?

Kūrimo proceso metu „Docker“ veikia standartinė vietinių sluoksnių talpykla. Tačiau svarbu ir tai, kad werf integruoja Dockerfile konfigūraciją į savo infrastruktūrą. Ką tai reiškia?

1. Kiekvienas vaizdas, sukurtas iš Dockerfile, susideda iš vieno etapo, vadinamo dockerfile (daugiau apie tai, kokie etapai yra werf čia).
2. Scenai dockerfile werf apskaičiuoja parašą, kuris priklauso nuo Dockerfile konfigūracijos turinio. Pasikeitus Dockerfile konfigūracijai, pasikeičia etapo parašas dockerfile ir werf inicijuoja šio etapo atkūrimą su nauja Dockerfile konfigūracija. Jei parašas nesikeičia, werf paima vaizdą iš talpyklos (daugiau informacijos apie parašų naudojimą werf buvo aprašyta ši ataskaita).
3. Tada surinktus vaizdus galima publikuoti su komanda werf publish (Arba werf build-and-publish) ir naudoti jį diegti Kubernetes. Paskelbti vaizdai į Docker registrą bus valomi naudojant standartinius werf valymo įrankius, t.y. Seni vaizdai (senesni nei N dienų), vaizdai, susieti su neegzistuojančiomis „Git“ šakomis, ir kitos strategijos bus automatiškai išvalytos.

Daugiau informacijos apie čia aprašytus punktus rasite dokumentacijoje:

• Publikavimo procesas;
• Integracija su Kubernetes diegimo procesu;
• Valymo procesas.

Pastabos ir atsargumo priemonės

1. Išorinis URL nepalaikomas ADD

Šiuo metu direktyvoje nepalaikomas išorinio URL naudojimas ADD. Werf nepradės atkūrimo, kai pasikeis nurodyto URL ištekliai. Netrukus planuojame pridėti šią funkciją.

2. Negalite pridėti .git prie vaizdo

Paprastai tariant, pridedant katalogą .git paveikslėlyje – žiauri bloga praktika ir štai kodėl:

1. jei .git lieka galutiniame vaizde, tai pažeidžia principus 12 faktorių programa: Kadangi galutinis vaizdas turi būti susietas su vienu įsipareigojimu, to neturėtų būti įmanoma padaryti git checkout savavališkas įsipareigojimas.
2. .git padidina vaizdo dydį (saugykla gali būti didelė dėl to, kad kažkada į ją buvo įtraukti dideli failai, o paskui ištrinti). Darbo medžio, susieto tik su konkrečiu įsipareigojimu, dydis nepriklausys nuo Git operacijų istorijos. Šiuo atveju papildymas ir vėlesnis pašalinimas .git nuo galutinio vaizdo neveiks: vaizdas vis tiek įgis papildomą sluoksnį – taip veikia Docker.
3. „Docker“ gali inicijuoti nereikalingą atstatymą, net jei kuriamas tas pats įsipareigojimas, bet iš skirtingų darbo medžių. Pavyzdžiui, „GitLab“ sukuria atskirus klonuotus katalogus /home/gitlab-runner/builds/HASH/[0-N]/yourproject kai įjungtas lygiagretus surinkimas. Papildomas surinkimas bus dėl to, kad katalogas .git skiriasi skirtingose ​​tos pačios saugyklos klonuotose versijose, net jei sukurtas tas pats įsipareigojimas.

Paskutinis punktas taip pat turi pasekmių naudojant werf. „Werf“ reikalauja, kad įmontuota talpykla būtų vykdoma vykdant kai kurias komandas (pvz., werf deploy). Kai vykdomos šios komandos, werf apskaičiuoja etapinius parašus vaizdams, nurodytiems werf.yaml, ir jie turi būti surinkimo talpykloje – kitaip komanda negalės toliau veikti. Jei sceninis parašas priklauso nuo turinio .git, tada gauname talpyklą, kuri yra nestabili nereikšmingų failų pakeitimams, ir werf negalės atleisti tokio apsirikimo (daugiau informacijos žr. dokumentacija).

Apskritai, pridedant tik tam tikrus reikalingus failus per instrukcijas ADD bet kuriuo atveju padidina rašto efektyvumą ir patikimumą Dockerfile, taip pat pagerina tam surinktos talpyklos stabilumą Dockerfile, į nereikšmingus Git pakeitimus.

Visas

Mūsų pradinis kelias kurti savo konkrečius poreikius atitinkantį kūrėją buvo sunkus, sąžiningas ir paprastas: užuot naudoję ramentus ant standartinio Dockerfile, rašėme savo sprendimą naudodami tinkintą sintaksę. Ir tai turėjo savo privalumų: Stapel kolektorius puikiai susidoroja su savo užduotimi.

Tačiau rašydami savo kūrėją neteko matyti esamų Dockerfiles palaikymo. Šis trūkumas buvo ištaisytas ir ateityje planuojame plėtoti Dockerfile palaikymą kartu su mūsų pasirinktiniu Stapel kūrimo įrankiu, skirtu paskirstytoms versijoms ir kūrimui naudojant Kubernetes (t. y. kuriamas pagal Kubernetes viduje esančias bėgikas, kaip daroma Kaniko).

Taigi, jei staiga aplinkui guli pora Docker failų... pabandykite werf!

PS Dokumentų sąrašas šia tema

• Greitos pradžios vadovai;
• dockerfile kūrimo priemonės konfigūracijos;
• Stages įrenginys werf;
• Vaizdo publikavimo procesas;
• Integracija su Kubernetes diegimo procesu;
• Valymo procesas;
• Stapel statybininkas kaip alternatyva Dockerfile.

Taip pat skaitykite mūsų tinklaraštyje: “werf - mūsų CI / CD įrankis Kubernetes (apžvalga ir vaizdo reportažas)".

Šaltinis: www.habr.com