Sasa unaweza kuunda picha za Docker kwenye werf kwa kutumia Dockerfile ya kawaida

Bora kuchelewa kuliko kamwe. Au jinsi tulivyokaribia kufanya makosa makubwa kwa kukosa msaada kwa Dockerfiles za kawaida kuunda picha za programu.

Tutazungumzia werf - Huduma ya GitOps ambayo inaunganishwa na mfumo wowote wa CI/CD na hutoa usimamizi wa mzunguko mzima wa maombi, kuruhusu:

• kukusanya na kuchapisha picha,
• kupeleka maombi katika Kubernetes,
• futa picha ambazo hazijatumiwa kwa kutumia sera maalum.

Falsafa ya mradi ni kukusanya zana za kiwango cha chini katika mfumo mmoja uliounganishwa ambao huwapa wahandisi wa DevOps udhibiti wa programu. Ikiwezekana, huduma zilizopo (kama Helm na Docker) zinapaswa kutumika. Ikiwa hakuna suluhisho la tatizo, tunaweza kuunda na kusaidia kila kitu muhimu kwa hili.

Usuli: kikusanya picha chako mwenyewe

Hii ndio ilifanyika na mkusanyaji wa picha kwenye werf: Dockerfile ya kawaida haikutosha kwetu. Ikiwa utaangalia haraka historia ya mradi huo, shida hii ilionekana tayari katika matoleo ya kwanza ya werf (basi bado. inayojulikana kama dapp).

Wakati wa kuunda zana ya kuunda programu kwenye picha za Docker, tuligundua haraka kuwa Dockerfile haikufaa kwetu kwa kazi fulani mahususi:

1. Haja ya kuunda programu ndogo za wavuti kulingana na mpango wa kawaida ufuatao:
   • sasisha utegemezi wa programu ya mfumo mzima,
   • sasisha rundo la maktaba za utegemezi wa programu,
   • kukusanya mali,
   • na muhimu zaidi, sasisha msimbo kwenye picha haraka na kwa ufanisi.
2. Wakati mabadiliko yanafanywa kwa faili za mradi, mjenzi lazima atengeneze safu mpya haraka kwa kutumia kiraka kwenye faili zilizobadilishwa.
3. Ikiwa faili fulani zimebadilika, basi ni muhimu kujenga upya hatua ya tegemezi inayolingana.

Leo mtoza wetu ana uwezekano mwingine mwingi, lakini haya yalikuwa matamanio na matakwa ya awali.

Kwa ujumla, bila kufikiria mara mbili, tulijizatiti na lugha ya programu tuliyotumia (tazama hapa chini) na kugonga barabara kutekeleza mwenyewe DSL! Kwa mujibu wa malengo, ilikusudiwa kuelezea mchakato wa mkusanyiko katika hatua na kuamua utegemezi wa hatua hizi kwenye faili. Na iliyokamilishwa yake mtoza mwenyewe, ambayo iligeuza DSL kuwa lengo la mwisho - picha iliyokusanyika. Mwanzoni DSL ilikuwa Ruby, lakini kama mpito kwenda Golang - usanidi wa mkusanyaji wetu ulianza kuelezewa katika faili ya YAML.

Usanidi wa zamani wa dapp katika Ruby

Usanidi wa sasa wa werf kwenye YAML

Utaratibu wa mtoza pia ulibadilika kwa wakati. Mwanzoni, tulitoa tu Dockerfile ya muda kwenye kuruka kutoka kwa usanidi wetu, na kisha tukaanza kutekeleza maagizo ya kusanyiko kwenye vyombo vya muda na kujitolea.

NB: Kwa sasa, mkusanyaji wetu, ambaye anafanya kazi na usanidi wake (katika YAML) na anaitwa mtozaji wa Stapel, tayari ameunda zana yenye nguvu. Maelezo yake ya kina yanastahili makala tofauti, na maelezo ya msingi yanaweza kupatikana ndani nyaraka.

Ufahamu wa tatizo

Lakini tuligundua, na sio mara moja, kwamba tumefanya kosa moja: hatukuongeza uwezo jenga picha kupitia Dockerfile ya kawaida na uzijumuishe katika miundombinu sawa ya usimamizi wa programu-msingi (yaani, kukusanya picha, kuzipeleka na kuzisafisha). Inawezekanaje kutengeneza zana ya kupelekwa katika Kubernetes na sio kutekeleza usaidizi wa Dockerfile, i.e. njia ya kawaida ya kuelezea picha kwa miradi mingi? ..

Badala ya kujibu swali hili, tunatoa suluhisho. Ikiwa tayari unayo Dockerfile (au seti ya Dockerfiles) na unataka kutumia werf?

NB: Kwa njia, kwa nini hata unataka kutumia werf? Vipengele kuu vinakuja kwa zifuatazo:

• mzunguko kamili wa usimamizi wa maombi ikiwa ni pamoja na kusafisha picha;
• uwezo wa kusimamia mkusanyiko wa picha kadhaa mara moja kutoka kwa usanidi mmoja;
• Mchakato wa uwekaji ulioboreshwa wa chati zinazooana na Helm.

Orodha kamili zaidi yao inaweza kupatikana ukurasa wa mradi.

Kwa hivyo, ikiwa mapema tungejitolea kuandika tena Dockerfile katika usanidi wetu, sasa tutasema kwa furaha: "Wacha tujenge Dockerfiles zako!"

Jinsi ya kutumia?

Utekelezaji kamili wa kipengele hiki ulionekana katika toleo werf v1.0.3-beta.1. Kanuni ya jumla ni rahisi: mtumiaji anabainisha njia ya Dockerfile iliyopo kwenye usanidi wa werf, kisha anaendesha amri. werf build... na ndivyo hivyo - werf itakusanya picha. Hebu tuangalie mfano wa kufikirika.

Hebu tangaza ijayo Dockerfile katika mzizi wa mradi:

FROM ubuntu:18.04
RUN echo Building ...

Na tutatangaza werf.yamlambayo hutumia hii Dockerfile:

configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile

Wote! Kushoto kukimbia werf build:

Kwa kuongeza, unaweza kutangaza zifuatazo werf.yaml kuunda picha kadhaa kutoka kwa Dockerfiles tofauti mara moja:

configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend

Mwishowe, inasaidia pia kupitisha vigezo vya ziada vya ujenzi, kama vile --build-arg и --add-host - kupitia usanidi wa werf. Maelezo kamili ya usanidi wa picha ya Dockerfile yanapatikana ukurasa wa nyaraka.

Jinsi gani kazi?

Wakati wa mchakato wa ujenzi, kashe ya kawaida ya tabaka za ndani katika kazi za Docker. Walakini, cha muhimu ni kwamba werf pia inaunganisha usanidi wa Dockerfile katika miundombinu yake. Hii ina maana gani?

1. Kila picha iliyojengwa kutoka kwa Dockerfile ina hatua moja inayoitwa dockerfile (unaweza kusoma zaidi juu ya hatua gani ziko kwenye werf hapa).
2. Kwa jukwaa dockerfile werf huhesabu saini ambayo inategemea yaliyomo kwenye usanidi wa Dockerfile. Wakati usanidi wa Dockerfile unabadilika, saini ya hatua inabadilika dockerfile na werf huanzisha uundaji upya wa hatua hii na usanidi mpya wa Dockerfile. Ikiwa saini haibadilika, basi werf inachukua picha kutoka kwa kache (maelezo zaidi juu ya utumiaji wa saini katika werf yalielezewa katika ripoti hii).
3. Ifuatayo, picha zilizokusanywa zinaweza kuchapishwa kwa amri werf publish (Au werf build-and-publish) na uitumie kupelekwa Kubernetes. Picha zilizochapishwa kwenye Usajili wa Docker zitasafishwa kwa kutumia zana za kawaida za kusafisha werf, i.e. Picha za zamani (zaidi ya siku N), picha zinazohusiana na matawi ya Git ambayo hayapo, na sera zingine zitasafishwa kiotomatiki.

Maelezo zaidi juu ya vidokezo vilivyoelezewa hapa yanaweza kupatikana katika nyaraka:

• Mchakato wa uchapishaji;
• Kuunganishwa na mchakato wa kusambaza Kubernetes;
• Mchakato wa kusafisha.

Vidokezo na tahadhari

1. URL ya Nje haitumiki katika ADD

Kwa sasa haitumiki kutumia URL ya nje katika maagizo ADD. Werf haitaanzisha uundaji upya wakati rasilimali kwenye URL iliyobainishwa inabadilika. Tunapanga kuongeza kipengele hiki hivi karibuni.

2. Huwezi kuongeza .git kwenye picha

Kwa ujumla, kuongeza saraka .git kwenye picha - mazoea mabaya na hii ndio sababu:

1. Kama .git inabaki katika picha ya mwisho, hii inakiuka kanuni 12 kipengele programu: Kwa kuwa picha ya mwisho lazima iunganishwe na ahadi moja, haipaswi kuwa rahisi kufanya git checkout ahadi ya kiholela.
2. .git huongeza saizi ya picha (hazina inaweza kuwa kubwa kwa sababu ya ukweli kwamba faili kubwa ziliongezwa kwake na kisha kufutwa). Saizi ya mti-kazi unaohusishwa tu na ahadi maalum haitategemea historia ya utendakazi katika Git. Katika kesi hii, kuongeza na kuondolewa kwa baadae .git kutoka kwa picha ya mwisho haitafanya kazi: picha bado itapata safu ya ziada - hii ndio jinsi Docker inavyofanya kazi.
3. Docker inaweza kuanzisha ujenzi tena usio wa lazima, hata ikiwa ahadi hiyo hiyo inajengwa, lakini kutoka kwa miti tofauti ya kazi. Kwa mfano, GitLab huunda saraka tofauti zilizoundwa ndani /home/gitlab-runner/builds/HASH/[0-N]/yourproject wakati mkusanyiko sambamba umewezeshwa. Upyaji wa ziada utakuwa kutokana na ukweli kwamba saraka .git ni tofauti katika matoleo tofauti yaliyoundwa ya hazina moja, hata kama ahadi hiyo hiyo imejengwa.

Hoja ya mwisho pia ina matokeo wakati wa kutumia werf. Werf inahitaji kache iliyojengwa iwepo wakati wa kutekeleza amri kadhaa (k.m. werf deploy) Wakati amri hizi zinaendeshwa, werf hukokotoa saini za hatua kwa picha zilizobainishwa werf.yaml, na lazima ziwe kwenye kashe ya kusanyiko - vinginevyo amri haitaweza kuendelea kufanya kazi. Ikiwa saini ya hatua inategemea yaliyomo .git, basi tunapata kashe ambayo haina msimamo kwa mabadiliko katika faili zisizo na maana, na werf haitaweza kusamehe uangalizi kama huo (kwa maelezo zaidi, ona nyaraka).

Kwa ujumla kuongeza faili fulani tu muhimu kupitia maelekezo ADD kwa hali yoyote huongeza ufanisi na uaminifu wa maandishi Dockerfile, na pia inaboresha utulivu wa cache iliyokusanywa kwa hili Dockerfile, kwa mabadiliko yasiyofaa katika Git.

Jumla ya

Njia yetu ya awali ya kuandika mjenzi wetu kwa mahitaji maalum ilikuwa ngumu, ya uaminifu na ya moja kwa moja: badala ya kutumia mikongojo juu ya Dockerfile ya kawaida, tuliandika suluhisho letu kwa syntax maalum. Na hii ilikuwa na faida zake: mtozaji wa Stapel anashughulikia kazi yake kikamilifu.

Walakini, katika mchakato wa kuandika mjenzi wetu, tulipoteza mtazamo wa usaidizi wa Dockerfiles zilizopo. Hitilafu hii sasa imerekebishwa, na katika siku zijazo tunapanga kuendeleza usaidizi wa Dockerfile pamoja na kijenzi chetu maalum cha Stapel kwa miundo iliyosambazwa na kwa miundo inayotumia Kubernetes (yaani, inajengwa juu ya wakimbiaji ndani ya Kubernetes, kama inavyofanywa katika kaniko).

Kwa hivyo, ikiwa ghafla una Dockerfiles kadhaa zimelala karibu ... jaribu werf!

PS Orodha ya nyaraka juu ya mada

• Miongozo ya kuanza haraka;
• usanidi wa wajenzi wa dockerfile;
• Hatua kifaa katika werf;
• Mchakato wa kuchapisha picha;
• Kuunganishwa na mchakato wa kusambaza Kubernetes;
• Mchakato wa kusafisha;
• Mjenzi wa Stapel kama mbadala wa Dockerfile.

Soma pia katika blogi yetu: "werf - zana yetu ya CI/CD katika Kubernetes (hakiki na ripoti ya video)'.

Chanzo: mapenzi.com