{"id":76764,"date":"2020-04-04T13:42:24","date_gmt":"2020-04-04T11:42:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee"},"modified":"2020-04-04T13:42:24","modified_gmt":"2020-04-04T11:42:24","slug":"reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee","title":{"rendered":"Release van werf 1.1: verbeteringen in de builder vandaag en plannen voor de toekomst","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Release van werf 1.1: verbeteringen in de builder vandaag en plannen voor de toekomst\" src=\"\/wp-content\/uploads\/2020\/04\/c7c26e4a0b7bddb90ba087a4db7175dc.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/\">werf<\/a><\/noindex> \u2014 onze GitOps CLI-tool met open source voor het bouwen en leveren van applicaties in Kubernetes. Zoals beloofd, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/481306\/\">de release van versie v1.0<\/a><\/noindex> 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 <i>bouwer<\/i> werf. De nieuwe versie is momenteel beschikbaar in <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf#backward-compatibility-promise\">kanaal 1.1 ea<\/a><\/noindex>.<\/p>\n<p>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 \u00e9\u00e9n host.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>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\u00ebntere. Deze optimalisatie vermindert de gemiddelde bouwtijd van een project met behulp van werf. En lege builds, waarbij alle fasen in de cache bestaan, <i>stages-storage<\/i>, 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 <code>werf deploy<\/code> en <code>werf run<\/code>.<\/p>\n<p>Daarnaast is er in deze release een tagging-strategie voor afbeeldingen op basis van inhoud ge\u00efntroduceerd \u2014 <i>content-based tagging<\/i>, die nu standaard is ingeschakeld en de enige aanbevolen is.<\/p>\n<p>Laten we de belangrijkste nieuwigheden in werf v1.1 eens nader bekijken en ook onze plannen voor de toekomst bespreken.<\/p>\n<h2>Wat is er veranderd in werf v1.1?<\/h2>\n<p><\/p>\n<h3>Nieuw naamgevingsformaat voor fasen en algoritme voor het ophalen van fasen uit de cache<\/h3>\n<p>\nNieuwe 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.<\/p>\n<p>Bijvoorbeeld, de volledige naam van de fase-afbeelding kan er als volgt uitzien:<\/p>\n<p><code>werf-stages-storage\/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835<\/code><\/p>\n<p>\u2026of in het algemeen:<\/p>\n<p><code>werf-stages-storage\/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC<\/code><\/p>\n<p>Hier:<\/p>\n<ul>\n<li> <code>SIGNATURE<\/code> \u2014 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;<\/li>\n<li> <code>TIMESTAMP_MILLISEC<\/code> \u2014 dit is een gegarandeerd unieke identifier van de afbeelding, die wordt gegenereerd op het moment van het bouwen van de nieuwe afbeelding.<\/li>\n<\/ul>\n<p>\nHet algoritme voor het ophalen van fasen uit de cache is gebaseerd op het controleren van de verwantschap van Git-commits:<\/p>\n<ol>\n<li> Werf berekent de handtekening van een bepaalde fase.<\/li>\n<li> In <i>stages-storage<\/i> Er kunnen meerdere fasen zijn met dezelfde handtekening. Werf selecteert alle fasen die overeenkomen met de handtekening.<\/li>\n<li> Als de huidige fase verbonden is met Git (git-archive, aangepaste fase met Git-patches: <code>install<\/code>, <code>beforeSetup<\/code>, <code>setup<\/code>; 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).<\/li>\n<li> Van de resterende geschikte fasen wordt er \u00e9\u00e9n gekozen \u2014 de oudste op basis van de aanmaakdatum.<\/li>\n<\/ol>\n<p>\nFasen 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.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/reference\/stages_and_images.html#%D0%B8%D0%BC%D0%B5%D0%BD%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-%D1%81%D1%82%D0%B0%D0%B4%D0%B8%D0%B9\">\u2192 Documentatie<\/a><\/noindex>.<\/p>\n<h3>Nieuw algoritme voor het maken en opslaan van fasen in de fasenopslag<\/h3>\n<p>\nAls werf geen geschikte fase kan vinden tijdens het zoeken in de cache, wordt het proces voor het bouwen van een nieuwe fase ge\u00efnitieerd.<\/p>\n<p>Let op, dat meerdere processen (op \u00e9\u00e9n of meerdere hosts) tegelijkertijd kunnen beginnen met het bouwen van dezelfde fase. Werf gebruikt een algoritme voor optimistische locking <i>stages-storage<\/i> op het moment dat een vers gebouwd beeld wordt opgeslagen in <i>stages-storage<\/i>. Op deze manier, wanneer de bouw van een nieuwe fase gereed is, vergrendelt werf <i>stages-storage<\/i> en slaat daar het vers gebouwde beeld alleen op als er al geen geschikte afbeelding bestaat <i>(op basis van handtekening en andere parameters \u2014 zie het nieuwe algoritme voor het zoeken naar fasen in de cache)<\/i>.<\/p>\n<p>Het vers gebouwde beeld zal gegarandeerd een unieke identificatie hebben in <code>TIMESTAMP_MILLISEC<\/code> <i>(zie het nieuwe naamgevingsformaat voor fasen)<\/i>. In het geval dat er in <i>stages-storage<\/i> een geschikte afbeelding wordt gevonden, zal werf het vers gebouwde beeld afwijzen en de afbeelding uit de cache gebruiken.<\/p>\n<p>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.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/reference\/stages_and_images.html#%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0-%D0%B8-%D1%81%D0%BE%D1%85%D1%80%D0%B0%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5-%D1%81%D1%82%D0%B0%D0%B4%D0%B8%D0%B9\">\u2192 Documentatie<\/a><\/noindex>.<\/p>\n<h3>De prestaties van de Dockerfile-builder zijn verbeterd<\/h3>\n<p>\nMomenteel bestaat de fasepijplijn voor de afbeelding die wordt gebouwd uit Dockerfile uit \u00e9\u00e9n fase \u2014 <code>dockerfile<\/code>. Bij het berekenen van de handtekening wordt de checksum van bestanden in aanmerking genomen <code>context<\/code>, 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.<\/p>\n<p>De basis van het algoritme is <noindex><a rel=\"nofollow\" href=\"https:\/\/git-scm.com\/docs\/git-ls-tree\">git ls-tree<\/a><\/noindex>. Het algoritme houdt rekening met de vermeldingen in <code>.dockerignore<\/code> 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 <code>context<\/code> niet essentieel.<\/p>\n<p>Daarnaast controleert het algoritme ongetrackte bestanden en houdt het ze indien nodig mee in de checksum.<\/p>\n<h3>De prestaties bij het importeren van bestanden zijn verbeterd<\/h3>\n<p>\nIn versies van werf v1.1 wordt een rsync-server gebruikt bij <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/configuration\/stapel_image\/import_directive.html\">het importeren van bestanden uit artefacten en beelden<\/a><\/noindex>. Voorheen vond de import in twee stappen plaats met behulp van het mounten van een directory vanuit het hostsysteem.<\/p>\n<p>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.<\/p>\n<h3>Content-based tagging<\/h3>\n<p>\nWerf v1.1 ondersteunt zogenaamde tagging op basis van de inhoud van de afbeelding - <i>content-based tagging<\/i>. De tags van de resulterende Docker-afbeeldingen zijn afhankelijk van de inhoud van deze afbeeldingen.<\/p>\n<p>Bij het uitvoeren van het commando <code>werf publish --tags-by-stages-signature<\/code> of <code>werf ci-env --tagging-strategy=stages-signature<\/code> de te publiceren beelden zullen worden getagd met de zogenaamde <b>fase-signatuur<\/b> 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.<\/p>\n<p>De fase-signatuur van de afbeelding is afhankelijk van:<\/p>\n<ol>\n<li> de inhoud van deze afbeelding;<\/li>\n<li> de geschiedenis van de wijzigingen in Git die tot deze inhoud hebben geleid.<\/li>\n<\/ol>\n<p>\nIn 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\u00efmporteerd.<\/p>\n<p>Bij het gebruik van content-based tagging worden problemen met onnodige herstarts van applicatiepod's in Kubernetes opgelost, zelfs als de inhoud van de afbeelding niet is gewijzigd. Dit is overigens een van de redenen waarom het moeilijk is om meerdere microservices van \u00e9\u00e9n applicatie in een enkele Git-repository op te slaan.<\/p>\n<p>Daarnaast is content-based tagging een betrouwbaarder tagging-methode dan tagging op basis van Git-takken, omdat de inhoud van de resulterende afbeeldingen niet afhankelijk is van de volgorde van uitvoering van pipelines in het CI-systeem voor het bouwen van meerdere commits van dezelfde tak.<\/p>\n<p><b>Belangrijk<\/b>: vanaf dit moment <i>stages-signature<\/i> is <b>de enige aanbevolen taggingstrategie<\/b>. Deze zal standaard worden gebruikt in het team <code>werf ci-env<\/code> (tenzij expliciet een andere taggingstructuur wordt opgegeven).<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/reference\/publish_process.html#%D1%82%D0%B5%D0%B3%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-%D0%BE%D0%B1%D1%80%D0%B0%D0%B7%D0%BE%D0%B2-%D0%BF%D0%BE-%D1%81%D0%BE%D0%B4%D0%B5%D1%80%D0%B6%D0%B8%D0%BC%D0%BE%D0%BC%D1%83\">\u2192 Documentatie<\/a><\/noindex>. Aan deze functie zal ook een aparte publicatie worden gewijd. <b>BIJGEWERKT<\/b> (3 april): Artikel met details <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/495112\/\">gepubliceerd<\/a><\/noindex>.<\/p>\n<h3>Loggingniveaus<\/h3>\n<p>\nDe gebruiker heeft de mogelijkheid om de uitvoer te regelen, het logniveau in te stellen en met debug-informatie te werken. Toegevoegd zijn de opties <code>--log-quiet<\/code>, <code>--log-verbose<\/code>, <code>--log-debug<\/code>.<\/p>\n<p>Standaard bevat de uitvoer minimaal informatie:<\/p>\n<p><img decoding=\"async\" alt=\"Release van werf 1.1: verbeteringen in de builder vandaag en plannen voor de toekomst\" src=\"\/wp-content\/uploads\/2020\/04\/58e981b2e0c579ddde817eadc1732874.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nBij gebruik van gedetailleerde uitvoer (<code>--log-verbose<\/code>) kan men volgen hoe werf werkt:<\/p>\n<p><img decoding=\"async\" alt=\"Release van werf 1.1: verbeteringen in de builder vandaag en plannen voor de toekomst\" src=\"\/wp-content\/uploads\/2020\/04\/487ed5dfc5df0178f7c09f8da697ceff.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nGedetailleerde uitvoer (<code>--log-debug<\/code>), 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:<\/p>\n<p><img decoding=\"async\" alt=\"Release van werf 1.1: verbeteringen in de builder vandaag en plannen voor de toekomst\" src=\"\/wp-content\/uploads\/2020\/04\/99c1f3c2ab3803ff11fae1f2d5c9a5af.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Toekomstige plannen<\/h2>\n<p>\n<b>Let op!<\/b> De hieronder beschreven mogelijkheden met de aanduiding <b>v1.1<\/b> zijn al beschikbaar in deze versie, velen hiervan zullen binnenkort beschikbaar zijn. Updates zullen via automatische updates komen <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/guides\/installation.html#%D1%81%D0%BF%D0%BE%D1%81%D0%BE%D0%B1-1-%D1%80%D0%B5%D0%BA%D0%BE%D0%BC%D0%B5%D0%BD%D0%B4%D1%83%D0%B5%D0%BC%D1%8B%D0%B9-multiwerf\">bij gebruik van multiwerf<\/a><\/noindex>. Deze mogelijkheden be\u00efnvloeden de stabiele delen van de functies in v1.1 niet, hun komst vereist geen handmatige tussenkomst van de gebruiker in reeds bestaande configuraties.<\/p>\n<h3>Volledige ondersteuning voor verschillende implementaties van Docker Registry (NIEUW)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versie: v1.1<\/i><\/li>\n<li> <i>Termijnen: maart<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2199\">Probleem<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nDoel \u2014 de gebruiker moet een willekeurige implementatie kunnen gebruiken zonder beperkingen bij het gebruik van werf. <\/p>\n<p>Op dit moment onderscheiden we de volgende set oplossingen waarvoor we volledige ondersteuning zullen garanderen:<\/p>\n<ul>\n<li> Default (library\/registry)*,<\/li>\n<li> AWS ECR,<\/li>\n<li> Azure*,<\/li>\n<li> Docker Hub,<\/li>\n<li> GCR*,<\/li>\n<li> GitHub Packages,<\/li>\n<li> GitLab Registry*,<\/li>\n<li> Harbor*,<\/li>\n<li> Quay.<\/li>\n<\/ul>\n<p>\nMet een ster zijn oplossingen gemarkeerd die op dit moment al volledig door werf worden ondersteund. Voor de andere is er ondersteuning, maar met beperkingen.<\/p>\n<p>Er kunnen twee hoofdproblemen worden onderscheiden:<\/p>\n<ul>\n<li> Sommige oplossingen ondersteunen het verwijderen van tags via de Docker Registry API niet, waardoor gebruikers de automatische schoonmaak die in werf is ge\u00efmplementeerd, niet kunnen gebruiken. Dit geldt voor AWS ECR, Docker Hub en GitHub Packages.<\/li>\n<li> 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).<\/li>\n<\/ul>\n<p>\nDeze 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.<\/p>\n<h3>Gedecentraliseerde build van afbeeldingen (\u2191)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versie: v1.2 v1.1 (de prioriteit voor de implementatie van deze functie is verhoogd)<\/i><\/li>\n<li> <i>Tijdslijnen: maart-april maart<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/1614\">Probleem<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nMomenteel kunnen werf v1.0 en v1.1 alleen worden gebruikt op \u00e9\u00e9n vaste host voor de taken van het bouwen en publiceren van afbeeldingen en het deployen van applicaties in Kubernetes.<\/p>\n<p>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.<\/p>\n<p>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.<\/p>\n<p><b>Opmerking<\/b>. Deze mogelijkheid houdt geen rekening met het functioneren van de builder binnen Kubernetes-pod's, omdat het noodzakelijk is om de afhankelijkheid van de lokale Docker-server te elimineren (er is geen toegang tot de lokale Docker-server binnen de Kubernetes-pod, omdat het proces zelf in een container wordt uitgevoerd, en het werken met de Docker-server via het netwerk wordt niet ondersteund door werf en zal niet worden ondersteund). Ondersteuning voor het werken in Kubernetes zal afzonderlijk worden ge\u00efmplementeerd.<\/p>\n<h3>Offici\u00eble ondersteuning voor GitHub Actions (NIEUW)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versie: v1.1<\/i><\/li>\n<li> <i>Termijnen: maart<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2210\">Probleem<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nBevat documentatie voor werf (secties <i>referentie<\/i> en <i>gids<\/i>), evenals de offici\u00eble GitHub Action voor het werken met werf.<\/p>\n<p>Bovendien zal het werf mogelijk maken om te werken met ephemeral runners.<\/p>\n<p>De interactiemechanica van de gebruiker met het CI-systeem zal gebaseerd zijn op het instellen van labels op pull-requests om bepaalde acties voor de bouw\/uitrol van de applicatie te initi\u00ebren.<\/p>\n<h3>Lokale ontwikkeling en deployment van applicaties met werf (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versie: v1.1<\/i><\/li>\n<li> <i>Tijdslijnen: januari-februari april<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/1940\">Probleem<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nHet belangrijkste doel is om een uniforme configuratie te bereiken voor de deployment van applicaties zowel lokaal als in productie, zonder complexe handelingen, \u2018out of the box\u2019.<\/p>\n<p>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.<\/p>\n<h3>Nieuw schoonmaakalgoritme (NIEUW)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versie: v1.1<\/i><\/li>\n<li> <i>Termijnen: april<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2212\">Probleem<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nIn de huidige versie van werf v1.1 in de procedure <code>is het verwijderen van de instantie.<\/code> is er geen schoonmaak van afbeeldingen voor de inhoud-gebaseerde tagging \u2014 deze afbeeldingen zullen zich ophopen.<\/p>\n<p>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.<\/p>\n<p>Er is een nieuw uniform schoonmaakalgoritme voor alle tagging schema's bedacht op basis van de geschiedenis van commits in Git:<\/p>\n<ul>\n<li> Bewaar niet meer dan N1 afbeeldingen die zijn gerelateerd aan de N2 laatste commits voor elk van de git HEAD (takken en tags).<\/li>\n<li> Bewaar niet meer dan N1 stage-afbeeldingen die zijn gerelateerd aan de N2 laatste commits voor elk van de git HEAD (takken en tags).<\/li>\n<li> Alle afbeeldingen die in enige bronnen van het Kubernetes-cluster worden gebruikt, zullen worden opgeslagen (alle kube-contexten van het configuratiebestand en namespaces worden gescand; dit gedrag kan worden beperkt met speciale opties).<\/li>\n<li> Bewaar alle afbeeldingen die worden gebruikt in configuratie-manifesten van bronnen, opgeslagen in Helm-releases.<\/li>\n<li> 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.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Parallel assembleren van afbeeldingen (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versie: v1.1<\/i><\/li>\n<li> <i>Termijnen: januari-februari april*<\/i><\/li>\n<\/ul>\n<p>\nDe huidige versie van werf assembleert afbeeldingen en artefacten die beschreven zijn in <code>werf.yaml<\/code>, sequentieel. Het is nodig om het assembleren van onafhankelijke fasen van afbeeldingen en artefacten te paralleliseren, alsook zorgen voor een gemakkelijke en informatieve output.<\/p>\n<p><i>* 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.<\/i><\/p>\n<h3>Overstappen naar Helm 3 (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versie: v1.2<\/i><\/li>\n<li> <i>Termijnen: februari-maart mei*<\/i><\/li>\n<\/ul>\n<p>\nBevat de overstap naar een nieuwe codebasis <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/news\/t\/475722\/\">Helm 3<\/a><\/noindex> en een beproefde, gebruiksvriendelijke migratie methode voor bestaande installaties.<\/p>\n<p><i>* 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\u00efmplementeerd. Bovendien heeft werf <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/documentation\/reference\/deploy_process\/differences_with_helm.html\">aanvullende mogelijkheden<\/a><\/noindex> naast de genoemde. Deze overstap blijft echter op onze agenda en zal worden uitgevoerd.<\/i><\/p>\n<h3>Jsonnet voor het beschrijven van Kubernetes-configuratie (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versie: v1.2<\/i><\/li>\n<li> <i>Termijnen: januari-februari, april-mei<\/i><\/li>\n<\/ul>\n<p>\nWerf 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.<\/p>\n<p>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.<\/p>\n<p>Er wordt ook gekeken naar de mogelijkheid om andere systemen voor het beschrijven van Kubernetes-configuraties (bijvoorbeeld Kustomize) te implementeren.<\/p>\n<h3>Werken binnen Kubernetes (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versie: v1.2<\/i><\/li>\n<li> <i>Termijnen: april-mei, mei-juni<\/i><\/li>\n<\/ul>\n<p>\nDoel: 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.<\/p>\n<p>Om deze mogelijkheid te realiseren, is eerst de mogelijkheid van gedistribueerd bouwen van images nodig <i>(zie hierboven)<\/i>.<\/p>\n<p>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).<\/p>\n<p>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.<\/p>\n<h2>Een stap richting open ontwikkeling<\/h2>\n<p>\nWe houden van onze gemeenschap (<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">GitHub<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/t.me\/werf_ru\">Telegram<\/a><\/noindex>) en willen dat steeds meer mensen helpen om werf beter te maken, begrijpen in welke richting we gaan, en deelnemen aan de ontwikkeling.<\/p>\n<p>Onlangs werd besloten om over te schakelen naar <noindex><a rel=\"nofollow\" href=\"https:\/\/help.github.com\/en\/github\/managing-your-work-on-github\/about-project-boards\">GitHub-projectborden<\/a><\/noindex> om het werkproces van ons team te openen. Nu kan men de komende plannen bekijken, evenals het huidige werk op de volgende gebieden:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/9\">Documentatie en Site<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/7\">Testing<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/6\">Bugs en Slechte UX<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/5\">1.1<\/a><\/noindex>.<\/li>\n<\/ul>\n<p>\nEr is veel werk verzet met issues:<\/p>\n<ul>\n<li> Oude zijn verwijderd.<\/li>\n<li> Bestaande zijn gebracht in een uniform formaat, met voldoende details en precisie.<\/li>\n<li> Nieuwe issues met idee\u00ebn en voorstellen zijn toegevoegd.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Hoe versie v1.1 in te schakelen<\/h2>\n<p>\nDe versie is momenteel beschikbaar in <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf#backward-compatibility-promise\">kanaal 1.1 ea<\/a><\/noindex> (in de kanalen <i>stable<\/i> en <i>rock-solid<\/i> releases zullen verschijnen naarmate ze stabiliseren, maar <i>ea<\/i> is al op zichzelf vrij stabiel voor gebruik, aangezien het door de kanalen is gegaan. <i>alpha<\/i> en <i>beta<\/i>). Wordt geactiveerd <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/guides\/installation.html#%D1%81%D0%BF%D0%BE%D1%81%D0%BE%D0%B1-1-%D1%80%D0%B5%D0%BA%D0%BE%D0%BC%D0%B5%D0%BD%D0%B4%D1%83%D0%B5%D0%BC%D1%8B%D0%B9-multiwerf\">via multiwerf<\/a><\/noindex> volgende manier:<\/p>\n<pre><code class=\"bash\">source $(multiwerf use 1.1 ea)\nwerf COMMAND ...<\/code><\/pre>\n<p><\/p>\n<h2>Conclusie<\/h2>\n<p>\nNieuwe 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 <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/guides\/installation.html#%D1%81%D0%BF%D0%BE%D1%81%D0%BE%D0%B1-1-%D1%80%D0%B5%D0%BA%D0%BE%D0%BC%D0%B5%D0%BD%D0%B4%D1%83%D0%B5%D0%BC%D1%8B%D0%B9-multiwerf\">multiwerf<\/a><\/noindex>). <\/p>\n<p>In deze release is er een strategie voor tagging op basis van de inhoud van afbeeldingen toegevoegd \u2014 <i>content-based tagging<\/i>, \u2014 die de standaardstrategie is geworden. Ook is het logboek van de belangrijkste commando's herzien: <code>werf build<\/code>, <code>werf publish<\/code>, <code>werf deploy<\/code>, <code>werf dismiss<\/code>, <code>werf cleanup<\/code>.<\/p>\n<p>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\u00eble 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.<\/p>\n<p>Volg het nieuws! En vergeet niet om bij ons te kijken in <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">GitHub<\/a><\/noindex>, 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>\n<h2>P.S.<\/h2>\n<p>\nLees ook op onze blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/481306\/\">We presenteren werf 1.0 stable: wat heeft GitOps ermee te maken, status en plannen<\/a><\/noindex>\u00bb<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/460351\/\">werf \u2014 onze tool voor CI\/CD in Kubernetes (overzicht en video van de presentatie)<\/a><\/noindex>\u00bb;<\/li>\n<li> Een cyclus van notities over de innovaties in werf:\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/476646\/\">3-way merge in werf: deployen in Kubernetes met Helm \"op stero\u00efden\"<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/468049\/\">Het gebruik van werf voor het uitrollen van complexe Helm-charts<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465131\/\">Ondersteuning voor monorepo en multirepo in werf en wat Docker Registry hiermee te maken heeft<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/463613\/\">Docker-images kunnen nu ook met werf worden gebouwd met een gewone Dockerfile.<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>Bron: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/493170\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>werf \u2014 \u043d\u0430\u0448\u0430 GitOps CLI-\u0443\u0442\u0438\u043b\u0438\u0442\u0430 \u0441 \u043e\u0442\u043a\u0440\u044b\u0442\u044b\u043c \u043a\u043e\u0434\u043e\u043c \u0434\u043b\u044f \u0441\u0431\u043e\u0440\u043a\u0438 \u0438 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u0432 Kubernetes. \u041a\u0430\u043a \u0438 \u043e\u0431\u0435\u0449\u0430\u043b\u0438, \u0432\u044b\u0445\u043e\u0434 \u0432\u0435\u0440\u0441\u0438\u0438 v1.0 \u0437\u043d\u0430\u043c\u0435\u043d\u043e\u0432\u0430\u043b \u043d\u0430\u0447\u0430\u043b\u043e \u0434\u043e\u0431\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u0432 werf \u043d\u043e\u0432\u044b\u0445 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u0435\u0439 \u0438 \u043f\u0435\u0440\u0435\u0441\u043c\u043e\u0442\u0440\u0430 \u043f\u0440\u0438\u0432\u044b\u0447\u043d\u044b\u0445 \u043f\u043e\u0434\u0445\u043e\u0434\u043e\u0432. \u0422\u0435\u043f\u0435\u0440\u044c \u043c\u044b \u0440\u0430\u0434\u044b \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u0442\u044c \u0440\u0435\u043b\u0438\u0437 v1.1, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0431\u043e\u043b\u044c\u0448\u0438\u043c \u0448\u0430\u0433\u043e\u043c \u0432 \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u0438 \u0438 \u0437\u0430\u0434\u0435\u043b\u043e\u043c \u043d\u0430 \u0431\u0443\u0434\u0443\u0449\u0435\u0435 \u0441\u0431\u043e\u0440\u0449\u0438\u043a\u0430 werf. \u0412\u0435\u0440\u0441\u0438\u044f \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u0430 \u043d\u0430 \u0434\u0430\u043d\u043d\u044b\u0439 \u043c\u043e\u043c\u0435\u043d\u0442 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":76765,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-76764","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"nl_NL\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0420\u0435\u043b\u0438\u0437 werf 1.1: \u0443\u043b\u0443\u0447\u0448\u0435\u043d\u0438\u044f \u0432 \u0441\u0431\u043e\u0440\u0449\u0438\u043a\u0435 \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u0438 \u043f\u043b\u0430\u043d\u044b \u043d\u0430 \u0431\u0443\u0434\u0443\u0449\u0435\u0435 | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-04-04T11:42:24+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-04-04T11:42:24+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Release werf 1.1: verbeteringen in de bouwer vandaag en plannen voor de toekomst | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0420\u0435\u043b\u0438\u0437 werf 1.1: \u0443\u043b\u0443\u0447\u0448\u0435\u043d\u0438\u044f \u0432 \u0441\u0431\u043e\u0440\u0449\u0438\u043a\u0435 \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u0438 \u043f\u043b\u0430\u043d\u044b \u043d\u0430 \u0431\u0443\u0434\u0443\u0449\u0435\u0435 | ProHoster","og:url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-04-04T11:42:24+00:00","article:modified_time":"2020-04-04T11:42:24+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"76764","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 17:30:23","updated":"2022-09-28 14:39:02","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/76764","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=76764"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/76764\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/76765"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=76764"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=76764"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=76764"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}