Better let as nea. Of hoe't wy hast in serieuze flater makken troch gjin stipe te hawwen foar reguliere Dockerfiles om applikaasjeôfbyldings te bouwen.
Wy sille prate oer - GitOps-hulpprogramma dat yntegreart mei elk CI / CD-systeem en leveret behear fan 'e heule applikaasje-libbenssyklus, wêrtroch:
- ôfbyldings sammelje en publisearje,
- ynsette applikaasjes yn Kubernetes,
- wiskje net brûkte ôfbyldings mei help fan spesjale belied.
De filosofy fan it projekt is om ark op leech nivo te sammeljen yn ien ienriedich systeem dat DevOps-yngenieurs kontrôle jout oer applikaasjes. As it mooglik is, moatte besteande nutsbedriuwen (lykas Helm en Docker) brûkt wurde. As d'r gjin oplossing is foar in probleem, kinne wy alles hjirfoar oanmeitsje en stypje.
Eftergrûn: jo eigen ôfbyldingssamler
Dat barde mei de byldsamler yn werf: it gewoane Dockerfile wie net genôch foar ús. As jo efkes nei de skiednis fan it projekt sjogge, ferskynde dit probleem al yn de earste ferzjes fan werf (doe noch ).
By it meitsjen fan in ark foar it bouwen fan applikaasjes yn Docker-ôfbyldings, realisearren wy fluch dat Dockerfile net geskikt wie foar ús foar guon heul spesifike taken:
- De needsaak om typyske lytse webapplikaasjes te bouwen neffens it folgjende standertskema:
- ynstallearje systeem-wide applikaasje ôfhinklikens,
- ynstallearje in bondel fan tapassing ôfhinklikens bibleteken,
- besittings sammelje,
- en vooral, update de koade yn 'e ôfbylding fluch en effisjint.
- As wizigingen wurde makke oan projektbestannen, moat de bouwer fluch in nije laach meitsje troch in patch oan te passen op de feroare bestannen.
- As bepaalde bestannen binne feroare, dan is it nedich om de oerienkommende ôfhinklike poadium opnij op te bouwen.
Tsjintwurdich hat ús samler in protte oare mooglikheden, mar dit wiene de earste winsken en driuwfearren.
Yn 't algemien, sûnder twa kear nei te tinken, hawwe wy ússels bewapene mei de programmeartaal dy't wy brûkten (Sjoch hjirûnder) en sloech de wei om te ymplementearjen eigen DSL! Yn oerienstimming mei de doelstellingen wie it bedoeld om it assemblageproses stadichoan te beskriuwen en de ôfhinklikens fan dizze stadia op bestannen te bepalen. En oanfolle it eigen samler, dy't de DSL yn it lêste doel feroare - in gearstalde ôfbylding. Earst wie de DSL yn Ruby, mar as - de konfiguraasje fan ús samler begon te wurde beskreaun yn in YAML-bestân.
Alde konfiguraasje foar dapp yn Ruby
Aktuele konfiguraasje foar werf op YAML
It meganisme fan de samler ek feroare yn de rin fan de tiid. Yn it earstoan generearren wy gewoan in tydlike Dockerfile op 'e flecht út ús konfiguraasje, en doe begon wy assemblage-ynstruksjes yn tydlike konteners út te fieren en te commit.
NB: Op it stuit is ús samler, dy't wurket mei in eigen konfiguraasje (yn YAML) en hjit de Stapel-samler, al ûntwikkele ta in frij krêftich ark. De detaillearre beskriuwing dêrfan fertsjinnet aparte artikels, en basisdetails kinne fûn wurde yn .
Bewustwêzen fan it probleem
Mar wy realisearren, en net fuortendaliks, dat wy ien flater makke hienen: wy hawwe it fermogen net tafoege ôfbyldings bouwe fia standert Dockerfile en yntegrearje se yn deselde ein-to-ein applikaasje behear ynfrastruktuer (d.w.s. sammelje ôfbyldings, ynsette en skjin se). Hoe soe it mooglik wêze om in ark foar ynset yn Kubernetes te meitsjen en Dockerfile-stipe net te ymplementearjen, d.w.s. standert manier om ôfbyldings te beskriuwen foar de measte projekten? ..
Yn stee fan dizze fraach te beantwurdzjen, biede wy in oplossing. Wat as jo al in Dockerfile (of in set Dockerfiles) hawwe en werf wolle brûke?
NB: Trouwens, wêrom soene jo sels werf brûke wolle? De wichtichste skaaimerken komme del op it folgjende:
- folsleine applikaasje behear syklus ynklusyf ôfbylding skjinmeitsjen;
- de mooglikheid om de gearstalling fan ferskate ôfbyldings tagelyk te behearjen fan ien konfiguraasje;
- Ferbettere ynsetproses foar Helm-kompatible charts.
In mear folsleine list fan harren is te finen op .
Dus, as wy earder oanbean hawwe om de Dockerfile yn ús konfiguraasje te herskriuwen, no sille wy lokkich sizze: "Lit werf jo Dockerfiles bouwe!"
Hoe kinne jo brûke?
De folsleine ymplemintaasje fan dizze funksje ferskynde yn 'e release . It algemiene prinsipe is ienfâldich: de brûker spesifisearret it paad nei in besteande Dockerfile yn 'e werf konfiguraasje, en fiert dan it kommando út werf build... en dat is it - werf sil it byld gearstalle. Litte wy nei in abstrakt foarbyld sjen.
Litte wy de folgjende oankundigje Dockerfile yn 'e projektroot:
FROM ubuntu:18.04
RUN echo Building ...
En wy sille oankundigje werf.yamldy't dit brûkt Dockerfile:
configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile
Alle! Links rinne werf build:
Derneist kinne jo it folgjende ferklearje werf.yaml om ferskate ôfbyldings te bouwen fan ferskate Dockerfiles tagelyk:
configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend
Uteinlik stipet it ek it trochjaan fan ekstra buildparameters, lykas --build-arg и --add-host - fia werf config. In folsleine beskriuwing fan 'e Dockerfile-ôfbyldingskonfiguraasje is beskikber op .
Hoe wurket it?
Tidens it bouproses wurket de standert cache fan lokale lagen yn Docker. Wat lykwols wichtich is, is dat werf ek yntegreart Dockerfile-konfiguraasje yn har ynfrastruktuer. Wat betsjut dit?
- Elke ôfbylding boud fan in Dockerfile bestiet út ien poadium neamd
dockerfile(jo kinne mear lêze oer hokker etappes yn werf binne ). - Foar poadium
dockerfilewerf berekkent in hantekening dy't ôfhinklik is fan de ynhâld fan de Dockerfile-konfiguraasje. As de Dockerfile-konfiguraasje feroaret, feroaret de poadiumhantekeningdockerfileen werf inisjearret in weropbou fan dit poadium mei in nije Dockerfile-konfiguraasje. As de hantekening net feroaret, dan nimt werf de ôfbylding út de cache (mear details oer it brûken fan hantekeningen yn werf waarden beskreaun yn ). - Dêrnei kinne de sammele ôfbyldings wurde publisearre mei it kommando
werf publish(ofwerf build-and-publish) en brûk it foar ynset nei Kubernetes. Publisearre ôfbyldings nei it Docker Registry sille wurde skjinmakke mei standert werf-skjin-ark, d.w.s. Alde ôfbyldings (âlder dan N dagen), ôfbyldings ferbûn mei net-besteande Git-tûken, en oare belied sille automatysk skjinmakke wurde.
Mear details oer de hjir beskreaune punten kinne fûn wurde yn 'e dokumintaasje:
- ;
- ;
- .
Notysjes en foarsoarchsmaatregels
1. Eksterne URL wurdt net stipe yn ADD
Op it stuit wurdt it net stipe om in eksterne URL yn in rjochtline te brûken ADD. Werf sil gjin werbou begjinne as de boarne op de oantsjutte URL feroaret. Wy binne fan plan om dizze funksje gau ta te foegjen.
2. Jo kinne net tafoegje .git oan de ôfbylding
Algemien sprutsen, it tafoegjen fan in map .git yn 'e ôfbylding - in wrede minne praktyk en hjir is wêrom:
- as
.gitbliuwt yn it definitive byld, dit yn striid mei de prinsipes : Sûnt de definitive ôfbylding moat wurde keppele oan in inkele commit, it soe net mooglik wêze om te dwaangit checkoutwillekeurige commit. -
.gitfergruttet de grutte fan 'e ôfbylding (it repository kin grut wêze fanwege it feit dat der ienris grutte bestannen oan tafoege binne en dêrnei wiske binne). De grutte fan in wurkbeam dy't allinich ferbûn is mei in spesifike commit sil net ôfhinklik wêze fan 'e skiednis fan operaasjes yn Git. Yn dit gefal, de tafoeging en dêrop folgjende fuortheljen.gitfan 'e definitive ôfbylding sil net wurkje: de ôfbylding sil noch in ekstra laach krije - dit is hoe't Docker wurket. - Docker kin in ûnnedige werbou begjinne, sels as deselde commit wurdt boud, mar fan ferskate wurkbeammen. GitLab makket bygelyks aparte klone mappen yn
/home/gitlab-runner/builds/HASH/[0-N]/yourprojectas parallelle gearkomste is ynskeakele. De ekstra gearstalling sil wêze fanwege it feit dat de map.gitis oars yn ferskate cloned ferzjes fan deselde repository, sels as deselde commit is boud.
It lêste punt hat ek gefolgen by it brûken fan werf. Werf fereasket dat de ynboude cache oanwêzich is by it útfieren fan guon kommando's (bgl. werf deploy). As dizze kommando's rinne, berekkent werf poadiumhantekeningen foar de ôfbyldings oantsjutte yn werf.yaml, en se moatte yn 'e gearstalling-cache wêze - oars kin it kommando net trochgean mei wurkjen. As de poadium hantekening hinget ôf fan de ynhâld .git, dan krije wy in cache dy't ynstabyl is foar feroaringen yn irrelevante triemmen, en werf sil sa'n oersicht net ferjaan kinne (foar mear details sjoch ).
Yn 't algemien it tafoegjen fan allinich bepaalde needsaaklike bestannen troch de ynstruksjes ADD yn alle gefallen fergruttet de effisjinsje en betrouberens fan it skreaune Dockerfile, en ek ferbetteret de stabiliteit fan de cache sammele foar dit Dockerfile, oan irrelevante feroarings yn Git.
It resultaat
Us earste paad nei it skriuwen fan ús eigen bouwer foar spesifike behoeften wie hurd, earlik en rjochtlinich: ynstee fan krukken te brûken boppe op 'e standert Dockerfile, skreaunen wy ús oplossing mei oanpaste syntaksis. En dat hie syn foardielen: de Stapel-samler docht syn taak perfekt oan.
Yn it proses fan it skriuwen fan ús eigen bouwer hawwe wy lykwols de stipe foar besteande Dockerfiles út it each ferlern. Dizze flater is no reparearre, en yn 'e takomst binne wy fan plan om Dockerfile-stipe te ûntwikkeljen tegearre mei ús oanpaste Stapel-bouwer foar ferdielde builds en foar builds mei Kubernetes (dus bouwt op runners binnen Kubernetes, lykas wurdt dien yn kaniko).
Dus, as jo ynienen in pear Dockerfiles hawwe lizze ... probearje it !
PS List fan dokumintaasje oer it ûnderwerp
- ;
- ;
- ;
- ;
- ;
- ;
- .
Lês ek yn ús blog: "".
Boarne: www.habr.com