{"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 su contenuto in werf: perch\u00e9 e come funziona?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Tagging basato su contenuto in 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 CLI GitOps open source per la creazione e la distribuzione di applicazioni su 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 builder delle immagini: il 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 ramo Git o al commit Git. Tuttavia, tutti questi schemi presentano svantaggi che vengono completamente risolti dalla nuova strategia di tagging. Maggiori dettagli su di essa e perch\u00e9 \u00e8 cos\u00ec vantaggiosa \u2014 dopo il salto.<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>\nCapita spesso che un'applicazione sia suddivisa in molti servizi pi\u00f9 o meno indipendenti. Le release di questi servizi possono avvenire indipendentemente: pu\u00f2 essere rilasciato un solo servizio o pi\u00f9 servizi alla volta, 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 tenere tali servizi dell'applicazione in un unico repository.<\/p>\n<p>Ci sono situazioni in cui i servizi sono realmente indipendenti e non collegati a un'unica applicazione. In questo caso, saranno collocati in progetti separati e il loro rilascio avverr\u00e0 tramite processi CI\/CD distinti in ciascun progetto.<\/p>\n<p>Tuttavia, nella realt\u00e0 i programmatori spesso suddividono una singola applicazione in pi\u00f9 microservizi, ma creare un repository e un progetto separati per ciascuno di essi... \u00e8 un evidente overkill. \u00c8 proprio di questa situazione che si parler\u00e0: diversi microservizi si trovano in un unico repository di progetto e i rilasci avvengono tramite un unico processo in CI\/CD.<\/p>\n<h3>Tagging tramite 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 vengono taggate con il nome del branch; per ogni branch esiste solo un'immagine pubblicata con quel nome in un momento dato. Per i tag Git, le immagini vengono taggate rispettivamente con il nome del tag.<\/p>\n<p>Quando viene creato un nuovo tag Git \u2014 ad esempio, con il 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 inseriti tramite template Helm nella configurazione di Kubernetes. Durante l'implementazione con il comando <code>werf deploy<\/code> si aggiorna il campo <code>image<\/code> nei manifesti delle risorse di Kubernetes e si riavviano le 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 effettivamente cambiato rispetto al precedente rilascio (tag Git), ma esclusivamente il suo tag Docker, avviene <i>un inutile<\/i> riavvio di questa applicazione e, di conseguenza, c'\u00e8 la possibilit\u00e0 di un semplice downtime. Anche se non ci sono stati motivi reali per eseguire questo riavvio.<\/p>\n<p>Di conseguenza, con l'attuale schema di tagging \u00e8 necessario gestire diversi repository Git separati e si pone il problema di organizzare il rilascio di questi diversi repository. In generale, questo schema risulta sovraccaricato e complicato. \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 tramite commit Git<\/h3>\n<p>\nIn werf \u00e8 presente anche una strategia di tagging legata ai commit Git.<\/p>\n<p>Il commit Git \u00e8 un identificatore del contenuto del repository Git e dipende dalla storia delle modifiche dei file nel repository Git, quindi \u00e8 logico utilizzarlo per etichettare le immagini nel Docker Registry.<\/p>\n<p>Tuttavia, l'etichettatura basata sul commit Git presenta gli stessi svantaggi di quella basata su ramificazioni o tag Git:<\/p>\n<ul>\n<li> Potrebbe essere stato creato un commit vuoto che non cambia i file, mentre il tag Docker dell'immagine sar\u00e0 cambiato.<\/li>\n<li> Potrebbe essere stato creato un merge commit che non cambia i file, mentre il tag Docker dell'immagine sar\u00e0 cambiato.<\/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 sar\u00e0 nuovamente cambiato.<\/li>\n<\/ul>\n<p><\/p>\n<h2>L'etichettatura basata sul nome della ramificazione Git non riflette la versione dell'immagine.<\/h2>\n<p>\nC'\u00e8 anche un'altra problematica legata alla strategia di etichettatura basata sulle ramificazioni Git.<\/p>\n<p>L'etichettatura basata sul nome della ramificazione funziona finch\u00e9 i commit di quella ramificazione vengono raccolti in modo sequenziale in ordine cronologico.<\/p>\n<p>\u0415\u0441\u043b\u0438 \u0432 \u0442\u0435\u043a\u0443\u0449\u0435\u0439 \u0441\u0445\u0435\u043c\u0435 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u044c \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442 \u043f\u0435\u0440\u0435\u0441\u0431\u043e\u0440\u043a\u0443 \u0441\u0442\u0430\u0440\u043e\u0433\u043e \u043a\u043e\u043c\u043c\u0438\u0442\u0430, \u0441\u0432\u044f\u0437\u0430\u043d\u043d\u043e\u0433\u043e \u0441 \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u043e\u0439 \u0432\u0435\u0442\u043a\u043e\u0439, \u0442\u043e werf \u043f\u0435\u0440\u0435\u0442\u0440\u0435\u0442 \u043e\u0431\u0440\u0430\u0437 \u043f\u043e \u0441\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0443\u044e\u0449\u0435\u043c\u0443 Docker-\u0442\u0435\u0433\u0443 \u0432\u043d\u043e\u0432\u044c \u0441\u043e\u0431\u0440\u0430\u043d\u043d\u043e\u0439 \u0432\u0435\u0440\u0441\u0438\u0435\u0439 \u043e\u0431\u0440\u0430\u0437\u0430 \u0434\u043b\u044f \u0441\u0442\u0430\u0440\u043e\u0433\u043e \u043a\u043e\u043c\u043c\u0438\u0442\u0430. \u0418\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044e\u0449\u0438\u0435 \u044d\u0442\u043e\u0442 \u0442\u0435\u0433 Deployment&#8217;\u044b \u0441 \u044d\u0442\u043e\u0433\u043e \u043c\u043e\u043c\u0435\u043d\u0442\u0430 \u0440\u0438\u0441\u043a\u0443\u044e\u0442 \u0432\u043e \u0432\u0440\u0435\u043c\u044f \u043f\u0435\u0440\u0435\u0437\u0430\u043f\u0443\u0441\u043a\u0430 pod&#8217;\u043e\u0432 \u0441\u0434\u0435\u043b\u0430\u0442\u044c pull \u0434\u0440\u0443\u0433\u043e\u0439 \u0432\u0435\u0440\u0441\u0438\u0438 \u043e\u0431\u0440\u0430\u0437\u0430, \u0432 \u0440\u0435\u0437\u0443\u043b\u044c\u0442\u0430\u0442\u0435 \u0447\u0435\u0433\u043e \u043d\u0430\u0448\u0435 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u043f\u043e\u0442\u0435\u0440\u044f\u0435\u0442 \u0441\u0432\u044f\u0437\u044c \u0441 CI-\u0441\u0438\u0441\u0442\u0435\u043c\u043e\u0439, \u0440\u0430\u0441\u0441\u0438\u043d\u0445\u0440\u043e\u043d\u0438\u0437\u0438\u0440\u0443\u0435\u0442\u0441\u044f.<\/p>\n<p>Inoltre, quando si eseguono push consecutivi su un branch con un breve intervallo di tempo tra di loro, il vecchio commit potrebbe essere ricompilato dopo un commit pi\u00f9 recente: la vecchia versione dell'immagine sovrascrive la nuova con il tag del branch Git. Questi problemi possono essere risolti da un sistema CI\/CD (ad esempio, in GitLab CI viene avviato un pipeline per una serie di commit), ma non tutte le piattaforme supportano questa funzionalit\u00e0 e quindi \u00e8 necessario trovare un modo pi\u00f9 affidabile per prevenire tale problema fondamentale.<\/p>\n<h2>Che cos'\u00e8 il content-based tagging?<\/h2>\n<p>\nQuindi, che cos'\u00e8 il content-based tagging \u2014 la taggatura delle immagini in base al contenuto.<\/p>\n<p>\u0414\u043b\u044f \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u044f Docker-\u0442\u0435\u0433\u043e\u0432 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044e\u0442\u0441\u044f \u043d\u0435 \u043f\u0440\u0438\u043c\u0438\u0442\u0438\u0432\u044b Git&#8217;\u0430 (Git-\u0432\u0435\u0442\u043a\u0430, Git-\u0442\u0435\u0433\u2026), \u0430 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u043d\u0430\u044f \u0441\u0443\u043c\u043c\u0430, \u0441\u0432\u044f\u0437\u0430\u043d\u043d\u0430\u044f \u0441:<\/p>\n<ul>\n<li> <i>il contenuto dell'immagine<\/i>. L'identificatore del tag dell'immagine riflette il suo contenuto. Durante la creazione di una nuova versione, questo identificatore non cambier\u00e0 se i file nell'immagine non sono stati modificati;<\/li>\n<li> <i>la storia di creazione di quest'immagine in Git<\/i>. Le immagini collegate a rami Git diversi e con istorie di build diverse tramite werf avranno identificatori di tag diversi.<\/li>\n<\/ul>\n<p>\nCome identificatore di questo tipo, viene utilizzata la cosiddetta <b>firma delle fasi dell'immagine<\/b>.<\/p>\n<p>Ogni immagine \u00e8 composta da un insieme di fasi: <code>from<\/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 contrassegnata con la cosiddetta firma dell'insieme di queste fasi \u2014 <b>stages signature<\/b>, \u2014 che \u00e8 generale per tutte le fasi dell'immagine.<\/p>\n<p>Ogni immagine dalla configurazione <code>werf.yaml<\/code> in generale avr\u00e0 la sua firma e, di conseguenza, un tag Docker.<\/p>\n<p>La firma delle fasi risolve tutti i problemi indicati:<\/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 porta a problemi di sovrascrittura della versione attuale dell'immagine al riavvio delle build per vecchi commit Git del ramo.<\/li>\n<\/ul>\n<p>\nQuesta \u00e8 ora la strategia di tagging raccomandata e viene utilizzata per impostazione predefinita in werf per tutti i sistemi CI.<\/p>\n<h2>Come abilitare 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 era definito dal 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 se non si specifica questa opzione, werf utilizzer\u00e0 per impostazione predefinita la strategia di tagging <code>stages-signature<\/code>. 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 generare 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 delle fasi dell'immagine <code>backend<\/code>, e <code>f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6<\/code> \u2014 firma delle fasi dell'immagine <code>frontend<\/code>.<\/p>\n<p>Utilizzando funzioni speciali <code>werf_container_image<\/code> e <code>werf_container_env<\/code> non \u00e8 necessario modificare nulla nei modelli Helm: queste funzioni genereranno automaticamente i nomi delle 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 informazione sulla configurazione \u00e8 disponibile 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 Introduzione \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> 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, sar\u00e0 di default <code>stages-signature<\/code>).<\/li>\n<li> Se precedentemente sono state utilizzate opzioni di tagging per commit Git (<code>WERF_TAG_GIT_COMMIT<\/code> oppure l'opzione <code>werf publish --tag-git-commit COMMIT<\/code>), \u00e8 necessario passare alla strategia di tagging <i>stages-signature<\/i>.<\/li>\n<li> I nuovi progetti dovrebbero essere subito impostati sulla nuova strategia di tagging.<\/li>\n<li> Per i vecchi progetti, quando si passa a werf 1.1, \u00e8 consigliabile passare alla nuova strategia di tagging, tuttavia, la vecchia <i>tag-or-branch<\/i> \u00e8 ancora supportata.<\/li>\n<\/ul>\n<p>\nIl tagging basato sui contenuti risolve tutti i problemi discussi nell'articolo:<\/p>\n<ul>\n<li> La resilienza del nome del tag Docker ai commit Git vuoti.<\/li>\n<li> La robustezza del nome del tag Docker rispetto ai commit Git che cambiano 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 delle branche Git.<\/li>\n<\/ul>\n<p>\nUsate! E non dimenticate di visitarci su <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">GitHub<\/a><\/noindex>, per creare un'issue o trovare gi\u00e0 esistente, lasciare un like, creare una PR o semplicemente osservare l'evoluzione 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\/493170\/\">Rilascio di werf 1.1: miglioramenti nel builder 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 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\/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 4.9.10 - aioseo.com -->\n\t<meta name=\"description\" content=\"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,\" \/>\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) 4.9.10\" \/>\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:description\" content=\"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,\" \/>\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\udd47Content-based tagging nel builder werf: perch\u00e9 e come funziona? | ProHoster","description":"werf \u00e8 la nostra utilit\u00e0 CLI GitOps open-source per costruire e consegnare applicazioni in Kubernetes. Nel rilascio v1.1 \u00e8 stata introdotta una nuova funzionalit\u00e0 nel builder delle immagini: il tagging delle immagini basato sui contenuti o content-based tagging. Fino ad ora, lo schema tipico di tagging in werf prevedeva il tagging delle immagini Docker per tag Git, branch Git o commit Git. Ma tutte queste schemi hanno svantaggi.","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:description":"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,","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"},"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}]}}