Beter laat as nooit. Of hoe ons amper 'n ernstige fout gemaak het deur nie ondersteuning te hê vir gewone Dockerfiles om toepassingsbeelde te bou nie.
Dit sal oor - 'n GitOps-hulpmiddel wat met enige CI / CD-stelsel integreer en die bestuur van die hele toepassinglewensiklus bied, wat jou toelaat om:
- versamel en publiseer beelde,
- ontplooi toepassings na Kubernetes,
- verwyder ongebruikte beelde deur spesiale beleide te gebruik.
Die filosofie van die projek is om laevlakgereedskap in 'n enkele verenigde stelsel te versamel wat DevOps-ingenieurs beheer oor toepassings gee. Indien moontlik, moet bestaande nutsprogramme (soos Helm en Docker) gebruik word. As daar geen oplossing vir een of ander probleem is nie, kan ons alles wat nodig is hiervoor skep en in stand hou.
Agtergrond: jou eie beeldversamelaar
Dit is wat met die beeldbouer in werf gebeur het: ons het nie die gewone Dockerfile gehad nie. As jy kortliks in die geskiedenis van die projek duik, dan het hierdie probleem hom reeds in die eerste weergawes van werf (toe ).
Terwyl ons 'n instrument geskep het om toepassings in Docker-beelde in te bou, het ons vinnig besef dat die Dockerfile nie vir ons geskik was vir 'n paar baie spesifieke take nie:
- Die behoefte om tipiese klein webtoepassings volgens die volgende standaardskema saam te stel:
- installeer die toepassing se stelselwye afhanklikhede,
- installeer 'n bondel toepassingsafhanklikheidsbiblioteke,
- versamel bates,
- en die belangrikste, werk die kode in die prent vinnig en doeltreffend op.
- Wanneer veranderinge aan projeklêers aangebring word, moet die bouer vinnig 'n nuwe laag skep deur die veranderde lêers te pleister.
- As sekere lêers verander het, moet die ooreenstemmende afhanklike stadium herbou word.
Vandag is daar baie ander moontlikhede in ons kraan, maar die aanvanklike begeertes en drange was soos volg.
Oor die algemeen, sonder om twee keer te dink, het ons onsself bewapen met die programmeertaal wat gebruik is (sien onder) en vat die pad - te implementeer eie DSL! In ooreenstemming met die take wat gestel is, was dit bedoel om die bouproses in fases te beskryf en die afhanklikhede van hierdie stadiums op lêers te bepaal. En dit aangevul eie kraan, wat DSL in die finale doelwit verander het - die saamgestelde beeld. Aanvanklik was DSL in Ruby, maar as - die konfigurasie van ons versamelaar begin beskryf word in die YAML-lêer.
Ou config vir dapp in Ruby
Werklike config vir werf op YAML
Die meganisme van die versamelaar het ook mettertyd verander. Aanvanklik het ons eenvoudig 'n tydelike Docker-lêer vanaf ons konfigurasie gegenereer, en toe het ons bou-instruksies in tydelike houers begin uitvoer en 'n commit gemaak.
NB: Op die oomblik het ons bouer, wat met sy eie konfigurasie (in YAML) werk en die Stapel-bouer genoem word, reeds ontwikkel tot 'n redelik kragtige hulpmiddel. Die gedetailleerde beskrywing daarvan verdien aparte artikels, en die hoofbesonderhede kan gevind word in .
Bewustheid van die probleem
Maar ons het besef, en nie dadelik nie, dat ons een fout gemaak het: ons het nie die vermoë bygevoeg nie bou beelde deur 'n standaard Dockerfile en integreer dit in dieselfde end-tot-end toepassingsbestuurinfrastruktuur (d.w.s. versamel beelde, ontplooi en maak dit skoon). Hoe kan u 'n ontplooiingsinstrument in Kubernetes maak en nie Dockerfile-ondersteuning implementeer nie, d.w.s. 'n standaard manier om beelde vir die meeste projekte te beskryf? ..
In plaas daarvan om so 'n vraag te beantwoord, bied ons die oplossing daarvan. Wat as jy reeds 'n Dockerfile (of 'n stel Dockerfiles) het en werf wil gebruik?
NB: Terloops, hoekom sal jy selfs werf wil gebruik? Die hoofkenmerke kom neer op die volgende:
- volledige toepassingsbestuursiklus insluitend skoonmaakbeelde;
- die vermoë om die samestelling van verskeie beelde gelyktydig vanaf 'n enkele konfigurasie te bestuur;
- verbeterde ontplooiingsproses vir Helm-versoenbare kaarte.
'n Meer volledige lys kan gevind word by .
Dus, as ons vroeër sou voorstel om die Dockerfile na ons konfigurasie te herskryf, sê ons nou graag: "Laat werf jou Dockerfiles bou!"
Hoe om te gebruik?
Die volledige implementering van hierdie kenmerk verskyn in die vrystelling . Die algemene beginsel is eenvoudig: die gebruiker spesifiseer die pad na 'n bestaande Dockerfile in die werf config, en voer dan die opdrag uit werf build... en dit is dit - werf sal die beeld bou. Kom ons kyk na 'n abstrakte voorbeeld.
Kom ons kondig die volgende aan Dockerfile aan die wortel van die projek:
FROM ubuntu:18.04
RUN echo Building ...
En ons sal aankondig werf.yamlwat dit gebruik Dockerfile:
configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile
Almal! Links hardloop werf build:
Daarbenewens kan jy die volgende verklaar werf.yaml om verskeie beelde gelyktydig van verskillende Docker-lêers te bou:
configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend
Laastens word die deurvoer van bykomende bouparameters ook ondersteun - soos --build-arg и --add-host - via die werf config. 'n Volledige beskrywing van die Dockerfile-beeldkonfigurasie is beskikbaar by .
Hoe werk dit?
Tydens die bouproses funksioneer die standaardkas van plaaslike lae in Docker. Maar, belangrik, werf ook integreer die Dockerfile-konfigurasie in sy infrastruktuur. Wat beteken dit?
- Elke prent wat uit 'n Dockerfile gebou is, bestaan uit 'n enkele stadium genaamd
dockerfile(meer oor watter stadiums in werf is, kan jy lees ). - Vir verhoog
dockerfilewerf bereken 'n handtekening wat afhang van die inhoud van die Dockerfile-konfigurasie. Deur die Dockerfile-konfigurasie te verander, verander die verhooghandtekeningdockerfileen werf sal 'n herbou van daardie stadium begin met die nuwe Dockerfile-konfigurasie. As die handtekening nie verander nie, dan neem werf die beeld uit die kas (meer oor die gebruik van handtekeninge in werf is beskryf in ). - Verder kan die versamelde beelde gepubliseer word met die opdrag
werf publish(Ofwerf build-and-publish) en gebruik dit om na Kubernetes te ontplooi. Gepubliseerde beelde in die Docker Registry sal skoongemaak word met standaard werf skoonmaak gereedskap, d.w.s. daar sal 'n outomatiese opruiming wees van ou beelde (ouer as N dae), beelde wat verband hou met nie-bestaande Git-takke, en ander beleide.
Meer besonderhede oor die punte wat hier beskryf word, kan in die dokumentasie gevind word:
- ;
- ;
- .
Notas en Voorsorgmaatreëls
1. Eksterne URL in ADD word nie ondersteun nie
Die gebruik van 'n eksterne URL in 'n opdrag word tans nie ondersteun nie. ADD. Werf sal nie 'n herbou aktiveer wanneer 'n hulpbron by die gespesifiseerde URL verander nie. Hierdie kenmerk word beplan om binnekort bygevoeg te word.
2. Jy kan nie .git by 'n prent voeg nie
Oor die algemeen, die toevoeging van 'n gids .git in 'n beeld is 'n bose slegte praktyk, en dit is hoekom:
- As
.gitin die finale beeld bly, skend dit die beginsels : aangesien die resulterende beeld met 'n enkele commit geassosieer moet word, behoort dit nie moontlik te wees om te doen niegit checkoutarbitrêre pleeg. -
.gitverhoog die grootte van die prent (die bewaarplek kan groot wees as gevolg van die feit dat groot lêers een keer daarby gevoeg is en dan uitgevee is). Die grootte van die werkboom wat slegs met 'n spesifieke commit geassosieer word, sal nie afhang van die geskiedenis van bedrywighede in Git nie. In hierdie geval, die byvoeging en die daaropvolgende verwydering.gitvanaf die finale prent sal nie werk nie: die prent sal steeds 'n ekstra laag kry - dit is hoe Docker werk. - Docker kan 'n onnodige herbou veroorsaak, selfs al word dieselfde commit uit verskillende werkbome gebou. GitLab skep byvoorbeeld afsonderlike gekloonde dopgehou in
/home/gitlab-runner/builds/HASH/[0-N]/yourprojectmet parallelle samestelling geaktiveer. 'n Ekstra herbou sal wees as gevolg van die feit dat die gids.gitverskil in verskillende gekloonde weergawes van dieselfde bewaarplek, selfs al is dieselfde commit gebou.
Die laaste punt het ook gevolge wanneer werf gebruik word. Werf vereis dat die geboude kas teenwoordig moet wees wanneer sommige opdragte uitgevoer word (byvoorbeeld, werf deploy). Tydens die uitvoering van sulke opdragte, bereken werf verhooghandtekeninge vir die beelde gespesifiseer in werf.yaml, en hulle moet in die boukas wees, anders sal die opdrag nie kan voortgaan nie. As die handtekening van die stadiums afhang van die inhoud .git, dan kry ons 'n kas wat onstabiel is vir veranderinge in irrelevante lêers, en werf sal nie so 'n oorsig kan vergewe nie (vir meer besonderhede, sien ).
In die algemeen, slegs sekere vereiste lêers by te voeg deur instruksies ADD verhoog in elk geval die doeltreffendheid en betroubaarheid van die geskrewe Dockerfile, en verbeter ook die stabiliteit van die kas wat hierdeur versamel word Dockerfile, tot irrelevante veranderinge in Git.
Totale
Ons aanvanklike pad met die skryf van ons eie bouer vir spesifieke behoeftes was moeilik, eerlik en eenvoudig: in plaas daarvan om krukke bo-op die standaard Dockerfile te gebruik, het ons ons eie oplossing met persoonlike sintaksis geskryf. En dit het sy voordele gegee: die Stapel-versamelaar doen sy werk perfek.
In die proses om ons eie bouer te skryf, het ons egter die ondersteuning vir reeds bestaande Dockerfiles uit die oog verloor. Nou is hierdie tekortkoming reggestel, en in die toekoms beplan ons om Dockerfile-ondersteuning saam met ons pasgemaakte Stapel-bouer te ontwikkel vir verspreide bouwerk en vir bou met Kubernetes (d.w.s. bou op hardlopers binne Kubernetes, soos gedoen in kaniko).
Dus, as jy skielik 'n paar Dockerfiles het wat rondlê ... probeer dit !
NS Lys van dokumentasie oor die onderwerp
- ;
- ;
- ;
- ;
- ;
- ;
- .
Lees ook op ons blog:".
Bron: will.com