— onze GitOps CLI-tool met open source voor het bouwen en leveren van applicaties in Kubernetes. Zoals beloofd, markeerde het begin van de toevoeging van nieuwe mogelijkheden aan werf en een herziening van gebruikelijke benaderingen. We zijn blij om versie v1.1 voor te stellen, die een grote stap voorwaarts is in de ontwikkeling en een basis legt voor de toekomst bouwer werf. De nieuwe versie is momenteel beschikbaar in .
De basis van deze release is een nieuwe architectuur voor het opslaan van fasen en optimalisatie van de werking van beide builders (voor Stapel en Dockerfile). De nieuwe architectuur opent mogelijkheden voor gedistribueerde builds vanaf meerdere hosts en parallelle builds op één host.
De optimalisatie omvat het elimineren van onnodige berekeningen tijdens de fase-signatuurcalculatie en het wijzigen van de mechanismen voor het berekenen van bestandscontrolesummen naar efficiëntere. Deze optimalisatie vermindert de gemiddelde bouwtijd van een project met behulp van werf. En lege builds, waarbij alle fasen in de cache bestaan, stages-storage, zijn nu echt snel. In de meeste gevallen zal een herstart van de build sneller dan 1 seconde duren! Dit geldt ook voor de verificatieprocedures van fasen tijdens de uitvoering van teams werf deploy en werf run.
Daarnaast is er in deze release een tagging-strategie voor afbeeldingen op basis van inhoud geïntroduceerd — content-based tagging, die nu standaard is ingeschakeld en de enige aanbevolen is.
Laten we de belangrijkste nieuwigheden in werf v1.1 eens nader bekijken en ook onze plannen voor de toekomst bespreken.
Wat is er veranderd in werf v1.1?
Nieuw naamgevingsformaat voor fasen en algoritme voor het ophalen van fasen uit de cache
Nieuwe regel voor het genereren van de naam van een fase. Nu genereert elke build van een fase een unieke naam die bestaat uit 2 delen: een handtekening (zoals het was in v1.0) plus een unieke tijdstempel.
Bijvoorbeeld, de volledige naam van de fase-afbeelding kan er als volgt uitzien:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
…of in het algemeen:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Hier:
-
SIGNATURE— dit is de handtekening van de fase, die de inhoudsidentifier van de fase vertegenwoordigt en afhankelijk is van de geschiedenis van aanpassingen in Git die tot deze inhoud hebben geleid; -
TIMESTAMP_MILLISEC— dit is een gegarandeerd unieke identifier van de afbeelding, die wordt gegenereerd op het moment van het bouwen van de nieuwe afbeelding.
Het algoritme voor het ophalen van fasen uit de cache is gebaseerd op het controleren van de verwantschap van Git-commits:
- Werf berekent de handtekening van een bepaalde fase.
- In stages-storage Er kunnen meerdere fasen zijn met dezelfde handtekening. Werf selecteert alle fasen die overeenkomen met de handtekening.
- Als de huidige fase verbonden is met Git (git-archive, aangepaste fase met Git-patches:
install,beforeSetup,setup; of git-latest-patch), dan selecteert werf alleen die fasen die verband houden met de commit die een voorouder is van de huidige commit (waarvoor de build is aangeroepen). - Van de resterende geschikte fasen wordt er één gekozen — de oudste op basis van de aanmaakdatum.
Fasen voor verschillende Git-takken kunnen dezelfde handtekening hebben. Maar werf voorkomt het gebruik van de cache die verband houdt met verschillende takken, zelfs als de handtekeningen overeenkomen.
.
Nieuw algoritme voor het maken en opslaan van fasen in de fasenopslag
Als werf geen geschikte fase kan vinden tijdens het zoeken in de cache, wordt het proces voor het bouwen van een nieuwe fase geïnitieerd.
Let op, dat meerdere processen (op één of meerdere hosts) tegelijkertijd kunnen beginnen met het bouwen van dezelfde fase. Werf gebruikt een algoritme voor optimistische locking stages-storage op het moment dat een vers gebouwd beeld wordt opgeslagen in stages-storage. Op deze manier, wanneer de bouw van een nieuwe fase gereed is, vergrendelt werf stages-storage en slaat daar het vers gebouwde beeld alleen op als er al geen geschikte afbeelding bestaat (op basis van handtekening en andere parameters — zie het nieuwe algoritme voor het zoeken naar fasen in de cache).
Het vers gebouwde beeld zal gegarandeerd een unieke identificatie hebben in TIMESTAMP_MILLISEC (zie het nieuwe naamgevingsformaat voor fasen). In het geval dat er in stages-storage een geschikte afbeelding wordt gevonden, zal werf het vers gebouwde beeld afwijzen en de afbeelding uit de cache gebruiken.
Met andere woorden: het eerste proces dat klaar is met het bouwen van het beeld (de snelste) krijgt het recht om het op te slaan in stages-storage (en die enige afbeelding zal worden gebruikt voor alle builds). Een trager bouwproces zal nooit een snellere proces blokkeren bij het opslaan van de resultaten van de huidige bouwfase en het overschakelen naar het bouwen van de volgende.
.
De prestaties van de Dockerfile-builder zijn verbeterd
Momenteel bestaat de fasepijplijn voor de afbeelding die wordt gebouwd uit Dockerfile uit één fase — dockerfile. Bij het berekenen van de handtekening wordt de checksum van bestanden in aanmerking genomen context, die zullen worden gebruikt bij de bouw. Tot deze verbetering heeft werf recursief alle bestanden doorlopen en een checksum verkregen door de context en modus van elk bestand op te tellen. Beginnend met versies v1.1 kan werf gebruikmaken van de berekende checksums die in de Git-repository zijn opgeslagen.
De basis van het algoritme is . Het algoritme houdt rekening met de vermeldingen in .dockerignore en doorloopt recursief de bestandsstructuur alleen indien nodig. Op deze manier hebben we ons losgemaakt van het lezen van het bestandssysteem, en is de afhankelijkheid van het algoritme ten opzichte van de grootte context niet essentieel.
Daarnaast controleert het algoritme ongetrackte bestanden en houdt het ze indien nodig mee in de checksum.
De prestaties bij het importeren van bestanden zijn verbeterd
In versies van werf v1.1 wordt een rsync-server gebruikt bij . Voorheen vond de import in twee stappen plaats met behulp van het mounten van een directory vanuit het hostsysteem.
De prestaties van imports in macOS worden niet langer beperkt door Docker-volumes, en imports worden uitgevoerd in dezelfde tijd als in Linux en Windows.
Content-based tagging
Werf v1.1 ondersteunt zogenaamde tagging op basis van de inhoud van de afbeelding - content-based tagging. De tags van de resulterende Docker-afbeeldingen zijn afhankelijk van de inhoud van deze afbeeldingen.
Bij het uitvoeren van het commando werf publish --tags-by-stages-signature of werf ci-env --tagging-strategy=stages-signature de te publiceren beelden zullen worden getagd met de zogenaamde fase-signatuur van de afbeelding. Elke afbeelding wordt getagd met zijn eigen fase-signatuur, die wordt berekend op dezelfde manier als de reguliere signatuur van elke fase afzonderlijk, maar is een overkoepelende identifier van de afbeelding.
De fase-signatuur van de afbeelding is afhankelijk van:
- de inhoud van deze afbeelding;
- de geschiedenis van de wijzigingen in Git die tot deze inhoud hebben geleid.
In de Git-repository zijn er altijd lege commits die de inhoud van de bestanden in de afbeelding niet wijzigen. Bijvoorbeeld commits met alleen opmerkingen, merge-commits, of commits die de bestanden in Git wijzigen die niet in de afbeelding worden geïmporteerd.
Bij het gebruik van content-based tagging worden problemen van onnodige herstarts van de pods van de applicatie in Kubernetes opgelost vanwege veranderingen in de afbeeldingsnaam, zelfs als de inhoud van de afbeelding niet is veranderd. Overigens is dit een van de redenen die het moeilijk maken om meerdere microservices van één applicatie in één enkele Git-repository te bewaren.
Content-based tagging is een betrouwbaardere taggingmethode dan tagging via Git-branches, omdat de inhoud van de resulterende afbeeldingen niet afhankelijk is van de uitvoeringsvolgorde van pipelines in het CI-systeem voor het bouwen van meerdere commits van dezelfde branch.
Belangrijk: vanaf dit moment stages-signature is de enige aanbevolen taggingstrategie. Deze zal standaard worden gebruikt in het team werf ci-env (tenzij expliciet een andere taggingstructuur wordt opgegeven).
. Aan deze functie zal ook een aparte publicatie worden gewijd. BIJGEWERKT (3 april): Artikel met details .
Loggingniveaus
De gebruiker heeft de mogelijkheid om de uitvoer te regelen, het logniveau in te stellen en met debug-informatie te werken. Toegevoegd zijn de opties --log-quiet, --log-verbose, --log-debug.
Standaard bevat de uitvoer minimaal informatie:
Bij gebruik van gedetailleerde uitvoer (--log-verbose) kan men volgen hoe werf werkt:
Gedetailleerde uitvoer (--log-debug), naast de debug-informatie van werf, bevat ook de logs van de gebruikte bibliotheken. Bijvoorbeeld, je kunt zien hoe de interactie met Docker Registry plaatsvindt, evenals de plekken vastleggen waar aanzienlijk veel tijd wordt besteed:
Toekomstige plannen
Let op! De hieronder beschreven mogelijkheden met de aanduiding v1.1 zijn al beschikbaar in deze versie, velen hiervan zullen binnenkort beschikbaar zijn. Updates zullen via automatische updates komen . Deze mogelijkheden beïnvloeden de stabiele delen van de functies in v1.1 niet, hun komst vereist geen handmatige tussenkomst van de gebruiker in reeds bestaande configuraties.
Volledige ondersteuning voor verschillende implementaties van Docker Registry (NIEUW)
- Versie: v1.1
- Termijnen: maart
Doel — de gebruiker moet een willekeurige implementatie kunnen gebruiken zonder beperkingen bij het gebruik van werf.
Op dit moment onderscheiden we de volgende set oplossingen waarvoor we volledige ondersteuning zullen garanderen:
- Default (library/registry)*,
- AWS ECR,
- Azure*,
- Docker Hub,
- GCR*,
- GitHub Packages,
- GitLab Registry*,
- Harbor*,
- Quay.
Met een ster zijn oplossingen gemarkeerd die op dit moment al volledig door werf worden ondersteund. Voor de andere is er ondersteuning, maar met beperkingen.
Er kunnen twee hoofdproblemen worden onderscheiden:
- Sommige oplossingen ondersteunen het verwijderen van tags via de Docker Registry API niet, waardoor gebruikers de automatische schoonmaak die in werf is geïmplementeerd, niet kunnen gebruiken. Dit geldt voor AWS ECR, Docker Hub en GitHub Packages.
- Sommige oplossingen ondersteunen niet, de zogenaamde, nested repositories (Docker Hub, GitHub Packages en Quay) of ondersteunen het, maar de gebruiker moet deze handmatig aanmaken, gebruikmakend van de UI of API (AWS ECR).
Deze en andere problemen gaan we aanpakken met behulp van de native API's van de oplossingen. Deze taak omvat ook het testen van de volledige levenscyclus van werf voor elk van hen.
Gedecentraliseerde build van afbeeldingen (↑)
- Versie: v1.2 v1.1 (de prioriteit voor de implementatie van deze functie is verhoogd)
- Tijdslijnen: maart-april maart
Momenteel kunnen werf v1.0 en v1.1 alleen worden gebruikt op één vaste host voor de taken van het bouwen en publiceren van afbeeldingen en het deployen van applicaties in Kubernetes.
Om de mogelijkheden van gedecentraliseerd werken met werf te openen, waarbij de bouw en deployment van applicaties in Kubernetes op meerdere willekeurige hosts wordt gestart en deze hosts hun status niet behouden tussen builds (tijdelijke runners), moet werf de mogelijkheid implementeren om Docker Registry te gebruiken als opslag voor fases.
Eerder, toen het project werf nog dapp heette, was er zo'n mogelijkheid. We zijn echter tegen verschillende problemen aangelopen die we moeten overwegen bij het implementeren van deze functie in werf.
Opmerking. Deze mogelijkheid houdt geen rekening met het werken van de builder binnen Kubernetes pods, omdat het noodzakelijk is afhankelijkheid van de lokale Docker-server te elimineren (in een Kubernetes pod is er geen toegang tot de lokale Docker-server, omdat het proces zelf in een container draait, en interactie met de Docker-server via het netwerk wordt door werf niet ondersteund en zal dat ook niet worden). Ondersteuning voor werken in Kubernetes zal afzonderlijk worden gerealiseerd.
Officiële ondersteuning voor GitHub Actions (NIEUW)
- Versie: v1.1
- Termijnen: maart
Bevat documentatie voor werf (secties referentie en gids), evenals de officiële GitHub Action voor het werken met werf.
Bovendien maakt het mogelijk om werf op ephemeral runners te laten werken.
De interactie tussen de gebruiker en het CI-systeem is gebaseerd op het toewijzen van labels aan pull-requests om bepaalde acties voor het bouwen/deployen van de applicatie te initiëren.
Lokale ontwikkeling en deployment van applicaties met werf (↓)
- Versie: v1.1
- Tijdslijnen: januari-februari april
Het belangrijkste doel is om een uniforme configuratie te bereiken voor de deployment van applicaties zowel lokaal als in productie, zonder complexe handelingen, ‘out of the box’.
Van werf is ook een modus vereist waarin het gemakkelijk is om de code van de applicatie te bewerken en onmiddellijk feedback te krijgen van de werkende applicatie voor debugging.
Nieuw schoonmaakalgoritme (NIEUW)
- Versie: v1.1
- Termijnen: april
In de huidige versie van werf v1.1 in de procedure is het verwijderen van de instantie. is er geen schoonmaak van afbeeldingen voor de inhoud-gebaseerde tagging — deze afbeeldingen zullen zich ophopen.
Ook in de huidige versies van werf (v1.0 en v1.1) worden verschillende schoonmaakbeleid gebruikt voor afbeeldingen gepubliceerd volgens tagging schema's: Git-tak, Git-tag of Git-commit.
Er is een nieuw uniform schoonmaakalgoritme voor alle tagging schema's bedacht op basis van de geschiedenis van commits in Git:
- Bewaar niet meer dan N1 afbeeldingen die zijn gerelateerd aan de N2 laatste commits voor elk van de git HEAD (takken en tags).
- Bewaar niet meer dan N1 stage-afbeeldingen die zijn gerelateerd aan de N2 laatste commits voor elk van de git HEAD (takken en tags).
- Bewaar alle afbeeldingen die worden gebruikt in bronnen van het Kubernetes-cluster (alle kube-contexten in het configuratiebestand en namespaces worden gescand; dit gedrag kan worden beperkt met speciale opties).
- Bewaar alle afbeeldingen die worden gebruikt in configuratie-manifesten van bronnen, opgeslagen in Helm-releases.
- Een afbeelding kan worden verwijderd als deze niet is gerelateerd aan een HEAD uit git (bijvoorbeeld omdat de bijbehorende HEAD zelf is verwijderd) en niet wordt gebruikt in een van de manifesten in het Kubernetes-cluster en in de Helm-releases.
Parallel assembleren van afbeeldingen (↓)
- Versie: v1.1
- Termijnen: januari-februari april*
De huidige versie van werf assembleert afbeeldingen en artefacten die beschreven zijn in werf.yaml, sequentieel. Het is nodig om het assembleren van onafhankelijke fasen van afbeeldingen en artefacten te paralleliseren, alsook zorgen voor een gemakkelijke en informatieve output.
* Opmerking: de termijn is verschoven vanwege de verhoogde prioriteit voor de implementatie van gedistribueerde assemblage, die meer mogelijkheden voor horizontale schaalbaarheid zal toevoegen, evenals het gebruik van werf met GitHub Actions. Parallel assembleren is de volgende stap in optimalisatie, die verticale schaalbaarheid biedt bij de assemblage van een enkel project.
Overstappen naar Helm 3 (↓)
- Versie: v1.2
- Termijnen: februari-maart mei*
Bevat de overstap naar een nieuwe codebasis en een beproefde, gebruiksvriendelijke migratie methode voor bestaande installaties.
* Opmerking: de overstap naar Helm 3 zal geen significante functionaliteiten aan werf toevoegen, omdat alle belangrijke kenmerken van Helm 3 (3-way-merge en de afwezigheid van tiller) al in werf zijn geïmplementeerd. Bovendien heeft werf naast de genoemde. Deze overstap blijft echter op onze agenda en zal worden uitgevoerd.
Jsonnet voor het beschrijven van Kubernetes-configuratie (↓)
- Versie: v1.2
- Termijnen: januari-februari, april-mei
Werf zal het beschrijven van configuraties voor Kubernetes in Jsonnet-indeling ondersteunen. Werf blijft compatibel met Helm en er zal de mogelijkheid zijn om het beschrijvingsformaat te kiezen.
De reden hiervoor is het feit dat de templates van de Go-taal, volgens velen, een hoge instapdrempel hebben en de begrijpelijkheid van de code in deze templates ook lijdt.
Er wordt ook gekeken naar de mogelijkheid om andere systemen voor het beschrijven van Kubernetes-configuraties (bijvoorbeeld Kustomize) te implementeren.
Werken binnen Kubernetes (↓)
- Versie: v1.2
- Termijnen: april-mei, mei-juni
Doel: het mogelijk maken van het bouwen van images en de levering van applicaties met behulp van runners in Kubernetes. Dat wil zeggen, het bouwen van nieuwe images, hun publicatie, opschoning en deployment kan direct vanuit Kubernetes-pods plaatsvinden.
Om deze mogelijkheid te realiseren, is eerst de mogelijkheid van gedistribueerd bouwen van images nodig (zie hierboven).
Daarnaast is ondersteuning voor de werking modus van de builder zonder Docker-server vereist (d.w.z. een Kaniko-achtige buil of gebouwd in userspace).
Werf zal het bouwen in Kubernetes ondersteunen, niet alleen met behulp van Dockerfile, maar ook met zijn eigen builder Stapel voor incrementele builds en Ansible.
Een stap richting open ontwikkeling
We houden van onze gemeenschap (, ) en willen dat steeds meer mensen helpen om werf beter te maken, begrijpen in welke richting we gaan, en deelnemen aan de ontwikkeling.
Onlangs werd besloten om over te schakelen naar om het werkproces van ons team te openen. Nu kan men de komende plannen bekijken, evenals het huidige werk op de volgende gebieden:
- ;
- ;
- ;
- .
Er is veel werk verzet met issues:
- Oude zijn verwijderd.
- Bestaande zijn gebracht in een uniform formaat, met voldoende details en precisie.
- Nieuwe issues met ideeën en voorstellen zijn toegevoegd.
Hoe versie v1.1 in te schakelen
De versie is momenteel beschikbaar in (in de kanalen stable en rock-solid releases zullen verschijnen naarmate ze stabiliseren, maar ea is al op zichzelf vrij stabiel voor gebruik, aangezien het door de kanalen is gegaan. alpha en beta). Wordt geactiveerd volgende manier:
source $(multiwerf use 1.1 ea)
werf COMMAND ...Conclusie
Nieuwe opslagarchitectuur voor stadia en optimalisatie van de bouwer voor Stapel en Dockerfile-bouwers opent mogelijkheden voor gedistribueerde en parallelle builds in werf. Deze mogelijkheden zullen binnenkort beschikbaar zijn in dezelfde versie v1.1 en automatisch beschikbaar komen via het mechanisme voor automatische updates (voor gebruikers ).
In deze release is er een strategie voor tagging op basis van de inhoud van afbeeldingen toegevoegd — content-based tagging, — die de standaardstrategie is geworden. Ook is het logboek van de belangrijkste commando's herzien: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
De volgende belangrijke stap zal de toevoeging van gedistribueerde builds zijn. Gedistribueerde builds zijn sinds v1.0 een prioriteit geworden boven parallelle builds, omdat ze meer waarde aan werf toevoegen: verticale schaalvergroting van bouwers en ondersteuning voor tijdelijke bouwers in verschillende CI/CD-systemen, evenals de mogelijkheid voor officiële ondersteuning van GitHub Actions. Daarom zijn de termijnen voor de implementatie van parallelle builds verplaatst. We werken echter aan een snelle realisatie van beide mogelijkheden.
Volg het nieuws! En vergeet niet om bij ons te kijken in , om een issue te maken, een bestaande te vinden en een duimpje omhoog te geven, een PR aan te maken of gewoon het project te volgen.
P.S.
Lees ook op onze blog:
- «»
- «»;
- Een cyclus van notities over de innovaties in werf:
- «»;
- «»;
- «»;
- «».
Bron: habr.com
