{"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\/it\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee","title":{"rendered":"Rilascio di werf 1.1: miglioramenti nel builder oggi e piani per il futuro","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Rilascio di werf 1.1: miglioramenti nel builder oggi e piani per il futuro\" 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 la nostra utility CLI GitOps open source per costruire e distribuire applicazioni in Kubernetes. Come promesso, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/481306\/\">il rilascio della versione v1.0<\/a><\/noindex> ha segnato l'inizio dell'aggiunta di nuove funzionalit\u00e0 in werf e della revisione dei metodi consolidati. Siamo ora lieti di presentare il rilascio della versione v1.1, che rappresenta un grande passo avanti e un trampolino per il futuro. <i>costruttore<\/i> werf. La versione \u00e8 attualmente disponibile nel <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf#backward-compatibility-promise\">canale 1.1 ea<\/a><\/noindex>.<\/p>\n<p>Il fulcro di questo rilascio \u00e8 una nuova architettura dello storage delle fasi e l'ottimizzazione del funzionamento di entrambi i costruttori (per Stapel e Dockerfile). La nuova architettura dello storage apre opportunit\u00e0 per implementare build distribuite da pi\u00f9 host e build parallele su un singolo host.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>L'ottimizzazione comporta l'eliminazione di calcoli superflui nella fase di calcolo delle firme delle fasi e la modifica dei meccanismi di calcolo delle somme di controllo dei file per renderli pi\u00f9 efficaci. Questa ottimizzazione riduce il tempo medio di build del progetto utilizzando werf. E le build vuote, quando tutte le fasi esistono nella cache <i>stages-storage<\/i>, ora sono realmente rapide. Nella maggior parte dei casi, il riavvio di una build avverr\u00e0 pi\u00f9 rapidamente di 1 secondo! Questo vale anche per le procedure di verifica delle fasi durante il lavoro dei team <code>werf deploy<\/code> e <code>werf run<\/code>.<\/p>\n<p>In questo rilascio \u00e8 stata anche introdotta una strategia di tagging delle immagini basata sul contenuto \u2014 <i>tagging basato sul contenuto<\/i>, che ora \u00e8 abilitata per impostazione predefinita e \u00e8 l'unica raccomandata.<\/p>\n<p>Esaminiamo in dettaglio le principali novit\u00e0 in werf v1.1 e parliamo anche dei piani futuri.<\/p>\n<h2>Cosa \u00e8 cambiato in werf v1.1?<\/h2>\n<p><\/p>\n<h3>Nuovo formato di denominazione delle fasi e algoritmo di selezione delle fasi dalla cache<\/h3>\n<p>\nUna nuova regola per la generazione del nome della fase. Ora ogni build della fase genera un nome unico che consiste di 2 parti: la firma (come in v1.0) pi\u00f9 un identificativo temporale unico.<\/p>\n<p>Ad esempio, il nome completo dell'immagine della fase pu\u00f2 apparire cos\u00ec:<\/p>\n<p><code>werf-stages-storage\/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835<\/code><\/p>\n<p>\u2026 o in forma generale:<\/p>\n<p><code>werf-stages-storage\/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC<\/code><\/p>\n<p>Qui:<\/p>\n<ul>\n<li> <code>SIGNATURE<\/code> \u2014 \u00e8 la firma della fase, che rappresenta l'identificativo del contenuto della fase e dipende dalla storia delle modifiche in Git che ha portato a quel contenuto;<\/li>\n<li> <code>TIMESTAMP_MILLISEC<\/code> \u2014 \u00e8 l'identificativo garantito unico dell'immagine, generato nel momento della build di una nuova immagine.<\/li>\n<\/ul>\n<p>\nL'algoritmo di selezione delle fasi dalla cache \u00e8 basato sul controllo della parentela dei commit Git:<\/p>\n<ol>\n<li> Werf calcola la firma di una certa fase.<\/li>\n<li> In <i>stages-storage<\/i> possono esistere pi\u00f9 fasi con questa firma. Werf seleziona tutte le fasi corrispondenti alla firma.<\/li>\n<li> Se la fase attuale \u00e8 collegata a Git (git-archive, fase personalizzata con patch Git: <code>installare<\/code>, <code>beforeSetup<\/code>, <code>setup<\/code>; o git-latest-patch), allora werf seleziona solo le fasi collegate al commit che \u00e8 un antenato del commit attuale (per cui \u00e8 stata richiesta la build).<\/li>\n<li> Delle rimanenti fasi corrispondenti, se ne seleziona una \u2014 la pi\u00f9 vecchia per data di creazione.<\/li>\n<\/ol>\n<p>\nUna fase per diversi rami Git pu\u00f2 avere la stessa firma. Ma werf impedir\u00e0 l'uso della cache collegata a rami diversi, anche se le firme coincidet.<\/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 Documentazione<\/a><\/noindex>.<\/p>\n<h3>Nuovo algoritmo di creazione e salvataggio delle fasi nello storage delle fasi<\/h3>\n<p>\nSe durante la selezione delle fasi dalla cache werf non trova una fase corrispondente, inizia il processo di costruzione di una nuova fase.<\/p>\n<p>Si noti che pi\u00f9 processi (su uno o pi\u00f9 host) possono iniziare a costruire la stessa fase circa nello stesso momento. Werf utilizza un algoritmo di blocco ottimistico <i>stages-storage<\/i> al momento del salvataggio della nuova immagine in <i>stages-storage<\/i>. Pertanto, quando la costruzione della nuova fase \u00e8 pronta, werf blocca <i>stages-storage<\/i> e salva l\u00ec l'immagine appena costruita solo se non esiste gi\u00e0 un'immagine corrispondente <i>(secondo la firma e altri parametri \u2014 vedi il nuovo algoritmo di selezione delle fasi dalla cache)<\/i>.<\/p>\n<p>L'immagine appena costruita avr\u00e0 sicuramente un identificatore unico secondo <code>TIMESTAMP_MILLISEC<\/code> <i>(vedi il nuovo formato di denominazione delle fasi)<\/i>. Nel caso in cui in <i>stages-storage<\/i> venga trovata un'immagine corrispondente, werf scarter\u00e0 l'immagine appena costruita e utilizzer\u00e0 l'immagine dalla cache.<\/p>\n<p>In altre parole: il primo processo che termina la costruzione dell'immagine (il pi\u00f9 veloce) ottiene il diritto di salvarlo in stages-storage (e poi solo quest'unica immagine sar\u00e0 utilizzata per tutte le build). Tuttavia, il processo di costruzione pi\u00f9 lento non bloccher\u00e0 mai il processo pi\u00f9 veloce dal salvare i risultati della build della fase attuale e dal passare alla costruzione della successiva.<\/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 Documentazione<\/a><\/noindex>.<\/p>\n<h3>Migliorata la performance del costruttore Dockerfile<\/h3>\n<p>\nAttualmente la pipeline di fasi per l'immagine costruita da un Dockerfile consiste in una sola fase \u2014 <code>dockerfile<\/code>. Nel calcolo della firma viene considerato il checksum dei file. <code>context<\/code>, che verranno utilizzati durante la compilazione. Prima di questo miglioramento, werf eseguiva una scansione ricorsiva di tutti i file e calcolava un checksum sommando il contesto e il modulo di ogni file. A partire dalla versione v1.1, werf pu\u00f2 utilizzare i checksum calcolati memorizzati nel repository Git.<\/p>\n<p>Alla base dell'algoritmo c'\u00e8 <noindex><a rel=\"nofollow\" href=\"https:\/\/git-scm.com\/docs\/git-ls-tree\">git ls-tree<\/a><\/noindex>. L'algoritmo considera le registrazioni in <code>.dockerignore<\/code> e attraversa ricorsivamente l'albero dei file solo se necessario. In questo modo, ci siamo distaccati dalla lettura del file system e la dipendenza dell'algoritmo dalla dimensione <code>context<\/code> non \u00e8 significativa.<\/p>\n<p>L'algoritmo verifica anche i file non tracciati e, se necessario, li include nel checksum.<\/p>\n<h3>Migliorata la performance durante l'importazione dei file<\/h3>\n<p>\nNelle versioni di werf v1.1 viene utilizzato un server rsync durante <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/configuration\/stapel_image\/import_directive.html\">l'importazione dei file da artefatti e immagini<\/a><\/noindex>. In precedenza, l'importazione avveniva in due passaggi utilizzando il montaggio della directory dal sistema host.<\/p>\n<p>Le performance degli import su macOS non sono pi\u00f9 limitate dai volumi Docker e gli import vengono eseguiti nello stesso tempo che su Linux e Windows.<\/p>\n<h3>Tagging basato sul contenuto<\/h3>\n<p>\nWerf v1.1 supporta quello che viene chiamato il tagging basato sul contenuto dell'immagine \u2014 <i>tagging basato sul contenuto<\/i>. I tag delle immagini Docker risultanti dipendono dal contenuto di queste immagini.<\/p>\n<p>Eseguendo il comando <code>werf publish --tags-by-stages-signature<\/code> o <code>werf ci-env --tagging-strategy=stages-signature<\/code> saranno taggate le immagini pubblicate con la cosiddetta <b>firma delle fasi<\/b> dell'immagine. Ogni immagine \u00e8 taggata con la propria firma specifica delle fasi di quell'immagine, calcolata secondo le stesse regole della firma regolare di ciascuna fase separatamente, ma \u00e8 un identificatore generale dell'immagine.<\/p>\n<p>La firma delle fasi dell'immagine dipende da:<\/p>\n<ol>\n<li> il contenuto di quest'immagine;<\/li>\n<li> la cronologia delle modifiche in Git che hanno portato a questo contenuto.<\/li>\n<\/ol>\n<p>\nNel repository Git ci sono sempre commit vuoti, che non modificano il contenuto dei file dell'immagine. Ad esempio, commit solo con commenti o merge commit, oppure commit che modificano file in Git che non verranno importati nell'immagine.<\/p>\n<p>Con l'uso del tagging basato sul contenuto si risolvono i problemi di riavvii non necessari dei pod dell'applicazione in Kubernetes a causa di modifiche nel nome dell'immagine, anche se il contenuto dell'immagine non \u00e8 cambiato. Questo \u00e8, tra l'altro, uno dei motivi che ostacolano la conservazione di molti microservizi di una stessa applicazione in un unico repository Git.<\/p>\n<p>Inoltre, il tagging basato sul contenuto \u00e8 un metodo di tagging pi\u00f9 affidabile rispetto al tagging basato sui branch Git, poich\u00e9 il contenuto delle immagini risultanti non dipende dall'ordine di esecuzione delle pipeline nel sistema CI per la compilazione di pi\u00f9 commit della stessa branch.<\/p>\n<p><b>Importante<\/b>: a partire da questo momento <i>stages-signature<\/i> \u2014 rappresenta <b>l'unica strategia di tagging consigliata<\/b>. Essa sar\u00e0 utilizzata per impostazione predefinita nel comando <code>werf ci-env<\/code> (se non viene specificato esplicitamente un altro schema di tagging).<\/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 Documentazione<\/a><\/noindex>. Questa funzionalit\u00e0 sar\u00e0 oggetto di una pubblicazione separata. <b>AGGIORNATO<\/b> (3 aprile): Articolo con dettagli <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/495112\/\">pubblicata<\/a><\/noindex>.<\/p>\n<h3>Livelli di logging<\/h3>\n<p>\nL'utente ha ora la possibilit\u00e0 di controllare l'output, impostare il livello di logging e lavorare con informazioni di debug. Sono state aggiunte opzioni <code>--log-quiet<\/code>, <code>--log-verbose<\/code>, <code>--log-debug<\/code>.<\/p>\n<p>Per impostazione predefinita, l'output contiene un'informazione minima:<\/p>\n<p><img decoding=\"async\" alt=\"Rilascio di werf 1.1: miglioramenti nel builder oggi e piani per il futuro\" src=\"\/wp-content\/uploads\/2020\/04\/58e981b2e0c579ddde817eadc1732874.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCon l'uso dell'output dettagliato (<code>--log-verbose<\/code>) \u00e8 possibile osservare come funziona werf:<\/p>\n<p><img decoding=\"async\" alt=\"Rilascio di werf 1.1: miglioramenti nel builder oggi e piani per il futuro\" src=\"\/wp-content\/uploads\/2020\/04\/487ed5dfc5df0178f7c09f8da697ceff.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nL'output dettagliato (<code>--log-debug<\/code>), oltre alle informazioni di debug di werf, contiene anche i log delle librerie utilizzate. Ad esempio, \u00e8 possibile vedere come avviene l'interazione con il Docker Registry e registrare i punti in cui viene speso un tempo significativo:<\/p>\n<p><img decoding=\"async\" alt=\"Rilascio di werf 1.1: miglioramenti nel builder oggi e piani per il futuro\" src=\"\/wp-content\/uploads\/2020\/04\/99c1f3c2ab3803ff11fae1f2d5c9a5af.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Piani futuri<\/h2>\n<p>\n<b>Attenzione!<\/b> Le funzionalit\u00e0 descritte di seguito contrassegnate come <b>v1.1<\/b> saranno disponibili gi\u00e0 in questa versione, molte di esse \u2014 a breve. Gli aggiornamenti arriveranno tramite aggiornamenti automatici <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\">utilizzando multiwerf<\/a><\/noindex>. Queste funzionalit\u00e0 non influenzano la parte stabile delle funzioni v1.1; il loro arrivo non richieder\u00e0 interventi manuali da parte dell'utente nelle configurazioni esistenti.<\/p>\n<h3>Supporto completo per varie implementazioni del Docker Registry (NUOVO)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versione: v1.1<\/i><\/li>\n<li> <i>Tempi: marzo<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2199\">Issue<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nObiettivo: l'utente deve poter utilizzare qualsiasi implementazione senza restrizioni con werf. <\/p>\n<p>Attualmente abbiamo identificato il seguente insieme di soluzioni per cui intendiamo garantire il completo supporto:<\/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>\nCon l'asterisco sono indicate le soluzioni gi\u00e0 completamente supportate da werf. Per le altre c'\u00e8 supporto, ma con limitazioni.<\/p>\n<p>Si possono evidenziare due problemi principali:<\/p>\n<ul>\n<li> Alcune soluzioni non supportano l'eliminazione dei tag tramite l'API del Docker Registry, il che non consente agli utenti di utilizzare la pulizia automatica implementata in werf. Questo \u00e8 vero per AWS ECR, Docker Hub e GitHub Packages.<\/li>\n<li> Alcuni delle soluzioni non supportano i cosiddetti repository annidati (Docker Hub, GitHub Packages e Quay) oppure li supportano, ma l'utente deve crearli manualmente utilizzando l'interfaccia utente o l'API (AWS ECR).<\/li>\n<\/ul>\n<p>\nCi proponiamo di affrontare questi e altri problemi utilizzando le API native delle soluzioni. Questo compito include anche la copertura con test dell'intero ciclo di lavoro di werf per ognuna di esse.<\/p>\n<h3>Build distribuita delle immagini (\u2191)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versione: v1.2 v1.1 (la priorit\u00e0 per l'implementazione di questa funzionalit\u00e0 \u00e8 stata aumentata)<\/i><\/li>\n<li> <i>Scadenze: marzo-aprile marzo<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/1614\">Issue<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nAttualmente, werf v1.0 e v1.1 possono essere utilizzati solo su un singolo host dedicato per le operazioni di build e pubblicazione delle immagini e per il deploy delle applicazioni in Kubernetes.<\/p>\n<p>Per aprire le potenzialit\u00e0 del lavoro distribuito di werf, quando la build e il deploy delle applicazioni in Kubernetes vengono avviati su pi\u00f9 host arbitrari e questi host non mantengono il loro stato tra le build (runner temporanei), werf \u00e8 richiesto di implementare la possibilit\u00e0 di utilizzare il Docker Registry come storage delle fasi.<\/p>\n<p>In passato, quando il progetto werf era ancora chiamato dapp, questa possibilit\u00e0 era presente. Tuttavia, abbiamo affrontato una serie di problemi che devono essere considerati nell'implementazione di questa funzione in werf.<\/p>\n<p><b>Nota<\/b>. Questa funzionalit\u00e0 non prevede il funzionamento del builder all'interno dei pod di Kubernetes, poich\u00e9 per questo sarebbe necessario eliminare la dipendenza dal server Docker locale (nel pod di Kubernetes non \u00e8 possibile accedere al server Docker locale, perch\u00e9 il processo stesso \u00e8 eseguito in un contenitore e werf non supporta e non supporter\u00e0 l'interazione con il server Docker tramite la rete). Il supporto per il funzionamento in Kubernetes sar\u00e0 implementato separatamente.<\/p>\n<h3>Supporto ufficiale per GitHub Actions (NUOVO)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versione: v1.1<\/i><\/li>\n<li> <i>Tempi: marzo<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2210\">Issue<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nInclude la documentazione di werf (sezioni <i>reference<\/i> e <i>guida<\/i>), e anche l'Action ufficiale di GitHub per lavorare con werf.<\/p>\n<p>Inoltre, consentir\u00e0 a werf di funzionare su runner effimeri.<\/p>\n<p>La meccanica di interazione dell'utente con il sistema CI si baser\u00e0 sull'assegnazione di etichette alle pull request per avviare determinate azioni di build\/deploy dell'applicazione.<\/p>\n<h3>Sviluppo locale e deploy delle applicazioni con werf (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versione: v1.1<\/i><\/li>\n<li> <i>Scadenze: gennaio-febbraio aprile<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/1940\">Issue<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nL'obiettivo principale \u00e8 ottenere una configurazione unificata per il deploy delle applicazioni sia localmente che in produzione, senza complicati passaggi, 'pronto all'uso'.<\/p>\n<p>Da werf \u00e8 richiesto anche un modo di lavoro in cui sia comodo modificare il codice dell'applicazione e ricevere istantaneamente feedback dall'applicazione funzionante per il debugging.<\/p>\n<h3>Nuovo algoritmo di pulizia (NUOVO)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versione: v1.1<\/i><\/li>\n<li> <i>Scadenze: aprile<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2212\">Issue<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nNella versione attuale di werf v1.1 non \u00e8 prevista la pulizia delle immagini per lo schema di tagging basato sul contenuto (content-based tagging) \u2014 queste immagini si accumuleranno. <code>cleanup<\/code> Inoltre, nella versione attuale di werf (v1.0 e v1.1) vengono utilizzate politiche di pulizia diverse per le immagini pubblicate secondo gli schemi di tagging: ramo Git, tag Git o commit Git.<\/p>\n<p>\u00c8 stato creato un nuovo algoritmo unificato per tutti gli schemi di tagging per la pulizia delle immagini basato sulla storia dei commit in Git:<\/p>\n<p>Conservare non pi\u00f9 di N1 immagini associate agli ultimi N2 commit per ciascun git HEAD (rami e tag).<\/p>\n<ul>\n<li> Conservare non pi\u00f9 di N1 immagini di fase, associate agli ultimi N2 commit per ciascun git HEAD (rami e tag).<\/li>\n<li> Conservare non pi\u00f9 di N1 immagini-stadio associate agli ultimi N2 commit per ogni git HEAD (branche e tag).<\/li>\n<li> Conservare tutte le immagini che vengono utilizzate in risorse del cluster Kubernetes (vengono esaminati tutti i kube-context del file di configurazione e namespace; \u00e8 possibile limitare questo comportamento con opzioni specifiche).<\/li>\n<li> Conservare tutte le immagini utilizzate nei manifesti di configurazione delle risorse memorizzati nei rilasci Helm.<\/li>\n<li> Un'immagine pu\u00f2 essere rimossa se non \u00e8 collegata a nessun HEAD di git (ad esempio, perch\u00e9 l'HEAD corrispondente \u00e8 stato eliminato) e non \u00e8 utilizzata in nessuno dei manifesti nel cluster Kubernetes e nei rilasci Helm.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Build parallele delle immagini (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versione: v1.1<\/i><\/li>\n<li> <i>Scadenze: gennaio-febbraio aprile*<\/i><\/li>\n<\/ul>\n<p>\nL'attuale versione di werf costruisce le immagini e gli artefatti descritti in <code>werf.yaml<\/code>, in modo sequenziale. \u00c8 necessario parallelizzare il processo di build delle fasi e degli artefatti indipendenti, nonch\u00e9 garantire un output conveniente e informativo.<\/p>\n<p><i>* Nota: la scadenza \u00e8 stata spostata a causa dell'aumento della priorit\u00e0 per l'implementazione della build distribuita, che aggiunger\u00e0 ulteriori potenzialit\u00e0 per la scalabilit\u00e0 orizzontale, oltre all'uso di werf con GitHub Actions. La build parallela \u00e8 il passaggio successivo per l'ottimizzazione, che offre scalabilit\u00e0 verticale durante la build di un singolo progetto.<\/i><\/p>\n<h3>Transizione a Helm 3 (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versione: v1.2<\/i><\/li>\n<li> <i>Scadenze: febbraio-marzo maggio*<\/i><\/li>\n<\/ul>\n<p>\nInclude la transizione alla nuova base di codice <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/news\/t\/475722\/\">Helm 3<\/a><\/noindex> e un metodo verificato e conveniente per migrare installazioni esistenti.<\/p>\n<p><i>* Nota: la transizione a Helm 3 non aggiunger\u00e0 funzionalit\u00e0 significative a werf, poich\u00e9 tutte le principali funzionalit\u00e0 di Helm 3 (3-way-merge e assenza di tiller) sono gi\u00e0 state implementate in werf. Inoltre, werf ha <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/documentation\/reference\/deploy_process\/differences_with_helm.html\">funzionalit\u00e0 aggiuntive<\/a><\/noindex> oltre a quelle indicate. Tuttavia, questo passaggio rimane nei nostri piani e sar\u00e0 realizzato.<\/i><\/p>\n<h3>Jsonnet per la descrizione della configurazione Kubernetes (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versione: v1.2<\/i><\/li>\n<li> <i>Tempistiche: gennaio-febbraio aprile-maggio<\/i><\/li>\n<\/ul>\n<p>\nWerf supporter\u00e0 la descrizione della configurazione per Kubernetes in formato Jsonnet. Inoltre, werf rimarr\u00e0 compatibile con Helm e sar\u00e0 possibile scegliere il formato di descrizione.<\/p>\n<p>Questo \u00e8 dovuto al fatto che i modelli del linguaggio Go, secondo molti, hanno una soglia di accesso alta e la comprensibilit\u00e0 del codice di questi modelli ne risente.<\/p>\n<p>\u00c8 anche in fase di valutazione la possibilit\u00e0 di integrare altri sistemi di descrizione della configurazione Kubernetes (ad esempio, Kustomize).<\/p>\n<h3>Lavoro all'interno di Kubernetes (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versione: v1.2<\/i><\/li>\n<li> <i>Tempistiche: aprile-maggio maggio-giugno<\/i><\/li>\n<\/ul>\n<p>\nObiettivo: garantire la costruzione delle immagini e la distribuzione dell'applicazione utilizzando runner in Kubernetes. Cio\u00e8, la costruzione di nuove immagini, la loro pubblicazione, la pulizia e il deploy possono avvenire direttamente dai pod di Kubernetes.<\/p>\n<p>Per implementare questa possibilit\u00e0, \u00e8 prima necessaria la capacit\u00e0 di costruzione distribuita delle immagini <i>(vedi il punto precedente)<\/i>.<\/p>\n<p>\u00c8 anche necessaria la supporto per il funzionamento del builder senza server Docker (cio\u00e8, costruzione simile a Kaniko o costruzione in userspace).<\/p>\n<p>Werf supporter\u00e0 la costruzione in Kubernetes non solo tramite Dockerfile, ma anche con il proprio builder Stapel con ricostruzioni incrementali e Ansible.<\/p>\n<h2>Un passo verso lo sviluppo aperto<\/h2>\n<p>\nAmiamo la nostra comunit\u00e0 (<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>) e vogliamo che sempre pi\u00f9 persone ci aiutino a migliorare werf, comprendano in che direzione stiamo andando e partecipino allo sviluppo.<\/p>\n<p>\u00c8 stato deciso di passare a <noindex><a rel=\"nofollow\" href=\"https:\/\/help.github.com\/en\/github\/managing-your-work-on-github\/about-project-boards\">GitHub project boards<\/a><\/noindex> per aprire il processo di lavoro del nostro team. Ora \u00e8 possibile visualizzare i piani a breve termine, cos\u00ec come i lavori attuali nelle seguenti aree:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/9\">Documentazione e Sito<\/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\">Bug e UX scadente<\/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>\n\u00c8 stato fatto un grande lavoro con le issue:<\/p>\n<ul>\n<li> Sono state rimosse quelle obsolete.<\/li>\n<li> Le esistenti sono state uniformate a un formato comune con un numero sufficiente di dettagli e informazioni.<\/li>\n<li> Sono state aggiunte nuove issue con idee e proposte.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Come attivare la versione v1.1<\/h2>\n<p>\nLa versione \u00e8 attualmente disponibile in <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf#backward-compatibility-promise\">canale 1.1 ea<\/a><\/noindex> (nei canali <i>stable<\/i> e <i>rock-solid<\/i> le versioni appariranno man mano che si stabilizzano, tuttavia <i>ea<\/i> \u00e8 gi\u00e0 sufficientemente stabile per essere utilizzata, poich\u00e9 ha attraversato i canali <i>alpha<\/i> e <i>beta<\/i>). Si attiva <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\">attraverso multiwerf<\/a><\/noindex> nel seguente modo:<\/p>\n<pre><code class=\"bash\">source $(multiwerf use 1.1 ea)\nwerf COMMAND ...<\/code><\/pre>\n<p><\/p>\n<h2>Conclusione<\/h2>\n<p>\nLa nuova architettura dello storage delle fasi e l'ottimizzazione del funzionamento del builder per Stapel e Dockerfile aprono opportunit\u00e0 per implementare costruzioni distribuite e parallele in werf. Queste funzioni appariranno presto nello stesso rilascio v1.1 e saranno automaticamente disponibili tramite il meccanismo di aggiornamento automatico (per gli utenti <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 questo rilascio \u00e8 stata aggiunta una strategia di tagging basata sul contenuto delle immagini \u2014 <i>tagging basato sul contenuto<\/i>, \u2014 che \u00e8 diventata la strategia predefinita. \u00c8 stata inoltre rielaborata la log delle principali comandi: <code>werf build<\/code>, <code>werf publish<\/code>, <code>werf deploy<\/code>, <code>werf dismiss<\/code>, <code>werf cleanup<\/code>.<\/p>\n<p>Il prossimo passo significativo sar\u00e0 l'aggiunta delle costruzioni distribuite. Le costruzioni distribuite dalla versione v1.0 sono diventate un compito pi\u00f9 prioritario rispetto alle costruzioni parallele, poich\u00e9 aggiungono maggior valore a werf: scalabilit\u00e0 verticale dei builders e supporto per builders efimeri in vari sistemi CI\/CD, oltre alla possibilit\u00e0 di fornire supporto ufficiale a GitHub Actions. Pertanto, le tempistiche per l'implementazione delle costruzioni parallele sono state spostate. Tuttavia, stiamo lavorando per implementare entrambe le funzionalit\u00e0 il prima possibile.<\/p>\n<p>Segui gli aggiornamenti! E non dimenticare di visitare il nostro <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">GitHub<\/a><\/noindex>, per creare una issue, trovarne gi\u00e0 esistente e votare, creare una PR o semplicemente osservare lo sviluppo del progetto.<\/p>\n<h2>P.S.<\/h2>\n<p>\nLeggete anche nel nostro blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/481306\/\">Presentiamo werf 1.0 stable: quale \u00e8 il legame con GitOps, lo stato e i piani futuri<\/a><\/noindex>\u00bb<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/460351\/\">werf \u2014 il nostro strumento per CI\/CD in Kubernetes (panoramica e video della presentazione)<\/a><\/noindex>\u00bb;<\/li>\n<li> Ciclo di note sulle novit\u00e0 in werf:\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/476646\/\">Merge a 3 vie in werf: deploy in Kubernetes con Helm \"potenziato\"<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/468049\/\">Utilizzo di werf per il rilascio di complessi Helm charts<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465131\/\">Supporto monorepo e multirepo in werf e qual \u00e8 il legame con Docker Registry<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/463613\/\">Ora \u00e8 possibile costruire immagini Docker in werf anche tramite un normale Dockerfile<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>Fonte: <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.0.1 - 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\/it\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.0.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\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\/it\/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\udd47Rilascio di werf 1.1: miglioramenti nel builder oggi e piani per il futuro | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/it\/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":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/76764","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=76764"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/76764\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/76765"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=76764"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=76764"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=76764"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}