{"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\/da\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee","title":{"rendered":"Werf 1.1 udgivelse: forbedringer i samlerens dag i dag og planer for fremtiden","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Werf 1.1 udgivelse: forbedringer i samlerens dag i dag og planer for fremtiden\" 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 vores open source GitOps CLI-v\u00e6rkt\u00f8j til opbygning og levering af applikationer i Kubernetes. Som lovet, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/481306\/\">udgivelsen af version v1.0<\/a><\/noindex> markerede begyndelsen p\u00e5 tilf\u00f8jelsen af nye funktioner til werf og en revision af de kendte tilgange. Nu er vi glade for at pr\u00e6sentere udgivelsen v1.1, som er et stort skridt fremad og en base for fremtiden. <i>bygger<\/i> werf. Versionen er i \u00f8jeblikket tilg\u00e6ngelig i <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf#backward-compatibility-promise\">kanal 1.1 ea<\/a><\/noindex>.<\/p>\n<p>Grundlaget for udgivelsen er en ny arkitektur til stadieopbevaring og optimering af arbejdet i begge byggere (for Stapel og Dockerfile). Den nye arkitektur for opbevaring \u00e5bner op for mulighederne for at realisere distribuerede bygninger fra flere v\u00e6rter og parallelle bygninger p\u00e5 \u00e9n v\u00e6rt.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Optimeringen af arbejdet inkluderer at eliminere un\u00f8dige beregninger p\u00e5 stadie-signaturberegningstrinnet og \u00e6ndre mekanismerne til beregning af filchecksums til mere effektive. Denne optimering reducerer den gennemsnitlige byggetid for projekter med werf. Og tomme bygninger, n\u00e5r alle stadier findes i cachen, <i>stages-storage<\/i>, er nu virkelig hurtige. I de fleste tilf\u00e6lde vil en genstart af bygningen tage mindre end 1 sekund! Dette g\u00e6lder ogs\u00e5 for verificeringsprocedurerne for stadier under arbejdet med holdene <code>werf deploy<\/code> og <code>werf run<\/code>.<\/p>\n<p>Denne udgave introducerer ogs\u00e5 en strategi for billedtagging baseret p\u00e5 indhold \u2014 <i>content-based tagging<\/i>, som nu er aktiveret som standard og er den eneste anbefalede.<\/p>\n<p>Lad os se n\u00e6rmere p\u00e5 de vigtigste nyheder i werf v1.1, og samtidig fort\u00e6lle om fremtidsplanerne.<\/p>\n<h2>Hvad er \u00e6ndret i werf v1.1?<\/h2>\n<p><\/p>\n<h3>Nyt navnformat for stadier og algoritme til valg af stadier fra cachen<\/h3>\n<p>\nNy regel for generering af et stadienavn. Nu genererer hver bygning af et stadie et unikt stadienavn, der best\u00e5r af 2 dele: signatur (som i v1.0) plus en unik tidsstempelidentifikator.<\/p>\n<p>For eksempel kan det fulde navn p\u00e5 stadiebilledet se s\u00e5ledes ud:<\/p>\n<p><code>werf-stages-storage\/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835<\/code><\/p>\n<p>\u2026 eller i generel form:<\/p>\n<p><code>werf-stages-storage\/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC<\/code><\/p>\n<p>Her:<\/p>\n<ul>\n<li> <code>SIGNATURE<\/code> \u2014 er signaturen for stadiet, som repr\u00e6senterer en identifikator for indholdet af stadiet og afh\u00e6nger af historikken af \u00e6ndringer i Git, der f\u00f8rte til dette indhold;<\/li>\n<li> <code>TIMESTAMP_MILLISEC<\/code> \u2014 er et garanteret unikt identifikator for billedet, der genereres p\u00e5 tidspunktet for bygningen af det nye billede.<\/li>\n<\/ul>\n<p>\nAlgoritmen til valg af stadier fra cachen er baseret p\u00e5 kontrol af sl\u00e6gtskab mellem Git-commits:<\/p>\n<ol>\n<li> Werf beregner signaturen for en given fase.<\/li>\n<li> I <i>stages-storage<\/i> Der kan eksistere flere faser for denne signatur. Werf v\u00e6lger alle passende faser efter signaturen.<\/li>\n<li> Hvis den aktuelle fase er relateret til Git (git-archive, brugerdefineret fase med Git-patches: <code>installation<\/code>, <code>beforeSetup<\/code>, <code>setup<\/code>; eller git-latest-patch), v\u00e6lger werf kun de faser, der er relateret til den commit, der er en forfader til den aktuelle commit (for hvilken bygningen er kaldt).<\/li>\n<li> Af de resterende passende faser v\u00e6lges en \u2014 den \u00e6ldste efter oprettelsesdato.<\/li>\n<\/ol>\n<p>\nFasen for forskellige Git-grene kan have den samme signatur. Men werf vil forhindre brugen af cache, der er relateret til forskellige grene, mellem disse grene, selvom signaturerne er identiske.<\/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 Dokumentation<\/a><\/noindex>.<\/p>\n<h3>Ny algoritme til oprettelse og gemming af faser i fase-lageret<\/h3>\n<p>\nHvis werf ikke finder en passende fase under cache-s\u00f8gningen, initieres processen med at opbygge en ny fase.<\/p>\n<p>Lad os bem\u00e6rke, at flere processer (p\u00e5 en eller flere v\u00e6rter) kan begynde at bygge den samme fase p\u00e5 omtrent samme tid. Werf bruger en optimistisk l\u00e5sningsalgoritme <i>stages-storage<\/i> p\u00e5 tidspunktet for gemning af det nyopbyggede billede i <i>stages-storage<\/i>. S\u00e5 n\u00e5r den nye fase er klar, l\u00e5ser werf <i>stages-storage<\/i> og gemmer det nyopbyggede billede der, kun hvis der ikke allerede findes et passende billede <i>(efter signatur og andre parametre \u2014 se den nye algoritme til cache-s\u00f8gning af faser)<\/i>.<\/p>\n<p>Det nyopbyggede billede vil garanteret have en unik identifikator efter <code>TIMESTAMP_MILLISEC<\/code> <i>(se det nye navngivningsformat for faser)<\/i>. I tilf\u00e6lde af at der findes et passende billede i <i>stages-storage<\/i> , vil werf forkaste det nyopbyggede billede og bruge billedet fra cachen.<\/p>\n<p>Med andre ord: den f\u00f8rste proces, der afslutter opbygningen af billedet (den hurtigste), f\u00e5r ret til at gemme det i stages-storage (og derefter vil dette ene billede blive brugt til alle opbygninger). Den langsomme opbygningsproces vil aldrig blokere den hurtigere proces fra at gemme resultaterne af den aktuelle fase og g\u00e5 videre til bygningen af den n\u00e6ste.<\/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 Dokumentation<\/a><\/noindex>.<\/p>\n<h3>Forbedret ydeevne for Dockerfile byggeren<\/h3>\n<p>\nI \u00f8jeblikket best\u00e5r pipeline-faserne for billedet, der bygges fra Dockerfile, af en enkelt fase \u2014 <code>dockerfile<\/code>. Ved beregning af signaturen tages der hensyn til checksummerne for filerne <code>context<\/code>, som vil blive brugt under opbygningen. F\u00f8r denne opgradering gennemgik werf rekursivt alle filer og beregnede en kontrolsum ved at opsummere konteksten og modulerne af hver fil. Fra versionerne v1.1 kan werf bruge de beregnede kontrolsummer, der er gemt i Git-repositoriet.<\/p>\n<p>I bunden af algoritmen ligger <noindex><a rel=\"nofollow\" href=\"https:\/\/git-scm.com\/docs\/git-ls-tree\">git ls-tree<\/a><\/noindex>. Algoritmen tager h\u00f8jde for posterne i <code>.dockerignore<\/code> og gennemg\u00e5r rekursivt filstrukturen kun n\u00e5r det er n\u00f8dvendigt. P\u00e5 den m\u00e5de er vi frigjort fra at l\u00e6se filsystemet, og algoritmens afh\u00e6ngighed af st\u00f8rrelsen p\u00e5 <code>context<\/code> er ikke betydelig.<\/p>\n<p>Algoritmen tjekker ogs\u00e5 untracked-filer og medtager dem i kontrolsummen, n\u00e5r det er n\u00f8dvendigt.<\/p>\n<h3>Ydelsen ved import af filer er forbedret<\/h3>\n<p>\nI versionerne af werf v1.1 anvendes en rsync-server ved <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/configuration\/stapel_image\/import_directive.html\">import af filer fra artefakter og billeder<\/a><\/noindex>. Tidligere blev importen udf\u00f8rt i to trin ved at montere et bibliotek fra v\u00e6rtsystemet.<\/p>\n<p>Ydelsen ved importer p\u00e5 macOS er ikke l\u00e6ngere begr\u00e6nset af Docker-volumener, og importer udf\u00f8res p\u00e5 samme tid som i Linux og Windows.<\/p>\n<h3>Indholdbaseret tagging<\/h3>\n<p>\nWerf v1.1 underst\u00f8tter den s\u00e5kaldte tagging baseret p\u00e5 indholdet af et billede \u2014 <i>content-based tagging<\/i>. Tagene til de resulterende Docker-billeder afh\u00e6nger af indholdet af disse billeder.<\/p>\n<p>N\u00e5r du k\u00f8rer kommandoen <code>werf publish --tags-by-stages-signature<\/code> eller <code>werf ci-env --tagging-strategy=stages-signature<\/code> vil tagges med den s\u00e5kaldte <b>stadiesignatur<\/b> af billedet. Hvert billede tagges med sin egen stadiesignatur, der beregnes efter de samme regler som den almindelige signatur for hver enkelt fase, men som er en generaliserende identifikator for billedet.<\/p>\n<p>Stadiesignaturen for billedet afh\u00e6nger af:<\/p>\n<ol>\n<li> indholdet af dette billede;<\/li>\n<li> historien om \u00e6ndringer i Git, der f\u00f8rte til dette indhold.<\/li>\n<\/ol>\n<p>\nI Git-repositoriet findes der altid tomme commits, som ikke \u00e6ndrer indholdet af billedfilerne. For eksempel commits med kun kommentarer eller merge-commits, eller commits, der \u00e6ndrer de filer i Git, som ikke vil blive importeret til billedet.<\/p>\n<p>Ved brug af content-based tagging l\u00f8ses problemerne med un\u00f8dvendige genstarter af applikationens pods i Kubernetes p\u00e5 grund af \u00e6ndringer i billednavnet, selvom indholdet af billedet ikke har \u00e6ndret sig. Dette er i \u00f8vrigt en af \u00e5rsagerne til, at det er vanskeligt at gemme mange mikrotjenester af \u00e9n applikation i et enkelt Git-repository.<\/p>\n<p>Desuden er content-based tagging en mere p\u00e5lidelig metode til tagging end tagging baseret p\u00e5 Git-grene, fordi indholdet af de resulterende billeder ikke afh\u00e6nger af r\u00e6kkef\u00f8lgen af pipeline-udf\u00f8relser i CI-systemet til at bygge flere commits af den samme gren.<\/p>\n<p><b>Det er vigtigt<\/b>fra dette \u00f8jeblik <i>stages-signature<\/i> \u2014 det er <b>den eneste anbefalede tagging-strategi<\/b>. Denne vil blive brugt som standard i teamet <code>werf ci-env<\/code> (medmindre en anden tagging-scheme angives tydeligt).<\/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 Dokumentation<\/a><\/noindex>. Denne funktion vil ogs\u00e5 blive d\u00e6kket i en separat publikation. <b>OPDATERET<\/b> (3. april): Artikel med detaljer <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/495112\/\">offentliggjort<\/a><\/noindex>.<\/p>\n<h3>Loggerniveauer<\/h3>\n<p>\nBrugeren har nu mulighed for at kontrollere output, angive loggerniveauet og arbejde med debugging-information. Mulighederne er tilf\u00f8jet <code>--log-quiet<\/code>, <code>--log-verbose<\/code>, <code>--log-debug<\/code>.<\/p>\n<p>Som standard indeholder output minimum information:<\/p>\n<p><img decoding=\"async\" alt=\"Werf 1.1 udgivelse: forbedringer i samlerens dag i dag og planer for fremtiden\" src=\"\/wp-content\/uploads\/2020\/04\/58e981b2e0c579ddde817eadc1732874.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVed brug af detaljeret output (<code>--log-verbose<\/code>) kan man f\u00f8lge, hvordan werf fungerer:<\/p>\n<p><img decoding=\"async\" alt=\"Werf 1.1 udgivelse: forbedringer i samlerens dag i dag og planer for fremtiden\" src=\"\/wp-content\/uploads\/2020\/04\/487ed5dfc5df0178f7c09f8da697ceff.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDet detaljerede output (<code>--log-debug<\/code>), ud over debugging-informationen fra werf, indeholder ogs\u00e5 logs fra de anvendte biblioteker. Man kan for eksempel se, hvordan interaktionen med Docker Registry foreg\u00e5r, samt registrere steder, hvor der bruges v\u00e6sentlig tid:<\/p>\n<p><img decoding=\"async\" alt=\"Werf 1.1 udgivelse: forbedringer i samlerens dag i dag og planer for fremtiden\" src=\"\/wp-content\/uploads\/2020\/04\/99c1f3c2ab3803ff11fae1f2d5c9a5af.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Fremtidige planer<\/h2>\n<p>\n<b>Opm\u00e6rksomhed!<\/b> De f\u00f8lgende funktioner markeret med <b>v1.1<\/b> vil v\u00e6re tilg\u00e6ngelige i denne version, mange af dem - snart. Opdateringer vil komme via autoopdateringer <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\">ved brug af multiwerf<\/a><\/noindex>. Disse funktioner ber\u00f8rer ikke den stabile del af funktionerne i v1.1, deres fremkomst kr\u00e6ver ingen manuel indgriben fra brugeren i eksisterende konfigurationer.<\/p>\n<h3>Fuld st\u00f8tte til forskellige implementeringer af Docker Registry (NYT)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version: v1.1<\/i><\/li>\n<li> <i>Tidsramme: marts<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2199\">Problem<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nM\u00e5let er, at brugeren skal kunne bruge enhver implementering uden begr\u00e6nsninger, n\u00e5r de bruger werf. <\/p>\n<p>I \u00f8jeblikket har vi identificeret f\u00f8lgende s\u00e6t l\u00f8sninger, som vi agter at sikre fuld st\u00f8tte til:<\/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>\nL\u00f8sninger markeret med en stjerne er i \u00f8jeblikket allerede fuldt underst\u00f8ttet af werf. For de \u00f8vrige er der st\u00f8tte, men med begr\u00e6nsninger.<\/p>\n<p>Der kan identificeres to hovedproblemer:<\/p>\n<ul>\n<li> Nogle l\u00f8sninger underst\u00f8tter ikke sletning af tags via Docker Registry API, hvilket ikke giver brugerne mulighed for at bruge den automatiske oprydning, der er implementeret i werf. Dette g\u00e6lder for AWS ECR, Docker Hub og GitHub Packages.<\/li>\n<li> Nogle l\u00f8sninger underst\u00f8tter ikke s\u00e5kaldte nested repositories (Docker Hub, GitHub Packages og Quay) eller underst\u00f8tter dem, men brugeren skal oprette dem manuelt ved hj\u00e6lp af UI eller API (AWS ECR).<\/li>\n<\/ul>\n<p>\nDisse og andre problemer planl\u00e6gger vi at l\u00f8se ved at bruge de native API'er fra l\u00f8sningerne. Denne opgave inkluderer ogs\u00e5 testd\u00e6kning af hele arbejdsflowet i werf for hver af dem.<\/p>\n<h3>Distribueret bygning af billeder (\u2191)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version: v1.2 v1.1 (prioriteten for implementeringen af denne funktion er blevet for\u00f8get)<\/i><\/li>\n<li> <i>Tidsrammer: marts-april marts<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/1614\">Problem<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nI \u00f8jeblikket kan werf v1.0 og v1.1 kun bruges p\u00e5 \u00e9n dedikeret v\u00e6rt til bygning og publicering af billeder og deployment af applikationer i Kubernetes.<\/p>\n<p>For at \u00e5bne mulighederne for distribueret arbejde med werf, hvor bygning og deployment af applikationer i Kubernetes k\u00f8rer p\u00e5 flere tilf\u00e6ldige v\u00e6rtssystemer, og disse v\u00e6rtssystemer ikke bevarer deres tilstand mellem bygninger (midlertidige runners), kr\u00e6ver werf implementering af muligheden for at bruge Docker Registry som lagringssted for faser.<\/p>\n<p>Tidligere, da projektet werf stadig hed dapp, var der denne funktion. Men vi st\u00f8dte p\u00e5 en r\u00e6kke problemer, der skal tages i betragtning ved implementeringen af denne funktion i werf.<\/p>\n<p><b>Bem\u00e6rk<\/b>. Denne funktion kr\u00e6ver ikke, at build-v\u00e6rkt\u00f8jet k\u00f8rer inde i Kubernetes-pods, da det ville v\u00e6re n\u00f8dvendigt at fjerne afh\u00e6ngigheden af den lokale Docker-server (der er ikke adgang til den lokale Docker-server i Kubernetes-poden, fordi selve processen k\u00f8rer i en container, og werf underst\u00f8tter ikke og vil ikke underst\u00f8tte interaktion med Docker-serveren over netv\u00e6rket). Underst\u00f8ttelse af drift i Kubernetes vil blive implementeret separat.<\/p>\n<h3>Officiel support for GitHub Actions (NY)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version: v1.1<\/i><\/li>\n<li> <i>Tidsramme: marts<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2210\">Problem<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nInkluderer dokumentationen for werf (afsnit <i>reference<\/i> og <i>guide<\/i>), samt den officielle GitHub Action til arbejde med werf.<\/p>\n<p>Desuden vil det muligg\u00f8re, at werf kan k\u00f8re p\u00e5 efem\u00e6re runner.<\/p>\n<p>Brugerens interaktion med CI-systemet vil v\u00e6re baseret p\u00e5 at s\u00e6tte labels p\u00e5 pull-requests for at igangs\u00e6tte bestemte handlinger vedr\u00f8rende bygning\/udrulning af applikationen.<\/p>\n<h3>Lokal udvikling og deployment af applikationer med werf (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version: v1.1<\/i><\/li>\n<li> <i>Tidsrammer: januar-februar april<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/1940\">Problem<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nHovedm\u00e5let er at opn\u00e5 en ensartet konfiguration til deployment af applikationer b\u00e5de lokalt og i produktion, uden komplicerede handlinger, \"out of the box\".<\/p>\n<p>werf kr\u00e6ver ogs\u00e5 en arbejdsmetode, hvor det er nemt at redigere applikationens kode og straks f\u00e5 feedback fra den k\u00f8rende applikation til debugging.<\/p>\n<h3>Ny oprydningsalgoritme (NY)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version: v1.1<\/i><\/li>\n<li> <i>Frister: april<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2212\">Problem<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nI den nuv\u00e6rende version af werf v1.1 i proceduren <code>cleanup<\/code> er der ikke inkluderet oprydning af billeder til indholdsbaseret tagging \u2014 disse billeder vil hobe sig op.<\/p>\n<p>I den nuv\u00e6rende version af werf (v1.0 og v1.1) anvendes forskellige oprydningspolitikker for billeder offentliggjort efter tagging-skemer: Git-gren, Git-tag eller Git-commit.<\/p>\n<p>En ny, ensartet oprydningsalgoritme for alle tagging-skemer er blevet udviklet baseret p\u00e5 commit-historikken i Git:<\/p>\n<ul>\n<li> Opbevar ikke mere end N1 billeder, der er relateret til de N2 seneste commits for hver git HEAD (gren og tags).<\/li>\n<li> Opbevar ikke mere end N1 billed-faser, der er relateret til de N2 seneste commits for hver git HEAD (gren og tags).<\/li>\n<li> Opbevar alle billeder, der bruges i nogen af clusterens Kubernetes-ressourcer (alle kube-kontekster i konfigurationsfilen og namespaces scannes; det er muligt at begr\u00e6nse denne adf\u00e6rd med specifikke muligheder).<\/li>\n<li> Opbevar alle billeder, der bruges i konfigurationsressource-manifester gemt i Helm-udgivelser.<\/li>\n<li> Et billede kan fjernes, hvis det ikke er relateret til nogen HEAD fra git (for eksempel fordi den p\u00e5g\u00e6ldende HEAD blev slettet) og ikke bruges i nogen af manifestterne i Kubernetes-klusteret og i Helm-udgivelser.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Parallel bygning af billeder (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version: v1.1<\/i><\/li>\n<li> <i>Frister: januar-februar april*<\/i><\/li>\n<\/ul>\n<p>\nDen nuv\u00e6rende version af werf bygger billeder og artefakter, som er beskrevet i <code>werf.yaml<\/code>, sekventielt. Det er n\u00f8dvendigt at parallelisere processen med at bygge uafh\u00e6ngige faser af billeder og artefakter samt sikre en praktisk og informativ output.<\/p>\n<p><i>* Bem\u00e6rk: Fristen er flyttet p\u00e5 grund af \u00f8get prioritet for implementeringen af distribueret byggeri, hvilket vil tilf\u00f8je flere muligheder for horisontal skalerbarhed samt brug af werf med GitHub Actions. Den parallelle bygning er n\u00e6ste trin i optimeringen, som giver vertikal skalerbarhed ved bygning af et enkelt projekt.<\/i><\/p>\n<h3>Overgang til Helm 3 (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version: v1.2<\/i><\/li>\n<li> <i>Frister: februar-marts maj*<\/i><\/li>\n<\/ul>\n<p>\nOmfatter overgangen til den nye kodebase <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/news\/t\/475722\/\">Helm 3<\/a><\/noindex> og en velafpr\u00f8vet, brugervenlig metode til migrering af eksisterende installationer.<\/p>\n<p><i>* Bem\u00e6rk: Overgangen til Helm 3 vil ikke tilf\u00f8re betydelige funktioner til werf, da alle n\u00f8glefunktioner i Helm 3 (3-way-merge og frav\u00e6ret af tiller) allerede er implementeret i werf. Desuden har werf <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/documentation\/reference\/deploy_process\/differences_with_helm.html\">yderligere muligheder<\/a><\/noindex> ud over dem, der er n\u00e6vnt. Denne overgang er dog stadig p\u00e5 vores liste og vil blive gennemf\u00f8rt.<\/i><\/p>\n<h3>Jsonnet til beskrivelse af Kubernetes-konfiguration (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version: v1.2<\/i><\/li>\n<li> <i>Tidsramme: januar-februar april-maj<\/i><\/li>\n<\/ul>\n<p>\nWerf vil underst\u00f8tte beskrivelsen af konfigurationer for Kubernetes i Jsonnet-format. Samtidig forbliver werf kompatibel med Helm, og der vil v\u00e6re mulighed for at v\u00e6lge beskrivelsesformat.<\/p>\n<p>\u00c5rsagen hertil er, at skabelonerne i Go-sproget, if\u00f8lge mange vurderinger, har en h\u00f8j indl\u00e6ringskurve, og l\u00e6sbarheden af koden i disse skabeloner er ogs\u00e5 p\u00e5virket.<\/p>\n<p>Der overvejes ogs\u00e5 muligheden for at implementere andre systemer til beskrivelse af Kubernetes-konfiguration (f.eks. Kustomize).<\/p>\n<h3>Arbejdet inden for Kubernetes (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version: v1.2<\/i><\/li>\n<li> <i>Tidsramme: april-maj maj-juni<\/i><\/li>\n<\/ul>\n<p>\nM\u00e5l: at muligg\u00f8re opbygning af billeder og levering af applikationen ved hj\u00e6lp af runners i Kubernetes. Det vil sige, at nye billeder kan bygges, publiceres, reng\u00f8res og deployeres direkte fra Kubernetes-pods.<\/p>\n<p>For at realisere denne mulighed er f\u00f8rst muligheden for distribueret opbygning af billeder n\u00f8dvendig <i>(se punkt ovenfor)<\/i>.<\/p>\n<p>Der kr\u00e6ves ogs\u00e5 underst\u00f8ttelse af en byggem\u00e5de uden Docker-server (dvs. Kaniko-lignende byggeri eller bygning i userspace).<\/p>\n<p>Werf vil underst\u00f8tte byggeri i Kubernetes ikke kun ved hj\u00e6lp af Dockerfile, men ogs\u00e5 ved hj\u00e6lp af sin egen opsamler Stapel med inkrementelle opbygninger og Ansible.<\/p>\n<h2>Et skridt mod \u00e5ben udvikling<\/h2>\n<p>\nVi elsker vores f\u00e6llesskab (<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>) og \u00f8nsker, at flere mennesker hj\u00e6lper med at g\u00f8re werf bedre, forst\u00e5r, hvilken retning vi bev\u00e6ger os i, og deltager i udviklingen.<\/p>\n<p>For nylig blev det besluttet at skifte til <noindex><a rel=\"nofollow\" href=\"https:\/\/help.github.com\/en\/github\/managing-your-work-on-github\/about-project-boards\">GitHub project boards<\/a><\/noindex> for at \u00e5bne op for vores teams arbejdsgange. Det er nu muligt at se de kommende planer samt det aktuelle arbejde inden for f\u00f8lgende omr\u00e5der:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/9\">Dokumentation og websted<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/7\">Testning<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/6\">Fejl og d\u00e5rlig 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>\nDer er gjort meget arbejde med issues:<\/p>\n<ul>\n<li> Uaktuelle er fjernet.<\/li>\n<li> Eksisterende er bragt til et ensartet format med tilstr\u00e6kkelig detaljer og beskrivelse.<\/li>\n<li> Nye issues med id\u00e9er og forslag er blevet tilf\u00f8jet.<\/li>\n<\/ul>\n<p><\/p>\n<h2>S\u00e5dan aktiveres version v1.1<\/h2>\n<p>\nVersionen er i \u00f8jeblikket tilg\u00e6ngelig i <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf#backward-compatibility-promise\">kanal 1.1 ea<\/a><\/noindex> (i kanalerne <i>stable<\/i> og <i>rock-solid<\/i> udgivelser vil komme, efterh\u00e5nden som de stabiliseres, men <i>ea<\/i> den er allerede stabil nok til brug, da den har passeret gennem kanalerne <i>alpha<\/i> og <i>beta<\/i>). Aktiveres <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> p\u00e5 f\u00f8lgende m\u00e5de:<\/p>\n<pre><code class=\"bash\">source $(multiwerf use 1.1 ea)\nwerf COMMAND ...<\/code><\/pre>\n<p><\/p>\n<h2>Konklusion<\/h2>\n<p>\nDen nye arkitektur til opbevaring af stadier og optimering af samlerens arbejde for Stapel og Dockerfile-aggregatorer \u00e5bner muligheder for at implementere distribuerede og parallelle builds i werf. Disse funktioner vil snart v\u00e6re tilg\u00e6ngelige i version 1.1 og bliver automatisk tilg\u00e6ngelige gennem autoopdateringsmekanismen (for brugere <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>I denne udgivelse er der tilf\u00f8jet en strategi for taggning efter billedindhold - <i>content-based tagging<\/i>, - som er blevet standardstrategi. Desuden er loggen over prim\u00e6re kommandoer blevet revideret: <code>werf build<\/code>, <code>werf publish<\/code>, <code>werf deploy<\/code>, <code>werf dismiss<\/code>, <code>werf cleanup<\/code>.<\/p>\n<p>N\u00e6ste v\u00e6sentlige skridt vil v\u00e6re tilf\u00f8jelsen af distribuerede builds. Distribuerede builds er siden version 1.0 blevet en h\u00f8jere prioritet end parallelle builds, da de tilf\u00f8jer mere v\u00e6rdi til werf: vertikal skalering af samlere og st\u00f8tte til ephemeral samlere i forskellige CI\/CD-systemer, samt muligheden for at implementere officiel st\u00f8tte til GitHub Actions. Derfor er tidsrammen for implementering af parallelle builds blevet flyttet. Men vi arbejder p\u00e5 at implementere begge muligheder hurtigst muligt.<\/p>\n<p>Hold dig opdateret! Og glem ikke at tjekke ind hos os p\u00e5 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">GitHub<\/a><\/noindex>, for at oprette en issue, finde en eksisterende og give den et plus, oprette en PR eller bare f\u00f8lge udviklingen af projektet.<\/p>\n<h2>P.S.<\/h2>\n<p>\nL\u00e6s ogs\u00e5 p\u00e5 vores blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/481306\/\">Vi pr\u00e6senterer werf 1.0 stable: hvad har GitOps, status og planer at g\u00f8re med det?<\/a><\/noindex>\u00bb<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/460351\/\">werf \u2014 vores v\u00e6rkt\u00f8j til CI\/CD i Kubernetes (oversigt og video af pr\u00e6sentationen)<\/a><\/noindex>\u00bb;<\/li>\n<li> Cykelnotater om nyheder i werf:\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/476646\/\">3-vejs sammensmeltning i werf: deployment til Kubernetes med Helm \"p\u00e5 steroider\"<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/468049\/\">Brug af werf til implementering af komplekse Helm-diagrammer<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465131\/\">Underst\u00f8ttelse af monorepo og multirepo i werf og hvad Docker Registry har at g\u00f8re med det<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/463613\/\">Byg Docker-billeder i werf kan nu ogs\u00e5 g\u00f8res med en almindelig Dockerfile<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>Kilde: <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\/da\/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=\"da_DK\" \/>\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\/da\/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\udd47Udgivelse af werf 1.1: forbedringer i samleren i dag og planer for fremtiden | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/da\/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":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/76764","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=76764"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/76764\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/76765"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=76764"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=76764"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=76764"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}