🥇Release av werf 1.1: förbättringar i byggverktyget idag och planer för framtiden

werf — vårt GitOps CLI-verktyg med öppen källkod för byggande och leverans av applikationer till Kubernetes. Som vi lovade, utgivningen av version v1.0 markerade början på tillägget av nya funktioner till werf och en översyn av de traditionella metoderna. Nu är vi glada att presentera release v1.1, som är ett stort steg framåt och en grund för framtiden. byggverktyg werf. Versionen är för närvarande tillgänglig i kanal 1.1 ea.

Kärnan i versionen är den nya arkitekturen för steg-lagring och optimeringen av arbetet för båda byggverktygen (för Stapel och Dockerfile). Den nya arkitekturen för lagring öppnar möjligheter för att genomföra distribuerade byggnader från flera värdar och parallella byggprocesser på en värd.

Optimeringen av arbetet innebär att onödiga beräkningar i steget för att beräkna steg-signaturer avlägsnas och mekanismerna för att beräkna fil-checksummer görs mer effektiva. Denna optimering minskar den genomsnittliga byggtiden för projekt som använder werf. Och tomma byggnader, när alla steg finns i cache, stages-storage, är nu verkligen snabba. I de flesta fall kommer en omstart av byggnaden att ske snabbare än på 1 sekund! Detta gäller även verifieringsprocedurerna för steg under arbetet med teamet. werf deploy och werf run.

I denna release introducerades också en strategi för märkning av bilder baserat på innehåll — content-based tagging, som nu är aktiverad som standard och är den enda rekommenderade.

Låt oss ta en närmare titt på de viktigaste nyheterna i werf v1.1, och samtidigt berätta om framtidsplaner.

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

Nytt namnformat för steg och algoritm för urval av steg från cache

En ny regel för att generera namn på steg. Nu genererar varje byggt steg ett unikt namn som består av två delar: signatur (som i v1.0) plus en unik tidsstämpel.

Till exempel kan det fullständiga namnet på stegbilden se ut så här:

werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835

… eller i generell form:

werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC

Här:

SIGNATURE — detta är signaturen för steget, som representerar identifieraren för stegets innehåll och beror på historiken för ändringar i Git som ledde till detta innehåll;
TIMESTAMP_MILLISEC — detta är en garanterat unik identifierare för bilden, som genereras vid byggandet av en ny bild.

Algoritmen för att välja steg från cache baseras på att kontrollera släktskap mellan Git-commit.

Werf beräknar signaturen för en viss fas.
I stages-storage Det kan finnas flera faser med denna signatur. Werf väljer alla lämpliga faser baserat på signaturen.
Om den aktuella fasen är kopplad till Git (git-archive, anpassad fas med Git-patchar: install, beforeSetup, setup; eller git-latest-patch), väljer werf endast de faser som är kopplade till en commit som är en förfader till den aktuella commit (för vilken byggprocessen har anropats).
Av de återstående lämpliga faser väljs en - den äldsta baserat på skapelsedatum.

Fasen för olika Git-grenar kan ha samma signatur. Men werf förhindrar användning av cache som är kopplad till olika grenar mellan dessa grenar, även om signaturerna överensstämmer.

→ Dokumentation.

Ny algoritm för skapande och lagring av faser i fassystemet

Om werf inte hittar en lämplig fas i cachen när den försöker plocka faser, initieras processen för att bygga en ny fas.

Observera att flera processer (på en eller flera värdar) kan börja bygga samma fas vid ungefär samma tidpunkt. Werf använder en algoritm för optimistisk låsning stages-storage vid tidpunkten för lagring av den nybyggda bilden i stages-storage. Så när den nya fasen är färdigbyggd, låser werf stages-storage och sparar den nybyggda bilden endast om det inte redan finns en lämplig bild där (enligt signaturen och andra parametrar - se den nya algoritmen för att plocka faser från cachen).

Den nybyggda bilden kommer garanterat att ha ett unikt identifieringsnummer enligt TIMESTAMP_MILLISEC (se det nya namngivningsformatet för faser). Om en lämplig bild i stages-storage hittas, kommer werf att avfärda den nybyggda bilden och använda bilden från cachen.

Med andra ord: den första processen som slutför byggandet av bilden (den snabbaste) får rätt att spara den i stages-storage (och endast denna bild kommer att användas för alla byggprocesser). Den långsamma byggprocessen kommer aldrig att blockera den snabbare processen från att spara resultaten av byggandet av den aktuella fasen och gå vidare till byggandet av nästa.

→ Dokumentation.

Prestandan för Dockerfile-kompilatorn har förbättrats

För närvarande består konvergen av faser för bilden som byggs från Dockerfile av en fas - dockerfile. Vid beräkning av signaturen beaktas kontrollsumman av filerna. context, som kommer att användas vid byggandet. Fram till denna förbättring gick werf rekursivt igenom alla filer och fick en kontrollsumma genom att summera kontexten och modulen av varje fil. Från och med version v1.1 kan werf använda beräknade kontrollsummor som lagras i Git-förrådet.

I grunden för algoritmen — git ls-tree. Algoritmen tar hänsyn till poster i .dockerignore och går rekursivt genom filträdet endast när det behövs. På så sätt har vi kopplat bort läsningen av filsystemet, och algoritmens beroende av storlek context är inte väsentligt.

Algoritmen kontrollerar också untracked-filer och tar vid behov hänsyn till dem i kontrollsumman.

Prestandan har förbättrats vid import av filer

I wersjoner av werf v1.1 används en rsync-server vid import av filer från artefakter och bilder. Tidigare utfördes importen i två steg med användning av monterad katalog från värdsystemet.

Prestanda för importer på macOS är inte längre begränsad av Docker-volymer, utan importer utförs på samma tid som i Linux och Windows.

Innehållsbaserad märkning

Werf v1.1 stödjer så kallad märkning baserad på innehållet av bilden — content-based tagging. Taggar för de resulterande Docker-bilderna beror på innehållet i dessa bilder.

När kommandot werf publish --tags-by-stages-signature eller werf ci-env --tagging-strategy=stages-signature de publicerade bilderna kommer att märkas med den så kallade stadiesignaturen för bilden. Varje bild märks med sin egen stadiesignatur, som beräknas enligt samma regler som den vanliga signaturen för varje steg var för sig, men som är en övergripande identifierare för bilden.

Stadiesignaturen för bilden beror på:

innehållet i denna bild;
historiken av ändringar i Git, som ledde till detta innehåll.

I Git-förrådet finns det alltid tomma commits som inte ändrar innehållet i bildens filer. Till exempel commits endast med kommentarer eller merge-commits, eller commits som ändrar de filer i Git som inte kommer att importeras till bilden.

Vid användning av innehållsbaserad märkning löses problemen med onödiga omstarter av poddar i Kubernetes på grund av ändringar i bildnamnet, även om bildens innehåll inte har ändrats. Förresten är detta en av anledningarna till att det är svårt att lagra många mikrotjänster av en applikation i ett enda Git-förråd.

Content-based tagging är en mer pålitlig metod för taggning än taggning baserat på Git-grenar, eftersom innehållet i de resulterande bilderna inte beror på körordningen av pipeliner i CI-systemet för att bygga flera åtaganden från samma gren.

Det är viktigt: från och med nu stages-signature — detta är den enda rekommenderade taggningsstrategin. Denna kommer att användas som standard i teamet werf ci-env (om inte en annan taggningsschema anges specifikt).

→ Dokumentation. Denna funktion kommer också att få en separat publikation. UPPDATERAD (3 april): Artikel med detaljer i sin helhet i "Vladikavkaz Mathematical Journal"..

Loggnivåer

Användaren har nu möjlighet att kontrollera utmatningen, ställa in loggnivåer och arbeta med felsökningsinformation. Nyttiga alternativ har lagts till --log-quiet, --log-verbose, --log-debug.

Som standard innehåller utmatningen minimalt med information:

Med detaljerad utmatning (--log-verbose) kan man följa hur werf fungerar:

Detaljerad utmatning (--log-debug), förutom felsökningsinformationen från werf, innehåller även loggar från de använda biblioteken. Man kan exempelvis se hur interaktionen med Docker Registry går till och även notera var det går åt mycket tid:

Framtida planer

Varning! De möjligheter som beskrivs nedan och märkts med v1.1 kommer att finnas tillgängliga i denna version, många av dem — inom kort. Uppdateringar kommer genom automatiska uppdateringar vid användning av multiwerf. Dessa funktioner påverkar inte den stabila delen av funktionerna i v1.1, och deras introduktion kräver ingen manuell inblandning från användarens sida i redan existerande konfigurationer.

Fullt stöd för olika implementationer av Docker Registry (NYTT)

Version: v1.1
Tidsplan: mars
Issue

Målet är att användaren ska kunna använda valfri implementation utan begränsningar vid användning av werf.

För närvarande har vi identifierat följande uppsättning lösningar som vi avser att garantera fullt stöd för:

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

Lösningar markerade med stjärna är redan helt stödja av werf. För de andra finns det stöd, men med begränsningar.

Två huvudproblem kan identifieras:

Vissa lösningar stöder inte borttagning av taggar med hjälp av Docker Registry API, vilket gör det omöjligt för användare att använda den automatiska rensningen som implementerats i werf. Detta gäller AWS ECR, Docker Hub och GitHub Packages.
Vissa lösningar stöder inte så kallade nested repositories (Docker Hub, GitHub Packages och Quay) eller stöder dem men användaren måste skapa dem manuellt via UI eller API (AWS ECR).

Dessa och andra problem planerar vi att lösa med hjälp av inbyggda API:er i lösningarna. Denna uppgift omfattar även testtäckning av hela arbetscykeln för werf för var och en av dem.

Distribuerad byggande av bilder (↑)

Version: v1.2 v1.1 (prioriteringen för implementeringen av denna funktion har ökat)
Tidsramar: mars-april mars
Issue

För närvarande kan werf v1.0 och v1.1 endast användas på en dedikerad värd för operationer med byggande och publicering av bilder samt deployment av applikationer i Kubernetes.

För att öppna möjligheterna för distribuerat arbete med werf, när byggande och deployment av applikationer i Kubernetes startas på flera slumpmässiga värdar och dessa värdar inte behåller sitt tillstånd mellan byggnader (tillfälliga runner), krävs det att werf implementerar möjligheten att använda Docker Registry som lagring av steg.

Tidigare, när projektet werf fortfarande kallades dapp, fanns det denna möjlighet. Men vi stöttes på flera problem som måste beaktas vid implementeringen av denna funktion i werf.

Anmärkning. Denna möjlighet förutsätter inte att byggaren arbetar inom poddar i Kubernetes, eftersom detta kräver att man blir av med beroendet av den lokala Docker-servern (i podden Kubernetes har man inte tillgång till den lokala Docker-servern eftersom själva processen körs i en behållare, och arbetet med Docker-servern över nätet stöds inte av werf och kommer inte att stödjas). Stöd för arbete i Kubernetes kommer att implementeras separat.

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

Version: v1.1
Tidsplan: mars
Issue

Inkluderar dokumentationen för werf (avsnitt referens och guide), samt officiell GitHub Action för arbete med werf.

Dessutom kommer det att möjliggöra att werf fungerar på flyktiga runner.

Användarens interaktion med CI-systemet kommer att baseras på att sätta labels på pull-requester för att initiera vissa åtgärder för byggande/utrullning av applikationen.

Lokal utveckling och distribution av applikationer med werf (↓)

Version: v1.1
Tidsramar: januari-februari april
Issue

Huvudmålet är att uppnå en enhetlig och standardiserad konfiguration för distribution av applikationer både lokalt och i produktion, utan komplicerade åtgärder, "ur lådan".

Werf kräver också ett arbetsläge där det är bekvämt att redigera applikationskoden och omedelbart få återkoppling från den körande applikationen för felsökning.

Ny rensningsalgoritm (NYTT)

Version: v1.1
Tidsramar: april
Issue

I den aktuella versionen av werf v1.1 ingår inte rensning av bilder för innehållsbaserat taggning - dessa bilder kommer att samlas. — borttagning av instansen. I den nuvarande versionen av werf (v1.0 och v1.1) används olika rensningspolicyer för bilder publicerade enligt taggningsscheman: Git-gren, Git-tag eller Git-commit.

En ny enhetlig algoritm för rensning av bilder baserad på Git-commit-historik har tagits fram för alla taggningsscheman:

Behåll inte fler än N1 bilder kopplade till de N2 senaste commits för var och en av git HEAD (grenar och taggar).

Behåll inte fler än N1 stadiebilder kopplade till de N2 senaste commits för var och en av git HEAD (grenar och taggar).
Behåll alla bilder som används i några resurser i Kubernetes-klustret (alla kube-kontexter i konfigurationsfilen och namespaces skannas; detta beteende kan begränsas med speciella alternativ).
Behåll alla bilder som används i resurskonfigurationsmanifest som är sparade i Helm-releaser.
En bild kan raderas om den inte är kopplad till någon HEAD från git (till exempel eftersom den motsvarande HEAD har tagits bort) och inte används i något av manifesten i Kubernetes-klustret och i Helm-releaser.
Parallell byggande av bilder (↓)

Tidsramar: januari-februari april*

Version: v1.1
Den aktuella versionen av werf bygger bilder och artefakter som beskrivs i

, i följd. Det är nödvändigt att parallellisera byggprocessen av oberoende stadier av bilder och artefakter samt säkerställa en bekväm och informativ utdata. werf.yaml* Not: tidsramen har flyttats på grund av ökad prioritet för genomförandet av distribuerad byggnation, vilket kommer att ge fler möjligheter för horisontell skalning och användning av werf med GitHub Actions. Parallell byggnation är nästa steg mot optimering, vilket ger vertikal skalbarhet vid byggandet av ett enda projekt.

Övergång till Helm 3 (↓)

Version: v1.2

Tidsramar: februari-mars maj*
Inkluderar en övergång till en ny kodbas

och en beprövad, bekväm metod för migrering av befintliga installationer. Helm 3 och beprövad, smidig metod för att migrera befintliga installationer.

* Notera: Övergången till Helm 3 kommer inte att tillföra några avsevärda funktioner i werf, eftersom alla nyckelfunktioner i Helm 3 (3-vägs-sammanslagning och avsaknad av tiller) redan är implementerade i werf. Dessutom har werf ytterligare funktioner utöver de angivna. Dock förblir denna övergång i våra planer och kommer att genomföras.

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

Tidsramar: februari-mars maj*
Tidsramar: januari-februari, april-maj

Werf kommer att stödja beskrivningen av konfiguration för Kubernetes i Jsonnet-format. Samtidigt kommer werf att förbli kompatibelt med Helm och det kommer att finnas möjlighet att välja beskrivningsformat.

Anledningen är att mallarna i Go språket, enligt många, har en hög inlärningströskel och förståelsen av koden i dessa mallar lider också.

Det övervägs också att implementera andra system för beskrivning av Kubernetes-konfiguration (t.ex. Kustomize).

Arbete inom Kubernetes (↓)

Tidsramar: februari-mars maj*
Tidsramar: april-maj, maj-juni

Mål: att säkerställa byggandet av bilder och leverans av applikationen med hjälp av runner i Kubernetes. D.v.s. byggandet av nya bilder, deras publicering, rengöring och distribution kan ske direkt från poddar i Kubernetes.

För att genomföra denna möjlighet krävs först en förmåga till distribuerad byggnation av bilder (se punkt ovan).

Det krävs också stöd för arbetssättet där byggaren fungerar utan Docker-server (d.v.s. Kaniko-liknande byggande eller byggnation i användarrum).

Werf kommer att stödja byggnation i Kubernetes inte bara med hjälp av Dockerfile, utan också med sin egen byggare Stapel med inkrementella ombyggnader och Ansible.

Ett steg mot öppen utveckling

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

Det har nyligen beslutats att gå över till GitHub projektbrädor för att öppna upp vår teams arbetsprocess. Nu kan man se de närmaste planerna samt de aktuella arbetena inom följande områden:

Ett stort arbete har utförts med issues:

Obsoleta har tagits bort.
De befintliga har formats om till ett enhetligt format med tillräcklig mängd detaljer och insikter.
Nya issues med idéer och förslag har lagts till.

Hur man aktiverar version v1.1

Versionen är för närvarande tillgänglig i kanal 1.1 ea (i kanalerna stable och rock-solid utgåvor kommer att göras tillgängliga allteftersom stabiliseringen sker, men ea är redan tillräckligt stabil för användning, eftersom den har passerat genom kanaler. alpha och beta). Aktiveras genom multiwerf på följande sätt:

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

Slutsats

Den nya lagringsarkitekturen för steg och optimering av byggverktygen för Stapel och Dockerfile byggare öppnar möjligheter att genomföra distribuerade och parallella byggnationer i werf. Dessa möjligheter kommer snart att vara tillgängliga i samma release av v1.1 och bli automatiskt tillgängliga genom autouppdateringssystemet (för användare multiwerf).

I denna release har en taggstrategi baserat på innehållet i bilder lagts till — content-based tagging, — vilket blivit standardstrategin. En logg över de viktigaste kommandona har också omarbetats: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

Ett nästa betydande steg kommer att vara tillägget av distribuerade byggningar. Distribuerade byggningar har sedan v1.0 blivit en mer prioriterad uppgift än parallella byggningar, eftersom de tillför mer värde till werf: vertikal skalning av byggverktyg och stöd för tillfälliga byggverktyg i olika CI/CD-system, samt möjligheten att erbjuda officiellt stöd för GitHub Actions. Därför har tidsplaneringen för implementeringen av parallella byggningar flyttats. Men vi arbetar för att snabbt kunna realisera båda möjligheterna.

Håll dig uppdaterad! Och glöm inte att besöka oss på GitHub, för att skapa en issue, hitta en som redan finns och ge den ett plus, skapa en PR eller bara följa projektets utveckling.