🥇Werf 1.1 väljaanne: ehitaja täiustused täna ja tulevikuplaanid

werf — meie avatud lähtekoodiga GitOps CLI-utility rakenduste koostamiseks ja tarnimiseks Kubernetesesse. Nagu lubatud, väljaanne versioon v1.0 tähistas uute võimaluste lisamise ja harjumuspäraste lähenemiste ülevaatamise algust werfis. Nüüd oleme rõõmsad esitleda väljaannet v1.1, mis on suur samm edasi ja alus tulevikuks koostaja werf. Versioon on praegu saadaval kanalis 1.1 ea.

Väljaande alus on uus etappide salvestuse arhitektuur ja kahe koostaja (Stapel ja Dockerfile) töö optimeerimine. Uus salvestuse arhitektuur avab võimalused hajutatud koostamiseks mitmelt hostilt ja paralleelseks koostamiseks ühel hostil.

Töö optimeerimine hõlmab liialdavate arvutuste kõrvaldamist etappide allkirjade arvutamise etapis ja failide kontrollsummade arvutamismehhanismide muutmist efektiivsemateks. See optimeerimine vähendab keskmist projekti koostamise aega werfiga. Ja tühjad koostamised, kui kõik etapid eksisteerivad vahemälus stages-storage, on nüüd tõeliselt kiired. Enamikel juhtudel toimub koostamise uuesti käivitamine kiiremini kui 1 sekund! See kehtib ka etappide kinnitamisprotseduuride kohta meeskondade töötamise käigus werf deploy ja werf run.

Lisaks on selles väljaandes ilmunud kujundusstrateegia piltide märgistamiseks sisu põhjal — sisu põhine märgistamine, mis on nüüd vaikimisi lubatud ja ainus soovitatav.

Vaatame lähemalt werfi v1.1 põhimuudatusi ja räägime ka tulevikuplaanidest.

Mis on werf v1.1-s muutunud?

Uus etappide nimede formaat ja etappide valimise algoritm vahemälust

Uus etappide nime genereerimise reegel. Nüüdsest genereerib iga etapi koostamine unikaalse etapi nime, mis koosneb kahest osast: allkiri (nagu v1.0-s) pluss unikaalne ajasild.

Näiteks, täielik etapi pildi nimi võib välja näha nii:

werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835

… või üldises vormis:

werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC

Siin:

SIGNATURE — see on etapi allkiri, mis esindab etapi sisu identifikaatorit ja sõltub Git-i muudatuste ajaloost, mis viis sellise sisuni;
TIMESTAMP_MILLISEC — see on garanteeritult ainulaadne pildi identifikaator, mis genereeritakse uue pildi koostmise hetkel.

Etappide valimise algoritm vahemälust põhineb Git-i commitide suguluse kontrollimisel:

Werf arvutab mingi etapi allkirja.
Uues stages-storage Sama allkirjaga võib olla mitu etappi. Werf valib kõik allkirjale vastavad etapid.
Kui praegune etapp on seotud Gitiga (git-archive, kasutaja etapp Git-patchide jaoks: install, beforeSetup, setup; või git-latest-patch), valib werf ainult need etapid, mis on seotud commit'iga, mis on praeguse commit'i eelkäija (mille jaoks kutsuti esile koostamine).
Järelejäänud sobivate etappide hulgast valitakse üks – kõige vanem loomise kuupäeva järgi.

Erinevates Git-oksades võib samal etapp olla sama allkirjaga. Kuid werf takistab erinevate okste vahel koodi vahetamist, isegi kui allkirjad kattuvad.

→ Dokumentatsioon.

Uus etappide loomise ja salvestamise algoritm etappide salves

Kui werf ei leia vahemälust sobivat etappi, algatatakse uue etapi koostamisprotsess.

Märkusena, et mitu protsessi (ühel või mitmel serveril) võivad alustada sama etapi koostamist umbes samal ajal. Werf kasutab optimistliku lukustamise algoritmi stages-storage värskelt loodud pildi salvestamise hetkel stages-storage. Seega, kui uue etapi koostamine on valmis, lukustab werf stages-storage ja salvestab sinna värskelt loodud pildi ainult juhul, kui seal ei eksisteeri juba sobivat pilti (allkirja ja muude parameetrite kohaselt – vt uut algoritmi etappide valimiseks vahemälust).

Värskelt loodud pildil on garanteeritud ainulaadne ID TIMESTAMP_MILLISEC (vt uut etappide nimede formaat). Kui stages-storage leidub sobiv pilt, loob werf värskelt loodud pildi kõrvale ja kasutab vahemälus olevat pilti.

Teisisõnu: esimene protsess, mis lõpetab pildi koostamise (kõige kiirem), saab õiguse salvestada selle stages-storage'isse (ja just seda ainukest pilti kasutatakse kõigi koostamiste jaoks). Aeglane koostamisprotsess ei takista kunagi kiiremat protsessi praeguse etapi koostamise tulemuste salvestamisel ja järgmise etapi koostamisele üleminekul.

→ Dokumentatsioon.

Dockerfile'i koosturi jõudlust on parandatud

Praegu koosneb Dockerfile'ist genereeritava pildi etapi rida ühest etapist – dockerfile. Allkirja arvutamisel arvestatakse failide hajutuse summat. context, mis kasutatakse kogumisel. Selle täiustamise eel saavutab werf rekurssiivselt kõikidel failidel kontrollsummad, võttes arvesse konteksti ja iga faili moodulit. Alates versioonist v1.1 saab werf kasutada arvutatud kontrollsummasid, mis on talletatud Git-repositooriumis.

Algoritmi aluseks on git ls-tree. Algoritm arvestab kirjeid .dockerignore ja läbib rekurssiivselt failipuid ainult vajadusel. Nii oleme vabastanud end failisüsteemi lugemise sõltuvusest ja algoritmi sõltuvus context ei ole oluline.

Samuti kontrollib algoritm jälgimata faile ja arvestab neid vajadusel kontrollsummas.

Parandatud on jõudlust, kui faile importitakse

Werf v1.1 versioonides kasutatakse rsync-serverit failide importimisel artefaktidest ja piltidest. Varem viidi import läbi kahes etapis, kasutades host-süsteemi kausta montaaži.

Importsed jõudlust macOS-is ei piira enam Docker volumes, import toimub sama ajaga nagu Linuxis ja Windowsis.

Sisu põhine märgistamine

Werf v1.1 toetab nn pildisisese sisu märgistamist — sisu põhine märgistamine. Tulemuseks oleva Docker-pildi märgid sõltuvad nende piltide sisust.

Käivitades käsu werf publish --tags-by-stages-signature või werf ci-env --tagging-strategy=stages-signature märgistatakse avaldatud pildid nii nimetatud staadiumi allkirjaga pildi jaoks. Iga pilt saab omaenda selle pildi staadiumi allkirja, mis arvutatakse samade reeglite järgi kui iga eraldi staadiumi regulaarne allkiri, kuid on pildi üldine identifikaator.

Pildi staadiumi allkiri sõltub:

selle pildi sisust;
Git’is toimunud muudatuste ajaloost, mis viis sellise sisuni.

Git-repositooriumis on alati tühjad kommitsioonid, mis ei muuda pildi failide sisu. Näiteks ainult kommentaaridega kommitsioonid või sulandumise kommitsioonid, või kommitsioonid, mis muudavad Git’is faile, mis ei impordita pildisse.

Sisu põhise märgistamise kasutamisel lahendatakse probleeme liigsete pod'i taaskäivitustega Kubernetes'is pildi nime muutuste tõttu, isegi kui pildi sisu ei ole muutunud. Üldiselt on see üks põhjusi, miks on keeruline hoida mitmeid mikroteenuseid ühes rakenduses ühes Git-repositooriumis.

Samuti on content-based tagging usaldusväärsem meetod sildistamiseks kui Git-haarude sildistamine, kuna loodud piltide sisu ei sõltu pipeline'ide täitmise järjekorrast CI-süsteemis, et koguda mitmeid sama haru commit'e.

Oluline: alates käesolevast hetkest stages-signature — see on ainus soovitatav sildistamisstrateegia. See hakkab vaikimisi kasutama meeskonnas werf ci-env (kui ei ole selgelt määratud teist sildistamisskeemi).

→ Dokumentatsioon. Sellele funktsioonile pühendatakse ka eraldi artikkel. UUENDATUD (3. aprill): Artikkel üksikasjadega avalikustatud.

Logimise tasemed

Kasutajal on võimalus kontrollida väljundit, määrata logimise taset ja töötada silumisinfoga. Lisatud valikud --log-quiet, --log-verbose, --log-debug.

Vaikimisi sisaldab väljund minimaalset teavet:

Kasutades põhjalikku väljundit (--log-verbose) saab jälgida, kuidas werf töötab:

Täpne väljund (--log-debug), lisaks werf'i silumisinfotele, sisaldab ka kasutatavate raamatukogude logisid. Näiteks saab näha, kuidas toimub suhtlemine Docker Registry'ga, ning fikseerida kohad, kus kulub oluline kogus aega:

Edasised plaanid

Tähelepanu! Allpool kirjeldatud funktsioonid, mis on märgitud v1.1 on juba selle versiooni jooksul saadaval, paljusid neist - peagi. Uuendused tulevad automaatsete täiendustega kasutades multiwerf. Need funktsioonid ei mõjuta v1.1 stabiilsete funktsioonide osa, nende ilmumine ei nõua kasutajalt käsitsi sekkumist juba olemasolevatesse konfiguratsioonidesse.

Täielik toetus erinevatele Docker Registry rakendustele (UUED)

Versioon: v1.1
Ajad: märts
Probleem

Eesmärk - kasutaja peaks saama kasutada suvalist rakendust piiranguteta, kasutades werf'i.

Praegu oleme välja selgitanud järgmise lahenduste komplekti, mille jaoks plaanime täielikku toetust tagada:

Default (library/registry)*,
AWS ECR,
Azure*,
Docker Hub,
GCR*,
GitHub Packages,
GitLab Registry*,
Harbor*,
Quay.

Tärniga märgitud lahendused, mis on hetkel juba täielikult werf'i poolt toetatud. Ülejäänute puhul on toetus olemas, kuid piirangutega.

Saab eristada kahte peamist probleemi:

Mõned lahendused ei toeta siltide kustutamist Docker Registry API kaudu, mis ei luba kasutajatel kasutada werf'is rakendatud automaatset puhastamist. See kehtib AWS ECR, Docker Hub ja GitHub Packages kohta.
Mõned lahendused ei toeta nii öeldud nested repositories (Docker Hub, GitHub Packages ja Quay) või toetavad, kuid kasutaja peab need käsitsi looma, kasutades UI-d või API-d (AWS ECR).

Nende ja teiste probleemide lahendamiseks kavatseme kasutada lahenduste natiivseid API-sid. See ülesanne hõlmab ka testide katvuse loomist werfi kogu töötsükli jaoks igaühe jaoks.

Jaotatud piltide kogu (↑)

Versioon: v1.2 v1.1 (selle võimaluse rakendamise prioriteet on suurenenud)
Ajavahemikud: märts-aprill märts
Probleem

Hetkel saab werfi v1.0 ja v1.1 kasutada vaid ühel eraldatud serveril, et teostada pilte kogumist ja avaldamist ning rakenduse juurutamist Kubernetesesse.

Et avada werfi jaotatud töövõimalused, kui rakenduste kogumine ja juurutamine Kuberneteses algatatakse mitmetel suvalistel serveritel ning need serverid ei hoia oma seisundit kogumiste vahel (ajalised runnerid), on werfilt vajalik rakendada Docker Registry kasutamise võimalust etappide salvestamiseks.

Varem, kui projekt werf veel dapp-ina tuntud oli, oli sellel selline võimalus. Siiski seisime silmitsi mitmete probleemidega, mida on vaja arvesse võtta selle funktsiooni rakendamisel werfis.

Märkus. See võimalus ei eelda kogujate töötamist Kuberneteses pod’ides, kuna selleks on vajalik loobuda kohalikest Docker-serveri sõltuvustest (Kuberneteses pod’is ei ole juurdepääsu kohalikule Docker-serverile, kuna protsess ise töötab konteineris ja werf ei toeta ega hakka toetama Docker-serveriga võrgust töötamist). Kuberneteses töötamise tugi rakendatakse eraldi.

Ametlik tugi GitHub Actions (UUS)

Versioon: v1.1
Ajad: märts
Probleem

Selle hulka kuulub werf dokumentatsioon (peatükid reference ja guide), samuti ametlik GitHub Action, et töötada werfiga.

Lisaks võimaldab see werfi tööle minna efemäärsetel runneritel.

Kasutaja suhtlemismehhanism CI-süsteemiga põhineb labelite määramisel pull-requestidele, et algatada teatud tegevusi rakenduse kogumisel/välja toomisel.

Kohalik arendus ja rakenduste juurutamine werfiga (↓)

Versioon: v1.1
Ajavahemikud: jaanuar-veebruar aprill
Probleem

Peamine eesmärk on saavutada ühtne ühtne konfigureerimine rakenduste juurutamiseks nii kohalikult kui ka tootmises, ilma keerukate toiminguteta, „karbist välja“.

werf nõuab ka töörežiimi, kus on mugav rakenduse koodi redigeerida ja koheselt saada tagasisidet töötavast rakendusest veaotsimiseks.

Uus puhastamise algoritm (UUS)

Versioon: v1.1
Tähtajad: aprill
Probleem

Aktuaalses versioonis werf v1.1 on protsessis cleanup ei ole ette nähtud kuvandeid puhastamiseks sisu põhjal (content-based tagging) — need pildid kogunevad.

Samuti kasutatakse aktuaalses versioonis werf (v1.0 ja v1.1) erinevaid puhastusstrateegiaid piltide jaoks, mis on avaldatud tähistamisstrateegiate alusel: Git-haru, Git-silt või Git-commit.

On välja töötatud uus ühtne kõigile tähistamisstrateegiatele mõeldud piltide puhastusalgoritm, mis põhineb Git'i commitide ajaloos:

Hoida mitte rohkem kui N1 pilti, mis on seotud N2 viimase commitiga iga git HEAD (haru ja sildid) jaoks.
Hoida mitte rohkem kui N1 staatus ettepanekut, mis on seotud N2 viimase commitiga iga git HEAD (haru ja sildid) jaoks.
Hoida kõik pildid, mida kasutatakse mis tahes Kubernetes klastrite ressursside konfiguratsioonis (skannitakse kõiki kube-kontekste konfiguratsioonifailist ja nimekohtadest; seda käitumist saab piirata eriliste valikute abil).
Hoida kõik pildid, mida kasutatakse ressursside konfiguratsioonide manifestides, mis on salvestatud Helm'i väljalaskes.
Pilt võib olla eemaldatud, kui see ei ole seotud ühegi git HEAD'iga (nt kuna vastav HEAD on eemaldatud) ja ei ole kasutusel üheski manifestis Kubernetes klastris ja Helm'i väljalaskes.

Paralleelne piltide kogumine (↓)

Versioon: v1.1
Tähtajad: jaanuar-veebruar aprill*

Aktuaalne versioon werf kogub pilte ja artefakte, nagu on kirjeldatud werf.yaml, järjestikku. On vajalik jagada sõltumatute piltide ja artefaktide kogumise protsess ning tagada mugav ja informatiivne väljund.

* Märkus: tähtaeg on nihkunud distribuudi kogumise kõrgema prioriteedi tõttu, mis lisab rohkem horisontaalse skaleeritavuse võimalusi, samuti kasutades werf'i GitHub Actions'iga. Paralleelne kogumine on järgmine optimeerimise etapp, tasandades vertikaalselt ühe projekti kogumist.

Üleminek Helm 3-le (↓)

Versioon: v1.2
Tähtajad: veebruar-märts mai*

Sisaldab üleminekut uuele koodibaasile Helm 3 ja tõestatud, mugav migratsiooniviis olemasolevate installatsioonide jaoks.

* Märkus: üleminek Helm 3-le ei lisa werf-ile olulisi võimalusi, kuna kõik Helm 3 põhifunktsioonid (3-way-merge ja tilleri puudumine) on juba werf-is rakendatud. Veelgi enam, werf-l on lisafunktsioonid lisaks nimetatutele. Siiski jääb see üleminek meie plaanidesse ja see teostatakse.

Jsonnet Kubernetes'i konfiguratsiooni kirjeldamiseks (↓)

Versioon: v1.2
Ajakava: jaanuar-veebruar aprill-mai

Werf toetab Kubernetes'i konfiguratsiooni kirjeldamist Jsonnet formaadis. Samuti jääb werf Helmiga ühilduvaks ja on võimalus valida kirjeldusformaati.

Põhjuseks on asjaolu, et Go keele mallid, paljude arvates, on neil kõrge sisenemisbarjäär ning nende mallide koodi arusaadavus on samuti probleemne.

Samuti kaalutakse võimalust võtta kasutusele teiseid Kubernetes'i konfiguratsiooni kirjeldamise süsteeme (näiteks Kustomize).

Töö Kubernetes'is (↓)

Versioon: v1.2
Ajakava: aprill-mai mai-juuni

Eesmärk: tagada piltide koostamine ja rakenduse kohaletoimetamine runnerite abil Kubernetes'is. St. uute piltide koostamine, nende avaldamine, puhastamine ja juurutamine võib toimuda otse Kubernetes'i pod'idest.

Selle võimaluse teostamiseks on kõigepealt vajalik jaotatud piltide koostamise võimalus (vt eelpool).

Samuti on vajalik toetada koostaja töörežiimi ilma Docker-serverita (st Kaniko-sarnane koostamine või koostamine userspace'is).

Werf toetab Kubernetes'is piltide koostamist mitte ainult Dockerfile'i kaudu, vaid ka oma koostajaga Stapel, koos inkrementaalsete ümberkoostamiste ja Ansible'iga.

Samm avatud arendamise suunas

Me armastame oma kogukonda (GitHub, Telegram) ja soovime, et üha rohkem inimesi aitaks werf'i paremaks teha, mõistaks, millises suunas me liigume, ning osaleks arenduses.

Hiljuti otsustati minna üle GitHubi projektide tahvlitele et avada meie meeskonna tööprotsess. Nüüd saab vaadata lähituleviku plaane, samuti käimasolevaid töid järgmistes suundades:

On tehtud suur töö issue'idega:

Ebavajalikud on eemaldatud.
Olemasolevad on viidud ühtsesse vormingusse, piisavas koguses detaile ja põhjalikkust.
Uued issues on lisatud ideede ja ettepanekutega.

Kuidas lubada versioon v1.1

Versioon on praegu saadaval kanalis 1.1 ea (kanalites stable ja rock-solid väljaanded ilmuvad stabiliseerimise käigus, kuid ea ise on juba piisavalt stabiilne kasutamiseks, kuna see on läbinud kanalid alpha ja beta). Aktiveeritakse multiwerf kaudu järgmistel viisidel:

source $(multiwerf use 1.1 ea)
werf COMMAND ...

Kokkuvõte

Uus ladustamise etappide arhitektuur ja ehituse optimeerimine Stapeli ja Dockerfile ehitajate jaoks avavad võimalusi jaotatud ja paralleelsete ehituste teostamiseks werf'is. Need võimalused saavad peagi olema kergelt kättesaadavad versioonis v1.1 ja saadaval automaatselt uuendamise mehhanismi kaudu (kasutajatele multiwerf).

Selles versioonis lisati piltide sisu põhine ettepanekute strateegia — sisu põhine märgistamine, — mis on nüüd vaikimisi strateegia. Samuti on ümber kujundatud peamiste käskude logi: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

Järgmine oluline samm on jaotatud ehituste lisamine. Alates v1.0'st on jaotatud ehitused olnud prioriteediks rohkem kui paralleelsed ehitused, sest need toovad werf'ile rohkem väärtust: ehitajate vertikaalne skaleerimine ja ajutiste ehitajate toetamine erinevates CI/CD süsteemides, samuti võimalus ametlikuks toeks GitHub Actions'ile. Seetõttu on paralleelsete ehituste teostamise tähtaegu edasi lükatud. Töötame siiski selle nimel, et viia ellu mõlemad võimalused pigem varakult.

Jälgige uudiseid! Ja ärge unustage külastada meid GitHub, et luua issue, leida juba olemasolev ja panna pluss, luua PR või lihtsalt jälgida projekti arengut.