🥇Werf 1.1 -julkaisu: parannuksia keräilijässä tänään ja tulevaisuuden suunnitelmia

werf on avoimen lähdekoodin GitOps CLI -apuohjelma sovellusten rakentamiseen ja toimittamiseen Kubernetesille. Kuten luvattu, version 1.0 julkaisu merkitsi alkua uusien ominaisuuksien lisäämiselle werfiin ja perinteisten lähestymistapojen tarkistamiselle. Nyt meillä on ilo esitellä versio 1.1, joka on iso askel kehityksessä ja perusta tulevaisuudelle keräilijä werf. Versio on tällä hetkellä saatavilla kielellä kanava 1.1 ea.

Julkaisun perustana on uusi lavatallennusarkkitehtuuri ja molempien kerääjien työn optimointi (Stapelille ja Dockerfilelle). Uusi tallennusarkkitehtuuri avaa mahdollisuuden toteuttaa hajautettuja kokoonpanoja useista isännistä ja rinnakkaisia kokoonpanoja samassa isännässä.

Työn optimointi sisältää tarpeettomien laskelmien poistamisen vaiheiden allekirjoitusten laskentavaiheessa ja tiedostojen tarkistussummien laskentamekanismien muuttamisen tehokkaampiin. Tämä optimointi lyhentää projektin keskimääräistä rakennusaikaa werf:ää käyttämällä. Ja tyhjäkäynnit, kun kaikki vaiheet ovat olemassa välimuistissa vaiheet-varastointi, ovat nyt todella nopeita. Useimmissa tapauksissa rakentamisen uudelleen käynnistäminen kestää alle 1 sekunnin! Tämä koskee myös työryhmien työprosessin vaiheiden todentamismenettelyjä. werf deploy и werf run.

Myös tässä julkaisussa ilmestyi strategia kuvien merkitsemiseksi sisällön mukaan - sisältöön perustuva koodaus, joka on nyt oletuksena käytössä ja ainoa suositeltu.

Katsotaanpa lähemmin werf v1.1:n tärkeimpiä innovaatioita ja kerrotaan samalla tulevaisuuden suunnitelmista.

Mikä on muuttunut werf v1.1:ssä?

Uusi vaiheiden nimeämismuoto ja algoritmi vaiheiden valitsemiseen välimuistista

Uusi taiteilijanimen generointisääntö. Nyt jokainen vaiheversio luo yksilöllisen vaihenimen, joka koostuu kahdesta osasta: allekirjoituksesta (kuten se oli versiossa 2) sekä ainutlaatuisesta väliaikaisesta tunnisteesta.

Esimerkiksi koko näyttämökuvan nimi voi näyttää tältä:

werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835

...tai yleisesti:

werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC

tässä:

SIGNATURE on vaiheen allekirjoitus, joka edustaa lavasisällön tunnistetta ja riippuu tähän sisältöön johtaneiden Gitin muokkaushistoriasta;
TIMESTAMP_MILLISEC on taattu ainutlaatuinen kuvan tunniste, joka luodaan uuden kuvan rakentamisen yhteydessä.

Algoritmi vaiheiden valitsemiseksi välimuistista perustuu Git-sitoumusten suhteen tarkistamiseen:

Werf laskee tietyn vaiheen allekirjoituksen.
В vaiheet-varastointi Tietylle allekirjoitukselle voi olla useita vaiheita. Werf valitsee kaikki vaiheet, jotka vastaavat allekirjoitusta.
Jos nykyinen vaihe on linkitetty Gitiin (git-arkisto, mukautettu vaihe Git-korjauspäivityksillä: install, beforeSetup, setup; tai git-latest-patch), werf valitsee vain ne vaiheet, jotka liittyvät toimitukseen, joka on nykyisen toimituksen esi-isä (jonka koonti on kutsuttu).
Jäljellä olevista sopivista vaiheista valitaan yksi - vanhin luomispäivän mukaan.

Eri Git-haarojen vaiheessa voi olla sama allekirjoitus. Mutta werf estää eri haaroihin liittyvän välimuistin käytön näiden haarojen välillä, vaikka allekirjoitukset täsmäävät.

→ Dokumentaatio.

Uusi algoritmi vaiheiden luomiseen ja tallentamiseen vaihevarastossa

Jos werf ei löydä välimuistista vaiheita valitessaan sopivaa vaihetta, käynnistetään uuden vaiheen kokoaminen.

Huomaa, että useat prosessit (yhdessä tai useammassa isännässä) voivat aloittaa saman vaiheen rakentamisen suunnilleen samaan aikaan. Werf käyttää optimistista estoalgoritmia vaiheet-varastointi juuri kerätyn kuvan tallennushetkellä vaiheet-varastointi. Tällä tavalla, kun uusi vaiherakennus on valmis, werf-lohkot vaiheet-varastointi ja tallentaa juuri kerätyn kuvan sinne vain, jos sopivaa kuvaa ei enää ole siellä (allekirjoituksella ja muilla parametreilla - katso uusi algoritmi vaiheiden valitsemiseksi välimuistista).

Juuri kootulla kuvalla on taatusti yksilöllinen tunniste TIMESTAMP_MILLISEC (katso uusi vaiheiden nimeämismuoto). Siinä tapauksessa sisään vaiheet-varastointi sopiva kuva löytyy, werf hylkää juuri kootun kuvan ja käyttää kuvaa välimuistista.

Toisin sanoen: ensimmäinen prosessi, joka viimeistelee kuvan rakentamisen (nopein), saa oikeuden tallentaa se vaiheittaiseen tallennustilaan (ja sitten tämä yksittäinen kuva on sitä, jota käytetään kaikissa rakennelmissa). Hidas rakennusprosessi ei koskaan estä nopeampaa prosessia tallentamasta nykyisen vaiheen koontiversioita ja siirtymästä seuraavaan koontiversioon.

→ Dokumentaatio.

Parannettu Dockerfile Builderin suorituskyky

Tällä hetkellä Docker-tiedostosta rakennetun kuvan vaiheiden putkisto koostuu yhdestä vaiheesta - dockerfile. Allekirjoitusta laskettaessa lasketaan tiedostojen tarkistussumma context, jota käytetään asennuksen aikana. Ennen tätä parannusta werf kävi rekursiivisesti läpi kaikki tiedostot ja sai tarkistussumman summaamalla kunkin tiedoston kontekstin ja tilan. V1.1:stä alkaen werf voi käyttää Git-tietovarastoon tallennettuja laskettuja tarkistussummia.

Algoritmi perustuu git ls-tree. Algoritmi ottaa huomioon tietueet .dockerignore ja kulkee tiedostopuun läpi rekursiivisesti vain tarvittaessa. Näin ollen olemme eronneet tiedostojärjestelmän lukemisesta ja algoritmin riippuvuudesta koosta context ei ole merkittävää.

Algoritmi tarkistaa myös jäljittämättömät tiedostot ja ottaa ne tarvittaessa huomioon tarkistussummassa.

Parempi suorituskyky tiedostojen tuonnissa

Versiot werf v1.1 käyttävät rsync-palvelinta, kun tiedostojen tuominen esineistä ja kuvista. Aikaisemmin tuonti tehtiin kahdessa vaiheessa isäntäjärjestelmän hakemistoliitännällä.

Dockerin määrät eivät enää rajoita tuonnin suorituskykyä macOS:ssä, ja tuonti valmistuu samassa ajassa kuin Linux ja Windows.

Sisältöpohjainen taggaus

Werf v1.1 tukee niin sanottua kuvasisällön taggausta - sisältöön perustuva koodaus. Tuloksena olevien Docker-kuvien tunnisteet riippuvat näiden kuvien sisällöstä.

Kun suoritat komentoa werf publish --tags-by-stages-signature tai werf ci-env --tagging-strategy=stages-signature julkaistuja kuvia ns vaiheen allekirjoitus kuva. Jokainen kuva on merkitty omalla allekirjoituksellaan tämän kuvan vaiheista, joka lasketaan samojen sääntöjen mukaan kuin kunkin vaiheen tavallinen allekirjoitus erikseen, mutta on kuvan yleinen tunniste.

Kuvavaiheiden allekirjoitus riippuu:

tämän kuvan sisältö;
tähän sisältöön johtaneiden Git-muutosten historiat.

Git-varastossa on aina valetoimituksia, jotka eivät muuta kuvatiedostojen sisältöä. Sitoutuu esimerkiksi vain kommenteilla tai yhdistämistoimituksilla tai sitoumuksilla, jotka muuttavat Gitissä olevia tiedostoja, joita ei tuoda kuvaan.

Sisältöpohjaista taggausta käytettäessä ratkaistaan Kubernetesin tarpeettomien sovellusten uudelleenkäynnistysten ongelmat kuvan nimen muutoksista, vaikka kuvan sisältö ei olisi muuttunut. Muuten, tämä on yksi syistä, joka estää useiden yhden sovelluksen mikropalveluiden tallentamisen yhteen Git-tietovarastoon.

Myös sisältöpohjainen taggaus on luotettavampi koodausmenetelmä kuin tägäys Git-haaroihin, koska tuloksena olevien kuvien sisältö ei riipu siitä, missä järjestyksessä liukuhihnat suoritetaan CI-järjestelmässä saman haaran useiden toimitusten kokoamiseksi.

On tärkeää: tästä lähtien vaiheet-allekirjoitus - Onko ainoa suositeltu merkintästrategia. Sitä käytetään oletuksena komennossa werf ci-env (ellet nimenomaisesti määritä erilaista merkintäjärjestelmää).

→ Dokumentaatio. Tälle ominaisuudelle omistetaan myös erillinen julkaisu. PÄIVITETTY (3. huhtikuuta): Artikkeli yksityiskohdista julkaistu.

Kirjaustasot

Käyttäjällä on nyt mahdollisuus ohjata lähtöä, asettaa lokitason ja käsitellä virheenkorjaustietoja. Vaihtoehdot lisätty --log-quiet, --log-verbose, --log-debug.

Oletusarvoisesti tulos sisältää vähimmäistiedot:

Kun käytät sanallista tulostetta (--log-verbose) näet kuinka werf toimii:

Yksityiskohtainen tulos (--log-debug), sisältää werf-virheenkorjaustietojen lisäksi myös käytettyjen kirjastojen lokit. Voit esimerkiksi nähdä, kuinka vuorovaikutus Docker-rekisterin kanssa tapahtuu, ja myös tallentaa paikat, joissa kuluu huomattava määrä aikaa:

Lisäsuunnitelmat

Varoitus! Alla kuvatut vaihtoehdot on merkitty v1.1 tulee saataville tässä versiossa, monet niistä lähitulevaisuudessa. Päivitykset tulevat automaattisten päivitysten kautta käytettäessä multiwerfiä. Nämä ominaisuudet eivät vaikuta v1.1-toimintojen vakaaseen osaan; niiden ulkoasu ei vaadi käyttäjän manuaalista puuttumista olemassa oleviin kokoonpanoihin.

Täysi tuki erilaisille Docker Registry -toteutuksille (UUSI)

Versio: v1.1
Päivämäärät: maaliskuu
Kysymys

Tavoitteena on, että käyttäjä käyttää mukautettua toteutusta ilman rajoituksia käyttäessään werfiä.

Tällä hetkellä olemme tunnistaneet seuraavat ratkaisut, joille aiomme taata täyden tuen:

Oletus (kirjasto/rekisteri)*,
AWS ECR
Taivaansininen*,
Docker Hub
GCR*,
GitHub-paketit
GitLab-rekisteri*,
Satama*,
Laituri.

Ratkaisut, joita werf tukee tällä hetkellä täysin, on merkitty tähdellä. Toisille on tukea, mutta rajoituksin.

Kaksi pääongelmaa voidaan tunnistaa:

Jotkut ratkaisut eivät tue tunnisteiden poistamista Docker Registry API:n avulla, mikä estää käyttäjiä käyttämästä werfin automaattista puhdistusta. Tämä pätee AWS ECR-, Docker Hub- ja GitHub-paketteihin.
Jotkut ratkaisut eivät tue ns. sisäkkäisiä tietovarastoja (Docker Hub, GitHub Packages ja Quay) tai tukevat niitä, mutta käyttäjän on luotava ne manuaalisesti käyttöliittymän tai API:n (AWS ECR) avulla.

Aiomme ratkaista nämä ja muut ongelmat käyttämällä ratkaisujen alkuperäisiä API-liittymiä. Tämä tehtävä sisältää myös werf-toiminnan koko syklin kattamisen kunkin niistä testeillä.

Hajautettu kuvanrakennus (↑)

Versio: v1.2 v1.1 (tämän ominaisuuden käyttöönoton prioriteettia on lisätty)
Päivämäärät: maalis-huhtikuu maaliskuu
Kysymys

Tällä hetkellä werf v1.0 ja v1.1 voidaan käyttää vain yhdessä omistetussa isännässä kuvien rakentamiseen ja julkaisemiseen sekä sovelluksen käyttöönottoon Kubernetesissa.

werf:n hajautetun työn mahdollisuuksien avaamiseksi, kun Kubernetesin sovellusten rakentaminen ja käyttöönotto käynnistetään useilla mielivaltaisilla isännillä ja nämä isännät eivät tallenna tilaansa koontiversioiden välillä (väliaikaiset juoksijat), werf vaaditaan toteuttamaan kyky käyttää Docker Registry lavasäilönä.

Aiemmin, kun werf-projekti oli vielä nimeltään dapp, sillä oli tällainen mahdollisuus. Olemme kuitenkin kohdanneet useita ongelmia, jotka on otettava huomioon, kun tätä toimintoa toteutetaan werfissä.

Huomata. Tämä ominaisuus ei edellytä keräilijän toimimista Kubernetes-koteloiden sisällä, koska Tätä varten sinun on päästävä eroon riippuvuudesta paikallisesta Docker-palvelimesta (Kubernetes podissa ei ole pääsyä paikalliseen Docker-palvelimeen, koska itse prosessi on käynnissä säilössä, eikä werf tue eikä tue Työskentely Docker-palvelimen kanssa verkon kautta). Kubernetesin käytön tuki toteutetaan erikseen.

Virallinen tuki GitHub Actionsille (UUSI)

Versio: v1.1
Päivämäärät: maaliskuu
Kysymys

Sisältää werf-dokumentaation (osia viite и ohjaavat), sekä virallinen GitHub Action werf:n kanssa työskentelemiseen.

Lisäksi se antaa werfin työskennellä lyhytaikaisten juoksijoiden kanssa.

Käyttäjien vuorovaikutuksen mekaniikka CI-järjestelmän kanssa perustuu tarrojen asettamiseen vetopyyntöihin tiettyjen sovelluksen rakentamis-/käyttöönottotoimintojen käynnistämiseksi.

Sovellusten paikallinen kehittäminen ja käyttöönotto werfillä (↓)

Versio: v1.1
Päivämäärät: tammi-helmikuu huhtikuu
Kysymys

Päätavoitteena on saavuttaa yksi yhtenäinen konfiguraatio sovellusten käyttöönottamiseksi sekä paikallisesti että tuotannossa ilman monimutkaisia toimia heti valmiiksi.

werfillä on myös oltava toimintatila, jossa on kätevää muokata sovelluskoodia ja saada välittömästi palautetta käynnissä olevasta sovelluksesta virheenkorjausta varten.

Uusi puhdistusalgoritmi (UUSI)

Versio: v1.1
Päivämäärät: huhtikuu
Kysymys

Nykyisessä versiossa werf v1.1 menettelyssä cleanup Sisältöpohjaisessa merkintäjärjestelmässä ei ole mahdollista puhdistaa kuvia - nämä kuvat kerääntyvät.

Myös nykyinen werf-versio (v1.0 ja v1.1) käyttää erilaisia puhdistuskäytäntöjä kuville, jotka on julkaistu merkintämenetelmissä: Git haara, Git tag tai Git commit.

Uusi algoritmi kuvien puhdistamiseen, joka perustuu Gitin sitoumushistoriaan ja joka on yhtenäinen kaikille merkintäjärjestelmille, on keksitty:

Säilytä enintään N1-kuvaa, jotka liittyvät N2:n viimeisimpiin sitoumuksiin jokaiselle git HEAD:lle (haarat ja tagit).
Tallenna enintään N1 vaihekuvaa, jotka liittyvät N2:n viimeisimpiin sitoumuksiin jokaiselle git HEAD:lle (haarat ja tagit).
Tallenna kaikki kuvat, joita käytetään missä tahansa Kubernetes-klusteriresurssissa (kaikki määritystiedoston kube-kontekstit ja nimitilat tarkistetaan; voit rajoittaa tätä toimintaa erityisillä asetuksilla).
Tallenna kaikki Helm-julkaisuihin tallennetuissa resurssien määritysluetteloissa käytetyt kuvat.
Kuva voidaan poistaa, jos sitä ei ole liitetty mihinkään HEADiin gitistä (esimerkiksi koska itse vastaava HEAD on poistettu) eikä sitä käytetä missään Kubernetes-klusterissa ja Helm-julkaisuissa.

Rinnakkaiskuvan rakentaminen (↓)

Versio: v1.1
Päivämäärät: tammi-helmikuu huhtikuu*

Nykyinen werf-versio kerää kuvat ja esineet, jotka on kuvattu werf.yaml, peräkkäin. On tarpeen rinnastaa kuvien ja artefaktien itsenäisten vaiheiden kokoamisprosessi sekä tarjota kätevä ja informatiivinen tulos.

* Huomautus: määräaikaa on siirretty, koska hajautetun kokoonpanon käyttöönoton prioriteetti on lisääntynyt, mikä lisää horisontaalisia skaalausominaisuuksia, sekä werf:n käytön GitHub Actionsin kanssa. Rinnakkaiskokoonpano on seuraava optimointivaihe, joka tarjoaa pystysuuntaisen skaalautuvuuden yhtä projektia koottaessa.

Siirtyminen ruoriin 3 (↓)

Versio: v1.2
Päivämäärät: helmi-maaliskuu toukokuu*

Sisältää siirtymisen uuteen koodikantaan Kypärä 3 ja todistettu ja kätevä tapa siirtää olemassa olevia asennuksia.

* Huomautus: Helm 3:een siirtyminen ei lisää merkittäviä ominaisuuksia werfiin, koska kaikki Helm 3:n keskeiset ominaisuudet (3-way-merge ja ei ohjausta) on jo toteutettu werfissä. Lisäksi werfillä on lisäominaisuuksia ilmoitettujen lisäksi. Tämä siirtymä on kuitenkin edelleen suunnitelmissamme ja se toteutetaan.

Jsonnet Kubernetes-kokoonpanon kuvaamiseen (↓)

Versio: v1.2
Päivämäärät: tammi-helmikuu huhti-toukokuu

Werf tukee Kubernetesin konfiguraatiokuvauksia Jsonnet-muodossa. Samanaikaisesti werf pysyy yhteensopivana Helmin kanssa ja kuvausmuoto on valittavissa.

Syynä on se, että Go-malleilla on monien mielestä korkea markkinoille pääsyn este, ja myös näiden mallien koodin ymmärrettävyys kärsii.

Myös muiden Kubernetes-konfiguraatioiden kuvausjärjestelmien (esim. Kustomize) käyttöönottoa harkitaan.

Työskentely Kubernetesissa (↓)

Versio: v1.2
Päivämäärät: huhti-toukokuu touko-kesäkuu

Tavoite: Varmista, että kuvat luodaan ja sovellus toimitetaan Kubernetesin runnerien avulla. Nuo. Uusia kuvia voidaan rakentaa, julkaista, puhdistaa ja ottaa käyttöön suoraan Kubernetes podista.

Tämän ominaisuuden toteuttamiseksi sinun on ensin pystyttävä rakentamaan hajautettuja kuvia (katso kohta yllä).

Se vaatii myös tuen rakentajan toimintatilalle ilman Docker-palvelinta (eli Kaniko-tyyppistä buildia tai build in userspacea).

Werf tukee Kubernetesin rakentamista ei vain Dockerfilen, vaan myös Stapel builderin avulla vaiheittaisilla uusinnalla ja Ansiblella.

Askel kohti avointa kehitystä

Rakastamme yhteisöämme (GitHub, Telegram) ja haluamme yhä useampien ihmisten auttavan parantamaan werfiä, ymmärtämään, mihin suuntaan olemme menossa, ja osallistuvan kehitykseen.

Hiljattain päätettiin vaihtaa GitHub-projektilevyt paljastaaksemme tiimimme työprosessin. Nyt näet välittömät suunnitelmat sekä tämänhetkiset työt seuraavilla alueilla:

Ongelmien kanssa on tehty paljon työtä:

Asiattomat poistettu.
Nykyiset on koottu yhteen muotoon, jossa on riittävä määrä yksityiskohtia ja yksityiskohtia.
Uusia ideoita ja ehdotuksia koskevia ongelmia on lisätty.

Kuinka ottaa versio v1.1 käyttöön

Versio on tällä hetkellä saatavilla kielellä kanava 1.1 ea (kanavissa vakaa и kiven kova päästöt kuitenkin ilmestyvät vakiintuessa ea itse on jo tarpeeksi vakaa käytettäväksi, koska meni kanavien läpi alfa и beeta). Aktivoitu multiwerfin kautta seuraavalla tavalla:

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

Johtopäätös

Uusi vaiheen tallennusarkkitehtuuri ja rakentajien optimoinnit Stapel- ja Dockerfile-rakentajille tarjoavat mahdollisuuden toteuttaa hajautettuja ja rinnakkaisia koontiversioita werfissä. Nämä ominaisuudet näkyvät pian samassa versiossa 1.1 ja tulevat automaattisesti saataville automaattisen päivitysmekanismin kautta (käyttäjille multiwerf).

Tähän julkaisuun on lisätty kuvasisältöön perustuva taggausstrategia - sisältöön perustuva koodaus, josta on tullut oletusstrategia. Pääkomentoloki on myös muokattu: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

Seuraava merkittävä askel on hajautettujen kokoonpanojen lisääminen. Hajautetuista koontiversioista on tullut korkeampi prioriteetti kuin rinnakkaisista koontiversioista versiosta 1.0 lähtien, koska ne tuovat enemmän lisäarvoa werf:lle: rakentajien pystyskaalaus ja tuki lyhytkestoisille rakentajille erilaisissa CI/CD-järjestelmissä sekä mahdollisuus saada virallinen tuki GitHub Actionsille . Siksi rinnakkaisten kokoonpanojen täytäntöönpanon määräaikoja siirrettiin. Pyrimme kuitenkin toteuttamaan molemmat mahdollisuudet mahdollisimman pian.

Seuraa uutisia! Ja älä unohda vierailla osoitteessa GitHubluoda ongelma, etsiä olemassa oleva ja lisätä plus, luoda PR tai vain seurata projektin kehitystä.

PS.

Lue myös blogistamme:

Lähde: will.com

werf 1.1 -julkaisu: parannuksia rakentajaan tänään ja tulevaisuuden suunnitelmat