Gwell hwyr na byth. Neu sut y bu bron i ni wneud camgymeriad difrifol trwy beidio â chael cefnogaeth i Dockerfiles rheolaidd i adeiladu delweddau cymhwysiad.
Bydd yn ymwneud - Cyfleustodau GitOps sy'n integreiddio ag unrhyw system CI / CD ac sy'n darparu rheolaeth o gylch bywyd cyfan y cais, sy'n eich galluogi i:
- casglu a chyhoeddi delweddau,
- defnyddio ceisiadau i Kubernetes,
- dileu delweddau nas defnyddiwyd gan ddefnyddio polisïau arbennig.
Athroniaeth y prosiect yw casglu offer lefel isel i mewn i un system unedig sy'n rhoi rheolaeth i beirianwyr DevOps dros gymwysiadau. Os yn bosibl, dylid defnyddio cyfleustodau presennol (fel Helm and Docker). Os nad oes ateb i ryw broblem, gallwn greu a chynnal popeth sy'n angenrheidiol ar gyfer hyn.
Cefndir: eich casglwr delweddau eich hun
Dyma beth ddigwyddodd gyda'r adeiladwr delweddau yn werff: nid oedd gennym y Dockerfile arferol. Os byddwch chi'n plymio'n fyr i hanes y prosiect, yna daeth y broblem hon i'r amlwg eisoes yn y fersiynau cyntaf o werff (yna ).
Wrth greu teclyn ar gyfer adeiladu cymwysiadau i ddelweddau Docker, sylweddolom yn gyflym nad oedd y Dockerfile yn addas i ni ar gyfer rhai tasgau penodol iawn:
- Yr angen i gydosod cymwysiadau gwe bach nodweddiadol yn unol â'r cynllun safonol canlynol:
- gosod dibyniaethau system gyfan y rhaglen,
- gosod bwndel o lyfrgelloedd dibyniaeth ar gymwysiadau,
- casglu asedau,
- ac yn bwysicaf oll, diweddarwch y cod yn y ddelwedd yn gyflym ac yn effeithlon.
- Pan wneir newidiadau i ffeiliau prosiect, rhaid i'r adeiladwr greu haen newydd yn gyflym trwy glytio'r ffeiliau sydd wedi'u newid.
- Os yw rhai ffeiliau wedi newid, yna rhaid ailadeiladu'r cam dibynnol cyfatebol.
Heddiw, mae yna lawer o bosibiliadau eraill yn ein faucet, ond roedd y dyheadau a'r anogaethau cychwynnol fel a ganlyn.
Yn gyffredinol, heb feddwl ddwywaith, gwnaethom arfogi ein hunain â'r iaith raglennu a ddefnyddiwyd (gweler isod) a tharo ar y ffordd - i weithredu hun DSL! Yn unol â'r tasgau a osodwyd, y bwriad oedd disgrifio'r broses adeiladu fesul cam a phenderfynu ar ddibyniaethau'r camau hyn ar ffeiliau. Ac yn ei ategu faucet hun, a drodd DSL yn nod terfynol - y ddelwedd ymgynnull. Ar y dechrau roedd DSL yn Ruby, ond fel - dechreuwyd disgrifio ffurfwedd ein casglwr yn y ffeil YAML.
Hen config ar gyfer dapp yn Ruby
Cyfluniad gwirioneddol ar gyfer werf ar YAML
Mae mecanwaith y casglwr hefyd wedi newid dros amser. Ar y dechrau, yn syml iawn, fe wnaethom gynhyrchu rhywfaint o Dockerfile dros dro o'n cyfluniad ar y hedfan, ac yna fe ddechreuon ni redeg cyfarwyddiadau adeiladu mewn cynwysyddion dros dro a gwneud ymrwymiad.
NB: Ar hyn o bryd, mae ein hadeiladwr, sy'n gweithio gyda'i ffurfwedd ei hun (yn YAML) ac a elwir yn adeiladwr Stapel, eisoes wedi datblygu i fod yn offeryn eithaf pwerus. Mae ei ddisgrifiad manwl yn haeddu erthyglau ar wahân, a gellir dod o hyd i'r prif fanylion yn .
Ymwybyddiaeth o'r broblem
Ond sylweddolasom, ac nid ar unwaith, ein bod wedi gwneud un camgymeriad: ni wnaethom ychwanegu'r gallu adeiladu delweddau trwy Dockerfile safonol a’u hintegreiddio i’r un seilwaith rheoli cymwysiadau o un pen i’r llall (h.y. casglu delweddau, eu defnyddio a’u glanhau). Sut allech chi wneud teclyn lleoli yn Kubernetes a pheidio â gweithredu cefnogaeth Dockerfile, h.y. ffordd safonol o ddisgrifio delweddau ar gyfer y rhan fwyaf o brosiectau?..
Yn lle ateb cwestiwn o'r fath, rydym yn cynnig ei ateb. Beth os oes gennych Dockerfile eisoes (neu set o Dockerfiles) ac eisiau defnyddio werff?
NB: Gyda llaw, pam fyddech chi hyd yn oed eisiau defnyddio werff? Mae'r prif nodweddion yn deillio o'r canlynol:
- cylch rheoli cais llawn gan gynnwys glanhau delweddau;
- y gallu i reoli cydosod nifer o ddelweddau ar unwaith o un ffurfwedd;
- gwell proses ddefnyddio ar gyfer siartiau sy'n gydnaws â Helm.
Ceir rhestr fwy cyflawn yn .
Felly, pe baem yn gynharach yn awgrymu ailysgrifennu'r Dockerfile i'n ffurfwedd, nawr rydym yn hapus i ddweud: “Gadewch i werf adeiladu eich Dockerfiles!”
Sut i ddefnyddio?
Ymddangosodd gweithrediad llawn y nodwedd hon yn y datganiad . Mae'r egwyddor gyffredinol yn syml: mae'r defnyddiwr yn pennu'r llwybr i Dockerfile presennol yn y ffurfwedd werf, ac yna'n rhedeg y gorchymyn werf build... a dyna ni - werf fydd yn adeiladu'r ddelwedd. Gadewch i ni ystyried enghraifft haniaethol.
Gadewch i ni gyhoeddi'r nesaf Dockerfile wrth wraidd y prosiect:
FROM ubuntu:18.04
RUN echo Building ...
A byddwn yn cyhoeddi werf.yamlsy'n defnyddio hwn Dockerfile:
configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile
I gyd! Chwith rhedeg werf build:
Yn ogystal, gallwch ddatgan y canlynol werf.yaml i adeiladu sawl delwedd ar unwaith o wahanol Dockerfiles:
configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend
Yn olaf, mae pasio paramedrau adeiladu ychwanegol hefyd yn cael ei gefnogi - megis --build-arg и --add-host - trwy'r ffurfwedd werf. Mae disgrifiad cyflawn o ffurfweddiad delwedd Dockerfile ar gael yn .
Sut mae'n gweithio?
Yn ystod y broses adeiladu, mae'r storfa safonol o haenau lleol yn swyddogaethau Docker. Fodd bynnag, yn bwysig, werf hefyd yn integreiddio cyfluniad Dockerfile i'w seilwaith. Beth mae hyn yn ei olygu?
- Mae pob delwedd a adeiladwyd o Dockerfile yn cynnwys un cam o'r enw
dockerfile(mwy am ba gamau sydd yn weff, gallwch ddarllen ). - Ar gyfer llwyfan
dockerfileMae werf yn cyfrifo llofnod sy'n dibynnu ar gynnwys ffurfweddiad Dockerfile. Mae newid cyfluniad Dockerfile yn newid llofnod y llwyfandockerfilea bydd werf yn dechrau ailadeiladu'r cam hwnnw gyda'r ffurfwedd Dockerfile newydd. Os nad yw'r llofnod yn newid, yna mae werf yn cymryd y ddelwedd o'r storfa (disgrifiwyd mwy am y defnydd o lofnodion yn werf yn ). - Ymhellach, gellir cyhoeddi'r delweddau a gasglwyd gyda'r gorchymyn
werf publish(Neuwerf build-and-publish) a'i ddefnyddio i'w ddefnyddio i Kubernetes. Bydd delweddau cyhoeddedig yng Nghofrestrfa’r Docwyr yn cael eu glanhau gydag offer glanhau wern safonol, h.y. bydd hen ddelweddau (hŷn na diwrnod N), delweddau sy'n gysylltiedig â changhennau Git nad ydynt yn bodoli yn cael eu glanhau'n awtomatig, a pholisïau eraill.
Ceir rhagor o fanylion am y pwyntiau a ddisgrifir yma yn y ddogfennaeth:
- ;
- ;
- .
Nodiadau a Rhagofalon
1. Ni chefnogir URL allanol yn ADD
Ni chefnogir defnyddio URL allanol mewn cyfarwyddeb ar hyn o bryd. ADD. Ni fydd Werf yn sbarduno ailadeiladu pan fydd adnodd yn yr URL penodedig yn newid. Bwriedir ychwanegu'r nodwedd hon yn fuan.
2. Ni allwch ychwanegu .git at ddelwedd
A siarad yn gyffredinol, ychwanegu cyfeiriadur .git i mewn i ddelwedd yn arfer drwg dieflig, a dyma pam:
- Os
.gityn aros yn y ddelwedd derfynol, mae hyn yn torri'r egwyddorion : gan fod yn rhaid i'r ddelwedd sy'n deillio o hyn fod yn gysylltiedig ag un ymrwymiad, ni ddylai fod yn bosibl ei wneudgit checkoutymrwymiad mympwyol. -
.gityn cynyddu maint y ddelwedd (gallai'r ystorfa fod yn fawr oherwydd bod ffeiliau mawr unwaith wedi'u hychwanegu ati ac yna eu dileu). Ni fydd maint y goeden waith sy'n gysylltiedig ag ymrwymiad penodol yn unig yn dibynnu ar hanes gweithrediadau yn Git. Yn yr achos hwn, ychwanegu a thynnu dilynol.gitni fydd y ddelwedd derfynol yn gweithio: bydd y ddelwedd yn dal i gaffael haen ychwanegol - dyma sut mae Docker yn gweithio. - Gall tociwr ysgogi ailadeiladu diangen hyd yn oed os yw'r un ymrwymiad yn cael ei adeiladu o wahanol goed gwaith. Er enghraifft, mae GitLab yn creu cyfeiriaduron wedi'u clonio ar wahân yn
/home/gitlab-runner/builds/HASH/[0-N]/yourprojectgyda chydosod cyfochrog wedi'i alluogi. Bydd ailadeiladu ychwanegol oherwydd y ffaith bod y cyfeiriadur.gityn wahanol mewn gwahanol fersiynau wedi'u clonio o'r un gadwrfa, hyd yn oed os yw'r un ymrwymiad wedi'i adeiladu.
Mae gan y pwynt olaf ganlyniadau hefyd wrth ddefnyddio werff. Mae Werf yn mynnu bod y storfa adeiledig yn bresennol wrth redeg rhai gorchmynion (er enghraifft, werf deploy). Wrth weithredu gorchmynion o'r fath, mae werf yn cyfrifo llofnodion llwyfan ar gyfer y delweddau a nodir yn werf.yaml, a rhaid iddynt fod yn y storfa adeiladu, fel arall ni fydd y gorchymyn yn gallu parhau. Os yw llofnod y camau yn dibynnu ar y cynnwys .git, yna cawn storfa sy'n ansefydlog i newidiadau mewn ffeiliau amherthnasol, ac ni fydd werf yn gallu maddau amryfusedd o'r fath (am ragor o fanylion, gweler ).
Yn gyffredinol ychwanegu dim ond rhai ffeiliau gofynnol trwy gyfarwyddiadau ADD mewn unrhyw achos yn cynyddu effeithlonrwydd a dibynadwyedd y ysgrifenedig Dockerfile, a hefyd yn gwella sefydlogrwydd y storfa a gesglir gan hyn Dockerfile, i newidiadau amherthnasol yn Git.
Cyfanswm
Roedd ein llwybr cychwynnol wrth ysgrifennu ein hadeiladwr ein hunain ar gyfer anghenion penodol yn galed, yn onest ac yn syml: yn lle defnyddio baglau ar ben y Dockerfile safonol, fe wnaethom ysgrifennu ein datrysiad ein hunain gyda chystrawen arferol. A rhoddodd hyn ei fanteision: mae'r Stapel-collector yn gwneud ei waith yn berffaith.
Fodd bynnag, yn y broses o ysgrifennu ein hadeiladwr ein hunain, collasom olwg ar y gefnogaeth i Dockerfiles a oedd eisoes yn bodoli. Nawr mae'r diffyg hwn wedi'i unioni, ac yn y dyfodol rydym yn bwriadu datblygu cefnogaeth Dockerfile ynghyd â'n hadeiladwr Stapel arferol ar gyfer adeiladau gwasgaredig ac ar gyfer adeiladu gan ddefnyddio Kubernetes (h.y. adeiladu ar redwyr y tu mewn i Kubernetes, fel y gwneir yn kaniko).
Felly, os oes gennych chi un neu ddau o Dockerfiles yn gorwedd o gwmpas yn sydyn ... ceisiwch !
PS Rhestr o ddogfennaeth ar y pwnc
- ;
- ;
- ;
- ;
- ;
- ;
- .
Darllenwch hefyd ar ein blog:'.
Ffynhonnell: hab.com