Mas maganda ang huli kaysa sa wala. O kung paano kami halos gumawa ng isang malubhang pagkakamali sa pamamagitan ng hindi pagkakaroon ng suporta para sa mga regular na Dockerfiles upang bumuo ng mga larawan ng application.
Pag-uusapan natin β GitOps utility na sumasama sa anumang CI/CD system at nagbibigay ng pamamahala sa buong lifecycle ng application, na nagbibigay-daan sa:
- mangolekta at mag-publish ng mga larawan,
- mag-deploy ng mga application sa Kubernetes,
- tanggalin ang mga hindi nagamit na larawan gamit ang mga espesyal na patakaran.
Ang pilosopiya ng proyekto ay upang mangolekta ng mga tool na mababa ang antas sa isang solong pinag-isang sistema na nagbibigay sa mga inhinyero ng DevOps ng kontrol sa mga application. Kung maaari, ang mga kasalukuyang utility (tulad ng Helm at Docker) ay dapat gamitin. Kung walang solusyon sa isang problema, maaari tayong lumikha at suportahan ang lahat ng kailangan para dito.
Background: sarili mong kolektor ng imahe
Ito ang nangyari sa kolektor ng imahe sa werf: ang karaniwang Dockerfile ay hindi sapat para sa amin. Kung titingnan mo ang kasaysayan ng proyekto, ang problemang ito ay lumitaw na sa mga unang bersyon ng werf (pagkatapos ay ).
Habang lumilikha ng tool para sa pagbuo ng mga application sa mga imahe ng Docker, mabilis naming napagtanto na ang Dockerfile ay hindi angkop para sa amin para sa ilang partikular na gawain:
- Ang pangangailangang bumuo ng tipikal na maliliit na web application ayon sa sumusunod na karaniwang pamamaraan:
- i-install ang mga dependency ng application sa buong system,
- mag-install ng isang bundle ng application dependency library,
- mangolekta ng mga ari-arian,
- at higit sa lahat, i-update ang code sa larawan nang mabilis at mahusay.
- Kapag ang mga pagbabago ay ginawa sa mga file ng proyekto, ang tagabuo ay dapat na mabilis na lumikha ng isang bagong layer sa pamamagitan ng paglalapat ng isang patch sa mga binagong file.
- Kung nagbago ang ilang mga file, kinakailangan na muling itayo ang kaukulang yugto ng umaasa.
Ngayon ang aming kolektor ay may maraming iba pang mga posibilidad, ngunit ito ang mga unang hangarin at pag-uudyok.
Sa pangkalahatan, nang hindi nag-iisip nang dalawang beses, armado kami sa aming sarili ng programming language na ginamit namin (tingnan sa ibaba) at tumama sa kalsada upang ipatupad sariling DSL! Alinsunod sa mga layunin, nilayon itong ilarawan ang proseso ng pagpupulong sa mga yugto at matukoy ang mga dependency ng mga yugtong ito sa mga file. At pinupunan ito sariling kolektor, na naging pangwakas na layunin ang DSL - isang pinagsama-samang imahe. Sa una ang DSL ay nasa Ruby, ngunit bilang β nagsimulang ilarawan ang config ng aming collector sa isang YAML file.
Lumang config para sa dapp sa Ruby
Kasalukuyang config para sa werf sa YAML
Ang mekanismo ng kolektor ay nagbago din sa paglipas ng panahon. Sa una, nakabuo lang kami ng pansamantalang Dockerfile nang mabilis mula sa aming configuration, at pagkatapos ay nagsimula kaming magpatakbo ng mga tagubilin sa pagpupulong sa mga pansamantalang lalagyan at mag-commit.
NB: Sa ngayon, ang aming kolektor, na gumagana sa sarili nitong config (sa YAML) at tinatawag na Stapel collector, ay naging isang medyo makapangyarihang tool. Ang detalyadong paglalarawan nito ay nararapat sa hiwalay na mga artikulo, at ang mga pangunahing detalye ay matatagpuan sa .
Kamalayan sa problema
Ngunit napagtanto namin, at hindi kaagad, na nakagawa kami ng isang pagkakamali: hindi kami nagdagdag ng kakayahan bumuo ng mga imahe sa pamamagitan ng karaniwang Dockerfile at isama ang mga ito sa parehong end-to-end na imprastraktura sa pamamahala ng application (ibig sabihin, mangolekta ng mga larawan, i-deploy at linisin ang mga ito). Paano magiging posible na gumawa ng tool para sa pag-deploy sa Kubernetes at hindi ipatupad ang suporta sa Dockerfile, ibig sabihin. karaniwang paraan upang ilarawan ang mga larawan para sa karamihan ng mga proyekto?..
Sa halip na sagutin ang tanong na ito, nag-aalok kami ng solusyon. Paano kung mayroon ka nang Dockerfile (o isang set ng Dockerfiles) at gustong gumamit ng werf?
NB: Oo nga pala, bakit gusto mo pang gumamit ng werf? Ang mga pangunahing tampok ay bumaba sa mga sumusunod:
- buong ikot ng pamamahala ng aplikasyon kabilang ang paglilinis ng imahe;
- ang kakayahang pamahalaan ang pagpupulong ng ilang mga imahe nang sabay-sabay mula sa isang solong config;
- Pinahusay na proseso ng pag-deploy para sa mga chart na tugma sa Helm.
Ang isang mas kumpletong listahan ng mga ito ay matatagpuan sa .
Kaya, kung mas maaga ay nag-alok kami na muling isulat ang Dockerfile sa aming config, ngayon ay masayang sasabihin namin: "Hayaan ang werf na bumuo ng iyong Dockerfiles!"
Paano gamitin?
Ang buong pagpapatupad ng feature na ito ay lumabas sa release . Ang pangkalahatang prinsipyo ay simple: ang gumagamit ay tumutukoy sa landas sa isang umiiral na Dockerfile sa werf config, at pagkatapos ay pinapatakbo ang command werf build... at iyon lang - bubuoin ni werf ang imahe. Tingnan natin ang isang abstract na halimbawa.
I-announce natin ang susunod Dockerfile sa ugat ng proyekto:
FROM ubuntu:18.04
RUN echo Building ...
At iaanunsyo namin werf.yamlna gumagamit nito Dockerfile:
configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile
Lahat! Kaliwa tumakbo werf build:
Bilang karagdagan, maaari mong ipahayag ang mga sumusunod werf.yaml upang bumuo ng ilang mga imahe mula sa iba't ibang mga Dockerfile nang sabay-sabay:
configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend
Sa wakas, sinusuportahan din nito ang pagpasa ng mga karagdagang parameter ng build, gaya ng --build-arg ΠΈ --add-host - sa pamamagitan ng werf config. Ang kumpletong paglalarawan ng pagsasaayos ng imahe ng Dockerfile ay magagamit sa .
Paano ito gumagana?
Sa panahon ng proseso ng pagbuo, gumagana ang karaniwang cache ng mga lokal na layer sa Docker. Gayunpaman, ang mahalaga ay ang werf din isinasama ang configuration ng Dockerfile sa imprastraktura nito. Ano ang ibig sabihin nito?
- Ang bawat imahe na binuo mula sa isang Dockerfile ay binubuo ng isang yugto na tinatawag
dockerfile(maaari kang magbasa nang higit pa tungkol sa kung anong mga yugto ang nasa werf ). - Para sa entablado
dockerfileKinakalkula ng werf ang isang lagda na nakasalalay sa mga nilalaman ng pagsasaayos ng Dockerfile. Kapag nagbago ang configuration ng Dockerfile, nagbabago ang stage signaturedockerfileat sinisimulan ng werf ang muling pagtatayo ng yugtong ito gamit ang bagong Dockerfile config. Kung ang lagda ay hindi nagbabago, pagkatapos ay kukunin ng werf ang imahe mula sa cache (higit pang mga detalye tungkol sa paggamit ng mga lagda sa werf ay inilarawan sa ). - Susunod, ang mga nakolektang larawan ay maaaring mai-publish gamit ang utos
werf publish(Owerf build-and-publish) at gamitin ito para sa pag-deploy sa Kubernetes. Ang mga nai-publish na larawan sa Docker Registry ay lilinisin gamit ang karaniwang mga tool sa paglilinis ng werf, i.e. Awtomatikong malilinis ang mga lumang larawan (mas matanda sa N araw), mga larawang nauugnay sa mga hindi umiiral na sangay ng Git, at iba pang mga patakaran.
Higit pang mga detalye tungkol sa mga puntong inilarawan dito ay makikita sa dokumentasyon:
- ;
- ;
- .
Mga tala at pag-iingat
1. Ang panlabas na URL ay hindi suportado sa ADD
Sa kasalukuyan ay hindi sinusuportahan ang paggamit ng isang panlabas na URL sa isang direktiba ADD. Hindi magsisimula ang Werf ng muling pagbuo kapag nagbago ang mapagkukunan sa tinukoy na URL. Plano naming idagdag ang feature na ito sa lalong madaling panahon.
2. Hindi ka maaaring magdagdag ng .git sa larawan
Sa pangkalahatan, ang pagdaragdag ng isang direktoryo .git sa larawan - isang masamang gawi at narito kung bakit:
- Kung
.gitnananatili sa huling imahe, ito ay lumalabag sa mga prinsipyo : Dahil ang huling imahe ay dapat na naka-link sa isang solong commit, hindi ito dapat gawingit checkoutarbitrary commit. -
.gitpinapataas ang laki ng imahe (maaaring malaki ang repository dahil sa ang katunayan na ang malalaking file ay minsang idinagdag dito at pagkatapos ay tinanggal). Ang laki ng isang work-tree na nauugnay lang sa isang partikular na commit ay hindi nakadepende sa kasaysayan ng mga operasyon sa Git. Sa kasong ito, ang karagdagan at kasunod na pag-alis.gitmula sa huling imahe ay hindi gagana: ang imahe ay makakakuha pa rin ng isang karagdagang layer - ito ay kung paano gumagana ang Docker. - Maaaring simulan ng Docker ang isang hindi kinakailangang muling pagtatayo, kahit na ang parehong commit ay binuo, ngunit mula sa iba't ibang mga work-tree. Halimbawa, ang GitLab ay gumagawa ng hiwalay na mga naka-clone na direktoryo sa
/home/gitlab-runner/builds/HASH/[0-N]/yourprojectkapag pinagana ang parallel assembly. Ang dagdag na reassembly ay dahil sa ang katunayan na ang direktoryo.gitay naiiba sa iba't ibang mga cloned na bersyon ng parehong repository, kahit na ang parehong commit ay binuo.
Ang huling punto ay mayroon ding mga kahihinatnan kapag gumagamit ng werf. Kinakailangan ng Werf na naroroon ang built cache kapag nagpapatakbo ng ilang command (hal. werf deploy). Kapag tumakbo ang mga command na ito, kinakalkula ng werf ang mga stage signature para sa mga larawang tinukoy sa werf.yaml, at dapat na nasa cache ng pagpupulong ang mga ito - kung hindi, ang utos ay hindi makakapagpatuloy sa pagtatrabaho. Kung ang stage signature ay depende sa nilalaman .git, pagkatapos ay makakakuha tayo ng isang cache na hindi matatag sa mga pagbabago sa mga hindi nauugnay na mga file, at hindi mapapatawad ng werf ang gayong oversight (para sa higit pang mga detalye, tingnan ang ).
Sa pangkalahatan, pagdaragdag lamang ng ilang kinakailangang mga file sa pamamagitan ng mga tagubilin ADD sa anumang kaso pinatataas ang kahusayan at pagiging maaasahan ng nakasulat Dockerfile, at pinapabuti din ang katatagan ng cache na nakolekta para dito Dockerfile, sa mga hindi nauugnay na pagbabago sa Git.
Kabuuan
Ang aming paunang landas sa pagsulat ng aming sariling tagabuo para sa mga partikular na pangangailangan ay mahirap, tapat at prangka: sa halip na gumamit ng mga saklay sa itaas ng karaniwang Dockerfile, isinulat namin ang aming solusyon gamit ang custom na syntax. At ito ay may mga pakinabang nito: ang kolektor ng Stapel ay ganap na nakayanan ang gawain nito.
Gayunpaman, sa proseso ng pagsulat ng sarili naming tagabuo, nakalimutan namin ang suporta para sa mga umiiral na Dockerfiles. Ang flaw na ito ay naayos na ngayon, at sa hinaharap plano naming bumuo ng suporta sa Dockerfile kasama ang aming custom na Stapel builder para sa mga distributed build at para sa build gamit ang Kubernetes (ibig sabihin, build sa mga runner sa loob ng Kubernetes, tulad ng ginagawa sa kaniko).
Kaya, kung bigla kang magkaroon ng ilang Dockerfiles na nakahiga... subukan ito !
PS Listahan ng dokumentasyon sa paksa
- ;
- ;
- ;
- ;
- ;
- ;
- .
Basahin din sa aming blog: "'.
Pinagmulan: www.habr.com