Më mirë vonë sesa kurrë. Ose si pothuajse bëmë një gabim të rëndë, pa pasur mbështetje për Dockerfiles të zakonshme për ndërtimin e imazheve të aplikacioneve.
Ky artikull do tĂ« flasĂ« pĂ«r â njĂ« mjet GitOps, i cili integrot me çdo sistem CI/CD dhe siguron menaxhim tĂ« tĂ«rĂ« ciklit tĂ« jetĂ«s sĂ« aplikacionit, duke lejuar:
- të ndërtojnë dhe publikojnë imazhe,
- të vendosin aplikacione në Kubernetes,
- të fshijnë imazhet e panevojshme me ndihmën e politikave të veçanta.
Filozofia e projektit është të mblidhen mjete të nivelit të ulët në një sistem të unifikuar, duke i dhënë inxhinierëve DevOps kontroll mbi aplikacionet. Sipas mundësisë, duhet të përfshihen mjete ekzistuese (si Helm dhe Docker). Nëse nuk ka një zgjidhje për ndonjë problem, ne mund të krijojmë dhe mbështesim gjithçka të nevojshme për këtë.
Historia: ndërtuesi ynë i imazheve
Kështu ndodhi me ndërtuesin e imazheve në werf: na mungonte Dockerfile i zakonshëm. Nëse shikojmë shpejt në historinë e projektit, ky problem u shfaq qysh në versionet e para të werf (atëherë ende ).
Duke krijuar një mjet për ndërtimin e aplikacioneve në imazhe Docker, shpejt e kuptuam se Dockerfile nuk na përshtatet për disa detyra të caktuara:
- Nevoja për të ndërtuar aplikacione të vogla web sipas një skeme standarde:
- të instaloni varësitë e sistemit të zakonshëm të aplikacionit,
- të instaloni bundle të bibliotekave të varësive të aplikacionit,
- të ndërtoni asetet,
- dhe mĂ« e rĂ«ndĂ«sishmja â tĂ« pĂ«rditĂ«soni kodin nĂ« imazh shpejt dhe nĂ« mĂ«nyrĂ« efikase.
- Kur ndodhin ndryshime në skedarët e projektit, ndërtuesi duhet të krijojë shpejt një shtresë të re duke vendosur patches në skedarët e ndryshuar.
- Nëse ndryshojnë skedarë të caktuar, është e nevojshme të rine ndërroni fazën përkatëse të varësisë.
Sot, ndërtuesi ynë ka gjithashtu shumë mundësi të tjera, por dëshirat dhe nxitjet fillestare ishin të tilla.
PĂ«r tĂ« thĂ«nĂ« tĂ« drejtĂ«n, ne morĂ«m nĂ« dorĂ« gjuhĂ«n e programimit tĂ« pĂ«rdorur (shih mĂ« poshtĂ«) dhe u nisĂ«m drejt realizimit tĂ« DSL tonĂ«! Duke u pĂ«rputhur me detyrat e caktuara, ai ishte i destinuar pĂ«r tĂ« pĂ«rshkruar procesin e ndĂ«rtimit nĂ«pĂ«r faza dhe pĂ«r tĂ« pĂ«rcaktuar varĂ«sitĂ« e kĂ«tyre fazave nga skedarĂ«t. Dhe e plotĂ«sonte atĂ« ndĂ«rtuesi ynĂ«, i cili e kthente DSL nĂ« objektin pĂ«rfundimtar â imazhin e ndĂ«rtuar. NĂ« fillim, DSL ishte nĂ« Ruby, dhe me kalimin â konfigurimi ynĂ« i ndĂ«rtuesit filloi tĂ« pĂ«rshkruhej nĂ« njĂ« skedar YAML.
Konfigurimi i vjetshëm për dapp në Ruby
Konfigurimi aktual për werf në YAML
Mekanizmi i punës së ndërtuesit gjithashtu ndryshoi me kalimin e kohës. Fillimisht, ne thjesht gjeneronim në flakë një Dockerfile të përkohshëm nga konfigurimi ynë, dhe pastaj filluam të ekzekutonim udhëzime 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 tërësor meriton artikuj të veçantë, dhe detajet kryesore mund të merren nga .
E kuptuar si problem
Por ne e kuptuam, dhe jo menjëherë, se bëmë një gabim: nuk shtuam mundësinë për të ndërtuar imazhe përmes Dockerfile standard dhe për ta integruar në të njëjtën infrastrukturë të menaxhimit të aplikacioneve (dmth. për të ndërtuar imazhe, për të bërë deploy dhe për t'i pastruar). Si mund të krijojmë një mjet për deploy në Kubernetes dhe të mos realizojmë mbështetje për Dockerfile, dmth. mënyra standarde për ta përshkruar imazhet për shumicën e projekteve?..
NĂ« vend tĂ« pĂ«rgjigjes pĂ«r njĂ« pyetje tĂ« tillĂ«, ne ofrojmĂ« zgjidhjen e saj. ĂfarĂ« duhet tĂ« bĂ«ni, nĂ«se tashmĂ« keni njĂ« Dockerfile (ose njĂ« grup Dockerfileâash) dhe dĂ«shironi tĂ« pĂ«rdorni werf?
NB: Për të thënë të vërtetën, pse do të dëshironit të përdorni werf? Tiparet kryesore janë si më poshtë:
- cikli i plotë i menaxhimit të aplikacionit, duke përfshirë pastrimin e imazheve;
- mundësia për të menaxhuar ndërtimin e disa imazheve nga një konfigurim të vetme;
- procesi i përmirësuar i deploy të chart-eve, të cilat janë përputhëse me Helm.
Me një listë më të plotë të tyre mund të njoheni në .
Pra, nëse më parë ne do të kishim propozuar që ta rishkruanim Dockerfile në konfigurimin tonë, tani me kënaqësi do të themi: «Lejoni werf të ndërtojë Dockerfile tuaj!»
Si ta përdor?
Implementimi i plotĂ« i kĂ«saj mundĂ«sie u shfaq nĂ« versionin . Parimi i pĂ«rgjithshĂ«m Ă«shtĂ« i thjeshtĂ«: pĂ«rdoruesi specifikon rrugĂ«n deri te Dockerfile ekzistues nĂ« konfigurimin werf, pas sĂ« cilĂ«s ekzekuton komandĂ«n werf build⊠dhe gjithçka â werf do ta ndĂ«rtojĂ« imazhin. Le ta shqyrtojmĂ« nĂ« njĂ« shembull abstrakt.
Deklarojmë si më poshtë Dockerfile në rrënjën e projektit:
FROM ubuntu:18.04
RUN echo Building ... Dhe deklarojmë werf.yaml, i cili përdor këtë Dockerfile:
configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile E gjithë! Qëndron vetëm të fillojnë werf build:
Për më tepër, mund të deklaroni si më poshtë werf.yaml për të ndërtuar menjëherë disa imazhe nga Dockerfile të ndryshme:
configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend MĂ« nĂ« fund, mbĂ«shtetet edhe kalimi i parametrave shtesĂ« tĂ« ndĂ«rtimit â siç janĂ« --build-arg dhe --add-host â pĂ«rmes konfigurations werf. NjĂ« pĂ«rshkrim i plotĂ« i konfigurimit tĂ« imazhit Dockerfile Ă«shtĂ« i disponueshĂ«m nĂ« .
Si funksionon?
GjatĂ« procesit tĂ« ndĂ«rtimit funksionon cache standard i slojve lokale nĂ« Docker. MegjithatĂ«, e rĂ«ndĂ«sishme Ă«shtĂ« qĂ« werf gjithashtu integron konfigurimin e Dockerfile nĂ« infrastrukturĂ«n e saj. ĂfarĂ« do tĂ« thotĂ« kjo?
- Ădo imazh i ndĂ«rtuar nga Dockerfile pĂ«rbĂ«het nga njĂ« stad i njohur si
dockerfile(më shumë rreth asaj që janë stadi në werf, mund të lexoni ). - Për stadi-n
dockerfilewerf llogarit një nënshkrim, i cili varet nga përmbajtja e konfigurimit të Dockerfile. Kur ndodhin ndryshime në konfigurimin e Dockerfile, nënshkrimi i stages ndryshondockerfiledhe werf nismon rine ndërtimin e këtij stadi me një konfigurim të ri të Dockerfile. Nëse nënshkrimi nuk ndryshon, atëherë werf merr imazhin nga cache (më shumë për përdorimin e nënshkrimeve në werf është folur ). - Më pas, imazhet e ndërtuara mund të publikohen me komandën
werf publish(osewerf build-and-publish) dhe të përdoren për ndërrim në Kubernetes. Imazhet e publikuara në Docker Registry do të pastrohen me mjetet standarde të pastrimit të werf, dmth. do të ketë pastrim automatik të imazheve të vjetra (më të vjetra se N ditë), imazheve që lidhen me dega të paekzistuese Git, dhe sipas politikave të tjera.
Më shumë për momentet e përshkruara këtu mund të mësoni nga dokumentacioni:
- ;
- ;
- .
Shënime dhe masa paraprake
1. URL e jashtme në ADD nuk mbështetet
Aktualisht nuk mbështetet përdorimi i një URL-je të jashtme në direktivën ADD. Werf nuk do të nismojë rine ndërtimin në rast të ndryshimit të burimit në URL-në e dhënë. Në një të ardhme të afërt planifikohet shtimi i kësaj mundësie.
2. Nuk lejohet shtimi i .git në imazh
Në përgjithësi, shtimi i drejtorisë .git në imazh është një praktikë e keqe dhe ja pse:
- NĂ«se
.gitmbetet në imazhin përfundimtar, kjo cënon parimet : sepse imazhi përfundimtar duhet të lidhet me një commit të vetëm, nuk duhet të ketë mundësi për të bërëgit checkoutcommit të rastësishëm. -
.gitrrit madhĂ«sinĂ« e imazhit (repoja mund tĂ« jetĂ« e madhe pĂ«r shkak se njĂ«herĂ« janĂ« shtuar skedarĂ« tĂ« mĂ«dhenj dhe pastaj janĂ« fshirĂ«). MadhĂ«sia e work-tree, e lidhur vetĂ«m me njĂ« commit tĂ« caktuar, nuk do tĂ« varet nga historia e operacioneve nĂ« Git. NĂ« tĂ« njĂ«jtĂ«n kohĂ«, shtimi dhe fshirja e mĂ«passhme.gitnga imazhi pĂ«rfundimtar nuk do tĂ« funksionojĂ«: imazhi do tĂ« fitojĂ« njĂ« shtresĂ« tĂ« tepĂ«rt â kĂ«shtu funksionon Docker. - Docker mund tĂ« nismojĂ« rine ndĂ«rtim tĂ« panevojshĂ«m, edhe nĂ«se po ndodhet ndĂ«rtimi i njĂ«jti commit, por nga work-tree tĂ« ndryshme. PĂ«r shembull, GitLab krijon drejtoritĂ« e klonuara tĂ« veçanta
/home/gitlab-runner/builds/HASH/[0-N]/yourprojectme ndihmën e ndërtimit paralel. Rine ndërtimi i panevojshëm do të jetë i lidhur me faktin se direttoria.gitnuk është e njëjtë në versionet e ndryshme të klonuara të të njëjtit repozitor, edhe nëse po ndodhet ndërtimi i njëjti commit.
Pika e fundit ka pasoja edhe kur pĂ«rdoret werf. Werf kĂ«rkon qĂ« cache i ndĂ«rtuar tĂ« jetĂ« i pranishĂ«m gjatĂ« ekzekutimit tĂ« disa komandove (p.sh., werf deploy). GjatĂ« punĂ«s sĂ« kĂ«tyre komandave, werf llogarit nĂ«nshkrimet e stadeve pĂ«r imazhet e specifikuara nĂ« werf.yaml, dhe ato duhet tĂ« jenĂ« nĂ« cache-in e ndĂ«rtimit â ndryshe komanda nuk do tĂ« mund tĂ« vazhdojĂ«. NĂ«se nĂ«nshkrimi i stadi do tĂ« varet nga pĂ«rmbajtja .git, atĂ«herĂ« ne do tĂ« kemi njĂ« cache tĂ« paqĂ«ndrueshĂ«m ndaj ndryshimeve nĂ« skedarĂ«t e panesĂ«rishĂ«m dhe werf nuk do tĂ« mund ta falĂ« njĂ« gabim tĂ« tillĂ« (mĂ« shumĂ« shih nĂ« ).
Në përgjithësi shtimin e vetëm të 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 stabilitetin e cache-it, të ndërtuar sipas kësaj Dockerfile, ndaj ndryshimeve të panevojshme në Git.
PĂ«rfundimi
Rruga jonë fillestare me shkruarjen e ndërtuesit tonë për nevoja të caktuara ishte e vështirë, e sinqertë dhe e drejtpërdrejtë: në vend që të përdornim qershi mbi standardin Dockerfile ne shkruam zgjidhjen tonë me sintaksë të personalizuar. Dhe kjo dha përfitime të saj: ndërtuesi Stapel bën përshpejt një punë të shkëlqyer.
Megjithatë, gjatë procesit të shkruarjes së ndërtuesit tonë ne humbëm mbështetje për Dockerfile-të ekzistuese. Tani ky defekt është korrigjuar, dhe në të ardhmen planifikojmë të zhvillojmë mbështetje për Dockerfile përveç ndërtuesit tonë të personalizuar Stapel për ndërtim të shpërndarë dhe për ndërtim që përdor Kubernetes (p.sh., ndërtimi në runner brenda Kubernetes, ashtu siç është bërë në kaniko).
Prandaj, nëse ndonjëherë keni disa Dockerfile të ndodhur... provojeni !
P.S. Lista e dokumentacionit për këtë temë
- ;
- ;
- ;
- ;
- ;
- ;
- .
Lexoni gjithashtu në blogun tonë: «».
Burimi: habr.com
