{"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 costruttore 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 costruttore 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 CLI GitOps open source per la costruzione e distribuzione di 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 a werf e della revisione degli approcci consolidati. Siamo ora lieti di presentare il rilascio v1.1, che rappresenta un grande passo avanti nello sviluppo e una base per il futuro <i>del costruttore<\/i> werf. Al momento, la versione \u00e8 disponibile su <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf#backward-compatibility-promise\">canale 1.1 ea<\/a><\/noindex>.<\/p>\n<p>Il fulcro del rilascio \u00e8 una nuova architettura di archiviazione delle fasi e l'ottimizzazione del lavoro di entrambi i costruttori (per Stapel e Dockerfile). La nuova architettura di archiviazione apre opportunit\u00e0 per implementare costruzioni distribuite da pi\u00f9 host e costruzioni parallele su un solo host.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>L'ottimizzazione del lavoro include l'eliminazione di calcoli non necessari nella fase di calcolo delle firme e la modifica dei meccanismi di calcolo delle somme di controllo dei file in modi pi\u00f9 efficienti. Questa ottimizzazione riduce il tempo medio delle costruzioni di progetto tramite werf. E le costruzioni a vuoto, quando tutte le fasi esistono nella cache <i>stages-storage<\/i>, ora sono davvero veloci. Nella maggior parte dei casi, il riavvio della costruzione sar\u00e0 pi\u00f9 veloce di 1 secondo! Questo vale anche per le procedure di verifica delle fasi durante l'attivit\u00e0 delle squadre <code>werf deploy<\/code> e <code>werf run<\/code>.<\/p>\n<p>Inoltre, in questo rilascio \u00e8 stata introdotta una strategia di tagging delle immagini basata sul contenuto \u2014 <i>tagging basato sul contenuto<\/i>, che ora \u00e8 abilitata per impostazione predefinita ed \u00e8 l'unica raccomandata.<\/p>\n<p>Esaminiamo pi\u00f9 da vicino le principali novit\u00e0 in werf v1.1 e parleremo anche dei piani per il futuro.<\/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 delle fasi. Ora ogni costruzione di fase genera un nome unico, composto da 2 parti: firma (come era in v1.0) pi\u00f9 un identificatore temporale unico.<\/p>\n<p>Ad esempio, il nome completo dell'immagine della fase potrebbe essere:<\/p>\n<p><code>werf-stages-storage\/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835<\/code><\/p>\n<p>\u2026 oppure 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'identificatore del contenuto della fase e dipende dalla cronologia delle modifiche in Git che hanno portato a quel contenuto;<\/li>\n<li> <code>TIMESTAMP_MILLISEC<\/code> \u2014 \u00e8 un identificatore dell'immagine garantito unico, generato al momento della costruzione di una nuova immagine.<\/li>\n<\/ul>\n<p>\nL'algoritmo di selezione delle fasi dalla cache si basa 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 la stessa firma. Werf seleziona tutte le fasi idonee in base alla firma.<\/li>\n<li> Se la fase attuale \u00e8 associata a Git (git-archive, fase personalizzata con patch Git: <code>install<\/code>, <code>beforeSetup<\/code>, <code>setup<\/code>; o git-latest-patch), werf seleziona solo le fasi associate a un commit che \u00e8 un antenato del commit corrente (per il quale \u00e8 stata avviata la raccolta).<\/li>\n<li> Tra le fasi idonee rimanenti, viene selezionata una \u2014 la pi\u00f9 vecchia in base alla data di creazione.<\/li>\n<\/ol>\n<p>\nLe fasi per ramificazioni Git diverse possono avere la stessa firma. Ma werf impedir\u00e0 l'uso della cache associata a diverse ramificazioni tra queste ramificazioni, anche se le firme coincidono.<\/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 per la creazione e il salvataggio delle fasi nel deposito delle fasi<\/h3>\n<p>\nSe durante la selezione delle fasi dalla cache werf non trova una fase adatta, viene avviato 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 pi\u00f9 o meno allo stesso tempo. Werf utilizza un algoritmo di blocco ottimista <i>stages-storage<\/i> al momento del salvataggio di un'immagine appena creata in <i>stages-storage<\/i>. Pertanto, quando la costruzione di una nuova fase \u00e8 pronta, werf blocca <i>stages-storage<\/i> e salva l'immagine appena creata solo se non esiste gi\u00e0 un'immagine adatta <i>(in base alla firma e altri parametri \u2014 si veda il nuovo algoritmo di selezione delle fasi dalla cache)<\/i>.<\/p>\n<p>L'immagine appena creata avr\u00e0 sicuramente un identificatore unico in base a <code>TIMESTAMP_MILLISEC<\/code> <i>(si veda il nuovo formato di denominazione delle fasi)<\/i>. Nel caso in cui venga trovata un'immagine adatta in <i>stages-storage<\/i> , werf scarter\u00e0 l'immagine appena creata e utilizzer\u00e0 l'immagine dalla cache.<\/p>\n<p>In altre parole: il primo processo che termina di costruire l'immagine (quello pi\u00f9 veloce) avr\u00e0 il diritto di salvarla nello storage delle fasi (e quindi questa unica immagine sar\u00e0 utilizzata per tutte le costruzioni). Tuttavia, il processo di costruzione pi\u00f9 lento non bloccher\u00e0 mai il processo pi\u00f9 veloce dal salvare i risultati della costruzione della fase corrente e 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, il processo delle fasi per l'immagine costruita da un Dockerfile consiste in una fase \u2014 <code>dockerfile<\/code>. Nella calcolo della firma viene considerato il checksum dei file <code>context<\/code>, che verranno utilizzati durante l'assemblaggio. Fino a questo miglioramento, werf eseguiva un passaggio ricorsivo su tutti i file e calcolava la somma di controllo, sommando il contesto e il modulo di ogni file. A partire dalle versioni v1.1, werf pu\u00f2 utilizzare le somme di controllo calcolate archiviate 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 tiene conto delle voci in <code>.dockerignore<\/code> e attraversa ricorsivamente l'albero dei file solo se necessario. In questo modo, ci siamo liberati 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 li include nella somma di controllo se necessario.<\/p>\n<h3>\u00c8 stata 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 veniva eseguita in due passaggi utilizzando il montaggio della directory dal sistema host.<\/p>\n<p>Le performance delle importazioni su macOS non sono pi\u00f9 limitate ai volumi Docker, e le importazioni vengono effettuate nello stesso tempo che in Linux e Windows.<\/p>\n<h3>Tagging basato sul contenuto<\/h3>\n<p>\nWerf v1.1 supporta il cosiddetto 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>Quando si esegue il comando <code>werf publish --tags-by-stages-signature<\/code> o <code>werf ci-env --tagging-strategy=stages-signature<\/code> saranno etichettate le immagini pubblicate con quella che viene definita <b>firma delle fasi<\/b> dell'immagine. Ogni immagine viene etichettata con la propria firma delle fasi di questa immagine, che viene calcolata secondo le stesse regole della firma regolare di ciascuna fase separatamente, ma rappresenta un identificatore generale dell'immagine.<\/p>\n<p>La firma delle fasi dell'immagine dipende da:<\/p>\n<ol>\n<li> il contenuto di questa 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, i commit con solo commenti o commit di fusione, o commit che modificano quei file in Git che non saranno importati nell'immagine.<\/p>\n<p>L'uso del content-based tagging risolve i problemi dei riavvii inutili dei pod dell'applicazione in Kubernetes a causa delle modifiche nei nomi delle immagini, anche se il contenuto dell'immagine non \u00e8 cambiato. Questo \u00e8 uno dei motivi che impedisce di conservare pi\u00f9 microservizi di un'applicazione in un unico repository Git.<\/p>\n<p>Inoltre, il content-based tagging \u00e8 un metodo di tagging pi\u00f9 affidabile rispetto al tagging basato su branch Git, poich\u00e9 il contenuto delle immagini risultanti non dipende dall'ordine di esecuzione dei pipeline nel sistema CI per costruire pi\u00f9 commit dello stesso branch.<\/p>\n<p><b>Importante<\/b>: a partire da questo momento <i>stages-signature<\/i> \u00e8 <b>l'unica strategia di tagging raccomandata<\/b>. Sar\u00e0 utilizzata per impostazione predefinita nel team <code>werf ci-env<\/code> (a meno che non venga 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>. A questa funzionalit\u00e0 sar\u00e0 dedicata anche una pubblicazione separata. <b>AGGIORNATO<\/b> (3 aprile): Articolo con i dettagli <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/495112\/\">\u00e8 stata pubblicata<\/a><\/noindex>.<\/p>\n<h3>Livelli di logging<\/h3>\n<p>\nL'utente ha la possibilit\u00e0 di controllare l'output, impostare il livello di logging e lavorare con le informazioni di debug. Sono state aggiunte le opzioni <code>--log-quiet<\/code>, <code>--log-verbose<\/code>, <code>--log-debug<\/code>.<\/p>\n<p>Per impostazione predefinita, l'output contiene informazioni minime:<\/p>\n<p><img decoding=\"async\" alt=\"Rilascio di werf 1.1: miglioramenti nel costruttore oggi e piani per il futuro\" src=\"\/wp-content\/uploads\/2020\/04\/58e981b2e0c579ddde817eadc1732874.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUtilizzando un output dettagliato (<code>--log-verbose<\/code>) \u00e8 possibile seguire come funziona werf:<\/p>\n<p><img decoding=\"async\" alt=\"Rilascio di werf 1.1: miglioramenti nel costruttore 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, include anche i log delle librerie utilizzate. Ad esempio, \u00e8 possibile vedere come avviene l'interazione con Docker Registry, oltre a registrare i punti in cui viene speso un tempo considerevole:<\/p>\n<p><img decoding=\"async\" alt=\"Rilascio di werf 1.1: miglioramenti nel costruttore 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 con l'etichetta <b>v1.1<\/b> saranno disponibili gi\u00e0 in questa versione, molte di esse \u2014 a breve. Gli aggiornamenti arriveranno tramite autoaggiornamenti <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, la loro comparsa non richieder\u00e0 l'intervento manuale dell'utente nelle configurazioni gi\u00e0 esistenti.<\/p>\n<h3>Supporto completo per diverse implementazioni di Docker Registry (NUOVO)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versione: v1.1<\/i><\/li>\n<li> <i>Scadenze: marzo<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2199\">Problema<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nObiettivo \u2014 l'utente deve poter utilizzare qualsiasi implementazione senza limiti nell'uso di werf. <\/p>\n<p>Attualmente abbiamo identificato il seguente insieme di soluzioni per le quali siamo pronti a garantire un supporto completo:<\/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>\nLe soluzioni contrassegnate con asterisco sono quelle attualmente gi\u00e0 completamente supportate da werf. Per le altre esiste supporto, ma con limitazioni.<\/p>\n<p>Possiamo evidenziare due problemi principali:<\/p>\n<ul>\n<li> Alcune soluzioni non supportano la rimozione dei tag tramite l'API di 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> Alcune soluzioni non supportano, cos\u00ec dette, repository annidate (Docker Hub, GitHub Packages e Quay) o le supportano, ma l'utente deve crearle manualmente utilizzando l'interfaccia utente o l'API (AWS ECR).<\/li>\n<\/ul>\n<p>\nQueste e altre problematiche intendiamo affrontare utilizzando le API native delle soluzioni. Questa attivit\u00e0 include anche la copertura con test dell'intero ciclo di lavoro di werf per ciascuna di esse.<\/p>\n<h3>Costruzione 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>Tempistiche: marzo-aprile marzo<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/1614\">Problema<\/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 costruzione e pubblicazione delle immagini e il deployment delle applicazioni in Kubernetes.<\/p>\n<p>Per abilitare le funzionalit\u00e0 di lavoro distribuito di werf, quando la costruzione e il deployment delle applicazioni in Kubernetes vengono eseguiti su pi\u00f9 host arbitrari e questi host non mantengono il proprio stato tra le costruzioni (runner temporanei), werf richiede l'implementazione della possibilit\u00e0 di utilizzare Docker Registry come archivio delle fasi.<\/p>\n<p>In precedenza, quando il progetto werf era ancora chiamato dapp, questa possibilit\u00e0 esisteva. Tuttavia, abbiamo incontrato una serie di problemi che \u00e8 necessario considerare nell'implementazione di questa funzione in werf.<\/p>\n<p><b>Nota<\/b>. Questa funzionalit\u00e0 non prevede il funzionamento del costruttore all'interno dei pod di Kubernetes, poich\u00e9 per questo \u00e8 necessario eliminare la dipendenza dal server Docker locale (nel pod di Kubernetes non c'\u00e8 accesso al server Docker locale, poich\u00e9 il processo stesso \u00e8 eseguito in un container, e werf non supporta e non supporter\u00e0 il lavoro con il server Docker su rete). Il supporto per il lavoro 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>Scadenze: marzo<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2210\">Problema<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nInclude documentazione werf (sezioni <i>reference<\/i> e <i>guida<\/i>), oltre a un'azione ufficiale di GitHub per lavorare con werf.<\/p>\n<p>Inoltre, permetter\u00e0 a werf di lavorare su runner efimeri.<\/p>\n<p>La meccanica di interazione dell'utente con il sistema CI si baser\u00e0 sull'assegnazione di label alle pull request per iniziare determinate azioni di costruzione\/deploy dell'applicazione.<\/p>\n<h3>Sviluppo locale e deployment delle applicazioni con werf (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versione: v1.1<\/i><\/li>\n<li> <i>Tempistiche: gennaio-febbraio aprile<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/1940\">Problema<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nL'obiettivo principale \u00e8 ottenere una configurazione unificata per il deployment delle applicazioni sia in locale che in produzione, senza operazioni complesse, \"pronto all'uso\".<\/p>\n<p>Da werf \u00e8 richiesto anche un regime di lavoro in cui sia comodo modificare il codice dell'applicazione e ricevere immediatamente feedback dall'applicazione in esecuzione per il debug.<\/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\">Problema<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nNella versione corrente di werf v1.1 nella procedura <code>ripulire<\/code> non \u00e8 prevista la pulizia delle immagini per lo schema di tagging basato sul contenuto (content-based tagging) \u2014 queste immagini si accumuleranno.<\/p>\n<p>Nella versione attuale di werf (v1.0 e v1.1) sono utilizzate politiche di pulizia diverse per le immagini pubblicate secondo gli schemi di tagging: Git-branch, Git-tag o Git-commit.<\/p>\n<p>\u00c8 stato ideato un nuovo algoritmo di pulizia unificato per tutti gli schemi di tagging basato sulla cronologia dei commit in Git:<\/p>\n<ul>\n<li> Mantenere non pi\u00f9 di N1 immagini associate agli ultimi N2 commit per ciascun git HEAD (branch e tag).<\/li>\n<li> Mantenere non pi\u00f9 di N1 immagini-stadio associate agli ultimi N2 commit per ciascun git HEAD (branch e tag).<\/li>\n<li> Conservare tutte le immagini utilizzate in alcune risorse del cluster Kubernetes (vengono esaminati tutti i kube-contesti del file di configurazione e i namespace; \u00e8 possibile limitare questo comportamento tramite opzioni speciali).<\/li>\n<li> Mantenere tutte le immagini utilizzate nei manifest di configurazione delle risorse salvati nei rilasci Helm.<\/li>\n<li> Un'immagine pu\u00f2 essere rimossa se non \u00e8 associata a nessun HEAD di git (ad esempio, perch\u00e9 l'HEAD corrispondente \u00e8 stato eliminato) e non viene utilizzata in alcun manifest 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>\nLa versione corrente di werf costruisce immagini e artefatti, descritti in <code>werf.yaml<\/code>, in modo sequenziale. \u00c8 necessario parallelizzare il processo di costruzione di stadi indipendenti delle immagini e artefatti, e fornire un output chiaro e informativo.<\/p>\n<p><i>* Nota: la scadenza \u00e8 stata spostata a causa dell'aumento della priorit\u00e0 nell'implementazione della build distribuita, che aggiunger\u00e0 ulteriori possibilit\u00e0 di scalabilit\u00e0 orizzontale, nonch\u00e9 l'uso di werf con GitHub Actions. La build parallela \u00e8 il prossimo passo nell'ottimizzazione, che fornisce scalabilit\u00e0 verticale durante la costruzione 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 a una nuova base di codice <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/news\/t\/475722\/\">Helm 3<\/a><\/noindex> e un modo collaudato e semplice per migrare installazioni esistenti.<\/p>\n<p><i>* Nota: il passaggio a Helm 3 non aggiunger\u00e0 funzionalit\u00e0 significative a werf, poich\u00e9 tutte le funzionalit\u00e0 chiave di Helm 3 (3-way-merge e assenza di tiller) sono gi\u00e0 state implementate in werf. Inoltre, werf possiede <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/documentation\/reference\/deploy_process\/differences_with_helm.html\">ulteriori funzionalit\u00e0<\/a><\/noindex> oltre a quelle menzionate. Tuttavia, questo passaggio rimane nei nostri piani e sar\u00e0 realizzato.<\/i><\/p>\n<h3>Jsonnet per descrivere la configurazione di 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 nel formato Jsonnet. Allo stesso tempo, werf rimarr\u00e0 compatibile con Helm e ci sar\u00e0 la possibilit\u00e0 di scelta del formato di descrizione.<\/p>\n<p>La ragione \u00e8 che i template del linguaggio Go, secondo molti, hanno una soglia di accesso elevata e la comprensibilit\u00e0 del codice di questi template ne soffre.<\/p>\n<p>Si sta anche considerando la possibilit\u00e0 di implementare altri sistemi di descrizione della configurazione di 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 creazione di immagini e la distribuzione dell'applicazione utilizzando runner in Kubernetes. Cio\u00e8, la creazione di nuove immagini, la loro pubblicazione, la pulizia e il deploy possono avvenire direttamente dai pod di Kubernetes.<\/p>\n<p>Per realizzare questa possibilit\u00e0, \u00e8 prima richiesta la funzionalit\u00e0 di creazione distribuita di immagini <i>(vedi punto sopra)<\/i>.<\/p>\n<p>\u00c8 inoltre necessaria la supporto della modalit\u00e0 di funzionamento del builder senza server Docker (cio\u00e8, creazione simile a Kaniko o creazione in userspace).<\/p>\n<p>Werf supporter\u00e0 la creazione in Kubernetes non solo tramite Dockerfile, ma anche tramite 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 aiutino a rendere werf migliore, comprendano in quale direzione ci stiamo muovendo e partecipino allo sviluppo.<\/p>\n<p>Recentemente \u00e8 stata presa la decisione 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 vedere i piani a breve termine, nonch\u00e9 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 issues:<\/p>\n<ul>\n<li> Sono state rimosse quelle non pi\u00f9 rilevanti.<\/li>\n<li> Le esistenti sono state portate a un formato unico, con un numero sufficiente di dettagli e informazioni.<\/li>\n<li> Sono state aggiunte nuove issues 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 stabilizzano, tuttavia <i>ea<\/i> essa stessa \u00e8 gi\u00e0 sufficientemente stabile per l'uso, poich\u00e9 \u00e8 passata attraverso 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>\nUna nuova architettura per il deposito degli stati e l'ottimizzazione del funzionamento del builder per Stapel e Dockerfile aprono la possibilit\u00e0 di realizzare build distribuite e parallele in werf. Queste funzionalit\u00e0 saranno presto disponibili nella stessa release v1.1 e saranno automaticamente accessibili tramite il meccanismo degli aggiornamenti automatici (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 questa release \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. Inoltre, \u00e8 stata rivista la logica dei comandi principali: <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 di build distribuite. Le build distribuite sono diventate un compito pi\u00f9 prioritario rispetto alle build parallele da v1.0, poich\u00e9 aggiungono maggiore valore a werf: scalabilit\u00e0 verticale dei builder e supporto per builder effimeri in vari sistemi CI\/CD, oltre alla possibilit\u00e0 di offrire supporto ufficiale per GitHub Actions. Pertanto, i tempi per l'implementazione delle build parallele sono stati posticipati. Tuttavia, stiamo lavorando per implementare entrambe le funzionalit\u00e0 il prima possibile.<\/p>\n<p>Rimanete aggiornati! E non dimenticate di farci visita a <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">GitHub<\/a><\/noindex>, per creare un issue, trovare uno gi\u00e0 esistente e mettere un like, creare un PR o semplicemente osservare l'evoluzione del progetto.<\/p>\n<h2>P.S.<\/h2>\n<p>\nLeggi 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 stabile: cosa c'entra GitOps, stato e piani<\/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: deployment in Kubernetes con Helm \u00absotto steroidi\u00bb<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/468049\/\">Uso di werf per il rilascio di chart Helm complessi<\/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 cosa c'entra Docker Registry<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/463613\/\">Ora puoi costruire immagini Docker in werf anche usando 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.1.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.1.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\udd47Release 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}]}}