{"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\/de\/blog\/administrirovanie\/content-based-tagging-v-sborshhike-werf-zachem-i-kak-eto-rabotaet","title":{"rendered":"Content-basiertes Tagging im werf-Assembler: Warum und wie funktioniert das?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Content-basiertes Tagging im werf-Assembler: Warum und wie funktioniert das?\" 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 unser GitOps-CLI-Tool mit offenem Quellcode zur Erstellung und Bereitstellung von Anwendungen in Kubernetes. In <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/493170\/\">der Version v1.1<\/a><\/noindex> wurde eine neue Funktion im Image-Building vorgestellt: das Tagging von Images basierend auf dem Inhalt oder <i>content-based tagging<\/i>. Bisher war das typische Tagging-Schema in werf, dass Docker-Images anhand des Git-Tags, des Git-Zweigs oder des Git-Commits getaggt wurden. Doch alle diese Schemata haben Nachteile, die durch die neue Tagging-Strategie vollst\u00e4ndig gel\u00f6st werden. Details dazu und was sie so gut macht, finden Sie darunter.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Die Bereitstellung eines Satzes von Mikroservices aus einem einzelnen Git-Repository<\/h2>\n<p>\nEs gibt h\u00e4ufig Situationen, in denen eine Anwendung in mehrere mehr oder weniger unabh\u00e4ngige Dienste aufgeteilt ist. Die Bereitstellungen dieser Dienste k\u00f6nnen unabh\u00e4ngig voneinander erfolgen: auf einmal kann ein oder mehrere Dienste bereitgestellt werden, w\u00e4hrend die anderen weiterhin ohne \u00c4nderungen arbeiten m\u00fcssen. Aus der Sicht der Codeverwaltung und des Projektmanagements ist es jedoch praktischer, solche Dienste in einem einzigen Repository zu halten.<\/p>\n<p>Es gibt Situationen, in denen die Dienste tats\u00e4chlich unabh\u00e4ngig sind und nicht zu einer einzigen Anwendung geh\u00f6ren. In diesem Fall befinden sie sich in separaten Projekten, und die Bereitstellung erfolgt \u00fcber separate CI\/CD-Prozesse in jedem dieser Projekte.<\/p>\n<p>In der Realit\u00e4t jedoch zerlegen Entwickler oft eine einheitliche Anwendung in mehrere Mikroservices, aber f\u00fcr jeden einen separaten Repository und ein Projekt anzulegen, w\u00e4re ... ein offensichtlicher Overkill. Genau \u00fcber diese Situation wird im Folgenden gesprochen: mehrere solche Mikroservices liegen in einem einzigen Repository des Projekts und die Bereitstellungen erfolgen \u00fcber einen einzigen CI\/CD-Prozess.<\/p>\n<h3>Tagging nach Git-Zweig und Git-Tag<\/h3>\n<p>\nAngenommen, es wird die am weitesten verbreitete Tagging-Strategie verwendet \u2014 <i>tag-or-branch<\/i>. F\u00fcr Git-Zweige werden Images mit dem Namen des Zweigs getaggt, f\u00fcr einen Zweig existiert zu einem Zeitpunkt nur ein ver\u00f6ffentlichtes Image mit dem Namen dieses Zweigs. F\u00fcr Git-Tags werden die Images entsprechend dem Tag-Namen getaggt.<\/p>\n<p>Bei der Erstellung eines neuen Git-Tags \u2014 zum Beispiel bei der Ver\u00f6ffentlichung einer neuen Version \u2014 wird f\u00fcr alle Images des Projekts im Docker-Registry ein neuer Docker-Tag erstellt:<\/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>\nDiese neuen Bildnamen gelangen \u00fcber Helm-Templates in die Kubernetes-Konfiguration. Bei der Ausf\u00fchrung des Deployments mit dem Befehl <code>werf deploy<\/code> erfolgt eine Aktualisierung des Feldes <code>Image<\/code> in den Manifesten der Kubernetes-Ressourcen und ein Neustart der entsprechenden Ressourcen aufgrund des ge\u00e4nderten Bildnamens.<\/p>\n<p><b>Problem<\/b>: falls sich der Inhalt des Images seit dem letzten Rollout (Git-Tag) tats\u00e4chlich nicht ge\u00e4ndert hat, sondern nur dessen Docker-Tag, findet ein <i>\u00fcberfl\u00fcssiger<\/i> Neustart dieser Anwendung statt, wodurch m\u00f6glicherweise eine Unterbrechung entsteht. Obwohl es keine wirklichen Gr\u00fcnde gab, f\u00fcr diesen Neustart.<\/p>\n<p>Folglich muss bei dem aktuellen Taggingschema mehrere separate Git-Repositorys erstellt werden, und es entsteht das Problem, diese mehreren Repositorys auszuspielen. Insgesamt f\u00fchrt ein solches Schema zu einer \u00dcberlastung und Komplexit\u00e4t. Es ist besser, viele Dienste in einem einzigen Repository zu b\u00fcndeln und Docker-Tags so zu setzen, dass \u00fcberfl\u00fcssige Neustarts vermieden werden.<\/p>\n<h3>Tagging nach Git-Commit<\/h3>\n<p>\nIn werf gibt es auch eine Tagging-Strategie, die mit Git-Commits verbunden ist.<\/p>\n<p>Ein Git-Commit ist der Identifier f\u00fcr den Inhalt des Git-Repositorys und h\u00e4ngt von der \u00c4nderungs-Historie der Dateien im Git-Repository ab, daher erscheint es logisch, ihn f\u00fcr das Tagging von Bildern im Docker-Registry zu verwenden.<\/p>\n<p>Allerdings hat das Tagging nach Git-Commit die gleichen Nachteile wie das Tagging nach Git-Branches oder Git-Tags:<\/p>\n<ul>\n<li> Es k\u00f6nnte ein leerer Commit erstellt worden sein, der keine Dateien \u00e4ndert, w\u00e4hrend der Docker-Tag des Bildes ge\u00e4ndert wird.<\/li>\n<li> Es k\u00f6nnte ein Merge-Commit erstellt worden sein, der keine Dateien \u00e4ndert, w\u00e4hrend der Docker-Tag des Bildes ge\u00e4ndert wird.<\/li>\n<li> Es k\u00f6nnte ein Commit erstellt worden sein, der die Dateien in Git \u00e4ndert, die nicht im Image importiert werden, und der Docker-Tag des Bildes wird erneut ge\u00e4ndert.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Tagging nach dem Namen des Git-Branches spiegelt nicht die Version des Images wider<\/h2>\n<p>\nEs gibt noch ein weiteres Problem, das mit der Tagging-Strategie nach Git-Branches verbunden ist.<\/p>\n<p>Tagging nach dem Namen des Branches funktioniert, solange die Commits dieses Branches chronologisch aufeinanderfolgend gesammelt werden.<\/p>\n<p>Wenn ein Benutzer in dem aktuellen Schema eine Wiederherstellung eines alten Commits, der mit einem bestimmten Branch verkn\u00fcpft ist, startet, wird werf das Image unter dem entsprechenden Docker-Tag mit der neu gebauten Version des Images f\u00fcr den alten Commit \u00fcberschreiben. Deployments, die dieses Tag verwenden, riskieren ab diesem Moment, beim Neustart von Pods eine andere Version des Images zu pullen, wodurch unsere Anwendung die Verbindung zum CI-System verliert und sich desynchronisiert.<\/p>\n<p>Dar\u00fcber hinaus kann bei aufeinanderfolgenden Pushes in einen Branch mit geringen Zeitabst\u00e4nden zwischen ihnen der alte Commit sp\u00e4ter gebaut werden als der neuere: Die alte Version des Images \u00fcberschreibt die neue nach dem Git-Branch-Tag. Solche Probleme k\u00f6nnen von einem CI\/CD-System (z. B. wird in GitLab CI f\u00fcr eine Reihe von Commits das Pipeline des letzten Commits gestartet) gel\u00f6st werden. Allerdings unterst\u00fctzen nicht alle Systeme dies, und es sollte eine zuverl\u00e4ssigere Methode zur Vermeidung eines so fundamentalen Problems geben.<\/p>\n<h2>Was ist Content-based Tagging?<\/h2>\n<p>\nAlso, was ist Content-based Tagging \u2013 das Tagging von Images basierend auf deren Inhalt.<\/p>\n<p>F\u00fcr die Erstellung von Docker-Tags werden keine Git-Primitiven (Git-Branch, Git-Tag...) verwendet, sondern die Pr\u00fcfziffer, die verbunden ist mit:<\/p>\n<ul>\n<li> <i>dem Inhalt des Images<\/i>. Die Tag-ID des Images spiegelt dessen Inhalt wider. Bei der Erstellung einer neuen Version wird diese ID nicht ver\u00e4ndert, sofern sich die Dateien im Image nicht ge\u00e4ndert haben;<\/li>\n<li> <i>der Historie der Erstellung dieses Images in Git<\/i>. Images, die mit verschiedenen Git-Branches und unterschiedlichen Bauhistorien \u00fcber werf verbunden sind, haben unterschiedliche Tag-IDs.<\/li>\n<\/ul>\n<p>\nSo eine Tag-ID ist die sogenannte <b>Stufensignatur des Images<\/b>.<\/p>\n<p>Jedes Image besteht aus einer Reihe von Stufen: <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> usw. Jede Stufe hat eine ID, die ihren Inhalt widerspiegelt, \u2014 <b>Stufensignatur<\/b> <i>(stage signature)<\/i>.<\/p>\n<p>Das endg\u00fcltige Bild, das aus diesen Stufen besteht, wird mit der sogenannten Signatur der Stufensammlung getaggt \u2014 <b>stages signature<\/b>, \u2014 die verallgemeinernd f\u00fcr alle Stufen des Images ist.<\/p>\n<p>Jedes Image aus der Konfiguration <code>werf.yaml<\/code> wird im Allgemeinen eine solche Signatur und damit einen entsprechenden Docker-Tag haben.<\/p>\n<p>Die Stufensignatur l\u00f6st alle genannten Probleme:<\/p>\n<ul>\n<li> Ist resistent gegen leere Git-Commits.<\/li>\n<li> Ist resistent gegen Git-Commits, die Dateien ver\u00e4ndern, die nicht relevant f\u00fcr das Image sind.<\/li>\n<li> F\u00fchrt nicht zu einem Problem mit der \u00dcberschreibung der aktuellen Version des Images beim Neustart von Builds f\u00fcr alte Git-Commits des Branches.<\/li>\n<\/ul>\n<p>\nDies ist jetzt die empfohlene Tagging-Strategie und wird standardm\u00e4\u00dfig in werf f\u00fcr alle CI-Systeme verwendet.<\/p>\n<h2>Wie man es in werf aktiviert und verwendet<\/h2>\n<p>\nDie entsprechende Option wurde im Befehl hinzugef\u00fcgt <code>werf publish<\/code>: <code>--tag-by-stages-signature=true|false<\/code><\/p>\n<p>In der CI-System wird die Tagging-Strategie durch den Befehl festgelegt <code>werf ci-env<\/code>. Zuvor wurde daf\u00fcr der Parameter definiert <code>werf ci-env --tagging-strategy=tag-or-branch<\/code>. Wenn nun <code>werf ci-env --tagging-strategy=stages-signature<\/code> oder diese Option weggelassen wird, verwendet werf standardm\u00e4\u00dfig die Tagging-Strategie <code>stages-signature<\/code>. Der Befehl <code>werf ci-env<\/code> stellt automatisch die erforderlichen Flags f\u00fcr den Befehl ein <code>werf build-and-publish<\/code> (oder <code>werf publish<\/code>), daher m\u00fcssen f\u00fcr diese Befehle keine zus\u00e4tzlichen Optionen angegeben werden.<\/p>\n<p>Beispielsweise der Befehl:<\/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 kann die folgenden Images erstellen:<\/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>\nHier <code>4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d<\/code> \u2014 das ist die Signatur der Stufen des Images <code>backend<\/code>, und <code>f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6<\/code> \u2014 Signatur der Stufen des Images <code>frontend<\/code>.<\/p>\n<p>Bei der Verwendung spezieller Funktionen <code>werf_container_image<\/code> und <code>werf_container_env<\/code> muss im Helm-Template nichts ge\u00e4ndert werden: diese Funktionen generieren automatisch die korrekten Image-Namen.<\/p>\n<p>Beispielkonfiguration im CI-System:<\/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>\nWeitere Informationen zur Konfiguration finden Sie in der Dokumentation:<\/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\">Handbuch \u2192 Ver\u00f6ffentlichung (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\">Arbeiten mit CI\/CD \u2192 Allgemeine Informationen \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\">Integration mit GitLab CI\/CD \u2192 .gitlab-ci.yml<\/a><\/noindex>.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Insgesamt<\/h2>\n<p><\/p>\n<ul>\n<li> Neue Option <code>werf publish --tag-by-stages-signature=true|false<\/code>.<\/li>\n<li> Neuer Wert der Option <code>werf ci-env --tagging-strategy=stages-signature|tag-or-branch<\/code> (wenn nicht angegeben, wird standardm\u00e4\u00dfig <code>stages-signature<\/code>).<\/li>\n<li> Wenn zuvor Tags nach Git-Commits verwendet wurden (<code>WERF_TAG_GIT_COMMIT<\/code> oder die Option <code>werf publish --tag-git-commit COMMIT<\/code>), muss unbedingt auf die Tagging-Strategie umgestellt werden. <i>stages-signature<\/i>.<\/li>\n<li> Neue Projekte sollten sofort auf das neue Tagging-System umgestellt werden.<\/li>\n<li> Alte Projekte sollten beim \u00dcbergang zu werf 1.1 idealerweise auf das neue Tagging-System umgestellt werden, jedoch wird die alte <i>tag-or-branch<\/i> weiterhin unterst\u00fctzt.<\/li>\n<\/ul>\n<p>\nContent-basiertes Tagging l\u00f6st alle im Artikel angesprochenen Probleme:<\/p>\n<ul>\n<li> Widerstandsverm\u00f6gen des Docker-Tag-Namens gegen leere Git-Commits.<\/li>\n<li> Widerstandsverm\u00f6gen des Docker-Tag-Namens gegen Git-Commits, die irrelevante Dateien f\u00fcr das Image \u00e4ndern.<\/li>\n<li> F\u00fchrt nicht zu Problemen beim \u00dcberschreiben der aktuellen Version des Images bei einem Neustart von Builds f\u00fcr alte Git-Commits in Git-Zweigen.<\/li>\n<\/ul>\n<p>\nNutzen Sie es! Und vergessen Sie nicht, uns auf <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">GitHub<\/a><\/noindex>, um ein Issue zu erstellen oder ein bereits bestehendes zu finden, einen Daumen hoch zu geben, einen PR zu erstellen oder einfach den Fortschritt des Projekts zu beobachten.<\/p>\n<h2>P.S.<\/h2>\n<p>\nLesen Sie auch in unserem Blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/493170\/\">Release von werf 1.1: Verbesserungen im Assembler heute und Pl\u00e4ne f\u00fcr die Zukunft<\/a><\/noindex>\u00bb<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/481306\/\">Wir pr\u00e4sentieren werf 1.0 stable: was hat das mit GitOps, Status und Pl\u00e4nen zu tun?<\/a><\/noindex>\u00bb<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/460351\/\">Release des Konsolen-XMPP\/Jabber-Clients profanity 0.7.0<\/a><\/noindex>\u00bb;<\/li>\n<li> Eine Serie von Notizen zu neuen Funktionen in werf:\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/476646\/\">3-Wege-Merge in werf: Deployment in Kubernetes mit Helm \u201eauf Steroiden\u201c<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/468049\/\">Verwendung von werf zum Bereitstellen komplexer Helm-Charts<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465131\/\">Unterst\u00fctzung von Monorepo und Multirepo in werf und was hat das mit Docker Registry zu tun<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/463613\/\">Docker-Images in werf k\u00f6nnen jetzt auch mit einem normalen Dockerfile gebaut werden.<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>Quelle: <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.2 - 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\/de\/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.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\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\/de\/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\udd47Inhaltsbasierte Tagging im werf-Builder: Warum und wie funktioniert das? | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/de\/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":"de_DE","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\/de\/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\/de\/wp-json\/wp\/v2\/posts\/76769","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=76769"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/76769\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/76770"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=76769"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=76769"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=76769"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}