is ons open source GitOps CLI-hulpprogramma voor het bouwen en leveren van applicaties aan Kubernetes. Zoals beloofd, markeerde het begin van het toevoegen van nieuwe functies aan de werf en het herzien van traditionele benaderingen. Nu presenteren we met genoegen release v1.1, een grote stap in de ontwikkeling en een basis voor de toekomst verzamelaar werf. De versie is momenteel beschikbaar in .
De basis van de release is de nieuwe architectuur van de podiumopslag en optimalisatie van het werk van beide verzamelaars (voor Stapel en Dockerfile). De nieuwe opslagarchitectuur opent de mogelijkheid om gedistribueerde assemblages van meerdere hosts en parallelle assemblages op dezelfde host te implementeren.
Optimalisatie van het werk omvat het wegwerken van onnodige berekeningen in de fase van het berekenen van fasehandtekeningen en het veranderen van de mechanismen voor het berekenen van bestandscontrolesommen naar efficiëntere mechanismen. Deze optimalisatie verkort de gemiddelde bouwtijd van projecten met behulp van de werf. En inactieve builds, wanneer alle fasen in de cache aanwezig zijn podia-opslag, zijn nu echt snel. In de meeste gevallen duurt het herstarten van de build minder dan 1 seconde! Dit geldt ook voor procedures voor het verifiëren van fasen in het proces van teamwerk. werf deploy и werf run.
Ook in deze release verscheen een strategie voor het taggen van afbeeldingen op inhoud: op inhoud gebaseerde tagging, die nu standaard is ingeschakeld en de enige wordt aanbevolen.
Laten we de belangrijkste innovaties in werf v1.1 eens nader bekijken en u tegelijkertijd vertellen over plannen voor de toekomst.
Wat is er veranderd in werf v1.1?
Nieuw naamgevingsformaat en algoritme voor het selecteren van fasen uit de cache
Nieuwe regel voor het genereren van artiestennamen. Nu genereert elke stage-build een unieke stage-naam, die uit twee delen bestaat: een handtekening (zoals het was in v2) plus een unieke tijdelijke identificatie.
De volledige naam van de podiumafbeelding kan er bijvoorbeeld als volgt uitzien:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
...of in het algemeen:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Здесь:
-
SIGNATUREis een stage signature, die de identificatie van de stage-inhoud vertegenwoordigt en afhangt van de geschiedenis van bewerkingen in Git die tot deze inhoud hebben geleid; -
TIMESTAMP_MILLISECis een gegarandeerd unieke afbeeldingsidentificatie die wordt gegenereerd op het moment dat een nieuwe afbeelding wordt gemaakt.
Het algoritme voor het selecteren van fasen uit de cache is gebaseerd op het controleren van de relatie tussen Git-commits:
- Werf berekent de signatuur van een bepaalde etappe.
- В podia-opslag Er kunnen verschillende fasen zijn voor een bepaalde handtekening. Werf selecteert alle etappes die passen bij de signatuur.
- Als de huidige fase aan Git is gekoppeld (git-archief, aangepaste fase met Git-patches:
install,beforeSetup,setup; of git-latest-patch), dan selecteert werf alleen die fasen die geassocieerd zijn met een commit die een voorloper is van de huidige commit (waarvoor de build wordt aangeroepen). - Uit de resterende geschikte fasen wordt er één geselecteerd: de oudste op aanmaakdatum.
Een podium voor verschillende Git-takken kan dezelfde signatuur hebben. Maar werf zal voorkomen dat de cache die aan verschillende branches is gekoppeld, tussen deze branches wordt gebruikt, zelfs als de handtekeningen overeenkomen.
.
Nieuw algoritme voor het maken en opslaan van fasen in de podiumopslag
Als werf bij het selecteren van etappes uit de cache geen geschikte etappe vindt, wordt het proces van het samenstellen van een nieuwe etappe gestart.
Houd er rekening mee dat meerdere processen (op een of meer hosts) ongeveer tegelijkertijd kunnen beginnen met het bouwen van dezelfde fase. Werf maakt gebruik van een optimistisch blokkeeralgoritme podia-opslag op het moment dat de vers verzamelde afbeelding wordt opgeslagen podia-opslag. Zo blokkeert de werf als de nieuwe podiumopbouw klaar is podia-opslag en slaat daar alleen een nieuw verzamelde afbeelding op als daar geen geschikte afbeelding meer bestaat (via handtekening en andere parameters - zie het nieuwe algoritme voor het selecteren van fasen uit de cache).
Een vers samengestelde afbeelding heeft gegarandeerd een unieke identificatie door TIMESTAMP_MILLISEC (zie het nieuwe formaat voor de naamgeving van het podium). In het geval dat podia-opslag er wordt een geschikte afbeelding gevonden, de werf verwijdert de nieuw samengestelde afbeelding en gebruikt de afbeelding uit de cache.
Met andere woorden: het eerste proces dat het opbouwen van de afbeelding voltooit (de snelste) krijgt het recht om deze op te slaan in fasenopslag (en dan is het deze enkele afbeelding die voor alle builds wordt gebruikt). Een langzaam bouwproces zal nooit voorkomen dat een sneller proces de bouwresultaten van de huidige fase opslaat en doorgaat naar de volgende bouw.
.
Verbeterde prestaties van de Dockerfile-builder
Op dit moment bestaat de pijplijn van fasen voor een afbeelding die is opgebouwd uit een Dockerfile uit één fase: dockerfile. Bij het berekenen van de handtekening wordt de controlesom van de bestanden berekend context, die gebruikt zal worden tijdens de montage. Vóór deze verbetering liep Werf recursief door alle bestanden en verkreeg een controlesom door de context en modus van elk bestand op te tellen. Vanaf v1.1 kan werf berekende controlesommen gebruiken die zijn opgeslagen in de Git-repository.
Het algoritme is gebaseerd op . Het algoritme houdt rekening met records in .dockerignore en doorloopt de bestandsboom alleen recursief wanneer dat nodig is. We hebben ons dus losgekoppeld van het lezen van het bestandssysteem en de afhankelijkheid van het algoritme van de grootte context is niet significant.
Het algoritme controleert ook niet-bijgehouden bestanden en houdt daar indien nodig rekening mee in de controlesom.
Verbeterde prestaties bij het importeren van bestanden
Versies van werf v1.1 gebruiken een rsync-server wanneer . Voorheen gebeurde het importeren in twee stappen met behulp van een directorymount vanaf het hostsysteem.
De importprestaties op macOS worden niet langer beperkt door Docker-volumes, en het importeren is in dezelfde tijd voltooid als Linux en Windows.
Op inhoud gebaseerde tagging
Werf v1.1 ondersteunt zogenaamde tagging op afbeeldingsinhoud - op inhoud gebaseerde tagging. De tags van de resulterende Docker-afbeeldingen zijn afhankelijk van de inhoud van die afbeeldingen.
Bij het uitvoeren van de opdracht werf publish --tags-by-stages-signature of werf ci-env --tagging-strategy=stages-signature gepubliceerde afbeeldingen van de zogenaamde podium handtekening afbeelding. Elke afbeelding wordt getagd met een eigen handtekening van de stadia van deze afbeelding, die wordt berekend volgens dezelfde regels als de reguliere handtekening van elke fase afzonderlijk, maar die een algemene identificatie van de afbeelding is.
De signatuur van de beeldstadia is afhankelijk van:
- de inhoud van deze afbeelding;
- geschiedenis van de Git-veranderingen die tot deze inhoud hebben geleid.
Een Git-repository heeft altijd dummy-commits die de inhoud van de afbeeldingsbestanden niet veranderen. Bijvoorbeeld commits met alleen commentaar of merge commits, of commits die de bestanden in Git wijzigen die niet in de afbeelding geïmporteerd zullen worden.
Bij gebruik van op inhoud gebaseerde tagging worden de problemen van het onnodig opnieuw opstarten van applicatie-pods in Kubernetes als gevolg van wijzigingen in de afbeeldingsnaam opgelost, zelfs als de inhoud van de afbeelding niet is gewijzigd. Dit is trouwens een van de redenen die verhindert dat veel microservices van één applicatie in één Git-repository worden opgeslagen.
Ook is op inhoud gebaseerd taggen een betrouwbaardere taggingmethode dan taggen op Git-takken, omdat de inhoud van de resulterende afbeeldingen niet afhankelijk is van de volgorde waarin pipelines worden uitgevoerd in het CI-systeem voor het samenstellen van meerdere commits van dezelfde branch.
Het is belangrijk: vanaf nu stadia-handtekening - Is de enige aanbevolen tagstrategie. Het wordt standaard gebruikt in de opdracht werf ci-env (tenzij u expliciet een ander taggingschema opgeeft).
. Ook hieraan zal een aparte publicatie worden gewijd. BIJGEWERKT (3 april): Artikel met details .
Logboekniveaus
De gebruiker heeft nu de mogelijkheid om de uitvoer te controleren, het logniveau in te stellen en te werken met foutopsporingsinformatie. Opties toegevoegd --log-quiet, --log-verbose, --log-debug.
Standaard bevat de uitvoer de minimale informatie:
Bij gebruik van uitgebreide uitvoer (--log-verbose) kun je zien hoe werf werkt:
Gedetailleerde uitvoer (--log-debug), bevat naast foutopsporingsinformatie ook logs van gebruikte bibliotheken. U kunt bijvoorbeeld zien hoe de interactie met het Docker-register plaatsvindt en ook de plaatsen vastleggen waar een aanzienlijke hoeveelheid tijd wordt doorgebracht:
Verdere plannen
Waarschuwing! De hieronder beschreven opties zijn gemarkeerd v1.1 zullen in deze versie beschikbaar komen, waarvan vele in de nabije toekomst. Updates komen via automatische updates . Deze functies hebben geen invloed op het stabiele deel van v1.1-functies; hun uiterlijk vereist geen handmatige tussenkomst van de gebruiker in bestaande configuraties.
Volledige ondersteuning voor verschillende Docker Registry-implementaties (NIEUW)
- Versie: v1.1
- Data: maart
Het doel is dat de gebruiker zonder beperkingen gebruik kan maken van een maatwerkimplementatie bij het gebruik van werf.
Momenteel hebben we de volgende reeks oplossingen geïdentificeerd waarvoor we volledige ondersteuning gaan garanderen:
- Standaard (bibliotheek/register)*,
- AWS ECR
- Azuur*,
- Docker-hub
- GCR*,
- GitHub-pakketten
- GitLab-register*,
- Haven*,
- Kade.
Oplossingen die momenteel volledig door werf worden ondersteund, zijn gemarkeerd met een asterisk. Voor anderen is er wel steun, maar met beperkingen.
Er kunnen twee hoofdproblemen worden geïdentificeerd:
- Sommige oplossingen bieden geen ondersteuning voor het verwijderen van tags met behulp van de Docker Registry API, waardoor gebruikers de automatische opruiming van de werf niet kunnen gebruiken. Dit geldt voor AWS ECR-, Docker Hub- en GitHub-pakketten.
- Sommige oplossingen ondersteunen zogenaamde geneste repositories (Docker Hub, GitHub Packages en Quay) niet, maar de gebruiker moet deze handmatig aanmaken met behulp van de UI of API (AWS ECR).
We gaan deze en andere problemen oplossen met behulp van native API's van de oplossingen. Deze taak omvat ook het bestrijken van de volledige cyclus van de exploitatie van de werf, met tests voor elk ervan.
Gedistribueerde beeldopbouw (↑)
- Versie: v1.2 v1.1 (de prioriteit voor het implementeren van deze functie is verhoogd)
- Data: maart-april maart
Op dit moment kunnen werf v1.0 en v1.1 slechts op één speciale host worden gebruikt voor het bouwen en publiceren van afbeeldingen en het implementeren van de applicatie op Kubernetes.
Om de mogelijkheden van gedistribueerd werk van werf te openen, wanneer het bouwen en implementeren van applicaties in Kubernetes wordt gelanceerd op verschillende willekeurige hosts en deze hosts hun status niet opslaan tussen builds (tijdelijke runners), is werf vereist om de mogelijkheid te implementeren om gebruik te maken van de Docker Registry als stage store.
Vroeger, toen het werfproject nog dapp heette, had het zo’n kans. We zijn echter een aantal problemen tegengekomen waarmee rekening moet worden gehouden bij het implementeren van deze functionaliteit in de werf.
Noot. Voor deze functie is het niet nodig dat de verzamelaar in Kubernetes-pods werkt, omdat Om dit te doen moet je de afhankelijkheid van de lokale Docker-server wegnemen (in de Kubernetes-pod is er geen toegang tot de lokale Docker-server, omdat het proces zelf in een container draait en werf geen ondersteuning biedt en zal bieden werken met de Docker-server via het netwerk). Ondersteuning voor het uitvoeren van Kubernetes wordt afzonderlijk geïmplementeerd.
Officiële ondersteuning voor GitHub-acties (NIEUW)
- Versie: v1.1
- Data: maart
Inclusief werfdocumentatie (secties referentie и gids), evenals de officiële GitHub-actie voor het werken met werf.
Bovendien zal de werf hiermee kunnen werken aan kortstondige hardlopers.
De werking van de gebruikersinteractie met het CI-systeem zal gebaseerd zijn op het plaatsen van labels op pull-aanvragen om bepaalde acties te initiëren om de applicatie te bouwen/uitrollen.
Lokale ontwikkeling en inzet van applicaties met werf (↓)
- Versie: v1.1
- Data: januari-februari april
Het belangrijkste doel is om één uniforme configuratie te realiseren voor het out-of-the-box implementeren van applicaties, zowel lokaal als in productie, zonder complexe handelingen.
werf moet ook een bedieningsmodus hebben waarin het handig is om de applicatiecode te bewerken en direct feedback te ontvangen van de actieve applicatie voor foutopsporing.
Nieuw reinigingsalgoritme (NIEUW)
- Versie: v1.1
- Data: april
In de huidige versie van werf v1.1 in de procedure cleanup Er is geen voorziening voor het opschonen van afbeeldingen voor het op inhoud gebaseerde tagging-schema; deze afbeeldingen zullen zich opstapelen.
Ook gebruikt de huidige versie van werf (v1.0 en v1.1) een ander opschoonbeleid voor afbeeldingen die zijn gepubliceerd onder tagging-schema's: Git branch, Git tag of Git commit.
Er is een nieuw algoritme uitgevonden voor het opschonen van afbeeldingen, gebaseerd op de geschiedenis van commits in Git, verenigd voor alle tagging-schema's:
- Bewaar niet meer dan N1 images geassocieerd met de N2 meest recente commits voor elke git HEAD (takken en tags).
- Bewaar niet meer dan N1 stage-images die zijn gekoppeld aan de N2 meest recente commits voor elke git HEAD (takken en tags).
- Sla alle afbeeldingen op die worden gebruikt in alle Kubernetes-clusterbronnen (alle kube-contexten van het configuratiebestand en naamruimten worden gescand; u kunt dit gedrag beperken met speciale opties).
- Sla alle installatiekopieën op die worden gebruikt in resourceconfiguratiemanifesten die zijn opgeslagen in Helm-releases.
- Een afbeelding kan worden verwijderd als deze niet is gekoppeld aan een HEAD van git (bijvoorbeeld omdat de corresponderende HEAD zelf is verwijderd) en niet wordt gebruikt in manifesten in het Kubernetes-cluster en in Helm-releases.
Parallelle beeldvorming (↓)
- Versie: v1.1
- Data: januari-februari april*
De huidige versie van werf verzamelt de afbeeldingen en artefacten die worden beschreven in werf.yaml, opeenvolgend. Het is noodzakelijk om het proces van het samenstellen van onafhankelijke stadia van afbeeldingen en artefacten te parallelliseren, en om handige en informatieve uitvoer te bieden.
*Let op: de deadline is verschoven vanwege de toegenomen prioriteit voor het implementeren van gedistribueerde assemblage, wat meer horizontale schaalmogelijkheden zal toevoegen, evenals het gebruik van werf met GitHub Actions. Parallelle montage is de volgende optimalisatiestap en biedt verticale schaalbaarheid bij het samenstellen van één project.
Overgang naar roer 3 (↓)
- Versie: v1.2
- Data: februari-maart mei*
Inclusief migratie naar nieuwe codebase en een beproefde, handige manier om bestaande installaties te migreren.
* Opmerking: overstappen naar Helm 3 voegt geen significante functies toe aan de werf, omdat alle belangrijke kenmerken van Helm 3 (3-weg-samenvoegen en geen helmstok) al in de werf zijn geïmplementeerd. Bovendien heeft werf naast de aangegeven. Deze transitie blijft echter in onze plannen en zal worden doorgevoerd.
Jsonnet voor het beschrijven van Kubernetes-configuratie (↓)
- Versie: v1.2
- Data: januari-februari april-mei
Werf ondersteunt configuratiebeschrijvingen voor Kubernetes in Jsonnet-formaat. Tegelijkertijd blijft werf compatibel met Helm en is er keuze uit het beschrijvingsformaat.
De reden is dat Go-sjablonen volgens veel mensen een hoge toegangsdrempel hebben en dat ook de begrijpelijkheid van de code van deze sjablonen eronder lijdt.
Er wordt ook nagedacht over de mogelijkheid om andere Kubernetes-configuratiebeschrijvingssystemen te introduceren (bijvoorbeeld Kustomize).
Werken binnen Kubernetes (↓)
- Versie: v1.2
- Data: april-mei mei-juni
Doel: Zorgen dat images worden gebouwd en de applicatie wordt opgeleverd met behulp van runners in Kubernetes. Die. Nieuwe images kunnen rechtstreeks vanuit Kubernetes-pods worden gebouwd, gepubliceerd, opgeschoond en geïmplementeerd.
Om deze mogelijkheid te implementeren, hebt u eerst de mogelijkheid nodig om gedistribueerde images te bouwen (zie punt hierboven).
Het vereist ook ondersteuning voor de bedieningsmodus van de bouwer zonder een Docker-server (dat wil zeggen Kaniko-achtige build of ingebouwde gebruikersruimte).
Werf ondersteunt het bouwen op Kubernetes niet alleen met Dockerfile, maar ook met zijn Stapel-bouwer met incrementele verbouwingen en Ansible.
Een stap richting open ontwikkeling
We houden van onze gemeenschap (, ) en we willen dat steeds meer mensen helpen de werf beter te maken, de richting waarin we gaan begrijpen en deelnemen aan de ontwikkeling.
Vrij recent werd besloten om over te stappen naar om het werkproces van ons team zichtbaar te maken. Nu kunt u de directe plannen zien, evenals de huidige werkzaamheden op de volgende gebieden:
- ;
- ;
- ;
- .
Er is veel werk verricht met de volgende problemen:
- Onbelangrijke zaken verwijderd.
- De bestaande worden naar één formaat gebracht, met voldoende details en details.
- Er zijn nieuwe uitgaven met ideeën en suggesties toegevoegd.
Hoe versie v1.1 in te schakelen
De versie is momenteel beschikbaar in (in kanalen stabiel и Keihard; zeer stabiel releases zullen echter verschijnen naarmate stabilisatie plaatsvindt ea zelf is al stabiel genoeg voor gebruik, omdat ging via de kanalen alpha и beta). Geactiveerd op de volgende manier:
source $(multiwerf use 1.1 ea)
werf COMMAND ...Conclusie
De nieuwe platformopslagarchitectuur en bouweroptimalisaties voor Stapel- en Dockerfile-bouwers openen de mogelijkheid om gedistribueerde en parallelle builds in de werf te implementeren. Deze functies verschijnen binnenkort in dezelfde versie v1.1 en worden automatisch beschikbaar via het automatische updatemechanisme (voor gebruikers ).
In deze release is een taggingstrategie op basis van afbeeldingsinhoud toegevoegd - op inhoud gebaseerde tagging, wat de standaardstrategie is geworden. Het hoofdopdrachtlogboek is ook herwerkt: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
De volgende belangrijke stap is het toevoegen van gedistribueerde vergaderingen. Gedistribueerde builds hebben sinds v1.0 een hogere prioriteit gekregen dan parallelle builds omdat ze meer waarde toevoegen aan de werf: verticale schaling van bouwers en ondersteuning voor kortstondige bouwers in verschillende CI/CD-systemen, evenals de mogelijkheid om officiële ondersteuning te bieden voor GitHub-acties . Daarom werden de implementatiedeadlines voor parallelle assemblages verschoven. Wij doen er echter alles aan om beide mogelijkheden zo snel mogelijk te implementeren.
Volg het nieuws! En vergeet niet om ons te bezoeken op om een probleem aan te maken, een bestaand probleem te vinden en een plus toe te voegen, een PR te creëren of gewoon de ontwikkeling van het project te bekijken.
PS
Lees ook op onze blog:
- «»
- «";
- Een reeks notities over innovaties op de werf:
- «";
- «";
- «";
- «.
Bron: www.habr.com