Më mirë vonë se kurrë. Ose si ndodhi që ndalmost bëmë një gabim të rëndë, duke mos pasur mbështetje për Dockerfiles standard për ndërtimin e imazheve të aplikacioneve.
Do tĂ« flasim pĂ«r â njĂ« mjet GitOps, i cili integrohet me çdo sistem CI/CD dhe siguron menaxhimin e gjithĂ« ciklit tĂ« jetĂ«s sĂ« aplikacionit, duke lejuar:
- të mbledhim dhe të publikojmë imazhe,
- të vendosim aplikacione në Kubernetes,
- të fshijmë imazhet e pa përdorura duke përdorur politika të veçanta.
Filozofia e projektit është të mbledhë mjete me nivel të ulët në një sistem të unifikuar, duke i dhënë inxhinierëve DevOps kontroll mbi aplikacionet. Duhet të angazhohen mjete ekzistuese (si Helm dhe Docker) sa më shumë që të jetë e mundur. Nëse nuk ka një zgjidhje për ndonjë problem, ne mund të krijojmë dhe të mbajmë gjithçka të nevojshme për këtë.
Historia e prapavijës: ndërtuesi i imazheve tonë
Kështu ndodhi me ndërtuesin e imazheve në werf: na mungonte Dockerfile i njohur. Nëse shikojmë shpejt historinë e projektit, kjo problematike u shfaq që në versionet e para të werf (atëherë akoma ).
Duke krijuar një mjet për ndërtimin e aplikacioneve në imazhe Docker, shpejt kuptuam që Dockerfile nuk ishte i përshtatshëm për disa detyra të veçanta:
- Nevoja për të ndërtuar aplikacione të vogla web të zakonshme sipas një skeme standarde:
- instaloni varësitë e zakonshme të sistemit për aplikacionin,
- instaloni bibliotekat e varësive të aplikacionit,
- mbledhni asetet,
- dhe mĂ« e rĂ«ndĂ«sishmja â azhurnoni kodin nĂ« imazhe shpejt dhe efektivisht.
- Kur ndodhin ndryshime në skedaret e projektit, ndërtuesi duhet të krijojë shpejt një shtresë të re duke vendosur patch në skedaret e ndryshuara.
- Nëse disa skedare kanë ndryshuar, atëherë është e nevojshme të rindezështrohet faza përkatëse e varësive.
Sot, ndërtuesi ynë ka shumë mundësi të tjera, por dëshirat dhe impulse fillestare kanë qenë të tilla.
Pra, pa menduar gjatĂ«, ne u armatosĂ«m me gjuhĂ«n e programimit qĂ« pĂ«rdorim (shih mĂ« poshtĂ«) dhe gjithaqĂ« pĂ«r tĂ« realizuar DSL-nĂ« tonĂ«! Duke iu pĂ«rgjigjur detyrave tĂ« vendosura, ajo ishte e destinuar pĂ«r tĂ« pĂ«rshkruar procesin e ndĂ«rtimit nĂ« faza dhe pĂ«r tĂ« pĂ«rcaktuar varĂ«sitĂ« e kĂ«tyre fazave nga skedarĂ«t. E plotĂ«sonte ndĂ«rtuesi ynĂ«, i cili ktheu DSL nĂ« objektin pĂ«rfundimtar â imazhin e ndĂ«rtuar. Fillimisht DSL ishte nĂ« Ruby, dhe ndĂ«rsa kaluam â konfigurimi i ndĂ«rtuesit tonĂ« tani pĂ«rshkruhet nĂ« njĂ« skedar YAML.
Konfigurimi i vjetër për dapp në Ruby
Konfigurimi aktual për werf në YAML
Mekanizmi i funksionimit të ndërtuesit gjithashtu ka ndryshuar me kalimin e kohës. Në fillim ne thjesht gjeneronim në flakë një Dockerfile të përkohshëm nga konfigurimi ynë, dhe më pas filluam të ekzekutonim instrukcioni ndërtimi në kontejnerë të përkohshëm dhe të bënim commit.
NB: Aktualisht ndërtuesi ynë, i cili punon me konfigurimin e tij (në YAML) dhe quhet ndërtuesi Stapel, ka evoluar në një mjet mjaft të fuqishëm. Përshkrimi i tij i detajuar meriton artikuj të veçantë, dhe informacionin kryesor mund ta gjeni në .
Vetëdijësimi për problemin
Por ne kuptuam, dhe jo menjëherë, se kishim bërë një gabim: nuk kemi shtuar mundësinë për të ndërtuar imazhe përmes Dockerfile standard dhe për t'i integruar ato në të njëjtën infrastrukturë të menaxhimit të aplikacionit (dmth. të ndërtojmë imazhe, t'i hedhim ato dhe t'i pastrojmë). Si është e mundur të krijohet një mjet për hedhje në Kubernetes dhe të mos realizohet mbështetje për Dockerfile, dmth. mënyra standarde për të përshkruar imazhet për shumicën e projekteve?..
NĂ« vend tĂ« pĂ«rgjigjĂ«s pĂ«r njĂ« pyetje tĂ« tillĂ«, ne ofrojmĂ« zgjidhjen e saj. ĂfarĂ« tĂ« bĂ«ni nĂ«se tashmĂ« keni njĂ« Dockerfile (ose njĂ« grup DockerfileâĂ«sh) dhe dĂ«shironi tĂ« pĂ«rdorni werf?
NB: Për të thënë diçka, pse do të donit të përdorni werf? Tiparet kryesore përfshijnë:
- cikli i plotë i menaxhimit të aplikacionit përfshirë pastrimin e imazheve;
- mundësia për të menaxhuar ndërtimin e disa imazheve nga një konfigurim të vetëm;
- procedura e përmirësuar e hedhjes së chart-eve, të përshtatshme me Helm.
Për një listë më të plotë mund të konsultoheni në .
Pra, nëse më parë do të sugjeronim riformatimin e Dockerfile në konfigurimin tonë, tani me kënaqësi do të themi: «Lejoni që werf të ndjekë Dockerfile tuaj!»
Si të përdorni?
Implementimi i plotĂ« i kĂ«saj mundĂ«sie u shfaq nĂ« lĂ«shimin . Parimi i pĂ«rgjithshĂ«m Ă«shtĂ« i thjeshtĂ«: pĂ«rdoruesi tregon rrugĂ«n nĂ« Dockerfile ekzistues nĂ« konfigurimin e werf, pas sĂ« cilĂ«s ekzekuton komandĂ«n werf build⊠dhe gjithçka â werf do tĂ« ndjekĂ« imazhin. Le tĂ« ilustrojmĂ« me njĂ« shembull abstract.
Deklarojmë këtë Dockerfile në rrënjën e projektit:
FROM ubuntu:18.04
RUN echo Ndërtimi ... Dhe deklarojmë werf.yaml, i cili përdor këtë Dockerfile:
configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: .\/Dockerfile Kaq! Mund të të nisë werf build:
Për më tepër, mund të deklaroni këtë werf.yaml për ndërtimin e disa imazheve nga Dockerfile të ndryshëm:
configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: .\/dockerfiles\/Dockerfile-backend
---
image: frontend
dockerfile: .\/dockerfiles\/Dockerfile-frontend MĂ« nĂ« fund, mbĂ«shteten gjithashtu kalimi i parametrave shtesĂ« pĂ«r ndĂ«rtim â siç janĂ« --build-arg dhe --add-host â pĂ«rmes konfiguimit werf. PĂ«rshkrimi i plotĂ« i konfigurations Dockerfile image Ă«shtĂ« i disponueshĂ«m nĂ« .
Si funksionon kjo?
GjatĂ« ndĂ«rtimit funksionon cache standard i shtresave lokale nĂ« Docker. MegjithatĂ«, e rĂ«ndĂ«sishme Ă«shtĂ« se werf gjithashtu integron konfigurimin Dockerfile nĂ« infrastrukturĂ«n e tij. ĂfarĂ« do tĂ« thotĂ« kjo?
- Ădo imazh qĂ« ndĂ«rtohet nga Dockerfile pĂ«rbĂ«het nga njĂ« stage tĂ« quajtur
dockerfile(pĂ«r mĂ« shumĂ« rreth stages nĂ« werf, mund tĂ« lexoni ). - PĂ«r stageânĂ«
dockerfilewerf llogarit një nënshkrim që varet nga përmbajtja e konfigurimit Dockerfile. Kur ndodh ndryshimi i konfigurimit Dockerfile, nënshkrimi i fazës ndryshondockerfiledhe werf iniciaton riciklimin e kësaj faze me një konfig të ri Dockerfile. Nëse nënshkrimi nuk ndryshon, atëherë werf merr imazhin nga cache (për më shumë mbi përdorimin e nënshkrimeve në werf, është folur në ). - Pastaj, imazhet e ndërtuara mund të publikohen me komandën
werf publish(osewerf build-and-publish) dhe të përdoren për deploy në Kubernetes. Imazhet e publikuara në Docker Registry do të pastrohen me mjetet standarde të pastrimit werf, dmth do të ndodhë pastrimi automatik i imazheve të vjetra (më të vjetra se N ditë), imazheve të lidhura me degët e paekzistuese Git dhe sipas politikave të tjera.
Për më shumë rreth çështjeve të përshkruara këtu, mund të mësoni nga dokumentacioni:
- ;
- ;
- .
Shënime dhe kujdes
1. URL e jashtme në ADD nuk mbështetet
Aktualisht nuk mbështetet përdorimi i URL e jashtme në direktivën ADD. Werf nuk do të iniciatojë riciklimin kur ndryshohet burimi në URL të caktuar. Shpejt pritet të shtohet kjo mundësi.
2. Nuk mund të shtoni .git në imazh
Në përgjithësi, shtimi i direktorisë .git në imazh është një praktikë e keqe dhe ja pse:
- NĂ«se
.gitmbetet në imazhin përfundimtar, kjo shkel parimet : pasi imazhi përfundimtar duhet të lidhet me një commit, nuk duhet të ketë mundësi që të bënigit checkouttë një commit-i të rastësishëm. -
.gitrrit madhĂ«sinĂ« e imazhit (repoja mund tĂ« jetĂ« e madhe pĂ«r shkak se dikur janĂ« shtuar skedarĂ« tĂ« mĂ«dhenj dhe mĂ« pas janĂ« fshirĂ«). MadhĂ«sia e work-tree qĂ« lidhet vetĂ«m me njĂ« angazhim tĂ« caktuar, nuk do tĂ« varet nga historia e operacioneve nĂ« Git. MegjithatĂ«, shtimi dhe fshirja e mĂ«vonshme.gitnuk do tĂ« funksionojĂ« nga imazhi pĂ«rfundimtar: imazhi gjithsesi do tĂ« fitojĂ« njĂ« shtresĂ« tĂ« tepruar â kĂ«shtu funksionon Docker. - Docker mund tĂ« nxisĂ« njĂ« rindĂ«rtim tĂ« panevojshĂ«m, edhe kur Ă«shtĂ« duke ndodhur rindĂ«rtimi i tĂ« njĂ«jtit angazhim, por nga work-tree tĂ« ndryshme. PĂ«r shembull, GitLab krijon drejtime tĂ« klonuara veçmas nĂ«
/home/gitlab-runner/builds/HASH/[0-N]/yourprojectnë ndërtim paralel të aktivizuar. Rindërtimi i panevojshëm do të lidhet me faktin se direktoria.gitdallon në versione të ndryshme të klonuara të të njëjtës repo, edhe kur po ndërtohet të njëjtin angazhim.
Pika e fundit ka njĂ« pasojĂ« madje edhe kur pĂ«rdoret werf. Werf kĂ«rkon qĂ« ekzistenca e caches tĂ« ndĂ«rtuara tĂ« jetĂ« e pranishme gjatĂ« ekzekutimit tĂ« disa komandave (p.sh., werf deploy). GjatĂ« punĂ«s sĂ« atyre komandave, werf llogarit nĂ«nshkrimet e fazave pĂ«r imazhet, tĂ« pĂ«rcaktuara nĂ« werf.yaml, dhe ato duhet tĂ« jenĂ« nĂ« cache-n e ndĂ«rtimit â ndryshe komanda nuk do tĂ« mund tĂ« vazhdojĂ« punĂ«n. NĂ«se nĂ«nshkrimi i fazave varet nga pĂ«rmbajtja e .git, atĂ«herĂ« ne kemi njĂ« cache tĂ« paqĂ«ndrueshĂ«m ndaj ndryshimeve nĂ« skedarĂ« tĂ« panevojshĂ«m, dhe werf nuk do tĂ« mund tĂ« falĂ« njĂ« gabim tĂ« tillĂ« (shih mĂ« shumĂ« nĂ« ).
Në përgjithësi shtimi vetëm i skedarëve të nevojshëm përmes direktivës ADD në çdo rast rrit efikasitetin dhe besueshmërinë e asaj që është shkruar Dockerfile, si dhe përmirëson qëndrueshmërinë e caches të ndërtuara sipas këtij Dockerfile, ndaj ndryshimeve të panevojshme në Git.
PĂ«rfundimi
Rruga jonë fillestare me shkruan ndërtuesin tonë për nevoja të caktuara ishte e vështirë, e ndershme dhe e drejtpërdrejtë: në vend të përdorimit të plasteve mbi Dockerfile standard, ne shkruam zgjidhjen tonë me sintaksë të personalizuar. Dhe kjo kishte përfitimet e veta: ndërtuesi Stapel i bën shkëlqyeshëm punën e tij.
Megjithatë, gjatë procesit të shkruarjes së ndërtuesit tonë ne e humbëm nga vëmendja mbështetje për Dockerfile ekzistuese. Tani ky mungesë është rregulluar, dhe në të ardhmen ne planifikojmë të zhvillojmë mbështetje për Dockerfile së bashku me ndërtuesin tonë të personalizuar Stapel për ndërtim të shpërndarë dhe për ndërtim duke përdorur Kubernetes (dmth, ndërtim në runner në brendësi të Kubernetes, ashtu siç është bërë në kaniko).
Pra, nëse keni ndonjë Dockerfile diku të mbetur... provoni !
P.S. Lista e dokumentacionit mbi temën
- ;
- ;
- ;
- ;
- ;
- ;
- .
Lexoni gjithashtu në blogun tonë: "».
Burimi: habr.com
