on meie avatud lähtekoodiga GitOps CLI utiliit rakenduste loomiseks ja Kubernetesesse tarnimiseks. Nagu lubatud, tähistas werfi uute funktsioonide lisamise ja traditsiooniliste lähenemisviiside läbivaatamise algust. Nüüd on meil hea meel esitleda versiooni v1.1, mis on suur samm arengus ja alus tulevikuks koguja werf. Versioon on praegu saadaval keeles .
Väljalaske aluseks on lavasalvestuse uus arhitektuur ja mõlema koguja (Stapeli ja Dockerfile) töö optimeerimine. Uus salvestusarhitektuur avab võimaluse juurutada hajutatud kooste mitmelt hostilt ja paralleelselt samal hostil.
Töö optimeerimine hõlmab tarbetutest arvutustest vabanemist etapisignatuuride arvutamise etapis ja failide kontrollsummade arvutamise mehhanismide muutmist tõhusamaks. See optimeerimine vähendab werfi abil projekti ehitamise keskmist aega. Ja jõudeolekus järgud, kui kõik etapid on vahemälus olemas etapid-ladustamine, on nüüd tõesti kiired. Enamikul juhtudel võtab ehituse taaskäivitamine vähem kui 1 sekundi! See kehtib ka meeskondade tööprotsessi etappide kontrollimise protseduuride kohta. werf deploy и werf run.
Ka selles väljaandes ilmus piltide sisu järgi märgistamise strateegia - sisupõhine märgistamine, mis on nüüd vaikimisi lubatud ja ainus soovitatav.
Vaatame lähemalt werf v1.1 peamisi uuendusi ja räägime samal ajal tulevikuplaanidest.
Mis on versioonis werf v1.1 muutunud?
Uus etappide nimetamise formaat ja algoritm vahemälust etappide valimiseks
Uus lavanimede genereerimise reegel. Nüüd genereerib iga etapi järg kordumatu lavanime, mis koosneb kahest osast: allkirjast (nagu see oli versioonis 2) ja ainulaadsest ajutisest identifikaatorist.
Näiteks võib lavapildi täisnimi välja näha järgmine:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
...või üldiselt:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Siin:
-
SIGNATUREon lavasignatuur, mis tähistab lava sisu identifikaatorit ja sõltub selle sisuni viinud Giti muudatuste ajaloost; -
TIMESTAMP_MILLISECon garanteeritud kordumatu pildiidentifikaator, mis luuakse uue kujutise loomise ajal.
Vahemälust etappide valimise algoritm põhineb Giti kohustuste seoste kontrollimisel:
- Werf arvutab teatud etapi signatuuri.
- В etapid-ladustamine Antud allkirja jaoks võib olla mitu etappi. Werf valib kõik etapid, mis vastavad signatuurile.
- Kui praegune etapp on lingitud Gitiga (git-arhiiv, kohandatud etapp Giti paikadega:
install,beforeSetup,setup; või git-latest-patch), siis werf valib ainult need etapid, mis on seotud commitiga, mis on praeguse commit (mille jaoks ehitamist kutsutakse) eellane. - Ülejäänud sobivatest etappidest valitakse välja üks – loomise kuupäeva järgi vanim.
Erinevate Giti filiaalide etapil võib olla sama signatuur. Kuid werf takistab erinevate harudega seotud vahemälu kasutamist nende harude vahel, isegi kui allkirjad kattuvad.
.
Uus algoritm etappide loomiseks ja salvestamiseks etapi salvestamiseks
Kui vahemälust etappe valides ei leia werf sobivat etappi, siis käivitatakse uue etapi kokkupanemise protsess.
Pange tähele, et mitu protsessi (ühel või mitmel hostil) võivad alustada sama etapi loomist ligikaudu samal ajal. Werf kasutab optimistlikku blokeerimisalgoritmi etapid-ladustamine värskelt kogutud pildi salvestamise hetkel etapid-ladustamine. Niimoodi, kui uus lavaehitus on valmis, werf plokid etapid-ladustamine ja salvestab sinna värskelt kogutud pildi ainult siis, kui sobivat pilti seal enam ei eksisteeri (allkirja ja muude parameetrite järgi - vaadake vahemälust etappide valimise uut algoritmi).
Värskelt kokkupandud pildil on garanteeritud kordumatu identifikaator TIMESTAMP_MILLISEC (vt uut etapi nime vormingut). Juhul kui sisse etapid-ladustamine leitakse sobiv pilt, werf loobub värskelt koostatud pildist ja kasutab pilti vahemälust.
Teisisõnu: esimene protsess, mis lõpetab pildi koostamise (kõige kiirem), saab õiguse salvestada see etapiviisiliselt (ja seejärel kasutatakse seda ühte pilti kõigis ehitustes). Aeglane ehitusprotsess ei takista kunagi kiiremal protsessil praeguse etapi ehitustulemuste salvestamist ja järgmise järgu juurde liikumist.
.
Täiustatud Dockerfile'i koostaja jõudlus
Praegu koosneb Dockerfile'ist koostatud pildi etappide torustik ühest etapist - dockerfile. Allkirja arvutamisel arvutatakse failide kontrollsumma context, mida kasutatakse kokkupanekul. Enne seda täiustust käis werf rekursiivselt läbi kõik failid ja sai iga faili konteksti ja režiimi liitmise teel kontrollsumma. Alates versioonist 1.1 saab werf kasutada arvutatud kontrollsummasid, mis on salvestatud Giti hoidlasse.
Algoritm põhineb . Algoritm võtab arvesse kirjeid .dockerignore ja läbib failipuu rekursiivselt ainult vajaduse korral. Seega oleme lahti sidunud failisüsteemi lugemise ja algoritmi sõltuvuse suurusest context ei ole märkimisväärne.
Algoritm kontrollib ka jälgimata faile ja vajadusel võtab neid kontrollsummas arvesse.
Parem jõudlus failide importimisel
Versioonid werf v1.1 kasutavad rsync-serverit, kui . Varem toimus importimine kahes etapis, kasutades hostisüsteemi kataloogiühendust.
MacOS-i importimise jõudlust ei piira enam Dockeri mahud ning importimine lõpeb sama ajaga kui Linux ja Windows.
Sisupõhine märgistamine
Werf v1.1 toetab nn pildi sisu järgi märgistamist - sisupõhine märgistamine. Saadud Dockeri piltide sildid sõltuvad nende piltide sisust.
Käsu käivitamisel werf publish --tags-by-stages-signature või werf ci-env --tagging-strategy=stages-signature avaldatud pilte nn lavasignatuur pilt. Iga pilt on märgistatud selle pildi etappide oma signatuuriga, mis arvutatakse samade reeglite järgi nagu iga etapi tavaline signatuur eraldi, kuid on pildi üldine identifikaator.
Kujutise etappide signatuur sõltub:
- selle pildi sisu;
- selle sisuni viinud Giti muudatuste ajalugu.
Git-hoidlal on alati näivkohustused, mis ei muuda pildifailide sisu. Näiteks võtab sisse ainult kommentaaride või liitmistoimingutega või võtab kasutusele, mis muudab Gitis neid faile, mida pildile ei impordita.
Sisupõhise sildistamise kasutamisel lahenevad Kubernetese rakendusepodide tarbetute taaskäivituste probleemid, mis on tingitud pildi nime muutmisest, isegi kui pildi sisu pole muutunud. Muide, see on üks põhjusi, mis takistab ühe rakenduse paljude mikroteenuste salvestamist ühte Giti hoidlasse.
Samuti on sisupõhine sildistamine usaldusväärsem märgistamismeetod kui Git filiaalidel sildistamine, sest tekkivate piltide sisu ei sõltu sellest, millises järjekorras CI-süsteemis konveierid ühe haru mitme commit kokkupanemiseks täidetakse.
Oluline: alates praegusest etapid-signatuur - Kas ainus soovitatav märgistamisstrateegia. Seda kasutatakse käsus vaikimisi werf ci-env (välja arvatud juhul, kui määrate selgesõnaliselt teistsuguse märgistamisskeemi).
. Sellele funktsioonile pühendatakse ka eraldi väljaanne. VÄRSKENDATUD (3. aprill): artikkel üksikasjadega .
Logimise tasemed
Kasutajal on nüüd võimalus juhtida väljundit, määrata logimise taset ja töötada silumisinfoga. Valikud lisatud --log-quiet, --log-verbose, --log-debug.
Vaikimisi sisaldab väljund minimaalset teavet:
Kui kasutate paljusõnalist väljundit (--log-verbose) näete, kuidas werf töötab:
Üksikasjalik väljund (--log-debug), sisaldab lisaks werfi silumisinfole ka kasutatud teekide logisid. Näiteks näete, kuidas toimub suhtlemine Dockeri registriga, ja salvestada ka kohad, kus kulutatakse palju aega:
Edasised plaanid
Hoiatus! Allpool kirjeldatud valikud on märgitud v1.1 saadaval selles versioonis, paljud neist lähitulevikus. Värskendused tulevad automaatvärskenduste kaudu . Need funktsioonid ei mõjuta v1.1 funktsioonide stabiilset osa; nende välimus ei nõua olemasolevates konfiguratsioonides kasutaja käsitsi sekkumist.
Täielik tugi erinevatele Dockeri registri rakendustele (UUS)
- Versioon: v1.1
- Kuupäevad: märts
Eesmärk on, et kasutaja kasutaks werfi kasutamisel piiranguteta kohandatud teostust.
Praegu oleme tuvastanud järgmised lahendused, millele kavatseme tagada täieliku toe:
- Vaikimisi (raamatukogu/register)*,
- AWS ECR
- Azure*,
- Dockeri jaotur
- GCR*,
- GitHubi paketid
- GitLabi register*,
- sadam*,
- Kai.
Lahendused, mida werf praegu täielikult toetab, on tähistatud tärniga. Teiste jaoks on olemas tugi, kuid piirangutega.
Eristada saab kahte peamist probleemi:
- Mõned lahendused ei toeta sildi eemaldamist Dockeri registri API abil, mis takistab kasutajatel kasutada werfi automaatset puhastust. See kehtib AWS ECR, Docker Hubi ja GitHubi pakettide kohta.
- Mõned lahendused ei toeta nn pesastatud hoidlaid (Docker Hub, GitHub Packages ja Quay) või toetavad seda, kuid kasutaja peab need looma kasutajaliidese või API (AWS ECR) abil käsitsi.
Me lahendame need ja muud probleemid lahenduste natiivsete API-de abil. See ülesanne hõlmab ka werfi toimimise kogu tsükli katmist kõigi nende testidega.
Jaotatud pildi koostamine (↑)
- Versioon: v1.2 v1.1 (selle funktsiooni rakendamise prioriteetsust on suurendatud)
- Kuupäevad: märts-aprill märts
Praegu saab werf v1.0 ja v1.1 kasutada ainult ühes spetsiaalses hostis piltide loomiseks ja avaldamiseks ning rakenduse Kubernetesesse juurutamiseks.
werfi hajutatud töö võimaluste avamiseks, kui Kubernetes rakenduste ehitamine ja juurutamine käivitatakse mitmel suvalisel hostil ja need hostid ei salvesta oma olekut ehitamiste vahel (ajutised jooksjad), on vaja werf-i juurutada kasutusvõimalus Dockeri register lavakauplusena.
Varem, kui werfi projekti nimi oli veel dapp, oli tal selline võimalus. Siiski oleme kokku puutunud mitmete probleemidega, mida tuleb selle funktsiooni rakendamisel werfis arvestada.
Märkus. See funktsioon ei nõua, et kollektor töötaks Kubernetese kaustade sees, kuna Selleks peate vabanema sõltuvusest kohalikust Dockeri serverist (Kubernetes podis puudub juurdepääs kohalikule Dockeri serverile, kuna protsess ise töötab konteineris ja werf ei toeta ega toeta töötamine Dockeri serveriga üle võrgu). Kubernetese käitamise tugi juurutatakse eraldi.
GitHub Actionsi ametlik tugi (UUS)
- Versioon: v1.1
- Kuupäevad: märts
Sisaldab werf-dokumentatsiooni (jaotised viide и suunata), samuti ametlik GitHubi toiming werfiga töötamiseks.
Lisaks võimaldab see werfil töötada lühiajaliste jooksjate kallal.
Kasutaja interaktsiooni mehaanika CI-süsteemiga põhineb tõmbepäringutele siltide paigutamisel, et käivitada teatud toiminguid rakenduse koostamiseks/levitamiseks.
Kohalik arendus ja rakenduste juurutamine werf-iga (↓)
- Versioon: v1.1
- Kuupäevad: jaanuar-veebruar aprill
Peamine eesmärk on saavutada ühtne ühtne konfiguratsioon rakenduste juurutamiseks nii kohapeal kui ka tootmises ilma keeruliste toiminguteta.
Samuti peab werf omama töörežiimi, milles on mugav rakenduse koodi redigeerida ja saada silumiseks koheselt töötavalt rakenduselt tagasisidet.
Uus puhastusalgoritm (UUS)
- Versioon: v1.1
- Kuupäevad: aprill
Praeguses versioonis werf v1.1 protseduuris cleanup Sisupõhise märgistamisskeemi jaoks pole ette nähtud piltide puhastamist – need pildid kogunevad.
Samuti kasutab werfi praegune versioon (v1.0 ja v1.1) märgistusskeemide alusel avaldatud piltide jaoks erinevaid puhastusreegleid: Git haru, Git tag või Git Commit.
Leiutati uus algoritm piltide puhastamiseks, mis põhineb Giti sissekannete ajalool ja mis on ühtne kõigi märgistamisskeemide jaoks:
- Iga git HEAD (harud ja sildid) jaoks ei tohi jätta rohkem kui N1 kujutist, mis on seotud N2 viimaste tagatistega.
- Iga git HEAD (harud ja sildid) jaoks ei tohi salvestada rohkem kui N1 etapi kujutist, mis on seotud N2 viimaste tagatistega.
- Salvestage kõik Kubernetese klastri ressurssides kasutatavad pildid (skannitakse kõiki konfiguratsioonifaili ja nimeruumide kube kontekste; saate seda käitumist erisuvanditega piirata).
- Salvestage kõik Helmi väljalasetesse salvestatud ressursikonfiguratsiooni manifestides kasutatavad pildid.
- Pildi saab kustutada, kui see ei ole seotud ühegi GITI HEAD-iga (näiteks kuna vastav HEAD ise on kustutatud) ja seda ei kasutata Kubernetese klastris ega Helmi väljaannetes üheski manifestis.
Paralleelne kujutise loomine (↓)
- Versioon: v1.1
- Kuupäevad: jaanuar-veebruar aprill*
Praegune werfi versioon kogub pilte ja artefakte, mida on kirjeldatud artiklis werf.yaml, järjestikku. Kujutiste ja artefaktide sõltumatute etappide kokkupanemise protsess on vajalik paralleelseks, samuti mugava ja informatiivse väljundi pakkumine.
* Märkus: tähtaega on nihutatud hajutatud kokkupaneku rakendamise prioriteedi suurenemise tõttu, mis lisab rohkem horisontaalse skaleerimise võimalusi, samuti werfi kasutamise tõttu koos GitHubi toimingutega. Paralleelne kokkupanek on järgmine optimeerimise samm, mis tagab ühe projekti kokkupanemisel vertikaalse mastaapsuse.
Üleminek roolile 3 (↓)
- Versioon: v1.2
- Kuupäevad: veebruar-märts mai*
Sisaldab migreerimist uude koodibaasi ning tõestatud ja mugav viis olemasolevate installatsioonide üleviimiseks.
* Märkus: Helm 3-le üleminek ei lisa werfile olulisi funktsioone, kuna kõik Helm 3 põhifunktsioonid (3-suunaline ühendamine ja tiislita) on werfis juba rakendatud. Veelgi enam, werfil on lisaks märgitud. See üleminek jääb aga meie plaanidesse ja viiakse ellu.
Jsonnet Kubernetese konfiguratsiooni kirjeldamiseks (↓)
- Versioon: v1.2
- Kuupäevad: jaanuar-veebruar aprill-mai
Werf toetab Kubernetese konfiguratsioonikirjeldusi Jsonnet-vormingus. Samal ajal jääb werf Helmiga ühilduvaks ja saab valida kirjelduse vormingu.
Põhjus on selles, et Go mallidel on paljude arvates kõrge sisenemisbarjäär ning kannatab ka nende mallide koodide arusaadavus.
Kaalutakse ka teiste Kubernetese konfiguratsiooni kirjeldussüsteemide (näiteks Kustomize) juurutamist.
Kuberneteses töötamine (↓)
- Versioon: v1.2
- Kuupäevad: aprill-mai mai-juuni
Eesmärk: veenduge, et kujutised koostatakse ja rakendus tarnitakse Kubernetese jooksjate abil. Need. Uusi pilte saab luua, avaldada, puhastada ja juurutada otse Kubernetese kaustadest.
Selle võimaluse rakendamiseks peate esmalt suutma luua hajutatud pilte (vt ülaltoodud punkti).
See nõuab ka ehitaja töörežiimi tuge ilma Dockeri serverita (st Kaniko-laadne ehitamine või kasutajaruumis ehitamine).
Werf ei toeta Kubernetesele ehitamist mitte ainult Dockerfile'i, vaid ka oma Stapeli ehitajaga koos järkjärguliste ümberehitustega ja Ansible'iga.
Samm avatud arengu suunas
Me armastame oma kogukonda (, ) ja soovime, et üha rohkem inimesi aitaks werfi paremaks muuta, mõistaks, millises suunas liigume, ja osaleks arenduses.
Üsna hiljuti otsustati üle minna et paljastada meie meeskonna tööprotsess. Nüüd näete lähiplaane ja praegust tööd järgmistes valdkondades:
- ;
- ;
- ;
- .
Palju tööd on tehtud probleemidega:
- Ebaolulised eemaldati.
- Olemasolevad on viidud ühtsesse formaati, piisava hulga detaile ja detaile.
- Lisatud on uusi väljaandeid ideede ja ettepanekutega.
Kuidas lubada versiooni v1.1
Versioon on praegu saadaval keeles (kanalites stabiilne и kivikõva vabanemised ilmuvad siiski stabiliseerumisel ea ise on juba kasutamiseks piisavalt stabiilne, sest kanaleid läbi käinud alfa и beeta). Aktiveeritud järgmisel viisil:
source $(multiwerf use 1.1 ea)
werf COMMAND ...Järeldus
Stapeli ja Dockerfile'i koostajate uus etapi salvestusarhitektuur ja koostaja optimeerimised avavad võimaluse juurutada werfis hajutatud ja paralleelseid ehitusi. Need funktsioonid ilmuvad peagi samas versioonis 1.1 ja muutuvad automaatselt kättesaadavaks automaatse värskendusmehhanismi kaudu (kasutajatele ).
Sellesse väljaandesse on lisatud pildi sisul põhinev sildistamisstrateegia – sisupõhine märgistamine, millest on saanud vaikestrateegia. Peamine käsulogi on samuti ümber töödeldud: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
Järgmine oluline samm on hajutatud sõlmede lisamine. Alates versioonist 1.0 on hajutatud järgud muutunud prioriteetsemaks kui paralleelsed järgud, kuna need lisavad werfile rohkem väärtust: koostajate vertikaalne skaleerimine ja toetus lühiajalistele koostajatele erinevates CI/CD süsteemides, samuti võimalus GitHubi toiminguid ametlikult toetada. . Seetõttu nihutati paralleelkoostude rakendamise tähtaegu. Kuid me töötame selle nimel, et mõlemad võimalused võimalikult kiiresti kasutusele võtta.
Jälgi uudiseid! Ja ärge unustage meid külastada aadressil probleemi loomiseks, leidke olemasolev ja lisage pluss, looge PR või lihtsalt jälgige projekti arengut.
PS
Loe ka meie blogist:
- «»
- «";
- Märkuste sari werfi uuenduste kohta:
- «";
- «";
- «";
- «'.
Allikas: www.habr.com