werf 1.1 release: förbättringar av byggaren idag och planer för framtiden

werf är vårt GitOps CLI-verktyg med öppen källkod för att bygga och leverera applikationer till Kubernetes. Som utlovat, release av version v1.0 markerade början på att lägga till nya funktioner till werf och revidera traditionella metoder. Nu är vi glada att presentera release v1.1, som är ett stort steg i utvecklingen och en grund för framtiden samlare werf. Versionen finns för närvarande tillgänglig i kanal 1.1 ea.

Grunden för releasen är den nya arkitekturen för scenlagringen och optimeringen av båda samlarnas arbete (för Stapel och Dockerfile). Den nya lagringsarkitekturen öppnar för möjligheten att implementera distribuerade sammansättningar från flera värdar och parallella sammansättningar på samma värd.

Optimering av arbetet inkluderar att bli av med onödiga beräkningar vid beräkningen av etappsignaturer och att ändra mekanismerna för att beräkna filkontrollsummor till mer effektiva. Denna optimering minskar den genomsnittliga tiden för projektbyggen med werf. Och inaktiva bygger, när alla stadier finns i cachen scener-lagring, är nu riktigt snabba. I de flesta fall tar det mindre än 1 sekund att starta om bygget! Detta gäller även rutiner för att verifiera stadier i teamarbetet. werf deploy и werf run.

Även i den här utgåvan dök en strategi för att tagga bilder efter innehåll - innehållsbaserad taggning, som nu är aktiverat som standard och den enda som rekommenderas.

Låt oss ta en närmare titt på de viktigaste innovationerna i werf v1.1, och samtidigt berätta om planer för framtiden.

Vad har förändrats i werf v1.1?

Nytt scennamnformat och algoritm för att välja stadier från cachen

Ny regel för generering av artistnamn. Nu genererar varje scenbygge ett unikt scennamn, som består av 2 delar: en signatur (som den var i v1.0) plus en unik temporär identifierare.

Till exempel kan hela scenbildens namn se ut så här:

werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835

...eller generellt:

werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC

här:

• SIGNATURE är en scensignatur, som representerar identifieraren för scenens innehåll och beror på historiken för redigeringar i Git som ledde till detta innehåll;
• TIMESTAMP_MILLISEC är en garanterat unik bildidentifierare som genereras när en ny bild byggs.

Algoritmen för att välja stadier från cachen är baserad på att kontrollera förhållandet mellan Git commits:

1. Werf beräknar signaturen för ett visst stadium.
2. В scener-lagring Det kan finnas flera steg för en given signatur. Werf väljer alla stadier som matchar signaturen.
3. Om det aktuella steget är länkat till Git (git-arkiv, anpassat steg med Git-patchar: install, beforeSetup, setup; eller git-latest-patch), väljer werf endast de stadier som är associerade med en commit som är en förfader till den nuvarande commit (för vilken byggnaden kallas).
4. Från de återstående lämpliga stadierna väljs en - den äldsta efter skapelsedatum.

En scen för olika Git-grenar kan ha samma signatur. Men werf kommer att förhindra att cachen associerad med olika grenar används mellan dessa grenar, även om signaturerna matchar.

→ Dokumentation.

Ny algoritm för att skapa och spara stadier i scenlagringen

Om, när man väljer steg från cachen, werf inte hittar ett lämpligt steg, inleds processen med att montera ett nytt steg.

Observera att flera processer (på en eller flera värdar) kan börja bygga samma steg vid ungefär samma tidpunkt. Werf använder en optimistisk blockeringsalgoritm scener-lagring i ögonblicket för att spara den nyinsamlade bilden scener-lagring. På så sätt, när den nya scenbyggnaden är klar, blockerar werf scener-lagring och sparar en nyinsamlad bild där endast om en lämplig bild inte längre finns där (genom signatur och andra parametrar - se den nya algoritmen för att välja steg från cachen).

En nymonterad bild har garanterat en unik identifierare av TIMESTAMP_MILLISEC (se nytt format för scennamn). I fall i scener-lagring en lämplig bild kommer att hittas, werf kommer att kassera den nyligen kompilerade bilden och kommer att använda bilden från cachen.

Med andra ord: den första processen för att färdigställa bilden (den snabbaste) kommer att få rätten att lagra den i etapper-lagring (och sedan är det denna enda bild som kommer att användas för alla byggen). En långsam byggprocess kommer aldrig att blockera en snabbare process från att spara byggresultaten för det aktuella steget och gå vidare till nästa bygg.

→ Dokumentation.

Förbättrad Dockerfile-byggarprestanda

För närvarande består pipelinen av steg för en bild byggd från en Dockerfile av ett steg - dockerfile. Vid beräkning av signaturen beräknas kontrollsumman för filerna context, som kommer att användas vid montering. Innan denna förbättring gick werf rekursivt igenom alla filer och fick en kontrollsumma genom att summera varje fils sammanhang och läge. Från och med v1.1 kan werf använda beräknade kontrollsummor lagrade i ett Git-förråd.

Algoritmen är baserad på git ls-träd. Algoritmen tar hänsyn till poster i .dockerignore och korsar filträdet rekursivt endast när det behövs. Således har vi frikopplat från att läsa filsystemet, och algoritmens beroende av storleken context är inte signifikant.

Algoritmen kontrollerar även ospårade filer och tar vid behov hänsyn till dem i kontrollsumman.

Förbättrad prestanda vid import av filer

Versioner av werf v1.1 använder en rsync-server när importera filer från artefakter och bilder. Tidigare gjordes importen i två steg med hjälp av en katalogmontering från värdsystemet.

Importprestanda på macOS begränsas inte längre av Docker-volymer, och importen slutförs på samma tid som Linux och Windows.

Innehållsbaserad taggning

Werf v1.1 stöder så kallad taggning efter bildinnehåll - innehållsbaserad taggning. Taggarna för de resulterande Docker-bilderna beror på innehållet i dessa bilder.

När du kör kommandot werf publish --tags-by-stages-signature eller werf ci-env --tagging-strategy=stages-signature publicerade bilder av den sk scensignatur bild. Varje bild är taggad med sin egen signatur av stadierna i denna bild, som beräknas enligt samma regler som den vanliga signaturen för varje steg separat, men är en allmän identifierare för bilden.

Signaturen för bildstadierna beror på:

1. innehållet i denna bild;
2. historik över Git-ändringarna som ledde till detta innehåll.

Ett Git-förråd har alltid dummy-commits som inte ändrar innehållet i bildfilerna. Till exempel commits med bara kommentarer eller merge commits, eller commits som ändrar de filerna i Git som inte kommer att importeras till bilden.

När du använder innehållsbaserad taggning löses problemen med onödiga omstarter av applikationspoddar i Kubernetes på grund av ändringar i bildnamnet, även om innehållet i bilden inte har ändrats. Förresten, detta är en av anledningarna som förhindrar lagring av många mikrotjänster för en applikation i ett enda Git-förråd.

Innehållsbaserad taggning är också en mer tillförlitlig taggningsmetod än taggning på Git-grenar, eftersom innehållet i de resulterande bilderna inte beror på i vilken ordning pipelines exekveras i CI-systemet för att montera flera commits av samma gren.

Det är viktigt: från och med nu etapper-signatur - Är den enda rekommenderade taggningsstrategin. Det kommer att användas som standard i kommandot werf ci-env (såvida du inte uttryckligen anger ett annat taggningsschema).

→ Dokumentation. En separat publikation kommer också att ägnas åt denna funktion. UPPDATERAD (3 april): Artikel med detaljer publicerat.

Loggningsnivåer

Användaren har nu möjlighet att styra utdata, ställa in loggningsnivån och arbeta med felsökningsinformation. Alternativ har lagts till --log-quiet, --log-verbose, --log-debug.

Som standard innehåller utdata den minsta informationen:

När du använder utförlig utdata (--log-verbose) du kan se hur werf fungerar:

Detaljerad utdata (--log-debug), förutom werf felsökningsinformation, innehåller även loggar över använda bibliotek. Till exempel kan du se hur interaktion med Docker Registry sker, och även registrera de platser där en betydande mängd tid spenderas:

Framtida planer

Varning! Alternativen som beskrivs nedan är markerade v1.1 kommer att bli tillgängliga i denna version, många av dem inom en snar framtid. Uppdateringar kommer via automatiska uppdateringar när du använder multiwerf. Dessa funktioner påverkar inte den stabila delen av v1.1-funktioner; deras utseende kommer inte att kräva manuellt användaringripande i befintliga konfigurationer.

Fullt stöd för olika Docker Registry-implementeringar (NYTT)

• Version: v1.1
• Datum: mars
• Fråga

Målet är att användaren ska använda en anpassad implementering utan begränsningar vid användning av werf.

För närvarande har vi identifierat följande uppsättning lösningar som vi kommer att garantera full support för:

• Standard (bibliotek/register)*,
• AWS ECR
• Azurblå*,
• Docker Hub
• GCR*,
• GitHub-paket
• GitLab Registry*,
• Hamn*,
• Kaj.

Lösningar som för närvarande stöds fullt ut av werf är markerade med en asterisk. För andra finns stöd, men med begränsningar.

Två huvudproblem kan identifieras:

• Vissa lösningar stöder inte taggborttagning med Docker Registry API, vilket hindrar användare från att använda werfs automatiska rensning. Detta gäller för AWS ECR, Docker Hub och GitHub-paket.
• Vissa lösningar stöder inte så kallade kapslade repositories (Docker Hub, GitHub-paket och Quay) eller gör det, utan användaren måste skapa dem manuellt med hjälp av UI eller API (AWS ECR).

Vi kommer att lösa dessa och andra problem med hjälp av inbyggda API:er för lösningarna. Denna uppgift inkluderar också att täcka hela cykeln av anläggningsdrift med tester för var och en av dem.

Distribuerad bilduppbyggnad (↑)

• Version: v1.2 v1.1 (prioriteten för att implementera den här funktionen har höjts)
• Datum: mars-april mars
• Fråga

För närvarande kan werf v1.0 och v1.1 endast användas på en dedikerad värd för att bygga och publicera bilder och distribuera programmet till Kubernetes.

För att öppna upp möjligheterna för distribuerat arbete av werf, när byggandet och distributionen av applikationer i Kubernetes lanseras på flera godtyckliga värdar och dessa värdar inte sparar sitt tillstånd mellan byggen (tillfälliga löpare), krävs werf för att implementera möjligheten att använda Docker Registry som scenbutik.

Tidigare, när werfprojektet fortfarande hette dapp, hade det en sådan möjlighet. Vi har dock stött på ett antal problem som måste beaktas när vi implementerar denna funktionalitet i werf.

Notera. Den här funktionen kräver inte att samlaren arbetar inuti Kubernetes-skidor, eftersom För att göra detta måste du bli av med beroendet av den lokala Docker-servern (i Kubernetes-podden finns det ingen tillgång till den lokala Docker-servern, eftersom själva processen körs i en container, och werf stöder inte och kommer inte att stödja arbetar med Docker-servern över nätverket). Stöd för att köra Kubernetes kommer att implementeras separat.

Officiellt stöd för GitHub Actions (NYTT)

• Version: v1.1
• Datum: mars
• Fråga

Inkluderar werfdokumentation (avsnitt referens и styra), såväl som den officiella GitHub Action för att arbeta med werf.

Dessutom kommer det att tillåta werf att arbeta på tillfälliga löpare.

Mekaniken för användarinteraktion med CI-systemet kommer att baseras på att placera etiketter på pull-förfrågningar för att initiera vissa åtgärder för att bygga/rulla ut applikationen.

Lokal utveckling och distribution av applikationer med werf (↓)

• Version: v1.1
• Datum: januari-februari april
• Fråga

Huvudmålet är att uppnå en enda enhetlig konfiguration för att distribuera applikationer både lokalt och i produktion, utan komplexa åtgärder, direkt.

werf måste också ha ett driftläge där det är bekvämt att redigera applikationskoden och omedelbart få feedback från den körande applikationen för felsökning.

Ny rengöringsalgoritm (NY)

• Version: v1.1
• Datum: april
• Fråga

I den nuvarande versionen av werf v1.1 i proceduren cleanup Det finns ingen möjlighet att rengöra bilder för det innehållsbaserade taggningsschemat - dessa bilder kommer att ackumuleras.

Dessutom använder den nuvarande versionen av werf (v1.0 och v1.1) olika rensningspolicyer för bilder publicerade under taggningsscheman: Git branch, Git tag eller Git commit.

En ny algoritm för att rengöra bilder baserad på historien om commits i Git, enhetlig för alla taggningsscheman, har uppfunnits:

• Behåll inte fler än N1-bilder associerade med de N2 senaste commits för varje git HEAD (grenar och taggar).
• Lagra högst N1 scenbilder associerade med N2 senaste commits för varje git HEAD (grenar och taggar).
• Lagra alla bilder som används i alla Kubernetes-klusterresurser (alla kube-kontexter i konfigurationsfilen och namnutrymmen skannas; du kan begränsa detta beteende med speciella alternativ).
• Lagra alla bilder som används i resurskonfigurationsmanifest sparade i Helm-versioner.
• En bild kan tas bort om den inte är associerad med något HEAD från git (till exempel eftersom motsvarande HEAD själv togs bort) och inte används i några manifest i Kubernetes-klustret och i Helm-utgåvor.

Byggande av parallella bilder (↓)

• Version: v1.1
• Datum: januari-februari april*

Den nuvarande versionen av werf samlar in bilderna och artefakterna som beskrivs i werf.yaml, sekventiellt. Det är nödvändigt att parallellisera processen för att montera oberoende stadier av bilder och artefakter, samt tillhandahålla bekväm och informativ utdata.

* Notera: tidsfristen har flyttats på grund av ökad prioritet för att implementera distribuerad sammansättning, vilket kommer att lägga till fler horisontella skalningsmöjligheter, såväl som användningen av werf med GitHub Actions. Parallell montering är nästa optimeringssteg, vilket ger vertikal skalbarhet vid montering av ett projekt.

Övergång till Helm 3 (↓)

• Version: v1.2
• Datum: februari-mars maj*

Inkluderar migrering till ny kodbas Roder 3 och ett beprövat, bekvämt sätt att migrera befintliga installationer.

* Notera: att byta till Helm 3 kommer inte att lägga till betydande funktioner till werf, eftersom alla nyckelfunktioner i Helm 3 (3-vägs sammanfogning och ingen rorkult) redan är implementerade i werf. Dessutom har werf ytterligare egenskaper utöver de angivna. Denna övergång finns dock kvar i våra planer och kommer att genomföras.

Jsonnet för att beskriva Kubernetes-konfiguration (↓)

• Version: v1.2
• Datum: januari-februari april-maj

Werf kommer att stödja konfigurationsbeskrivningar för Kubernetes i Jsonnet-format. Samtidigt kommer werf att förbli kompatibel med Helm och det kommer att finnas ett val av beskrivningsformat.

Anledningen är att Go-mallar, enligt många, har en hög inträdesbarriär, och förståelsen av koden för dessa mallar blir också lidande.

Möjligheten att introducera andra Kubernetes konfigurationsbeskrivningssystem (till exempel Kustomize) övervägs också.

Arbeta inuti Kubernetes (↓)

• Version: v1.2
• Datum: april-maj maj-juni

Mål: Se till att bilder byggs och applikationen levereras med löpare i Kubernetes. De där. Nya bilder kan byggas, publiceras, rengöras och distribueras direkt från Kubernetes-poddar.

För att implementera denna förmåga måste du först kunna bygga distribuerade bilder (se punkten ovan).

Det kräver också stöd för byggarens driftläge utan en Docker-server (dvs Kaniko-liknande bygg eller inbyggt användarutrymme).

Werf kommer att stödja att bygga på Kubernetes inte bara med Dockerfile, utan också med dess Stapel-byggare med inkrementella ombyggnader och Ansible.

Ett steg mot öppen utveckling

Vi älskar vårt samhälle (GitHub, Telegram) och vi vill att fler och fler människor ska hjälpa till att göra werf bättre, förstå riktningen vi rör oss i och delta i utvecklingen.

Ganska nyligen beslutades att byta till GitHub-projektbrädor för att avslöja arbetsprocessen för vårt team. Nu kan du se de omedelbara planerna, såväl som aktuellt arbete inom följande områden:

• Dokumentation och webbplats;
• Testning;
• Buggar och dålig UX;
• 1.1.

Mycket arbete har gjorts med frågor:

• Tog bort irrelevanta.
• De befintliga förs till ett enda format, med ett tillräckligt antal detaljer och detaljer.
• Nya nummer med idéer och förslag har lagts till.

Hur man aktiverar version v1.1

Versionen finns för närvarande tillgänglig i kanal 1.1 ea (i kanaler stabil и stenhård releaser kommer dock att visas när stabilisering sker ea i sig är redan tillräckligt stabil för användning, eftersom gick genom kanalerna alfa и beta). Aktiverad via multiwerf på följande sätt:

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

Slutsats

Den nya scenlagringsarkitekturen och byggaroptimeringarna för Stapel- och Dockerfile-byggare öppnar för möjligheten att implementera distribuerade och parallella byggen i werf. Dessa funktioner kommer snart att visas i samma version 1.1 och blir automatiskt tillgängliga via mekanismen för automatisk uppdatering (för användare multiwerf).

I den här versionen har en taggningsstrategi baserad på bildinnehåll lagts till - innehållsbaserad taggning, som har blivit standardstrategin. Huvudkommandologgen har också omarbetats: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

Nästa viktiga steg är att lägga till distribuerade sammansättningar. Distribuerade byggen har blivit en högre prioritet än parallella byggnationer sedan v1.0 eftersom de tillför mer värde till werf: vertikal skalning av byggare och stöd för tillfälliga byggare i olika CI/CD-system, samt möjligheten att göra officiellt stöd för GitHub Actions . Därför flyttades implementeringstiderna för parallella sammansättningar. Vi arbetar dock för att implementera båda möjligheterna så snart som möjligt.

Följ nyheterna! Och glöm inte att besöka oss kl GitHubför att skapa ett problem, hitta ett befintligt och lägga till ett plus, skapa en PR eller helt enkelt se utvecklingen av projektet.

PS

Läs även på vår blogg:

• «Vi introducerar werf 1.0 stabil: vad har GitOps med det att göra, status och planer»
• «werf - vårt verktyg för CI / CD i Kubernetes (översikt och videorapport)";
• En serie anteckningar om innovationer i werf:
  • «3-vägs sammanslagning till werf: distribution till Kubernetes med Helm "på steroider"";
  • «Använder werf för att rulla ut komplexa Helm-diagram";
  • «Stöd för monorepo och multirepo i werf och vad har Docker Registry att göra med det";
  • «Du kan nu bygga Docker-bilder i werf med en vanlig Dockerfil".

Källa: will.com