Kubernetes aplikazioak eraikitzeko eta bidaltzeko gure kode irekiko GitOps CLI utilitatea da. Agindu bezala, werfeari ezaugarri berriak gehitzeko eta ohiko ikuspegiak berrikusteko hasiera markatu zuen. Orain pozik gaude. 1.1 bertsioa aurkezten dugu, garapenean urrats handia eta etorkizunerako oinarria dena biltzailea werf. Une honetan bertsioa eskuragarri dago .
Argitalpenaren oinarria biltegiratze eszenikoaren arkitektura berria eta bi bildumagileen (Stapel eta Dockerfile) lanaren optimizazioa da. Biltegiratze-arkitektura berriak ostalari anitzetatik banatutako muntaiak eta muntaia paraleloak ostalari berean ezartzeko aukera zabaltzen du.
Lanaren optimizazioak faseko sinadurak kalkulatzeko fasean beharrezkoak ez diren kalkuluak kentzea eta fitxategien egiaztapen-batzuak kalkulatzeko mekanismoak eraginkorragoetara aldatzea dakar. Optimizazio honek proiektuen batez besteko denbora murrizten du werf erabiliz. Eta inaktiboen eraikuntzak, fase guztiak cachean daudenean etapak-biltegiratzea, orain oso azkarrak dira. Kasu gehienetan, konpilazioa berrabiarazteko segundo 1 baino gutxiago beharko da! Hau taldeen lan-prozesuaren faseak egiaztatzeko prozedurei ere aplikatzen zaie. werf deploy ΠΈ werf run.
Argitalpen honetan ere, irudiak edukiaren arabera etiketatzeko estrategia bat agertu zen - edukietan oinarritutako etiketatzea, orain lehenespenez gaituta dagoena eta gomendatzen den bakarra.
Ikus ditzagun werf v1.1-en funtsezko berrikuntzak gertutik, eta, aldi berean, etorkizunerako planen berri emango dizugu.
Zer aldatu da werf v1.1-en?
Etapa izendatzeko formatu eta algoritmo berria cachetik faseak hautatzeko
Izen artistikoak sortzeko arau berria. Orain etapa-eraikitze bakoitzak etapa-izen bakarra sortzen du, 2 zatiz osatua: sinadura bat (v1.0-n zegoen bezala) gehi aldi baterako identifikatzaile esklusibo bat.
Adibidez, eszenatokiaren irudiaren izen osoa honelakoa izan daiteke:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
...edo orokorrean:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
hemen:
-
SIGNATUREetapako sinadura bat da, etapako edukiaren identifikatzailea adierazten duena eta eduki hori ekarri duen Git-en aldaketen historiaren araberakoa da; -
TIMESTAMP_MILLISECirudi berri bat eraikitzen den unean sortzen den irudi-identifikatzaile bakarra da.
Cachetik faseak hautatzeko algoritmoa Git-en konpromisoen erlazioa egiaztatzean oinarritzen da:
- Werfek etapa jakin baten sinadura kalkulatzen du.
- Π etapak-biltegiratzea Sinadura jakin baterako hainbat fase egon daitezke. Werfek sinadurarekin bat datozen fase guztiak hautatzen ditu.
- Uneko etapa Git-ekin lotuta badago (git-archive, etapa pertsonalizatua Git adabakiekin:
install,beforeSetup,setup; edo git-latest-patch), orduan werf-ek uneko konpromezuaren arbasoa den konpromezu batekin erlazionatutako etapak bakarrik hautatzen ditu (konpilazioa deitzen zaio). - Gainerako fase egokietatik bat hautatzen da - zaharrena sortze-dataren arabera.
Git adar ezberdinentzako etapa batek sinadura bera izan dezake. Baina werf-ek adar ezberdinekin lotutako cachea adar horien artean erabiltzea eragotziko du, nahiz eta sinadurak bat etorri.
.
Etapa-biltegian etapak sortzeko eta gordetzeko algoritmo berria
Cacheko etapak hautatzerakoan werf-ek etapa egokirik aurkitzen ez badu, etapa berri bat muntatzeko prozesua hasten da.
Kontuan izan hainbat prozesu (ostalari batean edo gehiagotan) gutxi gorabehera aldi berean etapa bera eraikitzen has daitezkeela. Werfek blokeo-algoritmo baikorra erabiltzen du etapak-biltegiratzea bildu berri den irudia gordetzeko unean etapak-biltegiratzea. Horrela, etapa berria eraikitzeko prest dagoenean, werf blokeak etapak-biltegiratzea eta bildu berri den irudi bat gordetzen du bertan irudi egokirik jada existitzen ez bada (sinadura eta beste parametro batzuen arabera - ikusi cacheko faseak hautatzeko algoritmo berria).
Muntatu berri den irudi batek identifikatzaile bakarra izango duela bermatzen du TIMESTAMP_MILLISEC (ikusi etapa izendatzeko formatu berria). Badaezpada etapak-biltegiratzea irudi egoki bat aurkituko da, werf-ek konpilatu berri den irudia baztertuko du eta cacheko irudia erabiliko du.
Beste era batera esanda: irudia eraikitzen amaitzeko lehen prozesuak (azkarrenak) faseetan gordetzeko eskubidea izango du (eta gero irudi bakar hau da eraikuntza guztietarako erabiliko dena). Eraikitze prozesu motel batek ez du inoiz blokeatuko prozesu azkarrago bat egungo faseko eraikuntza-emaitzak gordetzeko eta hurrengo eraikuntzara pasatzeko.
.
Dockerfile eraikitzailearen errendimendua hobetu da
Momentuz, Dockerfile batetik eraikitako irudi baten faseen kanalizazioa etapa bat da - dockerfile. Sinadura kalkulatzean, fitxategien checksum-a kalkulatzen da context, muntaian erabiliko dena. Hobekuntza honen aurretik, werf errekurtsiboki fitxategi guztietan zehar ibili zen eta kontrol-sumuma bat lortu zuen fitxategi bakoitzaren testuingurua eta modua batuz. v1.1-etik hasita, werf-ek Git biltegi batean gordetako kalkulatutako checksumak erabil ditzake.
Algoritmoan oinarritzen da . Algoritmoak barneko erregistroak hartzen ditu kontuan .dockerignore eta beharrezkoa denean soilik zeharkatzen du fitxategi-zuhaitza modu errekurtsiboan. Horrela, fitxategi-sistema irakurtzetik desakoplatu dugu, eta algoritmoak tamainaren menpekotasuna. context ez da esanguratsua.
Algoritmoak jarraipenik gabeko fitxategiak ere egiaztatzen ditu eta, behar izanez gero, kontutan hartzen ditu checksumean.
Errendimendua hobetu da fitxategiak inportatzerakoan
Werf v1.1 bertsioek rsync zerbitzari bat erabiltzen dute noiz . Aurretik, inportazioa bi urratsetan egiten zen ostalari-sistemako direktorioaren muntaketa erabiliz.
Inportazio-errendimendua macOS-en jada ez da Docker-en bolumenek mugatzen, eta inportazioak Linux eta Windows-en denbora berean egiten dira.
Edukietan oinarritutako etiketatzea
Werf v1.1-ek irudien edukiaren arabera etiketa deritzona onartzen du - edukietan oinarritutako etiketatzea. Sortutako Docker irudien etiketak irudi horien edukiaren araberakoak dira.
Komandoa exekutatzean werf publish --tags-by-stages-signature edo werf ci-env --tagging-strategy=stages-signature izenekoaren irudiak argitaratuak etapa sinadura irudia. Irudi bakoitza irudi honen faseen sinadura propioarekin etiketatzen da, etapa bakoitzaren sinadura arruntaren arau berdinen arabera kalkulatzen dena, baina irudiaren identifikatzaile orokorra da.
Irudiaren faseen sinadura hauen araberakoa da:
- irudi honen edukia;
- eduki hori ekarri duten Git aldaketen historiak.
Git biltegi batek beti ditu irudi-fitxategien edukia aldatzen ez duten konpromezu faltsuak. Esate baterako, iruzkinekin soilik egiten du konpromezuak edo batzen dituen konpromisoak, edo irudira inportatuko ez diren Git-eko fitxategi horiek aldatzen dituzten konpromezuak.
Edukian oinarritutako etiketatzea erabiltzean, Kubernetes-en aplikazio-poden alferrikako berrabiarazteko arazoak konpontzen dira, irudiaren izenaren aldaketak direla eta, irudiaren edukia aldatu ez bada ere. Bide batez, hau da aplikazio bateko mikrozerbitzu asko Git biltegi bakarrean gordetzea eragozten duen arrazoietako bat.
Gainera, edukian oinarritutako etiketatzea Git adarretan etiketatzea baino etiketatze-metodo fidagarriagoa da, ondoriozko irudien edukia ez baitago adar bereko hainbat konpromezu biltzeko kanalizazioak CI sisteman exekutatzen diren ordenaren araberakoa.
Garrantzitsua da: hemendik aurrera etapak-sinadura - Is gomendatutako etiketatze estrategia bakarra. Lehenespenez erabiliko da komandoan werf ci-env (esplizituki etiketatze-eskema ezberdin bat zehazten ez baduzu).
. Ezaugarri honi aparteko argitalpen bat ere eskainiko zaio. EGUNERATU (Apirilak 3): Xehetasunekin artikulua .
Erregistro-mailak
Erabiltzaileak aukera dauka orain irteera kontrolatzeko, erregistro-maila ezartzeko eta arazketa-informazioarekin lan egiteko. Aukerak gehitu dira --log-quiet, --log-verbose, --log-debug.
Lehenespenez, irteerak gutxieneko informazioa dauka:
Irteera zehatza erabiltzean (--log-verbose) werf nola funtzionatzen duen ikus dezakezu:
Irteera zehatza (--log-debug), werf arazketa-informazioaz gain, erabilitako liburutegien erregistroak ere baditu. Esaterako, Docker Erregistroarekin elkarrekintza nola gertatzen den ikus dezakezu eta denbora asko igarotzen den lekuak ere erregistratu ditzakezu:
Etorkizuneko planak
Arreta! Jarraian azaltzen diren aukerak markatuta daude v1.1 bertsio honetan eskuragarri egongo da, horietako asko etorkizun hurbilean. Eguneraketak eguneratze automatikoen bidez etorriko dira . Ezaugarri hauek ez dute v1.1 funtzioen zati egonkorrari eragiten; haien itxurak ez du eskuzko esku-hartzea beharko lehendik dauden konfigurazioetan.
Docker Erregistroko hainbat inplementaziorako laguntza osoa (BERRIA)
- Bertsioa: v1.1
- Egunak: martxoa
Helburua da erabiltzaileak inplementazio pertsonalizatu bat erabiltzea murrizketarik gabe werf erabiltzean.
Gaur egun, laguntza osoa bermatuko dugun irtenbide multzo hau identifikatu dugu:
- Lehenetsia (liburutegia/erregistroa)*,
- AWS ECR
- Azure*,
- Docker Hub
- GCR*,
- GitHub paketeak
- GitLab Erregistroa*,
- Portua*,
- Kaia.
Gaur egun werf-ek guztiz onartzen dituen soluzioak izartxo batekin markatzen dira. Beste batzuentzat laguntza dago, baina mugarekin.
Bi arazo nagusi identifikatu daitezke:
- Irtenbide batzuek ez dute onartzen etiketa kentzea Docker Registry APIa erabiliz, erabiltzaileek werf-en garbiketa automatikoa erabiltzea eragotziz. Hau egia da AWS ECR, Docker Hub eta GitHub paketeetarako.
- Soluzio batzuek ez dute onartzen habiaraturiko biltegiak (Docker Hub, GitHub Packages eta Quay) edo onartzen dituzte, baina erabiltzaileak eskuz sortu behar ditu UI edo APIa erabiliz (AWS ECR).
Arazo hauek eta beste batzuk konponduko ditugu soluzioen jatorrizko APIak erabiliz. Zeregin honek werf funtzionamenduaren ziklo osoa estaltzea ere barne hartzen du, haietako bakoitzaren probekin.
Banatutako irudien eraikuntza (β)
- Bertsioa: v1.2 v1.1 (eginbide hau ezartzeko lehentasuna handitu egin da)
- Egunak: martxoa-apirila martxoa
Momentuz, werf v1.0 eta v1.1 ostalari dedikatu batean bakarrik erabil daitezke irudiak eraikitzeko eta argitaratzeko eta aplikazioa Kubernetesen zabaltzeko eragiketak egiteko.
Werf-en lan banatuaren aukerak irekitzeko, Kubernetes-en aplikazioen eraikuntza eta hedapena hainbat ostalari arbitrariotan abiarazten direnean eta ostalari hauek ez dute beren egoera gordetzen eraikuntzaren artean (aldi baterako korrikalariak), werf erabiltzeko gaitasuna inplementatu behar da. Docker Erregistroa etapa denda gisa.
Aurretik, werf proiektua oraindik dapp deitzen zenean, bazuen halako aukera bat. Hala ere, funtzionalitate hau werf-en ezartzerakoan kontuan hartu beharreko hainbat arazo topatu ditugu.
Kontuan izan. Ezaugarri honek ez du behar biltzaileak Kubernetes ontzien barruan lan egin behar, izan ere Horretarako, Docker zerbitzari lokalarekiko menpekotasuna kendu behar duzu (Kubernetes pod-ean ez dago Docker zerbitzari lokalerako sarbiderik, prozesua bera edukiontzi batean exekutatzen ari delako eta werf-ek ez du onartzen eta ez du onartzen. Docker zerbitzariarekin sarean lan egitea). Kubernetes exekutatzeko laguntza bereizita ezarriko da.
GitHub Actions-en laguntza ofiziala (BERRIA)
- Bertsioa: v1.1
- Egunak: martxoa
Werf dokumentazioa (atalak erreferentzia ΠΈ gidatuko), baita werf-ekin lan egiteko GitHub Action ofiziala ere.
Horrez gain, werf-ek korrikalari iragankorrak lantzeko aukera emango du.
Erabiltzaileak CI sistemarekin elkarreraginaren mekanika tira-eskaeretan etiketak jartzean oinarrituko da aplikazioa eraikitzeko/zabaltzeko ekintza batzuk hasteko.
Tokiko garapena eta aplikazioen hedapena werf-ekin (β)
- Bertsioa: v1.1
- Egunak: urtarrila-otsaila apirila
Helburu nagusia konfigurazio bateratu bakarra lortzea da aplikazioak tokian zein ekoizpenean hedatzeko, ekintza konplexurik gabe, kaxatik kanpo.
werf-ek funtzionamendu-modu bat edukitzea ere beharrezkoa da, aplikazioaren kodea editatzea eta berehala exekutatzen ari den aplikazioaren iritzia jasotzea komenigarria izango den arazketarako.
Garbiketa algoritmo berria (BERRIA)
- Bertsioa: v1.1
- Egunak: apirila
Prozeduran werf v1.1-en egungo bertsioan cleanup Ez dago edukietan oinarritutako etiketa-eskemarako irudiak garbitzeko xedapenik - irudi horiek pilatuko dira.
Gainera, werf-en egungo bertsioak (v1.0 eta v1.1) garbiketa-politika desberdinak erabiltzen ditu etiketa-eskemetan argitaratutako irudietarako: Git adarra, Git etiketa edo Git commit.
Git-eko konpromisoen historian oinarritutako irudiak garbitzeko algoritmo berri bat asmatu da, etiketa-eskema guztietarako bateratua:
- Ez gorde N1 irudiak baino gehiago N2 konpromiso berrienekin lotutako git HEAD bakoitzeko (adarrak eta etiketak).
- Ez gorde git HEAD bakoitzeko (adarrak eta etiketak) N1 azken konpromezuekin lotutako N2 etapako irudiak.
- Gorde Kubernetes edozein kluster baliabidetan erabiltzen diren irudi guztiak (konfigurazio-fitxategiaren eta izen-espazioen kube testuinguru guztiak eskaneatzen dira; aukera bereziekin muga dezakezu jokabide hori).
- Gorde Helm-en bertsioetan gordetako baliabideen konfigurazio manifestuetan erabiltzen diren irudi guztiak.
- Irudi bat ezabatu daiteke git-eko HEAD-rekin lotuta ez badago (adibidez, dagokion HEAD bera ezabatu delako) eta ez bada erabiltzen Kubernetes klusterreko eta Helm-eko bertsioetan inongo manifestuetan.
Irudi paraleloen eraikuntza (β)
- Bertsioa: v1.1
- Egunak: urtarrila-otsaila apirila*
Werf-en egungo bertsioak deskribatutako irudiak eta artefaktuak biltzen ditu werf.yaml, sekuentzialki. Beharrezkoa da irudien eta artefaktuen fase independenteak muntatzeko prozesua paralelizatzea, baita irteera erosoa eta informatiboa ematea ere.
* Oharra: epea aldatu egin da muntaketa banatua ezartzeko lehentasuna handitu delako, eta horrek eskalatze gaitasun horizontal gehiago gehituko ditu, baita GitHub Actions-ekin werf erabiltzea ere. Muntaketa paraleloa da hurrengo optimizazio urratsa, proiektu bat muntatzean eskalagarritasun bertikala eskaintzen duena.
Helm 3rako trantsizioa (β)
- Bertsioa: v1.2
- Egunak: otsaila-martxoa maiatza*
Kode-base berrirako migrazioa barne hartzen du eta lehendik dauden instalazioak migratzeko modu frogatua eta erosoa.
* Oharra: Helm 3-ra aldatzeak ez dio ezaugarri esanguratsuak gehituko werf-ari, Helm 3-ren funtsezko ezaugarri guztiak (hiru bide-batzea eta tillerrik gabea) dagoeneko werf-en inplementatuta daudelako. Gainera, werf du adierazitakoez gain. Hala ere, trantsizio hau gure planetan jarraitzen du eta gauzatuko da.
Jsonnet Kubernetes konfigurazioa deskribatzeko (β)
- Bertsioa: v1.2
- Egunak: urtarrila-otsaila apirila-maiatza
Werf-ek Kubernetes-en konfigurazio deskribapenak Jsonnet formatuan onartzen ditu. Aldi berean, werf Helm-ekin bateragarria izango da eta deskribapen formatua aukeran egongo da.
Arrazoia da Go txantiloiek, jende askoren ustez, sarrerako oztopo handia dutela, eta txantiloi horien kodearen ulergarritasunak ere pairatzen duela.
Kubernetes-en konfigurazio deskribapen sistemak (adibidez, Kustomize) sartzeko aukera ere aztertzen ari da.
Kubernetesen barruan lan egiten (β)
- Bertsioa: v1.2
- Egunak: apirila-maiatza maiatza-ekaina
Helburua: Ziurtatu irudiak eraikitzen direla eta aplikazioa Kubernetes-eko korrikalariak erabiliz entregatzen dela. Horiek. Irudi berriak zuzenean eraiki, argitaratu, garbitu eta inplementa daitezke Kubernetes-eko ontzietatik.
Gaitasun hori ezartzeko, lehenik eta behin banatutako irudiak eraikitzeko gai izan behar duzu (ikus goiko puntua).
Docker zerbitzaririk gabe eraikitzailearen funtzionamendu-modurako laguntza ere behar du (hau da, Kaniko moduko eraikitzea edo erabiltzaile-espazioan eraikitzea).
Werf-ek Kubernetes-en eraikitzen lagunduko du Dockerfile-rekin ez ezik, baita Stapel eraikitzailearekin ere berreraikitze inkrementalekin eta Ansiblerekin.
Garapen irekirako urratsa
Gure komunitatea maite dugu (, ) eta gero eta jende gehiagok werf hobetzen laguntzea, goazen norabidea ulertzen eta garapenean parte hartzea nahi dugu.
Duela gutxi hona aldatzea erabaki zen gure taldearen lan-prozesua ezagutarazteko. Orain berehalako planak ikus ditzakezu, baita orain arteko lanak ere, arlo hauetan:
- ;
- ;
- ;
- .
Lan asko egin da gaiekin:
- Garrantzirik gabekoak kendu ditu.
- Daudenak formatu bakarrera eramaten dira, xehetasun eta xehetasun kopuru nahikoarekin.
- Ideia eta iradokizunak dituzten gai berriak gehitu dira.
Nola gaitu bertsioa v1.1
Une honetan bertsioa eskuragarri dago (kanaletan egonkorra ΠΈ harri-solidoa askapenak egonkortzea gertatu ahala agertuko dira, ordea ea bera jada nahikoa egonkorra da erabiltzeko, zeren kanaletatik joan zen alpha ΠΈ beta). Aktibatuta era honetan:
source $(multiwerf use 1.1 ea)
werf COMMAND ...Ondorioa
Stapel eta Dockerfile eraikitzaileentzako etapa biltegiratze arkitektura berriak eta eraikitzaileen optimizazioek werf-en eraikitze banatuak eta paraleloak ezartzeko aukera zabaltzen dute. Ezaugarri hauek laster agertuko dira v1.1 bertsio berean eta automatikoki eskuragarri egongo dira eguneratze automatikoaren mekanismoaren bidez (erabiltzaileentzat ).
Argitalpen honetan, irudien edukian oinarritutako etiketatze estrategia bat gehitu da - edukietan oinarritutako etiketatzea, estrategia lehenetsia bihurtu dena. Komandoen erregistro nagusia ere berritu da: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
Hurrengo urrats esanguratsua banatutako muntaiak gehitzea da. Banatutako eraikitzek eraikuntza paraleloek baino lehentasun handiagoa bihurtu dute v1.0tik aurrera, werf-i balio handiagoa ematen diotelako: eraikitzaileen eskalatze bertikala eta eraikitzaile iragankorrentzako laguntza CI/CD sistema ezberdinetan, baita GitHub Ekintzetarako euskarri ofiziala egiteko gaitasuna ere. . Hori dela eta, batzar paraleloen ezarpen-epeak aldatu ziren. Hala ere, bi aukerak ahalik eta azkarren ezartzeko lanean ari gara.
Jarraitu albistea! Eta ez ahaztu gurekin bisitatzea arazo bat sortzeko, lehendik dagoen bat aurkitu eta plus bat gehitzeko, PR bat sortzeko edo, besterik gabe, proiektuaren garapena ikusteko.
PS
Irakurri ere gure blogean:
- «»
- «»;
- Werf-eko berrikuntzei buruzko ohar sorta bat:
- «»;
- «»;
- «»;
- Β«'.
Iturria: www.habr.com