Me mire vone se kurre. Ose si pothuajse bëmë një gabim serioz duke mos pasur mbështetje për Dockerfiles të rregullt për të ndërtuar imazhe aplikacioni.
Ne do të flasim për — Shërbimi GitOps që integrohet me çdo sistem CI/CD dhe siguron menaxhimin e të gjithë ciklit jetësor të aplikacionit, duke lejuar:
- mbledhin dhe publikojnë imazhe,
- vendosja e aplikacioneve në Kubernetes,
- fshini imazhet e papërdorura duke përdorur politika të veçanta.
Filozofia e projektit është mbledhja e mjeteve të nivelit të ulët në një sistem të vetëm të unifikuar që u jep inxhinierëve DevOps kontroll mbi aplikacionet. Nëse është e mundur, duhet të përdoren shërbimet ekzistuese (si Helm dhe Docker). Nëse nuk ka zgjidhje për një problem, ne mund të krijojmë dhe mbështesim gjithçka që është e nevojshme për këtë.
Sfondi: koleksionisti juaj i imazheve
Kështu ndodhi me koleksionuesin e imazheve në werf: Dockerfile-i i zakonshëm nuk na mjaftonte. Nëse hidhni një vështrim të shpejtë në historinë e projektit, ky problem u shfaq tashmë në versionet e para të werf (atëherë ende ).
Ndërsa krijonim një mjet për ndërtimin e aplikacioneve në imazhet e Docker, shpejt kuptuam se Dockerfile nuk ishte i përshtatshëm për ne për disa detyra shumë specifike:
- Nevoja për të ndërtuar aplikacione tipike të vogla në internet sipas skemës standarde të mëposhtme:
- instaloni varësi të aplikacioneve në të gjithë sistemin,
- instaloni një paketë bibliotekash të varësisë së aplikacionit,
- mbledhin pasuri,
- dhe më e rëndësishmja, përditësoni kodin në imazh shpejt dhe me efikasitet.
- Kur bëhen ndryshime në skedarët e projektit, ndërtuesi duhet të krijojë shpejt një shtresë të re duke aplikuar një patch në skedarët e ndryshuar.
- Nëse skedarë të caktuar kanë ndryshuar, atëherë është e nevojshme të rindërtoni fazën përkatëse të varur.
Sot koleksionisti ynë ka shumë mundësi të tjera, por këto kanë qenë dëshirat dhe nxitjet fillestare.
Në përgjithësi, pa u menduar dy herë, ne u armatosëm me gjuhën e programimit që përdornim (Shikoni më poshtë) dhe doli në rrugë për të zbatuar DSL e vet! Në përputhje me objektivat, synohej të përshkruhej në faza procesi i montimit dhe të përcaktohej varësia e këtyre fazave nga dosjet. Dhe e plotësoi atë koleksionisti i vet, e cila e ktheu DSL-në në qëllimin përfundimtar - një imazh të montuar. Në fillim DSL ishte në Ruby, por si — konfigurimi i koleksionistit tonë filloi të përshkruhet në një skedar YAML.
Konfigurimi i vjetër për dapp në Ruby
Konfigurimi aktual për werf në YAML
Me kalimin e kohës ndryshoi edhe mekanizmi i kolektorit. Në fillim, ne thjesht krijuam një Dockerfile të përkohshëm në fluturim nga konfigurimi ynë, dhe më pas filluam të ekzekutonim udhëzimet e montimit në kontejnerë të përkohshëm dhe të kryenim.
NB: Për momentin, koleksionisti ynë, i cili punon me konfigurimin e tij (në YAML) dhe quhet kolektor Stapel, tashmë është zhvilluar në një mjet mjaft të fuqishëm. Përshkrimi i detajuar i tij meriton artikuj të veçantë, dhe detajet themelore mund të gjenden në .
Ndërgjegjësimi për problemin
Por e kuptuam, dhe jo menjëherë, se kishim bërë një gabim: nuk e shtuam aftësinë ndërtoni imazhe përmes Dockerfile standarde dhe t'i integroni ato në të njëjtën infrastrukturë të menaxhimit të aplikacioneve nga skaji në fund (d.m.th. mbledhni imazhe, vendosni dhe pastroni ato). Si mund të jetë e mundur të krijohet një mjet për vendosje në Kubernetes dhe të mos zbatohet mbështetja e Dockerfile, d.m.th. mënyrë standarde për të përshkruar imazhet për shumicën e projekteve?..
Në vend që t'i përgjigjemi kësaj pyetjeje, ne ofrojmë një zgjidhje. Po sikur të keni tashmë një Dockerfile (ose një grup Dockerfiles) dhe dëshironi të përdorni werf?
NB: Nga rruga, pse do të dëshironit të përdorni edhe werf? Karakteristikat kryesore zbresin në sa vijon:
- cikli i plotë i menaxhimit të aplikacionit duke përfshirë pastrimin e imazhit;
- aftësia për të menaxhuar montimin e disa imazheve në të njëjtën kohë nga një konfigurim i vetëm;
- Procesi i përmirësuar i vendosjes për grafikët e përputhshëm me Helm.
Një listë më e plotë e tyre mund të gjendet në .
Pra, nëse më parë do të kishim ofruar të rishkruanim Dockerfile në konfigurimin tonë, tani me kënaqësi do të themi: "Lëreni të ndërtojë Dockerfiles tuaj!"
Si të përdorni?
Zbatimi i plotë i kësaj veçorie u shfaq në version . Parimi i përgjithshëm është i thjeshtë: përdoruesi specifikon shtegun për në një Dockerfile ekzistues në konfigurimin werf dhe më pas ekzekuton komandën werf build... dhe kjo është ajo - werf do të mbledhë imazhin. Le të shohim një shembull abstrakt.
Le të shpallim të radhës Dockerfile në rrënjën e projektit:
FROM ubuntu:18.04
RUN echo Building ...
Dhe ne do të shpallim werf.yamle cila e përdor këtë Dockerfile:
configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile
Të gjitha! Majtas vrapoj werf build:
Përveç kësaj, ju mund të deklaroni sa vijon werf.yaml për të ndërtuar disa imazhe nga Dockerfiles të ndryshëm në të njëjtën kohë:
configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend
Së fundi, ai gjithashtu mbështet kalimin e parametrave shtesë të ndërtimit, si p.sh --build-arg и --add-host - nëpërmjet konfigurimit të werf. Një përshkrim i plotë i konfigurimit të imazhit Dockerfile është i disponueshëm në .
Si funksionon kjo gjë?
Gjatë procesit të ndërtimit, cache standarde e shtresave lokale në Docker funksionon. Megjithatë, ajo që është e rëndësishme është edhe ajo integron konfigurimin e Dockerfile në infrastrukturën e tij. Çfarë do të thotë kjo?
- Çdo imazh i ndërtuar nga një Dockerfile përbëhet nga një fazë e quajtur
dockerfile(mund të lexoni më shumë se cilat faza janë në werf ). - Për skenën
dockerfilewerf llogarit një nënshkrim që varet nga përmbajtja e konfigurimit të Dockerfile. Kur ndryshon konfigurimi i Dockerfile, nënshkrimi i fazës ndryshondockerfiledhe werf fillon një rindërtim të kësaj faze me një konfigurim të ri Dockerfile. Nëse nënshkrimi nuk ndryshon, atëherë werf merr imazhin nga cache (më shumë detaje rreth përdorimit të nënshkrimeve në werf u përshkruan në ). - Më pas, imazhet e mbledhura mund të publikohen me komandën
werf publish(Osewerf build-and-publish) dhe përdorni atë për vendosjen në Kubernetes. Imazhet e publikuara në Regjistrin Docker do të pastrohen duke përdorur mjete standarde të pastrimit të werf, d.m.th. Imazhet e vjetra (më të vjetra se N ditë), imazhet e lidhura me degët inekzistente Git dhe politikat e tjera do të pastrohen automatikisht.
Më shumë detaje rreth pikave të përshkruara këtu mund të gjenden në dokumentacion:
- ;
- ;
- .
Shënime dhe masa paraprake
1. URL-ja e jashtme nuk mbështetet në ADD
Aktualisht nuk mbështetet përdorimi i një URL të jashtme në një direktivë ADD. Werf nuk do të fillojë një rindërtim kur burimi në URL-në e specifikuar ndryshon. Ne planifikojmë ta shtojmë këtë veçori së shpejti.
2. Nuk mund të shtoni .git në imazh
Në përgjithësi, duke shtuar një drejtori .git në imazh - një praktikë e keqe e keqe dhe ja pse:
- Nëse
.gitmbetet në imazhin përfundimtar, kjo shkel parimet : Meqenëse imazhi përfundimtar duhet të lidhet me një kryerje të vetme, nuk duhet të jetë e mundur të bëhetgit checkoutkryerje arbitrare. -
.gitrrit madhësinë e imazhit (depoja mund të jetë e madhe për shkak të faktit se skedarë të mëdhenj u shtuan një herë në të dhe më pas u fshinë). Madhësia e një peme pune të lidhur vetëm me një angazhim specifik nuk do të varet nga historia e operacioneve në Git. Në këtë rast, shtimi dhe heqja e mëvonshme.gitnga imazhi përfundimtar nuk do të funksionojë: imazhi do të marrë ende një shtresë shtesë - kështu funksionon Docker. - Docker mund të inicojë një rindërtim të panevojshëm, edhe nëse po ndërtohet i njëjti angazhim, por nga pemë të ndryshme pune. Për shembull, GitLab krijon direktori të veçanta të klonuara në
/home/gitlab-runner/builds/HASH/[0-N]/yourprojectkur aktivizohet montimi paralel. Rimontimi shtesë do të jetë për shkak të faktit se drejtoria.gitështë i ndryshëm në versione të ndryshme të klonuara të të njëjtit depo, edhe nëse është ndërtuar i njëjti commit.
Pika e fundit gjithashtu ka pasoja kur përdoret werf. Werf kërkon që cache e ndërtuar të jetë e pranishme gjatë ekzekutimit të disa komandave (p.sh. werf deploy). Kur ekzekutohen këto komanda, werf llogarit nënshkrimet e fazës për imazhet e specifikuara në werf.yaml, dhe ato duhet të jenë në memorien e montimit - përndryshe komanda nuk do të mund të vazhdojë të punojë. Nëse nënshkrimi skenik varet nga përmbajtja .git, atëherë marrim një cache që është e paqëndrueshme ndaj ndryshimeve në skedarë të parëndësishëm dhe werf nuk do të jetë në gjendje të falë një shkelje të tillë (për më shumë detaje, shih ).
Në përgjithësi, duke shtuar vetëm disa skedarë të nevojshëm përmes udhëzimeve ADD në çdo rast rrit efikasitetin dhe besueshmërinë e shkrimit Dockerfile, dhe gjithashtu përmirëson stabilitetin e cache-it të mbledhur për këtë Dockerfile, ndaj ndryshimeve të parëndësishme në Git.
Total
Rruga jonë fillestare për të shkruar ndërtuesin tonë për nevoja specifike ishte e vështirë, e sinqertë dhe e drejtpërdrejtë: në vend që të përdornim paterica në krye të Dockerfile standarde, ne shkruam zgjidhjen tonë me sintaksë të personalizuar. Dhe kjo kishte avantazhet e saj: koleksionisti Stapel e përballon në mënyrë të përsosur detyrën e tij.
Sidoqoftë, gjatë procesit të shkrimit të ndërtuesit tonë, ne humbëm nga sytë mbështetjen për Dockerfiles ekzistues. Ky defekt tani është rregulluar dhe në të ardhmen ne planifikojmë të zhvillojmë mbështetjen e Dockerfile së bashku me ndërtuesin tonë të personalizuar Stapel për ndërtimet e shpërndara dhe për ndërtimet që përdorin Kubernetes (d.m.th. ndërtimet në runner brenda Kubernetes, siç bëhet në kaniko).
Pra, nëse befas keni disa Dockerfiles të shtrirë përreth... përpiqem !
PS Lista e dokumentacionit mbi temën
- ;
- ;
- ;
- ;
- ;
- ;
- .
Lexoni gjithashtu në blogun tonë: "'.
Burimi: www.habr.com