🥇werf 1.1 väljalase: täna toimetaja täiustused ja tulevikuplaanid

werf — meie avatud lähtekoodiga GitOps CLI-utility rakenduste ehitamiseks ja tarnimiseks Kubernetesesse. Nagu lubatud, väljaanne v1.0 tähistas werfi uusimate võimaluste lisamise ja tuttavate lähenemisviiside ülevaatamise algust. Nüüd on meil hea meel esitleda versiooni v1.1, mis on suur samm edasi ja alustab tulevikku suunatud arendusi. kompilaator werf. Versioon on hetkel saadaval 1.1 ea kanalil..

Uue versiooni alus on uus etappide salvestusarkitektuur ja kahe kompilaatori (Stapel ja Dockerfile) töö optimiseerimine. Uus salvestusarkitektuur avab võimalused jaotatud kompilaadiks mitmelt hostilt ja paralleelseks kompilaadiks ühel hostil.

Töö optimiseerimine hõlmab üleliigsete arvutuste eemaldamist etappide allkirjade arvutamise etapis ja failide kontrollsummade arvutamise mehhanismide asendamist efektiivsematega. See optimeerimine vähendab keskmist projekti kompileerimise aega werfi abil. Ja tühjad kompilaadid, kui kõik etapid on vahemikus olemas. stages-storage, nüüd tõeliselt kiired. Enamasti kulgeb koostamise taaskäivitamine kiiremini kui sekundiga! See kehtib ka etappide kontrollimisprotseduuride kohta, mis toimuvad meeskonna töös. werf deploy ja werf run.

Samuti on selles väljalaskes saadaval sisu põhjal pildi sildistamise strateegia — sisu põhine märgistamine, mis on nüüd vaikimisi sisse lülitatud ja on ainus soovitatav variant.

Vaatame lähemalt werf v1.1 peamisi uuendusi ja räägime samal ajal tulevikuplaanidest.

Mis on muutunud werf v1.1-s?

Uus etappide nimetamise formaat ja etappide valimise algoritm kaustast

Uus etapi nime genereerimise reegel. Iga etapi koostamine genereerib nüüd ainulaadse etapi nime, mis koosneb kahest osast: allkiri (nagu v1.0-s) pluss ainulaadne ajakood.

Näiteks võib etapi täielik nimi välja näha järgmiselt:

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 redigeerimise ajaloost, mis viis selleni;
TIMESTAMP_MILLISEC — see on garanteeritud unikaalne pildi identifikaator, mis genereeritakse uue pildi kokkupanemise hetkel.

Etapi valimise algoritm vahemälust põhineb Git-commitite suguluskontrollil:

Werf arvutab välja teatud etapi allkirja.
V stages-storage võib eksisteerida mitu etappi sama allkirja jaoks. Werf valib kõik sobivad allkirja järgi etapid.
Kui praegune etapp on seotud Git'iga (git-archive, kasutaja etapp Git'i patchidega: install, beforeSetup, setup; või git-latest-patch), siis werf valib ainult need etapid, mis on seotud commitiga, mis on praeguse commit'i eelkäija (mille jaoks on käivitatud koostamine).
Järelejäänud sobivate etappide hulgast valitakse üks — kõige vanem loomise kuupäeva järgi.

Erinevate Git-harude jaoks võib olla üks ja sama allkiri. Kuid werf takistab erinevate harude vahel sündikaedude kasutamist, isegi kui allkirjad kattuvad.

→ Dokumentatsioon.

Uus etappide loomise ja salvestamise algoritm etappide ladustamises

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

Tuleb märkida, et mitu protsessi (ühel või mitmel hostil) võivad alustada sama etapi kogumist peaaegu samal ajal. Werf kasutab optimistliku lukustamise algoritmi. stages-storage hetkel, kui uut ehitatud pilti salvestatakse stages-storage. Nii et kui uue etapi kogumine on valmis, lukustab werf stages-storage ja salvestab sinna uue ehitatud pildi ainult siis, kui seal juba ei eksisteeri sobivat pilti (allkirja ja teiste parameetrite alusel — vt. uusi etappide valimise algoritme vahemälust).

Uus ehitatud pilt omab garanteeritult unikaalset identifikaatorit TIMESTAMP_MILLISEC (vt. uusi etappide nimete vorme). Kui stages-storage leiad sobiva pildi, loob werf uue ehitatud pildi ja kasutab vahemälust pilti.

Teisisõnu: esimene protsess, mis lõpetab pildi kogumise (kiireim), saab õiguse salvestada selle stages-storage'i (ja see ainus pilt kasutatakse kõigi kogumiste jaoks). Aeglane kogumisprotsess ei blokeeri kunagi kiiremat protsessi, et salvestada kaudsete etappide kogumise tulemusi ja liikuda järgmise etapi kogumise juurde.

→ Dokumentatsioon.

Dockerfile'i komponendi jõudlust on parendatud

Praegu koosneb Dockerfile'ist koostatud piltide etappide torustik ühest etapist — dockerfile. Allkirja arvutamisel arvestatakse failide kontrollettevõttega context, mis kasutatakse koostamisel. Enne seda täiustust läbis werf rekursiivselt kõik failid ja sai kontrollsummat, liites iga faili konteksti ja muutuja. Alates versioonidest v1.1 saab werf kasutada arvutatud kontrollettevõtteid, mis on salvestatud Git-repositooriumisse.

Algrütm põhineb git ls-tree. Algoritm arvestab sissekandeid .dockerignore ja läbib rekursiivselt failipuud vaid vajadusel. Seega oleme lahti lasknud failisüsteemi lugemisest ning algoritmi sõltuvus suurusest context ei ole oluline.

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

Failide importimise tulemuslikkust on parendatud

Versioonides werf v1.1 kasutatakse rsync-serverit failide importimiseks artefaktidest ja piltidest. Varasemalt toimus importimine kahes etapis, kasutades hosti süsteemist kaustamontaaži.

macOS-i importide jõudlus ei ole enam piiratud Docker mahutitega, ning impordid toimuvad sama kiiresti kui Linuxis ja Windowsis.

Sisu põhine märgistamine

Werf v1.1 toetab nii nimetatud sisu põhist märgistamist piltide jaoks — sisu põhine märgistamine. Tulemuseks olevate Docker-piltide sildid sõltuvad nende piltide sisust.

Kui käivitate käsu werf publish --tags-by-stages-signature või werf ci-env --tagging-strategy=stages-signature publikule esitatavad pildid saavad nimetatud etappide allkiri pildist. Iga pilt on märgistatud omaenda etapi allkirjaga, mis arvutatakse samade reeglite järgi nagu iga etapi regulaarne allkiri eraldi, kuid on pildi üldistav identifikaator.

Etapi allkiri sõltub:

selle pildi sisust;
Git-i muudatuste ajaloost, mis viisid selle sisuni.

Git-i hoidlas on alati tühjad commitid, mis ei muuda pildi failide sisu. Näiteks commitid, millel on ainult kommentaarid või merge-commitid, või commitid, mis muudavad Git-is faile, mis ei lisandu pildile.

Content-based tagging lahendab Kubernetes'i rakenduste pod'ide üleliigse taaskäivitamise probleemid, mis tulenevad pildi nime muutmisest, isegi kui pildi sisu ei ole muutunud. See on üks põhjusi, miks on keeruline hoida mitmeid sama rakenduse mikroteenuseid ühes Git-repositooriumis.

Samuti on content-based tagging usaldusväärsem meetod kui Git-harude põhine tagimine, kuna lõpptoodetud piltide sisu ei sõltu pipeline'ide täitmise järjestusest CI-süsteemis mitme sama haru commit'i ehitamisel.

Oluline: alates käesolevast hetkest stages-signature — see on ainus soovitatav tagimisstrateegia. Just seda kasutatakse vaikimisi meeskonnas werf ci-env (kui ei ole selgelt määratud teist tagimisskeemi).

→ Dokumentatsioon. Sellele funktsioonile pühendatakse ka eraldi publikatsioon. UUENDATUD (3. aprill): Artikkel üksikasjadega on avaldatud.

Logimise tasemed

Kasutajal on nüüd võimalus kontrollida väljastust, määrata logimise taset ja töötada silumisinfo kallal. Lisatud on valikud --log-quiet, --log-verbose, --log-debug.

Vaikimisi sisaldab väljund minimaalset teavet:

Detailse väljundi kasutamisel (--log-verbose) on võimalik jälgida, kuidas werf töötab:

Detailne väljund (--log-debug), lisaks werfi silumise teabele sisaldab ka kasutatavate raamatukogude logisid. Näiteks saab näha, kuidas toimub suhtlemine Docker Registry'ga, ja fikseerida kohad, kus kulub märkimisväärselt aega:

Edasised plaanid

Tähelepanu! Allpool kirjeldatud võimalused, millel on silt v1.1 on juba selles versioonis saadaval, paljusid neist saadakse peagi. Uuendused tulevad läbi automaatsete uuenduste multiwerf'i kasutamisel. Need võimalused ei mõjuta v1.1 stabiilse funktsionaalsuse osa, nende tulek ei nõua kasutajalt juba olemasolevates konfiguratsioonides käsitsi sekkumist.

Täielik toetus erinevatele Docker Registry rakendustele (UUS)

Versioon: v1.1
Ajad: märts
Issue

Eesmärk — kasutaja peaks saama kasutada suvalist rakendust ilma piiranguteta werfi kasutamisel.

Praegu oleme määratlenud järgmise lahenduste komplekti, mille osas kavatseme tagada täieliku toe:

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

Tärniga märgitud lahendused on praeguseks täielikult toetatud werf'i poolt. Teiste jaoks on toetus olemas, kuid piirangutega.

Saab välja tuua kaks peamist probleemi:

Mõned lahendused ei toeta siltide kustutamist Docker Registry API kaudu, mis ei võimalda kasutajatel kasutada werf'is rakendatud automaatset puhastamist. See kehtib AWS ECR, Docker Hub'i ja GitHub Packages'i puhul.
Mõned lahendused ei toeta nn sisemisi repository'sid (Docker Hub, GitHub Packages ja Quay) või toetavad, kuid kasutaja peab need käsitsi looma, kasutades UI-d või API-t (AWS ECR).

Nende ja teiste probleemide lahendamiseks kavatseme kasutada lahenduste natiivseid API-sid. Selle ülesande alla kuulub ka werf'i täiskäigu testide katmine igaühe jaoks.

Jaotatud piltide koostamine (↑)

Versioon: v1.2 v1.1 (selle võimaluse elluviimise prioriteet on suurenenud)
Ajaraam: märts-aprill märts
Issue

Praegu saab werf v1.0 ja v1.1 kasutada ainult ühel eraldatud hostil kogumise ja piltide avaldamise operatsioonide ning rakenduse juurutamise jaoks Kuberneteses.

Werf'i mitme töö võimaluste avamiseks, kui rakenduste koostamine ja juurutamine Kuberneteses käivitatakse mitmel suvalisel hostil, mille olekut ei salvestata koostamiste vahel (ajutised runner'id), on vajalik, et werf toetaks Docker Registry kasutamist etappide hoidmiseks.

Varem, kui werf'i projekt kandis veel nime dapp, oli see võimalus olemas. Kuid seisis silmitsi mitmete probleemidega, mida tuleb arvesse võtta selle funktsiooni teostamisel werf'is.

Märkus. See võimalus ei hõlma koostajate tööd Kuberneteses pod'ides, kuna selleks on vaja loobuda sõltuvusest lokaalsest Docker-serverist (Kuberneteses pod'is ei ole juurdepääsu lokaalsele Docker-serverile, kuna protsess ise töötab konteineris, ning werf ei toeta ja ei toeta juurdepääsu Docker-serverile üle võrgu). Tugi Kuberneteses töötamiseks rakendatakse eraldi.

Ametlik tugi GitHub Actions (UUENDUS)

Versioon: v1.1
Ajad: märts
Issue

Hõlmab werf'i dokumentatsiooni (osad viidatud ja juhend), samuti ametlikku GitHub Action'it werf'iga töötamiseks.

Lisaks võimaldab werf'il töötada efemeraalsetel runner'itel.

Kasutaja interaktsioon CI-süsteemiga põhineb label'ite määramisel pull-request'idele, et algatada teatud tegevusi rakenduse kogumise/elustamise jaoks.

Rakenduste kohalik arendamine ja juurutamine werf'iga (↓)

Versioon: v1.1
Aeg: jaanuar-veebruar aprill
Issue

Peamine eesmärk on saavutada ühtne ja ühtlustatud konfigureerimine rakenduste juurutamiseks nii kohalikus keskkonnas kui ka tootmises, ilma keeruliste tegevusteta, 'karbist välja'.

Werfilt oodatakse ka sellist töörežiimi, kus rakenduskoodi on mugav redigeerida ja kohe tagasisidet saada töötava rakenduse kohta veaotsinguks.

Uus puhastusalgoritm (UUED)

Versioon: v1.1
Aeg: aprill
Issue

Praeguses versioonis werf v1.1 menetluses cleanup ei ole ette nähtud pildi puhastamiseks sisu põhjalikest märgistamisstrateegiatest (content-based tagging) — need pildid hakkavad kuhjuma.

Samuti kasutavad praegused wersf versioonid (v1.0 ja v1.1) erinevaid puhastuspolitikaid piltide jaoks, mis on avaldatud märgistamisstrateegiate järgi: Git haru, Git silt või Git commit.

On välja mõeldud uus ühtne piltide puhastusalgoritm, mis põhineb commitide ajaloos Git:

Hoida mitte rohkem kui N1 pilti, mis on seotud N2 viimase commitiga igas git HEAD-is (harudes ja silti).
Hoida mitte rohkem kui N1 faasipilti, mis on seotud N2 viimase commitiga igas git HEAD-is (harudes ja silti).
Hoida kõik pildid, mida kasutatakse Kubernetes klastrite ressurssides (uskumused skaneeritakse kõikidele kube-konfiguratsioonifailide kontekstidele ja namespace'idele; seda käitumist saab piirata erivõimalustega).
Hoida kõik pildid, mida kasutatakse ressursside konfiguratsiooni manfestides, mis on salvestatud Helm'i väljaannetes.
Pilt võib olla kustutatud, kui see pole seotud ühegi git HEAD-iga (näiteks, kuna vastav HEAD on kustutatud) ja seda ei kasutata üheski manfestis Kubernetes klastris ega Helm'i väljaannetes.

Paralleelne piltide koostamine (↓)

Versioon: v1.1
Ajakava: jaanuar-veebruar aprill*

Praegune wersioon werf kogub pilte ja artefakte, mis on kirjeldatud werf.yaml, järjekorras. On vajalik iseseisvate etappide piltide ja artefaktide koostamisprotsessi paralleelne ülesehitamine ning mugava ja informatiivse väljundi tagamine.

* Märkus: tähtaeg on edasi lükatud, et suurendada prioriteeti ja rakendada jaotatud koostööd, mis lisab rohkem horisontaalse skaaleerimise võimalusi ning võimaldab kasutada werfi koos GitHub Actions'iga. Paralleelne koostamine on järgmine optimeerimise samm, mis pakub vertikaalset skaaleeritavust ühe projekti koostamisel.

Üleminek Helm 3-le (↓)

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

Sisaldab üleminekut uuele koodibaasile Helm 3 ja katsetatud, mugav viis olemasolevate paigaldiste migreerimiseks.

* Märkus: üleminek Helm 3-le ei too werfisse olulisi uusi võimalusi, kuna kõik Helm 3 peamised funktsioonid (3-way-merge ja tilleri puudumine) on juba werfis rakendatud. Veelgi enam, werfil on täiendavad võimalused lisaks nendele, mida on loetletud. Siiski jääb see üleminek meie plaanidesse ja rakendatakse.

Jsonnet Kubernetes'i konfiguratsiooni kirjeldamiseks (↓)

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

Werf toetab Kubernetes'i konfiguratsiooni kirjeldamist Jsonnet formaadis. Samal ajal jääb werf Helmiga ühilduvaks ning on võimalik valida kirjeldusformaati.

Põhjus on see, et Go keele mallidel on paljude arvates suur sisenemisbarjäär ning nende mallide kood on ka raskesti mõistetav.

Samuti kaalutakse teiste Kubernetes'i konfigureerimissüsteemide, näiteks Kustomize'i, rakendamise võimalust.

Töö Kubernetes'is (↓)

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

Eesmärk: tagada piltide koostamine ja rakenduse tarnimine runner'ite kasutamisega Kubernetes'is. See tähendab, et uusi pilte saab koostada, avaldada, puhastada ja juurutada otse Kubernetes'i pod'idest.

Selle võimaluse rakendamiseks on kõigepealt vajalik jaotatud piltide koostamise võimalus (vt eelmist punkti).

Samuti on vajalik toetada koostamisseisundi tööd ilma Docker'i serverita (st Kaniko-sarnane koostamine või koostamine kasutajaruumi).

Werf toetab koostamist Kubernetes'is mitte ainult Dockerfile'i kaudu, vaid ka oma koostaja Stapeli kaudu, mis võimaldab inkrementaalseid uuesti koostamisi ja Ansible'i kasutamist.

Samm avatud arenduse suunas

Me armastame oma kogukonda (GitHub, Telegram) ja soovime, et üha rohkem inimesi aitaks werfi paremaks muuta, mõistaks, kuhu suunas me liigume, ja osaleks arenduses.

Hiljuti otsustati перейти на GitHub'i projekti tahvlid et avada meie tiimi tööprotsesse. Hetkel on saadaval ülevaade lähituleviku plaanidest ning hetkeolukorrast järgmistes valdkondades:

On tehtud suur töö issues'idega:

Ebaolulised on eemaldatud.
Olemasolevad on viidud ühtsesse formaati, piisavalt detailide ja üksikasjade hulgaga.
Sisse on viidud uusi issues'id ideedega ja ettepanekutega.

Kuidas aktiveerida versioon v1.1

Versioon on praegu saadaval 1.1 ea kanalil. (kanalites stabiilseks ja rock-solid väljalasked ilmuvad stabiilsuse saavutamisega, kuid ees see on juba iseenesest piisavalt stabiilne kasutamiseks, kuna see on läbinud kanalid alpha ja beta). Aktiveeritakse multiwerf'i kaudu järgmist viisi:

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

Kokkuvõte

Uus etappide salvestamise arhitektuur ja kogumise optimeerimine Stapel ja Dockerfile kogujate jaoks avavad võimalused jaotatud ja paralleelsete kogumiste rakendamiseks werf'is. Need võimalused ilmuvad varsti samas versioonis v1.1 ning on automaatselt saadaval automaatse uuendamise mehhanismi kaudu (kasutajatele multiwerf).

Selles väljalaskes on lisatud piltide sisu põhine märgistamisstrateegia — sisu põhine märgistamine, — mis on vaikimisi strateegia. Samuti on üle töötatud põhikomandide loogika: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

Järgmine oluline samm on hajusate ehituste lisamine. Hajusad ehitused on alates v1.0 saanud kõrgema prioriteedi kui paralleelsed ehitused, kuna need pakuvad werfile suuremat väärtust: vertikaalne koormuse skaleerimine ehitajates ja ajutiste ehitajate tugi erinevates CI/CD süsteemides, samuti võimalus ametlikuks toeks GitHub Actions'ile. Seetõttu on paralleelsete ehituste rakendamise tähtaeg edasi lükatud. Töötame aga selle nimel, et mõlemad võimalused võimalikult kiiresti ellu viia.

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