{"id":76769,"date":"2020-04-04T13:42:27","date_gmt":"2020-04-04T11:42:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/content-based-tagging-v-sborshhike-werf-zachem-i-kak-eto-rabotaet"},"modified":"2020-04-04T13:42:27","modified_gmt":"2020-04-04T11:42:27","slug":"content-based-tagging-v-sborshhike-werf-zachem-i-kak-eto-rabotaet","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/content-based-tagging-v-sborshhike-werf-zachem-i-kak-eto-rabotaet","title":{"rendered":"Tagging basato sui contenuti nel costruttore werf: perch\u00e9 e come funziona?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Tagging basato sui contenuti nel costruttore werf: perch\u00e9 e come funziona?\" src=\"\/wp-content\/uploads\/2020\/04\/494346bbee96cc2b6c838491ba1c67fb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/\">werf<\/a><\/noindex> \u2014 il nostro strumento GitOps CLI open source per costruire e distribuire applicazioni in Kubernetes. Nel <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/493170\/\">rilascio v1.1<\/a><\/noindex> \u00e8 stata introdotta una nuova funzionalit\u00e0 nel costruttore di immagini: tagging delle immagini in base al contenuto o <i>tagging basato sul contenuto<\/i>. Fino ad ora, lo schema di tagging tipico in werf prevedeva il tagging delle immagini Docker in base al tag Git, al branch Git o al commit Git. Ma tutte queste strategie hanno dei difetti, che vengono completamente risolti dalla nuova strategia di tagging. Maggiori dettagli su di essa e su quanto sia buona saranno forniti di seguito.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Distribuzione di un set di microservizi da un singolo repository Git<\/h2>\n<p>\nSi verifica spesso la situazione in cui un'applicazione \u00e8 suddivisa in molti servizi pi\u00f9 o meno indipendenti. Le release di questi servizi possono avvenire in modo indipendente: in un'unica occasione pu\u00f2 essere rilasciato uno o pi\u00f9 servizi, mentre gli altri devono continuare a funzionare senza alcuna modifica. Ma dal punto di vista della gestione del codice e del progetto, \u00e8 pi\u00f9 comodo mantenere tali servizi dell'applicazione in un unico repository.<\/p>\n<p>Ci sono situazioni in cui i servizi sono davvero indipendenti e non appartengono a un'unica applicazione. In tal caso, saranno collocati in progetti separati e il loro rilascio avverr\u00e0 tramite processi CI\/CD separati in ciascun progetto.<\/p>\n<p>Tuttavia, nella realt\u00e0, gli sviluppatori spesso suddividono un'unica applicazione in diversi microservizi, ma gestire un singolo repository e progetto per ciascuno\u2026 \u00e8 palesemente un overkill. \u00c8 di quest'ultima situazione di cui parleremo: diversi microservizi si trovano all'interno di un unico repository di progetto e le release avvengono tramite un unico processo in CI\/CD.<\/p>\n<h3>Tagging per branch e tag Git<\/h3>\n<p>\nSupponiamo di utilizzare la strategia di tagging pi\u00f9 comune \u2014 <i>tag-or-branch<\/i>. Per i branch Git, le immagini sono taggate con il nome del branch, per un singolo branch esiste in un dato momento solo un'immagine pubblicata con il nome di quel branch. Per i tag Git, le immagini sono taggate di conseguenza con il nome del tag.<\/p>\n<p>Quando viene creato un nuovo tag Git \u2014 ad esempio, al rilascio di una nuova versione \u2014 verr\u00e0 creato un nuovo tag Docker per tutte le immagini del progetto nel Docker Registry:<\/p>\n<ul>\n<li> <code>myregistry.org\/myproject\/frontend:v1.1.10<\/code><\/li>\n<li> <code>myregistry.org\/myproject\/myservice1:v1.1.10<\/code><\/li>\n<li> <code>myregistry.org\/myproject\/myservice2:v1.1.10<\/code><\/li>\n<li> <code>myregistry.org\/myproject\/myservice3:v1.1.10<\/code><\/li>\n<li> <code>myregistry.org\/myproject\/myservice4:v1.1.10<\/code><\/li>\n<li> <code>myregistry.org\/myproject\/myservice5:v1.1.10<\/code><\/li>\n<li> <code>myregistry.org\/myproject\/database:v1.1.10<\/code><\/li>\n<\/ul>\n<p>\nQuesti nuovi nomi delle immagini vengono inclusi nella configurazione di Kubernetes tramite i modelli Helm. Al momento del lancio del deployment con il comando <code>werf deploy<\/code> avviene l'aggiornamento del campo <code>image<\/code> nei manifesti delle risorse di Kubernetes e viene effettuato il riavvio delle risorse corrispondenti a causa della modifica del nome dell'immagine.<\/p>\n<p><b>Problema<\/b>: nel caso in cui il contenuto dell'immagine non sia realmente cambiato dal precedente rilascio (tag Git), ma sia solo il suo tag Docker a essere modificato, si verifica <i>un inutile<\/i> riavvio di questa applicazione e, di conseguenza, \u00e8 possibile un certo fermo. Sebbene non ci siano state ragioni reali per effettuare questo riavvio.<\/p>\n<p>Di conseguenza, con l'attuale schema di tagging, \u00e8 necessario creare diversi repository Git separati e si pone il problema di organizzare il rilascio di questi diversi repository. In generale, questo schema risulta sovraccarico e complesso. \u00c8 meglio unire pi\u00f9 servizi in un unico repository e creare tag Docker in modo da evitare riavvii non necessari.<\/p>\n<h3>Tagging per commit Git<\/h3>\n<p>\nIn werf \u00e8 presente anche una strategia di tagging collegata ai commit Git.<\/p>\n<p>Il commit Git \u00e8 un identificatore del contenuto del repository Git e dipende dalla cronologia delle modifiche ai file nel repository Git, quindi sembra logico utilizzarlo per il tagging delle immagini nel Docker Registry.<\/p>\n<p>Tuttavia, il tagging per commit Git presenta gli stessi svantaggi di quello per rami Git o tag Git:<\/p>\n<ul>\n<li> Potrebbe essere stato creato un commit vuoto che non modifica i file, ma il tag Docker dell'immagine verr\u00e0 modificato.<\/li>\n<li> Potrebbe essere stato creato un commit di fusione che non modifica i file, ma il tag Docker dell'immagine verr\u00e0 modificato.<\/li>\n<li> Potrebbe essere stato creato un commit che modifica file in Git che non vengono importati nell'immagine, e il tag Docker dell'immagine verr\u00e0 nuovamente modificato.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Il tagging per nome del ramo Git non riflette la versione dell'immagine<\/h2>\n<p>\nC'\u00e8 anche un altro problema legato alla strategia di tagging per rami Git.<\/p>\n<p>Il tagging per nome del ramo funziona finch\u00e9 i commit di quel ramo vengono raccolti in modo sequenziale in ordine cronologico.<\/p>\n<p>Se nella scheda attuale un utente avvia la ricostruzione di un vecchio commit associato a un certo ramo, werf sovrascriver\u00e0 l'immagine con la versione appena assemblata dell'immagine per il vecchio commit, utilizzando il corrispondente tag Docker. I Deployment che utilizzano questo tag rischiano, a partire da ora, di eseguire pull di un'altra versione dell'immagine durante il riavvio dei pod, causando cos\u00ec la perdita di connessione dell'applicazione con il sistema CI e la desincronizzazione.<\/p>\n<p>Inoltre, durante i push consecutivi su uno stesso ramo con breve intervallo di tempo tra di essi, un vecchio commit potrebbe essere ricompilato dopo un commit pi\u00f9 recente: la vecchia versione dell'immagine sovrascriver\u00e0 la nuova in base al tag del ramo Git. Tali problemi possono essere risolti da un sistema CI\/CD (ad esempio, in GitLab CI, viene attivato un pipeline per l'ultimo di una serie di commit). Tuttavia, non tutti i sistemi lo supportano e deve esserci un metodo pi\u00f9 affidabile per prevenire un problema cos\u00ec fondamentale.<\/p>\n<h2>Che cos'\u00e8 il content-based tagging?<\/h2>\n<p>\nAllora, cos'\u00e8 il content-based tagging \u2014 il tagging delle immagini basato sul contenuto.<\/p>\n<p>Per creare i tag Docker non si utilizzano le primitive di Git (ramo Git, tag Git\u2026), ma un checksum associato a:<\/p>\n<ul>\n<li> <i>il contenuto dell'immagine<\/i>. L'identificatore-tag dell'immagine riflette il suo contenuto. Durante la costruzione di una nuova versione, questo identificatore non cambier\u00e0 se non ci sono stati cambiamenti nei file dell'immagine;<\/li>\n<li> <i>la storia di creazione di quest'immagine in Git<\/i>. Le immagini correlate a diversi rami Git e con storie di costruzione diverse mediante werf avranno identificatori-tag diversi.<\/li>\n<\/ul>\n<p>\nCome identificatore-tag viene utilizzata la cosiddetta <b>firma delle fasi dell'immagine<\/b>.<\/p>\n<p>Ogni immagine consiste in un insieme di fasi: <code>da<\/code>, <code>before-install<\/code>, <code>git-archive<\/code>, <code>install<\/code>, <code>imports-after-install<\/code>, <code>before-setup<\/code>,\u2026 <code>git-latest-patch<\/code> ecc. Ogni fase ha un identificatore che riflette il suo contenuto \u2014 <b>firma della fase<\/b> <i>(stage signature)<\/i>.<\/p>\n<p>L'immagine finale, composta da queste fasi, viene etichettata con quella che si chiama firma dell'insieme di queste fasi \u2014 <b>stages signature<\/b>, che \u00e8 un riassunto per tutte le fasi dell'immagine.<\/p>\n<p>Ogni immagine dalla configurazione <code>werf.yaml<\/code> in generale avr\u00e0 una propria firma e, di conseguenza, un tag Docker.<\/p>\n<p>La firma delle fasi risolve tutti i problemi menzionati:<\/p>\n<ul>\n<li> \u00c8 resistente ai commit Git vuoti.<\/li>\n<li> \u00c8 resistente ai commit Git che modificano file non rilevanti per l'immagine.<\/li>\n<li> Non provoca il problema di sovrascrivere la versione attuale dell'immagine durante il riavvio delle costruzioni per vecchi commit Git del ramo.<\/li>\n<\/ul>\n<p>\nOra questa \u00e8 la strategia di tagging raccomandata e viene utilizzata per impostazione predefinita in werf per tutti i sistemi CI.<\/p>\n<h2>Come attivare e utilizzare in werf<\/h2>\n<p>\nL'opzione corrispondente \u00e8 stata aggiunta al comando <code>werf publish<\/code>: <code>--tag-by-stages-signature=true|false<\/code><\/p>\n<p>Nella CI, la strategia di tagging \u00e8 impostata dal comando <code>werf ci-env<\/code>. In precedenza, per essa era definito il parametro <code>werf ci-env --tagging-strategy=tag-or-branch<\/code>. Ora, se si specifica <code>werf ci-env --tagging-strategy=stages-signature<\/code> o non si specifica questa opzione, werf utilizzer\u00e0 per impostazione predefinita la strategia di tagging <code>stages-signature<\/code>. Il comando <code>werf ci-env<\/code> imposter\u00e0 automaticamente i flag necessari per il comando <code>werf build-and-publish<\/code> (o <code>werf publish<\/code>), quindi non \u00e8 necessario specificare ulteriori opzioni per questi comandi.<\/p>\n<p>Ad esempio, il comando:<\/p>\n<pre><code class=\"plaintext\">werf publish --stages-storage :local --images-repo registry.hello.com\/web\/core\/system --tag-by-stages-signature<\/code><\/pre>\n<p>\n\u2026 pu\u00f2 creare le seguenti immagini:<\/p>\n<ul>\n<li> <code>registry.hello.com\/web\/core\/system\/backend:4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d<\/code><\/li>\n<li> <code>registry.hello.com\/web\/core\/system\/frontend:f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6<\/code><\/li>\n<\/ul>\n<p>\nQui <code>4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d<\/code> \u2014 questa \u00e8 la firma della fase dell'immagine <code>backend<\/code>, ma <code>f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6<\/code> \u2014 firma della fase dell'immagine <code>frontend<\/code>.<\/p>\n<p>Utilizzando funzioni speciali <code>werf_container_image<\/code> e <code>werf_container_env<\/code> nei modelli Helm non \u00e8 necessario modificare nulla: queste funzioni genereranno automaticamente nomi di immagini corretti.<\/p>\n<p>Esempio di configurazione nel sistema CI:<\/p>\n<pre><code class=\"plaintext\">type multiwerf &amp;&amp; source &lt;(multiwerf use 1.1 beta)\ntype werf &amp;&amp; source &lt;(werf ci-env gitlab)\nwerf build-and-publish|deploy<\/code><\/pre>\n<p>\nMaggiore informazioni sulla configurazione sono disponibili nella documentazione:<\/p>\n<ul>\n<li> <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\">Guida \u2192 Pubblicazione (publish)<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/reference\/plugging_into_cicd\/overview.html#stages-signature\">Lavorare con CI\/CD \u2192 Panoramica generale \u2192 stages-signature<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/guides\/gitlab_ci_cd_integration.html#gitlab-ciyml\">Integrazione con GitLab CI\/CD \u2192 .gitlab-ci.yml<\/a><\/noindex>.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Totale<\/h2>\n<p><\/p>\n<ul>\n<li> Una nuova opzione <code>werf publish --tag-by-stages-signature=true|false<\/code>.<\/li>\n<li> Nuovo valore dell'opzione <code>werf ci-env --tagging-strategy=stages-signature|tag-or-branch<\/code> (se non specificato, per impostazione predefinita sar\u00e0 <code>stages-signature<\/code>).<\/li>\n<li> Se in precedenza sono state utilizzate opzioni di tagging basate su commit Git (<code>WERF_TAG_GIT_COMMIT<\/code> o l'opzione <code>werf publish --tag-git-commit COMMIT<\/code>), allora bisogna cambiare obbligatoriamente alla strategia di tagging <i>stages-signature<\/i>.<\/li>\n<li> \u00c8 meglio cambiare i nuovi progetti subito alla nuova schema di tagging.<\/li>\n<li> Per i progetti esistenti che passano a werf 1.1, \u00e8 consigliabile cambiare alla nuova schema di tagging, tuttavia la vecchia <i>tag-or-branch<\/i> \u00e8 ancora supportata.<\/li>\n<\/ul>\n<p>\nIl tagging basato sul contenuto risolve tutti i problemi menzionati nell'articolo:<\/p>\n<ul>\n<li> Resistenza del nome del tag Docker ai commit Git vuoti.<\/li>\n<li> Resistenza del nome del tag Docker a commit Git che modificano file non rilevanti per l'immagine.<\/li>\n<li> Non comporta problemi di sovrascrittura della versione attuale dell'immagine durante il riavvio delle build per vecchi commit Git per i rami Git.<\/li>\n<\/ul>\n<p>\nUsate! E non dimenticate di visitare il nostro <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">GitHub<\/a><\/noindex>, per creare un'issue o trovare gi\u00e0 esistente, mettere un like, creare una PR o semplicemente seguire lo sviluppo 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\/493170\/\">Rilascio di werf 1.1: miglioramenti nel costruttore oggi e piani per il futuro<\/a><\/noindex>\u00bb<\/li>\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\/495112\/\">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. \u0412 \u0440\u0435\u043b\u0438\u0437\u0435 v1.1 \u0431\u044b\u043b\u0430 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u043b\u0435\u043d\u0430 \u043d\u043e\u0432\u0430\u044f \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c \u0432 \u0441\u0431\u043e\u0440\u0449\u0438\u043a\u0435 \u043e\u0431\u0440\u0430\u0437\u043e\u0432: \u0442\u0435\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u043e\u0431\u0440\u0430\u0437\u043e\u0432 \u043f\u043e \u0441\u043e\u0434\u0435\u0440\u0436\u0438\u043c\u043e\u043c\u0443 \u0438\u043b\u0438 content-based tagging. \u0414\u043e \u0441\u0438\u0445 \u043f\u043e\u0440 \u0442\u0438\u043f\u0438\u0447\u043d\u0430\u044f \u0441\u0445\u0435\u043c\u0430 \u0442\u0435\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0432 werf \u043f\u0440\u0435\u0434\u043f\u043e\u043b\u0430\u0433\u0430\u043b\u0430 \u0442\u0435\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 Docker-\u043e\u0431\u0440\u0430\u0437\u043e\u0432 \u043f\u043e Git-\u0442\u0435\u0433\u0443, Git-\u0432\u0435\u0442\u043a\u0435 \u0438\u043b\u0438 Git-\u043a\u043e\u043c\u043c\u0438\u0442\u0443. \u041d\u043e \u0443 \u0432\u0441\u0435\u0445 \u044d\u0442\u0438\u0445 \u0441\u0445\u0435\u043c \u0435\u0441\u0442\u044c \u043d\u0435\u0434\u043e\u0441\u0442\u0430\u0442\u043a\u0438, [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":76770,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-76769","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\/content-based-tagging-v-sborshhike-werf-zachem-i-kak-eto-rabotaet\" \/>\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\udd47Content-based tagging \u0432 \u0441\u0431\u043e\u0440\u0449\u0438\u043a\u0435 werf: \u0437\u0430\u0447\u0435\u043c \u0438 \u043a\u0430\u043a \u044d\u0442\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442? | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/content-based-tagging-v-sborshhike-werf-zachem-i-kak-eto-rabotaet\" \/>\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:27+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-04-04T11:42:27+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\udd47Tagging basato sui contenuti nel builder werf: perch\u00e9 e come funziona? | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/content-based-tagging-v-sborshhike-werf-zachem-i-kak-eto-rabotaet","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\udd47Content-based tagging \u0432 \u0441\u0431\u043e\u0440\u0449\u0438\u043a\u0435 werf: \u0437\u0430\u0447\u0435\u043c \u0438 \u043a\u0430\u043a \u044d\u0442\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442? | ProHoster","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/content-based-tagging-v-sborshhike-werf-zachem-i-kak-eto-rabotaet","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:27+00:00","article:modified_time":"2020-04-04T11:42:27+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"76769","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:22","updated":"2022-09-28 05:59:33","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\/76769","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=76769"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/76769\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/76770"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=76769"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=76769"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=76769"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}