er vårt åpen kildekode GitOps CLI-verktøy for å bygge og levere applikasjoner til Kubernetes. Som lovet, markerte begynnelsen på å legge til nye funksjoner til werf og revidere tradisjonelle tilnærminger. Nå er vi glade for å presentere versjon 1.1, som er et stort skritt i utviklingen og et grunnlag for fremtiden samler werf. Versjonen er for øyeblikket tilgjengelig i .
Grunnlaget for utgivelsen er den nye scenelagringsarkitekturen og optimalisering av arbeidet til begge samlere (for Stapel og Dockerfile). Den nye lagringsarkitekturen åpner for muligheten for å implementere distribuerte sammenstillinger fra flere verter og parallelle sammenstillinger på samme vert.
Optimalisering av arbeid inkluderer å kvitte seg med unødvendige beregninger på stadiet med å beregne scenesignaturer og endre mekanismene for å beregne filsjekksummer for å være mer effektive. Denne optimaliseringen reduserer gjennomsnittstiden for prosjektbygging ved bruk av werf. Og inaktive bygg, når alle stadier finnes i cachen scener-lagring, er nå veldig raske. I de fleste tilfeller vil det ta mindre enn 1 sekund å starte bygget på nytt! Dette gjelder også prosedyrer for å verifisere stadier i prosessen med teams arbeid. werf deploy и werf run.
Også i denne utgivelsen dukket det opp en strategi for å merke bilder etter innhold - innholdsbasert tagging, som nå er aktivert som standard og den eneste anbefalte.
La oss se nærmere på de viktigste innovasjonene i werf v1.1, og samtidig fortelle deg om planer for fremtiden.
Hva er endret i werf v1.1?
Nytt scenenavningsformat og algoritme for å velge stadier fra cache
Ny generasjonsregel for scenenavn. Nå genererer hver scenebygging et unikt scenenavn, som består av 2 deler: en signatur (som den var i v1.0) pluss en unik midlertidig identifikator.
For eksempel kan hele scenebildenavnet se slik ut:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
...eller generelt:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
her:
-
SIGNATUREer en scenesignatur, som representerer identifikatoren til sceneinnholdet og avhenger av historien til redigeringer i Git som førte til dette innholdet; -
TIMESTAMP_MILLISECer en garantert unik bildeidentifikator som genereres når et nytt bilde bygges.
Algoritmen for å velge stadier fra cachen er basert på å sjekke forholdet mellom Git-forpliktelser:
- Werf beregner signaturen til et bestemt stadium.
- В scener-lagring Det kan være flere stadier for en gitt signatur. Werf velger alle stadier som matcher signaturen.
- Hvis det gjeldende stadiet er koblet til Git (git-arkiv, tilpasset stadium med Git-patcher:
install,beforeSetup,setup; eller git-latest-patch), så velger werf bare de stadiene som er assosiert med en commit som er en stamfar til gjeldende commit (som bygningen kalles for). - Fra de resterende passende stadiene velges en - den eldste etter opprettelsesdato.
En scene for forskjellige Git-grener kan ha samme signatur. Men werf vil forhindre at cachen knyttet til forskjellige grener brukes mellom disse grenene, selv om signaturene samsvarer.
.
Ny algoritme for å lage og lagre stadier i scenelagringen
Hvis werf ikke finner et passende stadium når du velger trinn fra hurtigbufferen, starter prosessen med å sette sammen et nytt trinn.
Legg merke til at flere prosesser (på en eller flere verter) kan begynne å bygge det samme trinnet omtrent samtidig. Werf bruker en optimistisk blokkeringsalgoritme scener-lagring i øyeblikket du lagrer det nyinnsamlede bildet scener-lagring. På denne måten, når det nye scenebygget er klart, blokkerer werf scener-lagring og lagrer et ferskt innsamlet bilde der bare hvis et passende bilde ikke lenger finnes der (ved signatur og andre parametere - se den nye algoritmen for å velge stadier fra cachen).
Et ferskt sammensatt bilde har garantert en unik identifikator av TIMESTAMP_MILLISEC (se nytt format for scenenavn). I tilfelle i scener-lagring et passende bilde vil bli funnet, werf vil forkaste det nylig kompilerte bildet og vil bruke bildet fra hurtigbufferen.
Med andre ord: den første prosessen for å fullføre byggingen av bildet (den raskeste) vil få rett til å lagre det i trinn-lagring (og så er det dette enkeltbildet som vil bli brukt for alle bygg). En langsom byggeprosess vil aldri blokkere en raskere prosess fra å lagre byggeresultatene fra det gjeldende stadiet og gå videre til neste bygg.
.
Forbedret Dockerfile-byggerytelse
For øyeblikket består pipelinen av stadier for et bilde bygget fra en Dockerfile av ett trinn - dockerfile. Ved beregning av signaturen beregnes kontrollsummen til filene context, som skal brukes under montering. Før denne forbedringen gikk werf rekursivt gjennom alle filene og oppnådde en kontrollsum ved å summere konteksten og modusen til hver fil. Fra og med v1.1 kan werf bruke beregnede kontrollsummer lagret i et Git-depot.
Algoritmen er basert på . Algoritmen tar hensyn til poster i .dockerignore og krysser filtreet rekursivt bare når det er nødvendig. Dermed har vi koblet fra å lese filsystemet, og algoritmens avhengighet av størrelsen context er ikke vesentlig.
Algoritmen sjekker også usporede filer og tar om nødvendig hensyn til dem i kontrollsummen.
Forbedret ytelse ved import av filer
Versjoner av werf v1.1 bruker en rsync-server når . Tidligere ble importen utført i to trinn ved hjelp av en katalogmontering fra vertssystemet.
Importytelse på macOS er ikke lenger begrenset av Docker-volumer, og importen fullføres på samme tid som Linux og Windows.
Innholdsbasert tagging
Werf v1.1 støtter såkalt tagging etter bildeinnhold - innholdsbasert tagging. Taggene til de resulterende Docker-bildene avhenger av innholdet i disse bildene.
Når du kjører kommandoen werf publish --tags-by-stages-signature eller werf ci-env --tagging-strategy=stages-signature publiserte bilder av den såkalte scenesignatur bilde. Hvert bilde er merket med sin egen signatur av stadiene i dette bildet, som beregnes i henhold til de samme reglene som den vanlige signaturen for hvert trinn separat, men er en generell identifikator for bildet.
Signaturen til bildestadiene avhenger av:
- innholdet i dette bildet;
- historier om Git-endringene som førte til dette innholdet.
Et Git-depot har alltid dummy-commits som ikke endrer innholdet i bildefilene. For eksempel, commits med bare kommentarer eller merge commits, eller commits som endrer de filene i Git som ikke vil bli importert til bildet.
Ved bruk av innholdsbasert tagging løses problemene med unødvendig omstart av applikasjonsputer i Kubernetes på grunn av endringer i bildenavnet, selv om innholdet i bildet ikke er endret. Forresten, dette er en av grunnene som forhindrer lagring av mange mikrotjenester av en applikasjon i et enkelt Git-depot.
Innholdsbasert tagging er også en mer pålitelig taggingsmetode enn tagging på Git-grener, fordi innholdet i de resulterende bildene ikke avhenger av rekkefølgen pipelines utføres i i CI-systemet for å sette sammen flere forpliktelser av samme gren.
Det er viktig: starter fra nå etapper-signatur - Er den eneste anbefalte taggestrategien. Det vil bli brukt som standard i kommandoen werf ci-env (med mindre du eksplisitt spesifiserer et annet merkeskjema).
. En egen publikasjon vil også bli viet denne funksjonen. OPPDATERT (3. april): Artikkel med detaljer .
Loggingsnivåer
Brukeren har nå mulighet til å kontrollere utgangen, stille inn loggingsnivå og jobbe med feilsøkingsinformasjon. Alternativer lagt til --log-quiet, --log-verbose, --log-debug.
Som standard inneholder utdata minimumsinformasjonen:
Når du bruker detaljert utdata (--log-verbose) kan du se hvordan werf fungerer:
Detaljert utgang (--log-debug), i tillegg til werf feilsøkingsinformasjon, inneholder også logger over brukte biblioteker. For eksempel kan du se hvordan interaksjon med Docker Registry oppstår, og også registrere stedene hvor en betydelig mengde tid er brukt:
Ytterligere planer
Advarsel! Alternativene beskrevet nedenfor er merket v1.1 vil bli tilgjengelig i denne versjonen, mange av dem i nær fremtid. Oppdateringer vil komme via automatiske oppdateringer . Disse funksjonene påvirker ikke den stabile delen av v1.1-funksjonene; deres utseende vil ikke kreve manuell brukerintervensjon i eksisterende konfigurasjoner.
Full støtte for ulike Docker Registry-implementeringer (NY)
- Versjon: v1.1
- Datoer: mars
Målet er at brukeren skal bruke en tilpasset implementering uten begrensninger ved bruk av werf.
For øyeblikket har vi identifisert følgende sett med løsninger som vi skal garantere full støtte for:
- Standard (bibliotek/register)*,
- AWS ECR
- Azure*,
- Docker Hub
- GCR*,
- GitHub-pakker
- GitLab-registeret*,
- Havn*,
- Kai.
Løsninger som for øyeblikket er fullt støttet av werf er merket med en stjerne. For andre er det støtte, men med begrensninger.
To hovedproblemer kan identifiseres:
- Noen løsninger støtter ikke fjerning av tagger ved å bruke Docker Registry API, og hindrer brukere i å bruke werfs automatiske opprydding. Dette gjelder for AWS ECR, Docker Hub og GitHub-pakker.
- Noen løsninger støtter ikke såkalte nestede repositories (Docker Hub, GitHub-pakker og Quay) eller gjør det, men brukeren må opprette dem manuelt ved hjelp av UI eller API (AWS ECR).
Vi skal løse disse og andre problemer ved å bruke native API-er for løsningene. Denne oppgaven inkluderer også å dekke hele syklusen av werfdrift med tester for hver av dem.
Distribuert bildeoppbygging (↑)
- Versjon: v1.2 v1.1 (prioriteten for å implementere denne funksjonen er økt)
- Datoer: mars-april mars
For øyeblikket kan werf v1.0 og v1.1 bare brukes på én dedikert vert for operasjoner med å bygge og publisere bilder og distribuere applikasjonen til Kubernetes.
For å åpne opp mulighetene for distribuert arbeid av werf, når bygging og distribusjon av applikasjoner i Kubernetes lanseres på flere vilkårlige verter og disse vertene ikke lagrer tilstanden sin mellom bygg (midlertidige løpere), er werf pålagt å implementere muligheten til å bruke Docker Registry som scenebutikk.
Tidligere, da werf-prosjektet fortsatt het dapp, hadde det en slik mulighet. Vi har imidlertid støtt på en rekke problemer som må tas i betraktning når vi implementerer denne funksjonaliteten i werf.
Note. Denne funksjonen krever ikke at samleren jobber inne i Kubernetes-pods, fordi For å gjøre dette, må du kvitte deg med avhengigheten av den lokale Docker-serveren (i Kubernetes-poden er det ingen tilgang til den lokale Docker-serveren, fordi selve prosessen kjører i en container, og werf støtter ikke og vil ikke støtte arbeider med Docker-serveren over nettverket). Støtte for å kjøre Kubernetes vil bli implementert separat.
Offisiell støtte for GitHub Actions (NY)
- Versjon: v1.1
- Datoer: mars
Inkluderer werfdokumentasjon (seksjoner referanse и veilede), samt den offisielle GitHub-aksjonen for å jobbe med werf.
I tillegg vil det tillate werf å jobbe med flyktige løpere.
Mekanikken for brukerinteraksjon med CI-systemet vil være basert på å plassere etiketter på pull-forespørsler for å sette i gang visse handlinger for å bygge/rulle ut applikasjonen.
Lokal utvikling og distribusjon av applikasjoner med werf (↓)
- Versjon: v1.1
- Datoer: januar-februar april
Hovedmålet er å oppnå en enkelt enhetlig konfigurasjon for å distribuere applikasjoner både lokalt og i produksjon, uten komplekse handlinger, rett ut av boksen.
werf er også pålagt å ha en driftsmodus der det vil være praktisk å redigere applikasjonskoden og umiddelbart motta tilbakemelding fra den kjørende applikasjonen for feilsøking.
Ny rensealgoritme (NY)
- Versjon: v1.1
- Datoer: april
I den gjeldende versjonen av werf v1.1 i prosedyren cleanup Det er ingen bestemmelser om rengjøring av bilder for den innholdsbaserte tagging-ordningen - disse bildene vil samle seg.
Den nåværende versjonen av werf (v1.0 og v1.1) bruker også forskjellige oppryddingspolicyer for bilder publisert under tagging-skjemaer: Git branch, Git tag eller Git commit.
En ny algoritme for å rense bilder basert på historien til forpliktelser i Git, forent for alle tagging-opplegg, har blitt oppfunnet:
- Behold ikke mer enn N1-bilder assosiert med N2 siste commits for hver git HEAD (grener og tagger).
- Lagre ikke mer enn N1 scenebilder assosiert med N2 siste commits for hver git HEAD (grener og tagger).
- Lagre alle bilder som brukes i alle Kubernetes-klyngressursene (alle kube-kontekster i konfigurasjonsfilen og navneområdene skannes; du kan begrense denne virkemåten med spesielle alternativer).
- Lagre alle bilder som brukes i ressurskonfigurasjonsmanifester lagret i Helm-utgivelser.
- Et bilde kan slettes hvis det ikke er assosiert med noen HEAD fra git (for eksempel fordi den tilsvarende HEAD selv ble slettet) og ikke brukes i noen manifester i Kubernetes-klyngen og i Helm-utgivelser.
Parallell bildebygging (↓)
- Versjon: v1.1
- Datoer: januar-februar april*
Den nåværende versjonen av werf samler bildene og artefaktene beskrevet i werf.yaml, sekvensielt. Det er nødvendig å parallellisere prosessen med å sette sammen uavhengige stadier av bilder og artefakter, samt gi praktisk og informativ utgang.
* Merk: fristen har blitt forskjøvet på grunn av økt prioritet for implementering av distribuert montering, som vil legge til flere horisontale skaleringsmuligheter, samt bruk av werf med GitHub Actions. Parallell montering er det neste optimaliseringstrinnet, og gir vertikal skalerbarhet ved montering av ett prosjekt.
Overgang til ror 3 (↓)
- Versjon: v1.2
- Datoer: februar-mars mai*
Inkluderer migrering til ny kodebase og en velprøvd, praktisk måte å migrere eksisterende installasjoner på.
* Merk: Bytting til Helm 3 vil ikke legge til vesentlige funksjoner til werf, fordi alle nøkkelfunksjonene til Helm 3 (3-veis sammenslåing og ingen rorkult) allerede er implementert i werf. Dessuten har werf i tillegg til de som er angitt. Denne overgangen forblir imidlertid i våre planer og vil bli gjennomført.
Jsonnet for å beskrive Kubernetes-konfigurasjonen (↓)
- Versjon: v1.2
- Datoer: januar-februar april-mai
Werf vil støtte konfigurasjonsbeskrivelser for Kubernetes i Jsonnet-format. Samtidig vil werf forbli kompatibel med Helm, og det vil være et valg av beskrivelsesformat.
Årsaken er at Go-maler, ifølge mange, har høy inngangsbarriere, og forståelsen av koden til disse malene lider også.
Muligheten for å introdusere andre Kubernetes-konfigurasjonsbeskrivelsessystemer (for eksempel Kustomize) vurderes også.
Arbeid inne i Kubernetes (↓)
- Versjon: v1.2
- Datoer: april-mai mai-juni
Mål: Sørg for at bilder bygges og applikasjonen leveres ved hjelp av løpere i Kubernetes. De. Nye bilder kan bygges, publiseres, renses og distribueres direkte fra Kubernetes-pods.
For å implementere denne muligheten må du først kunne bygge distribuerte bilder (se punkt over).
Det krever også støtte for byggherrens driftsmodus uten en Docker-server (dvs. Kaniko-lignende bygg eller innebygd brukerområde).
Werf vil støtte bygging på Kubernetes, ikke bare med Dockerfile, men også med Stapel-byggeren med inkrementelle ombygginger og Ansible.
Et skritt mot åpen utvikling
Vi elsker samfunnet vårt (, ) og vi ønsker at flere og flere skal bidra til å gjøre werf bedre, forstå retningen vi beveger oss i og delta i utviklingen.
Ganske nylig ble det besluttet å bytte til for å avsløre arbeidsprosessen til teamet vårt. Nå kan du se de umiddelbare planene, samt gjeldende arbeid på følgende områder:
- ;
- ;
- ;
- .
Det er gjort mye arbeid med problemstillinger:
- Fjernet irrelevante.
- De eksisterende bringes til ett enkelt format, med et tilstrekkelig antall detaljer og detaljer.
- Nye problemer med ideer og forslag er lagt til.
Slik aktiverer du versjon v1.1
Versjonen er for øyeblikket tilgjengelig i (i kanaler stabil и bunnsolid utgivelser vil imidlertid vises når stabilisering skjer ea i seg selv er allerede stabil nok til bruk, fordi gikk gjennom kanalene alpha и beta). Aktivert på følgende måte:
source $(multiwerf use 1.1 ea)
werf COMMAND ...Konklusjon
Den nye scenelagringsarkitekturen og byggherreoptimeringene for Stapel- og Dockerfile-byggere åpner for muligheten for å implementere distribuerte og parallelle bygg i werf. Disse funksjonene vil snart vises i samme versjon 1.1 og vil bli automatisk tilgjengelige gjennom den automatiske oppdateringsmekanismen (for brukere ).
I denne utgivelsen er det lagt til en taggestrategi basert på bildeinnhold - innholdsbasert tagging, som har blitt standardstrategien. Hovedkommandologgen har også blitt omarbeidet: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
Det neste viktige trinnet er å legge til distribuerte sammenstillinger. Distribuerte bygg har blitt en høyere prioritet enn parallelle bygg siden v1.0 fordi de gir mer verdi til werf: vertikal skalering av byggherrer og støtte for flyktige byggere i ulike CI/CD-systemer, samt muligheten til å lage offisiell støtte for GitHub Actions . Derfor ble implementeringsfristene for parallelle samlinger forskjøvet. Vi jobber imidlertid med å implementere begge mulighetene så snart som mulig.
Følg med på nyhetene! Og ikke glem å besøke oss kl for å opprette et problem, finne et eksisterende og legge til et pluss, lage en PR, eller bare se utviklingen av prosjektet.
PS
Les også på bloggen vår:
- «»
- «";
- En serie notater om innovasjoner i werf:
- «";
- «";
- «";
- «'.
Kilde: www.habr.com