Mas maayo nga ulahi kaysa dili. O kung giunsa kami hapit nakahimo usa ka seryoso nga sayup pinaagi sa walaβy suporta alang sa regular nga Dockerfiles aron makahimo mga imahe sa aplikasyon.
Kini mahitungod sa β Usa ka utility sa GitOps nga naghiusa sa bisan unsang sistema sa CI/CD ug nagdumala sa tibuuk nga siklo sa kinabuhi sa aplikasyon, nga gitugotan ka nga:
- pagkolekta ug pagmantala sa mga imahe,
- i-deploy ang mga aplikasyon sa Kubernetes,
- kuhaa ang wala magamit nga mga imahe gamit ang mga espesyal nga palisiya.
Ang pilosopiya sa proyekto mao ang pagkolekta sa mga gamit nga mubu nga lebel sa usa ka hiniusa nga sistema nga naghatag kontrol sa mga inhenyero sa DevOps sa mga aplikasyon. Kung mahimo, ang mga naglungtad nga mga utilities (sama sa Helm ug Docker) kinahanglan gamiton. Kung walaβy solusyon sa usa ka problema, mahimo naton ug mapadayon ang tanan nga kinahanglan alang niini.
Background: imong kaugalingon nga tigkolekta sa imahe
Mao kini ang nahitabo sa tigtukod sa imahe sa werf: kulang kami sa naandan nga Dockerfile. Kung dali ka nga mosulod sa kasaysayan sa proyekto, nan kini nga problema nagpakita na sa una nga mga bersyon sa werf (unya ).
Samtang nagmugna usa ka himan alang sa paghimo og mga aplikasyon sa mga imahe sa Docker, dali namon nahibal-an nga ang Dockerfile dili angay alang kanamo alang sa pipila ka piho nga mga buluhaton:
- Ang panginahanglan sa pagpundok sa kasagaran nga gagmay nga mga aplikasyon sa web sumala sa mosunod nga sumbanan nga pamaagi:
- i-install ang mga dependency sa tibuok sistema sa aplikasyon,
- i-install ang usa ka hugpong sa mga librarya sa dependency sa aplikasyon,
- pagkolekta sa mga kabtangan,
- ug labaw sa tanan, i-update ang code sa hulagway nga dali ug episyente.
- Kung ang mga pagbag-o gihimo sa mga file sa proyekto, ang magtutukod kinahanglan nga dali nga maghimo usa ka bag-ong layer pinaagi sa pag-patch sa nabag-o nga mga file.
- Kung ang pipila ka mga file nausab, nan ang katugbang nga nagsalig nga yugto kinahanglan nga tukuron pag-usab.
Karon, adunay daghang uban pang mga posibilidad sa among gripo, apan ang una nga mga tinguha ug pag-awhag mao ang mosunod.
Sa kinatibuk-an, sa walay paghunahuna sa makaduha, gisangkapan namo ang among kaugalingon sa programming language nga gigamit (Tan-awa sa ubos) ug naigo sa dalan - sa pagpatuman kaugalingon nga DSL! Nahiuyon sa mga buluhaton nga gitakda, gituyo aron ihulagway ang proseso sa pagtukod sa mga yugto ug mahibal-an ang mga dependency sa kini nga mga yugto sa mga file. Ug gidugangan kini kaugalingon nga gripo, nga nahimong DSL ngadto sa kataposang tumong - ang gitigom nga hulagway. Sa una ang DSL kay Ruby, pero as - ang config sa among kolektor nagsugod nga gihulagway sa YAML file.
Daang config para sa dapp sa Ruby
Aktuwal nga config para sa werf sa YAML
Ang mekanismo sa kolektor usab nausab sa paglabay sa panahon. Sa sinugdanan, naghimo lang kami og pipila ka temporaryo nga Dockerfile gikan sa among configuration on the fly, ug dayon nagsugod kami sa pagpadagan sa mga instruksiyon sa pagtukod sa temporaryo nga mga sudlanan ug paghimo sa usa ka pasalig.
NB: Sa pagkakaron, ang among magtutukod, nga nagtrabaho uban sa iyang kaugalingong config (sa YAML) ug gitawag nga Stapel builder, nahimo nang usa ka medyo gamhanan nga himan. Ang detalyado nga paghubit niini angayan sa bulag nga mga artikulo, ug ang panguna nga mga detalye makita sa .
Kahibalo sa problema
Apan among naamgohan, ug dili dayon, nga nakahimo kami og usa ka sayop: wala namo dugangi ang abilidad paghimo og mga imahe pinaagi sa usa ka standard nga Dockerfile ug i-integrate kini sa parehas nga end-to-end nga imprastraktura sa pagdumala sa aplikasyon (sama sa pagkolekta sa mga imahe, pag-deploy ug paglimpyo niini). Giunsa nimo paghimo ang usa ka himan sa pag-deploy sa Kubernetes ug dili ipatuman ang suporta sa Dockerfile, i.e. usa ka sumbanan nga paagi sa paghulagway sa mga imahe alang sa kadaghanan sa mga proyekto?..
Imbis nga tubagon ang ingon nga pangutana, among gitanyag ang solusyon niini. Unsa kaha kung ikaw adunay usa ka Dockerfile (o usa ka set sa Dockerfiles) ug gusto nimo gamiton ang werf?
NB: By the way, nganong gusto man nimo gamiton ang werf? Ang mga nag-unang bahin gibahin ngadto sa mosunod:
- bug-os nga siklo sa pagdumala sa aplikasyon lakip ang paglimpyo sa mga imahe;
- ang abilidad sa pagdumala sa asembliya sa daghang mga imahe sa usa ka higayon gikan sa usa ka config;
- gipaayo nga proseso sa pag-deploy alang sa mga tsart nga katugma sa Helm.
Ang mas kompleto nga listahan makita sa .
Mao nga, kung sa sayo pa among isugyot ang pagsulat pag-usab sa Dockerfile sa among config, karon nalipay kami sa pag-ingon: "Pasagdi ang werf nga tukuron ang imong Dockerfiles!"
Unsaon paggamit?
Ang bug-os nga pagpatuman niini nga bahin nagpakita sa pagpagawas . Ang kinatibuk-ang prinsipyo yano ra: ang user nagtino sa dalan sa usa ka kasamtangan nga Dockerfile sa werf config, ug dayon nagpadagan sa sugo werf build... ug mao kana - ang werf ang magtukod sa imahe. Atong tagdon ang usa ka abstract nga pananglitan.
Atong ipahibalo ang sunod Dockerfile sa ugat sa proyekto:
FROM ubuntu:18.04
RUN echo Building ...
Ug among ipahibalo werf.yamlnga naggamit niini Dockerfile:
configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile
Tanan! Sa wala dagan werf build:
Dugang pa, mahimo nimong ipahayag ang mosunod werf.yaml aron magtukod daghang mga imahe sa usa ka higayon gikan sa lainlaing mga Dockerfile:
configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend
Sa katapusan, ang pagpasa sa dugang nga mga parameter sa pagtukod gisuportahan usab - sama sa --build-arg ΠΈ --add-host - pinaagi sa werf config. Ang usa ka kompleto nga paghulagway sa configuration sa imahe sa Dockerfile anaa sa .
Unsang paagi kini sa trabaho?
Atol sa proseso sa pagtukod, ang standard cache sa mga lokal nga layer sa Docker naglihok. Apan, importante, werf usab nag-integrate sa configuration sa Dockerfile ngadto sa imprastraktura niini. Unsay buot ipasabot niini?
- Ang matag imahe nga gitukod gikan sa usa ka Dockerfile naglangkob sa usa ka yugto nga gitawag
dockerfile(dugang pa bahin sa kung unsang mga yugto ang naa sa werf, mabasa nimo ). - Alang sa entablado
dockerfileAng werf nagkalkula sa usa ka pirma nga nagdepende sa sulod sa configuration sa Dockerfile. Ang pagbag-o sa configuration sa Dockerfile nagbag-o sa pirma sa entabladodockerfileug ang werf magsugod sa pagtukod pag-usab sa kana nga yugto gamit ang bag-ong Dockerfile config. Kung ang pirma dili mausab, unya gikuha ni werf ang imahe gikan sa cache (dugang bahin sa paggamit sa mga pirma sa werf gihulagway sa ). - Dugang pa, ang mga nakolekta nga mga imahe mahimong ma-publish gamit ang mando
werf publish(owerf build-and-publish) ug gamiton kini sa pag-deploy sa Kubernetes. Ang gipatik nga mga imahe sa Docker Registry limpyohan gamit ang standard nga mga gamit sa paglimpyo sa werf, i.e. adunay usa ka awtomatik nga paglimpyo sa mga daan nga mga imahe (mas karaan sa N nga mga adlaw), mga hulagway nga may kalabutan sa wala'y mga sanga sa Git, ug uban pang mga palisiya.
Ang dugang nga mga detalye bahin sa mga punto nga gihulagway dinhi makita sa dokumentasyon:
- ;
- ;
- .
Mga Nota ug Pag-amping
1. Ang gawas nga URL sa ADD wala gisuportahan
Ang paggamit sa usa ka eksternal nga URL sa usa ka direktiba sa pagkakaron wala gisuportahan. ADD. Ang Werf dili mag-trigger sa usa ka pagtukod pag-usab kung ang usa ka kapanguhaan sa piho nga URL mausab. Kini nga bahin giplano nga idugang sa dili madugay.
2. Dili nimo madugang ang .git sa usa ka imahe
Sa kinatibuk-an, pagdugang usa ka direktoryo .git ngadto sa usa ka imahen usa ka mapintas nga daotan nga buhat, ug ania kung ngano:
- kon
.gitnagpabilin sa katapusang imahe, kini naglapas sa mga prinsipyo : tungod kay ang resulta nga hulagway kinahanglan nga nalambigit sa usa ka commit, kini dili mahimo nga mahimogit checkoutarbitraryong pasalig. -
.gitnagdugang sa gidak-on sa hulagway (mahimo nga dako ang repository tungod sa kamatuoran nga ang dagkong mga file gidugang niini ug dayon gitangtang). Ang gidak-on sa work-tree nga nalangkit lamang sa usa ka partikular nga commit dili magdepende sa kasaysayan sa mga operasyon sa Git. Sa kini nga kaso, ang pagdugang ug sa sunod nga pagtangtang.gitgikan sa katapusang imahe dili molihok: ang imahe makakuha gihapon usa ka dugang nga layer - kini kung giunsa ang pagtrabaho sa Docker. - Ang Docker mahimong mag-trigger sa usa ka dili kinahanglan nga pagtukod pag-usab bisan kung ang parehas nga pasalig gitukod gikan sa lainlaing mga punoan sa trabaho. Pananglitan, ang GitLab nagmugna og bulag nga mga cloned directory sa
/home/gitlab-runner/builds/HASH/[0-N]/yourprojectnga gipaandar ang parallel assembly. Ang usa ka dugang nga pagtukod pag-usab tungod sa kamatuoran nga ang direktoryo.gitlahi sa lainlaing mga cloned nga bersyon sa parehas nga repository, bisan kung ang parehas nga commit gitukod.
Ang katapusan nga punto usab adunay mga sangputanan kung gigamit ang werf. Ang Werf nagkinahanglan sa gitukod nga cache nga anaa sa diha nga nagpadagan sa pipila ka mga sugo (pananglitan, werf deploy). Atol sa pagpatuman sa maong mga sugo, ang werf nagkalkula sa mga pirma sa entablado alang sa mga hulagway nga gipiho sa werf.yaml, ug kinahanglan nga naa sila sa build cache, kung dili ang mando dili makapadayon. Kung ang pirma sa mga yugto nagdepende sa sulud .git, unya makakuha kami usa ka cache nga dili lig-on sa mga pagbag-o sa walaβy kalabotan nga mga file, ug ang werf dili makahimo sa pagpasaylo sa ingon nga usa ka paglapas (alang sa dugang nga mga detalye, tan-awa ).
Sa kinatibuk-an pagdugang lamang sa pipila ka gikinahanglan nga mga file pinaagi sa mga instruksyon ADD sa bisan unsa nga kaso nagdugang sa kahusayan ug kasaligan sa gisulat Dockerfile, ug gipauswag usab ang kalig-on sa cache nga nakolekta niini Dockerfile, sa wala'y kalabutan nga mga pagbag-o sa Git.
Ang resulta
Ang among una nga agianan sa pagsulat sa among kaugalingon nga tigtukod alang sa piho nga mga panginahanglan lisud, matinud-anon ug prangka: imbis nga mogamit mga crutches sa ibabaw sa standard nga Dockerfile, gisulat namon ang among kaugalingon nga solusyon nga adunay naandan nga syntax. Ug kini naghatag sa mga bentaha niini: ang Stapel-collector naghimo sa iyang trabaho nga hingpit.
Bisan pa, sa proseso sa pagsulat sa among kaugalingon nga magtutukod, nawad-an kami sa panan-aw sa suporta alang sa naa na nga Dockerfiles. Karon kini nga kakulangan naayo na, ug sa umaabot nagplano kami sa pagpalambo sa suporta sa Dockerfile uban sa among custom nga Stapel builder alang sa gipang-apod-apod nga mga pagtukod ug alang sa pagtukod gamit ang Kubernetes (ie pagtukod sa mga runner sa sulod sa Kubernetes, sama sa gibuhat sa kaniko).
Mao nga, kung kalit ka adunay usa ka magtiayon nga Dockerfiles nga naghigda ... pagsulay !
PS Listahan sa dokumentasyon sa hilisgutan
- ;
- ;
- ;
- ;
- ;
- ;
- .
Basaha usab sa among blog:".
Source: www.habr.com