Þú getur nú smíðað Docker myndir í werf með því að nota venjulega Dockerfile

Betra seint en aldrei. Eða hvernig við gerðum næstum alvarleg mistök með því að hafa ekki stuðning fyrir venjulegar Dockerfiles til að búa til forritamyndir.

Við munum tala um werf — GitOps tól sem fellur inn í hvaða CI/CD kerfi sem er og veitir stjórnun á öllu líftíma forritsins, sem gerir:

• safna og birta myndir,
• dreifa forritum í Kubernetes,
• eyða ónotuðum myndum með sérstökum reglum.

Hugmyndafræði verkefnisins er að safna verkfærum á lágu stigi í eitt sameinað kerfi sem veitir DevOps verkfræðingum stjórn á forritum. Ef mögulegt er ætti að nota núverandi tól (eins og Helm og Docker). Ef það er engin lausn á vandamáli getum við búið til og stutt allt sem þarf til þess.

Bakgrunnur: þinn eigin myndasafnari

Þetta er það sem gerðist með myndasafnarann ​​í werf: venjulega Dockerfile var ekki nóg fyrir okkur. Ef þú lítur fljótt á sögu verkefnisins birtist þetta vandamál þegar í fyrstu útgáfum werf (þá enn þekktur sem dapp).

Þegar við bjuggum til tól til að byggja upp forrit í Docker myndir, áttuðum við okkur fljótt á því að Dockerfile hentaði okkur ekki fyrir mjög ákveðin verkefni:

1. Þörfin fyrir að smíða dæmigerð lítil vefforrit í samræmi við eftirfarandi staðlaða kerfi:
   • setja upp forrit sem eru ósjálfstæðir í kerfinu,
   • setja upp búnt af forritaháð bókasöfnum,
   • safna eignum,
   • og síðast en ekki síst, uppfærðu kóðann á myndinni fljótt og vel.
2. Þegar breytingar eru gerðar á verkefnaskrám verður byggirinn fljótt að búa til nýtt lag með því að setja plástur á breyttar skrár.
3. Ef ákveðnar skrár hafa breyst, þá er nauðsynlegt að endurbyggja samsvarandi háða stig.

Í dag hefur safnari okkar marga aðra möguleika, en þetta voru fyrstu óskir og hvatir.

Almennt, án þess að hugsa tvisvar um, vopnuðum við okkur forritunarmálinu sem við notuðum (sjá fyrir neðan) og fór á götuna til að hrinda í framkvæmd eiga DSL! Í samræmi við markmiðin var ætlunin að lýsa samsetningarferlinu í áföngum og ákvarða hversu háðir þessir áfangar eru á skrám. Og bætti það við eigin safnara, sem breytti DSL í lokamarkið - samsett mynd. Í fyrstu var DSL í Ruby, en eins og umskipti yfir í Golang — byrjað var að lýsa uppsetningu safnara okkar í YAML skrá.

Gömul stilling fyrir dapp í Ruby

Núverandi stillingar fyrir werf á YAML

Vélbúnaður safnara breyttist einnig með tímanum. Í fyrstu bjuggum við einfaldlega til tímabundna Dockerfile á flugu úr stillingum okkar, og síðan fórum við að keyra samsetningarleiðbeiningar í tímabundnum gámum og skuldbinda okkur.

NB: Í augnablikinu hefur safnari okkar, sem vinnur með sína eigin stillingu (í YAML) og er kallaður Stapel safnari, þegar þróast í nokkuð öflugt tól. Nákvæm lýsing þess verðskuldar sérstakar greinar og helstu upplýsingar er að finna í skjöl.

Meðvitund um vandamálið

En við áttuðum okkur á, og ekki strax, að við höfðum gert ein mistök: við bættum ekki við getu búa til myndir með venjulegu Dockerfile og samþætta þær í sama enda-til-enda forritastjórnunarinnviði (þ.e. safna myndum, dreifa og þrífa þær). Hvernig gæti verið hægt að búa til tól fyrir uppsetningu í Kubernetes og innleiða ekki Dockerfile stuðning, þ.e. venjuleg leið til að lýsa myndum fyrir flest verkefni? ..

Í stað þess að svara þessari spurningu bjóðum við upp á lausn. Hvað ef þú ert nú þegar með Dockerfile (eða sett af Dockerfile) og vilt nota werf?

NB: Við the vegur, hvers vegna myndirðu jafnvel vilja nota werf? Helstu eiginleikarnir koma niður á eftirfarandi:

• fullt forritastjórnunarferli þar á meðal myndhreinsun;
• getu til að stjórna samsetningu nokkurra mynda í einu frá einni stillingu;
• Bætt dreifingarferli fyrir Helm-samhæf töflur.

Nánari lista yfir þá er að finna á verkefnasíðu.

Svo, ef við hefðum áður boðið að endurskrifa Dockerfile í stillingum okkar, nú munum við hamingjusamlega segja: "Láttu werf byggja Dockerfiles þínar!"

Hvernig á að nota?

Full útfærsla þessa eiginleika birtist í útgáfunni werf v1.0.3-beta.1. Almenna meginreglan er einföld: notandinn tilgreinir slóðina að núverandi Dockerfile í werf stillingunni og keyrir síðan skipunina werf build... og það er það - werf mun setja saman myndina. Við skulum skoða abstrakt dæmi.

Við skulum tilkynna næsta Dockerfile í verkefnarótinni:

FROM ubuntu:18.04
RUN echo Building ...

Og við munum tilkynna werf.yamlsem notar þetta Dockerfile:

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

Allt! Vinstri hlaupa werf build:

Að auki getur þú lýst yfir eftirfarandi werf.yaml til að búa til nokkrar myndir úr mismunandi Dockerfiles í einu:

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

Að lokum styður það einnig að senda fleiri byggingarfæribreytur, svo sem --build-arg и --add-host - í gegnum werf stillingar. Heildarlýsing á Dockerfile myndstillingu er fáanleg á skjalasíðu.

Hvernig virkar það?

Á byggingarferlinu virkar staðlað skyndiminni staðbundinna laga í Docker. Hins vegar, það sem er mikilvægt er að werf líka samþættir Dockerfile stillingar innviði þess. Hvað þýðir þetta?

1. Hver mynd byggð úr Dockerfile samanstendur af einu stigi sem kallast dockerfile (þú getur lesið meira um hvaða stig eru í werf hér).
2. Fyrir svið dockerfile werf reiknar út undirskrift sem fer eftir innihaldi Dockerfile stillingarinnar. Þegar Dockerfile stillingar breytast breytist sviðsundirskriftin dockerfile og werf byrjar endurbyggingu á þessu stigi með nýrri Dockerfile stillingu. Ef undirskriftin breytist ekki, þá tekur werf myndina úr skyndiminni (nánari upplýsingar um notkun undirskrifta í werf var lýst í þessari skýrslu).
3. Næst er hægt að birta söfnuðu myndirnar með skipuninni werf publish (Eða werf build-and-publish) og notaðu það til dreifingar á Kubernetes. Birtar myndir í Docker Registry verða hreinsaðar með venjulegum werf hreinsunarverkfærum, þ.e. Gamlar myndir (eldri en N dagar), myndir tengdar Git útibúum sem ekki eru til og aðrar reglur verða sjálfkrafa hreinsaðar.

Frekari upplýsingar um atriðin sem lýst er hér er að finna í skjölunum:

• Útgáfuferli;
• Samþætting við Kubernetes dreifingarferli;
• Hreinsunarferli.

Athugasemdir og varúðarráðstafanir

1. Ytri vefslóð er ekki studd í ADD

Eins og er er ekki stutt að nota ytri vefslóð í tilskipun ADD. Werf mun ekki hefja endurbyggingu þegar tilföngin á tilgreindri vefslóð breytist. Við ætlum að bæta við þessum eiginleika fljótlega.

2. Þú getur ekki bætt .git við myndina

Almennt talað, að bæta við möppu .git á myndinni - grimm slæm æfing og hér er ástæðan:

1. Ef .git er áfram í endanlegri mynd, þetta brýtur gegn meginreglunum 12 þátta app: Þar sem lokamyndin verður að vera tengd við eina commit ætti það ekki að vera hægt að gera það git checkout handahófskennda skuldbindingu.
2. .git eykur stærð myndarinnar (geymslan getur verið stór vegna þess að stórum skrám var einu sinni bætt við hana og síðan eytt). Stærð vinnutrés sem aðeins tengist tiltekinni skuldbindingu fer ekki eftir aðgerðasögu í Git. Í þessu tilviki, viðbót og síðari flutningur .git frá endanlegri mynd virkar ekki: myndin mun samt eignast aukalag - svona virkar Docker.
3. Docker getur hafið óþarfa endurbyggingu, jafnvel þó að verið sé að byggja sama commit, en úr mismunandi vinnutré. Til dæmis býr GitLab til aðskildar klónaðar möppur í /home/gitlab-runner/builds/HASH/[0-N]/yourproject þegar samhliða samsetning er virkjuð. Auka samsetningin verður vegna þess að skráin .git er öðruvísi í mismunandi klónuðum útgáfum af sömu geymslunni, jafnvel þó að sama commit sé byggt.

Síðasti liðurinn hefur einnig afleiðingar þegar werf er notað. Werf krefst þess að innbyggða skyndiminni sé til staðar þegar sumar skipanir eru keyrðar (t.d. werf deploy). Þegar þessar skipanir keyra reiknar werf sviðsundirskriftir fyrir myndirnar sem tilgreindar eru í werf.yaml, og þeir verða að vera í samsetningarskyndiminni - annars mun skipunin ekki geta haldið áfram að virka. Ef undirskrift sviðs fer eftir innihaldi .git, þá fáum við skyndiminni sem er óstöðugt fyrir breytingum á óviðkomandi skrám og werf mun ekki geta fyrirgefið slíka yfirsjón (fyrir frekari upplýsingar, sjá skjöl).

Almennt að bæta aðeins við ákveðnum nauðsynlegum skrám í gegnum leiðbeiningarnar ADD í öllum tilvikum eykur skilvirkni og áreiðanleika ritaðs Dockerfile, og bætir einnig stöðugleika skyndiminni sem safnað er fyrir þetta Dockerfile, að óviðkomandi breytingum á Git.

Samtals

Upphafleg leið okkar til að skrifa okkar eigin smið fyrir sérstakar þarfir var erfið, heiðarleg og einföld: í stað þess að nota hækjur ofan á venjulegu Dockerfile, skrifuðum við lausnina okkar með sérsniðnum setningafræði. Og þetta hafði sína kosti: Stapel safnarinn tekst verkefni sínu fullkomlega.

Hins vegar, í því ferli að skrifa eigin byggingaraðila, misstum við sjónar á stuðningi við núverandi Dockerfiles. Þessi galli hefur nú verið lagaður og í framtíðinni ætlum við að þróa Dockerfile stuðning ásamt sérsniðna Stapel smiðnum okkar fyrir dreifða samsetningu og fyrir samsetningu með Kubernetes (þ.e. samsetningu á hlaupara inni í Kubernetes, eins og gert er í kaniko).

Svo, ef þú ert skyndilega með nokkrar Dockerfiles liggjandi... reyna werf!

PS Listi yfir skjöl um efnið

• Leiðbeiningar fyrir fljótlega byrjun;
• stillingar dockerfile byggir;
• Stages tæki í werf;
• Myndbirtingarferli;
• Samþætting við Kubernetes dreifingarferli;
• Hreinsunarferli;
• Stapel byggir sem valkostur við Dockerfile.

Lestu líka á blogginu okkar: “werf - tól okkar fyrir CI / CD í Kubernetes (yfirlit og myndbandsskýrsla)'.

Heimild: www.habr.com