Hobe berandu inoiz baino. Edo nola ia akats larri bat egin genuen aplikazioen irudiak eraikitzeko Dockerfiles ohiko laguntzarik ez izateagatik.
buruz hitz egingo dugu β GitOps utilitatea, edozein CI/CD sistemarekin integratzen duena eta aplikazioaren bizi-ziklo osoa kudeatzen duena, aukera ematen duena:
- irudiak bildu eta argitaratu,
- inplementatu aplikazioak Kubernetes-en,
- ezabatu erabili gabeko irudiak politika bereziak erabiliz.
Proiektuaren filosofia maila baxuko tresnak biltzea da, DevOps ingeniariei aplikazioen gaineko kontrola ematen dien sistema bateratu bakar batean biltzea. Ahal izanez gero, lehendik dauden utilitateak (Helm eta Docker bezalakoak) erabili behar dira. Arazo bati irtenbiderik ez badago, horretarako beharrezkoa den guztia sortu eta lagundu dezakegu.
Aurrekariak: zure irudi-biltzailea
Hau da werf-eko irudi biltzailearekin gertatu zena: ohiko Dockerfile ez zitzaigun nahikoa izan. Proiektuaren historiari begirada azkar bat ematen badiozu, arazo hau jada agertu zen werf-en lehen bertsioetan (orduan oraindik ).
Docker irudietan aplikazioak sortzeko tresna bat sortzen ari ginenean, azkar konturatu ginen Dockerfile ez zela guretzat egokia zeregin zehatz batzuetarako:
- Web-aplikazio txiki tipikoak eraikitzeko beharra, eskema estandar honen arabera:
- instalatu sistema osorako aplikazioen mendekotasunak,
- instalatu aplikazioen mendekotasun liburutegi sorta bat,
- aktiboak biltzea,
- eta garrantzitsuena, irudiko kodea azkar eta eraginkortasunez eguneratzea.
- Proiektu-fitxategietan aldaketak egiten direnean, eraikitzaileak azkar sortu behar du geruza berri bat aldatutako fitxategiei adabaki bat aplikatuz.
- Fitxategi batzuk aldatu badira, beharrezkoa da dagokion menpeko etapa berreraikitzea.
Gaur egun gure bildumagileak beste aukera asko ditu, baina hauek ziren hasierako nahiak eta gogoak.
Orokorrean, birritan pentsatu gabe, erabiltzen genuen programazio-lengoaiaz armatu ginen (ikus behean) eta ezartzeko bidea hartu DSL propioa! Helburuekin bat etorriz, muntaketa-prozesua faseka deskribatu eta fase horiek fitxategiekiko duten mendekotasuna zehaztu nahi izan da. Eta osatu bildumagile propioa, DSL azken helburua bihurtu zuen - irudi muntatu bat. Hasieran DSL Ruby-n zegoen, baina bezala β gure biltzailearen konfigurazioa YAML fitxategi batean deskribatzen hasi zen.
Ruby-n dapp-erako konfigurazio zaharra
YAML-n werf-erako uneko konfigurazioa
Kolektorearen mekanismoa ere aldatu egin zen denborarekin. Hasieran, behin-behineko Dockerfile bat sortu genuen gure konfiguraziotik hegan, eta gero muntatzeko argibideak aldi baterako edukiontzietan exekutatzen eta konprometitzen hasi ginen.
NB: Momentuz, gure biltzailea, bere konfigurazioarekin lan egiten duena (YAML-n) eta Stapel biltzailea deitzen dena, nahiko tresna indartsu bihurtu da jada. Bere deskribapen zehatzak artikulu bereiziak merezi ditu, eta oinarrizko xehetasunak hemen aurki daitezke .
Arazoaren kontzientzia
Baina konturatu ginen, eta ez berehala, akats bat egin genuela: ez genuen gaitasuna gehitu sortu irudiak Dockerfile estandarraren bidez eta amaierako aplikazioen kudeaketa-azpiegitura berean integratzea (hau da, irudiak bildu, zabaldu eta garbitu). Nola liteke Kubernetes-en hedatzeko tresna bat egitea eta Dockerfile euskarria ez ezartzea, hau da. Proiektu gehienetarako irudiak deskribatzeko modu estandarra?...
Galdera honi erantzun beharrean, irtenbide bat eskaintzen dugu. Zer gertatzen da dagoeneko Dockerfile bat (edo Dockerfiles multzo bat) eta werf erabili nahi baduzu?
NB: Bide batez, zergatik erabili nahi zenuke werf? Ezaugarri nagusiak honako hauek dira:
- aplikazioen kudeaketa-ziklo osoa irudien garbiketa barne;
- konfigurazio bakar batetik hainbat irudiren muntaketa aldi berean kudeatzeko gaitasuna;
- Helm-ekin bateragarriak diren diagramen inplementazio-prozesua hobetu da.
Horien zerrenda osatuagoa helbidean aurki daiteke .
Beraz, lehenago Dockerfile gure konfigurazioan berridaztea eskaini izan bagenu, orain pozik esango dugu: "Utzi werfek zure Dockerfiles eraikitzen!"
Nola erabili?
Ezaugarri honen inplementazio osoa oharra agertu zen . Printzipio orokorra sinplea da: erabiltzaileak lehendik dagoen Dockerfilerako bidea zehazten du werf konfigurazioan, eta gero komandoa exekutatzen du. werf build... eta kitto - werfek irudia muntatuko du. Ikus dezagun adibide abstraktu bat.
Iragar dezagun hurrengoa Dockerfile proiektuaren erroan:
FROM ubuntu:18.04
RUN echo Building ...
Eta iragarriko dugu werf.yamlhau erabiltzen duena Dockerfile:
configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile
Denak! Ezkerra Korrika egin werf build:
Horrez gain, honako hau deklaratu dezakezu werf.yaml Dockerfiles ezberdinetako hainbat irudi aldi berean eraikitzeko:
configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend
Azkenik, eraikuntza-parametro osagarriak pasatzea ere onartzen du, adibidez --build-arg ΠΈ --add-host - werf konfigurazioaren bidez. Dockerfile irudiaren konfigurazioaren deskribapen osoa eskuragarri dago hemen .
Nola funtzionatzen du?
Eraikitze prozesuan, Docker-eko geruzen lokalen cache estandarrak funtzionatzen du. Hala ere, garrantzitsua da werf hori ere Dockerfile konfigurazioa bere azpiegituran integratzen du. Zer esan nahi du honek?
- Dockerfile batetik eraikitako irudi bakoitza deitzen den etapa batek osatzen du
dockerfile(Gehiago irakurri dezakezu werf-en zer etapa dauden ). - Etaparako
dockerfilewerf-ek Dockerfile konfigurazioaren edukiaren araberako sinadura bat kalkulatzen du. Dockerfile konfigurazioa aldatzen denean, etapako sinadura aldatzen dadockerfileeta werf-ek etapa honen berreraikitze bat hasten du Dockerfile konfigurazio berri batekin. Sinadura aldatzen ez bada, werf-ek irudia cachetik hartuko du (Werf-en sinadurak erabiltzeari buruzko xehetasun gehiago azaldu ziren ). - Ondoren, bildutako irudiak komandoarekin argitaratu daitezke
werf publish(Edowerf build-and-publish) eta erabili Kubernetes-en inplementatzeko. Docker Erregistroan argitaratutako irudiak werf garbiketa tresna estandarrak erabiliz garbituko dira, hau da. Irudi zaharrak (N egun baino zaharragoak), existitzen ez diren Git adarrei lotutako irudiak eta bestelako gidalerroak automatikoki garbituko dira.
Hemen deskribatutako puntuei buruzko xehetasun gehiago dokumentazioan aurki daitezke:
- ;
- ;
- .
Oharrak eta neurriak
1. Kanpoko URLa ez da onartzen ADD-n
Une honetan ez da onartzen kanpoko URL bat zuzentarau batean erabiltzea ADD. Werfek ez du berreraikitzerik hasiko zehaztutako URLko baliabidea aldatzen denean. Ezaugarri hau laster gehitzeko asmoa dugu.
2. Ezin diozu .git gehitu irudiari
Oro har, direktorio bat gehitzea .git irudian - praktika txarra gaiztoa eta hona hemen zergatik:
- Bada
.gitazken irudian geratzen da, honek printzipioak urratzen ditu : Azken irudia konpromiso bakarrarekin lotu behar denez, ezin da egingit checkoutkonpromiso arbitrarioa. -
.gitirudiaren tamaina handitzen du (biltegia handia izan daiteke, behin fitxategi handiak gehitu eta gero ezabatzen zirelako). Konpromiso zehatz batekin soilik lotutako lan-zuhaitz baten tamaina ez da Git-eko eragiketen historiaren araberakoa izango. Kasu honetan, gehitzea eta ondorengo kentzea.gitazken iruditik ez du funtzionatuko: irudiak geruza gehigarri bat eskuratuko du oraindik - horrela funtzionatzen du Docker-ek. - Docker-ek alferrikako berreraikitze bat abiarazi dezake, konpromezu bera eraikitzen ari bada ere, baina lan-zuhaitz desberdinetatik. Adibidez, GitLab-ek klonatutako direktorio bereiziak sortzen ditu
/home/gitlab-runner/builds/HASH/[0-N]/yourprojectmuntaketa paraleloa gaituta dagoenean. Aparteko muntaketa direktorioa delako izango da.gitdesberdina da biltegi beraren klonatutako bertsio desberdinetan, nahiz eta konpromezu bera eraiki.
Azken puntuak ere ondorioak ditu werf erabiltzean. Werf-ek eraikitako cachea egotea eskatzen du komando batzuk exekutatzen direnean (adibidez. werf deploy). Komando hauek exekutatzen direnean, werf-ek atalean zehaztutako irudien etapa sinadurak kalkulatzen ditu werf.yaml, eta muntaketa-cachean egon behar dute; bestela, komandoak ezin izango du lanean jarraitu. Etapa sinadura edukiaren araberakoa bada .git, orduan garrantzirik gabeko fitxategietan aldaketekiko ezegonkorra den cache bat lortzen dugu, eta werf-ek ezin izango du horrelako gainbegiratu bat barkatu (xehetasun gehiagorako, ikus ).
Oro har, beharrezko fitxategi batzuk bakarrik gehituz argibideen bidez ADD nolanahi ere idatziaren eraginkortasuna eta fidagarritasuna areagotzen du Dockerfile, eta horretarako bildutako cachearen egonkortasuna ere hobetzen du Dockerfile, Git-en garrantzirik gabeko aldaketei.
Guztira
Behar zehatzetarako gure eraikitzailea idazteko hasierako bidea gogorra, zintzoa eta zuzena izan zen: Dockerfile estandarraren gainean makuluak erabili beharrean, sintaxi pertsonalizatuarekin idatzi genuen gure irtenbidea. Eta horrek bere abantailak zituen: Stapel bildumagileak ezin hobeto egiten dio bere zereginari.
Hala ere, gure eraikitzailea idazteko prozesuan, lehendik zeuden Dockerfiles-en euskarria galdu genuen. Akats hau konpondu da, eta etorkizunean Dockerfile euskarria garatzeko asmoa dugu gure Stapel eraikitzaile pertsonalizatuarekin batera muntaketa banaturako eta Kubernetes erabiliz muntatzeko (hau da, Kubernetes barruko korrikalarietan muntatzea, kaniko-n egiten den bezala).
Beraz, bat-batean Dockerfile pare bat etzanda badituzu... saiatu !
PS Gaiari buruzko dokumentazioaren zerrenda
- ;
- ;
- ;
- ;
- ;
- ;
- .
Irakurri ere gure blogean: β'.
Iturria: www.habr.com