{"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\/nl\/blog\/administrirovanie\/content-based-tagging-v-sborshhike-werf-zachem-i-kak-eto-rabotaet","title":{"rendered":"Content-gebaseerde tagging in de werf-builder: waarom en hoe werkt dit?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Content-gebaseerde tagging in de werf-builder: waarom en hoe werkt dit?\" 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 onze GitOps CLI-tool met open source voor het bouwen en leveren van applicaties in Kubernetes. In <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/493170\/\">release v1.1<\/a><\/noindex> is een nieuwe functie gepresenteerd in de image builder: tags voor images op basis van inhoud of <i>content-based tagging<\/i>. Tot nu toe was de typische tagging-strategie in werf het taggen van Docker-images op git-tag, git-branch of git-commit. Maar al deze schema's hebben nadelen die volledig worden opgelost door de nieuwe tagging-strategie. Meer details daarover en wat het zo goed maakt \u2014 verderop.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>De uitrol van een set microservices vanuit \u00e9\u00e9n Git-repository<\/h2>\n<p>\nHet komt vaak voor dat een applicatie is opgesplitst in meerdere meer of minder onafhankelijke services. De releases van deze services kunnen onafhankelijk plaatsvinden: in \u00e9\u00e9n keer kan \u00e9\u00e9n of meerdere services worden vrijgegeven, terwijl de andere zonder enige wijziging moeten blijven werken. Maar vanuit het oogpunt van codemanagement en projectbeheer is het handiger om dergelijke services in \u00e9\u00e9n repository te houden.<\/p>\n<p>Er zijn situaties waarin services echt onafhankelijk zijn en niet zijn verbonden aan \u00e9\u00e9n applicatie. In dat geval zullen ze zich in aparte projecten bevinden en zal hun release via afzonderlijke CI\/CD-processen in elk van de projecten plaatsvinden.<\/p>\n<p>In de praktijk splitsen ontwikkelaars vaak een enkele applicatie op in verschillende microservices, maar het aanmaken van een aparte repository en project voor elk\u2026 \u2014 is duidelijk overkill. Dit artikel behandelt precies deze situatie: verschillende microservices bevinden zich in \u00e9\u00e9n enkele projectrepository en releases vinden plaats via \u00e9\u00e9n proces in CI\/CD.<\/p>\n<h3>Taggen op Git-branch en Git-tag<\/h3>\n<p>\nLaten we de meest voorkomende tagging-strategie gebruiken \u2014 <i>tag-or-branch<\/i>. Voor Git-branches worden images getagd met de naam van de branch, voor \u00e9\u00e9n branch bestaat er op elk moment slechts \u00e9\u00e9n gepubliceerde image met de naam van deze branch. Voor Git-tags worden images overeenkomstig de naam van de tag getagd.<\/p>\n<p>Bij het aanmaken van een nieuwe Git-tag \u2014 bijvoorbeeld bij de uitgave van een nieuwe versie \u2014 zal voor alle images van het project in de Docker Registry een nieuwe Docker-tag worden aangemaakt:<\/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>\nDeze nieuwe afbeeldingsnamen worden via Helm-templates in de configuratie van Kubernetes opgenomen. Bij het uitvoeren van de deployment met het commando <code>werf deploy<\/code> wordt het veld <code>afbeelding<\/code> in de manifesten van Kubernetes-resources bijgewerkt en worden de bijbehorende resources opnieuw opgestart vanwege de gewijzigde afbeeldingsnaam.<\/p>\n<p><b>Probleem<\/b>: in het geval dat de inhoud van de afbeelding niet is gewijzigd sinds de vorige release (Git-tag), maar alleen de Docker-tag, vindt er <i>onnodig<\/i> herstarten van deze applicatie plaats en kan er dus enige downtime optreden. Hoewel er geen echte redenen waren om deze herstart uit te voeren.<\/p>\n<p>Als gevolg hiervan moet bij de huidige tagstrategie verschillende aparte Git-repositories worden opgezet en rijst het probleem van de organisatie van de releases van deze verschillende repositories. Over het algemeen lijkt deze aanpak overbelast en complex. Het is beter om meerdere services in \u00e9\u00e9n enkele repository te combineren en Docker-tags te cre\u00ebren om onn\u00f3dige herstarts te voorkomen.<\/p>\n<h3>Tagging op basis van Git-commits<\/h3>\n<p>\nIn werf is er ook een taggingstrategie die verband houdt met Git-commits.<\/p>\n<p>Een Git-commit is een identificatie van de inhoud van de Git-repository en is afhankelijk van de bewerkingsgeschiedenis van bestanden in de Git-repository, daarom lijkt het logisch om deze te gebruiken voor het taggen van afbeeldingen in de Docker Registry.<\/p>\n<p>Echter, tagging op basis van Git-commits heeft dezelfde nadelen als tagging op basis van Git-branches of Git-tags:<\/p>\n<ul>\n<li> Er had een lege commit kunnen worden gemaakt die geen bestanden wijzigt, maar de Docker-tag van de afbeelding zal worden gewijzigd.<\/li>\n<li> Er had een merge-commit kunnen worden gemaakt die geen bestanden wijzigt, maar de Docker-tag van de afbeelding zal worden gewijzigd.<\/li>\n<li> Er had een commit kunnen worden gemaakt die de bestanden in Git wijzigt die niet in de afbeelding zijn ge\u00efmporteerd, en de Docker-tag van de afbeelding zal opnieuw worden gewijzigd.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Tagging op basis van de naam van de Git-branch weerspiegelt niet de versie van de afbeelding.<\/h2>\n<p>\nEr is ook nog een probleem dat verband houdt met de taggingstrategie op basis van Git-branches.<\/p>\n<p>Tagging op basis van de naam van de branch werkt zolang de commits van deze branch sequentieel in chronologische volgorde worden verzameld.<\/p>\n<p>Als een gebruiker in het huidige schema een heropbouw van een oude commit, die met een bepaalde branch is verbonden, start, dan zal werf de afbeelding onder de bijbehorende Docker-tag overschrijven met de opnieuw gebouwde versie van de afbeelding voor de oude commit. Deployment's die deze tag gebruiken, lopen vanaf dat moment het risico dat ze tijdens het herstarten van de pods een andere versie van de afbeelding pullen, wat ertoe kan leiden dat onze applicatie de verbinding met het CI-systeem verliest en desynchroniseert.<\/p>\n<p>Bovendien kan bij opeenvolgende pushs naar dezelfde branch met een korte tijdsinterval tussen hen, een oude commit later worden opgebouwd dan een nieuwere: de oude versie van de afbeelding overschrijft de nieuwe op de Git-branch tag. Dergelijke problemen kunnen worden opgelost door een CI\/CD-systeem (bijvoorbeeld in GitLab CI wordt voor een reeks commits de pipeline van de laatste gestart). Niet alle systemen ondersteunen dit en er moet een betrouwbaardere manier zijn om zo'n fundamenteel probleem te voorkomen.<\/p>\n<h2>Wat is content-based tagging?<\/h2>\n<p>\nDus wat is content-based tagging - het taggen van afbeeldingen op basis van hun inhoud.<\/p>\n<p>Voor het maken van Docker-tags worden geen primitieve Git-elementen (Git-branch, Git-tag\u2026) gebruikt, maar een controlegetal dat gerelateerd is aan:<\/p>\n<ul>\n<li> <i>de inhoud van de afbeelding<\/i>. De tag-identificator van de afbeelding weerspiegelt zijn inhoud. Bij het samenstellen van een nieuwe versie verandert deze identificator niet, als de bestanden in de afbeelding niet zijn gewijzigd;<\/li>\n<li> <i>de geschiedenis van het cre\u00ebren van deze afbeelding in Git<\/i>. Afbeeldingen die zijn gekoppeld aan verschillende Git-branches en verschillende bouwgeschiedenissen via werf, zullen verschillende tag-identificatoren hebben.<\/li>\n<\/ul>\n<p>\nAls zo'n tag-identificator fungeert de zogenaamde <b>fase-signatuur van de afbeelding<\/b>.<\/p>\n<p>Elke afbeelding bestaat uit een set fasen: <code>van<\/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> enzovoort. Elke fase heeft een identificator die zijn inhoud weerspiegelt, - <b>de fase-signatuur<\/b> <i>(stage signature)<\/i>.<\/p>\n<p>De uiteindelijke afbeelding, die bestaat uit deze fasen, wordt getagd met de zogenaamde signatuur van deze set fasen - <b>stages signature<\/b>, - die een algemeen beeld geeft van alle fasen van de afbeelding.<\/p>\n<p>Elke afbeelding uit de configuratie <code>werf.yaml<\/code> zal in het algemeen zijn eigen zo'n signatuur hebben en bijgevolg een Docker-tag.<\/p>\n<p>De fase-signatuur lost al deze genoemde problemen op:<\/p>\n<ul>\n<li> Is resistent tegen lege Git-commits.<\/li>\n<li> Is resistent tegen Git-commits die bestanden wijzigen die niet relevant zijn voor de afbeelding.<\/li>\n<li> Veroorzaakt geen probleem met het overschrijven van de huidige versie van de afbeelding bij het opnieuw opstarten van builds voor oude Git-commits van de branch.<\/li>\n<\/ul>\n<p>\nDit is nu de aanbevolen taggingstrategie en wordt standaard gebruikt in werf voor alle CI-systemen.<\/p>\n<h2>Hoe in te schakelen en te gebruiken in werf<\/h2>\n<p>\nDe relevante optie is toegevoegd aan het commando <code>werf publish<\/code>: <code>--tag-by-stages-signature=true|false<\/code><\/p>\n<p>In het CI-systeem wordt de taggingstrategie ingesteld met het commando <code>werf ci-env<\/code>. Eerder werd hiervoor een parameter gedefinieerd <code>werf ci-env --tagging-strategy=tag-or-branch<\/code>. Nu, als je opgeeft <code>werf ci-env --tagging-strategy=stages-signature<\/code> of deze optie niet op te geven, zal werf standaard de tagging-strategie gebruiken <code>stages-signature<\/code>. De opdracht <code>werf ci-env<\/code> zal automatisch de benodigde vlaggen voor het commando instellen <code>werf build-and-publish<\/code> (of <code>werf publish<\/code>), dus er zijn geen extra opties nodig voor deze commando's.<\/p>\n<p>Bijvoorbeeld, het commando:<\/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 kan de volgende beelden aanmaken:<\/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 dit is de signature van de beeldfase <code>backend<\/code>, met behulp van 1 bit, gelijk aan 0, <code>f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6<\/code> \u2014 signature van de beeldfase <code>frontend<\/code>.<\/p>\n<p>Bij het gebruik van speciale functies <code>werf_container_image<\/code> en <code>werf_container_env<\/code> hoeven er in de Helm-sjablonen niets te worden gewijzigd: deze functies zullen automatisch de juiste namen voor de beelden genereren.<\/p>\n<p>Voorbeeldconfiguratie in het CI-systeem:<\/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>\nMeer informatie over de configuratie is beschikbaar in de documentatie:<\/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\">Handleiding \u2192 Publicatie (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\">Werken met CI\/CD \u2192 Algemene informatie \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\">Integratie met GitLab CI\/CD \u2192 .gitlab-ci.yml<\/a><\/noindex>.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Total<\/h2>\n<p><\/p>\n<ul>\n<li> Nieuwe optie <code>werf publish --tag-by-stages-signature=true|false<\/code>.<\/li>\n<li> Nieuwe waarde voor optie <code>werf ci-env --tagging-strategy=stages-signature|tag-or-branch<\/code> (als niet opgegeven, is het standaard <code>stages-signature<\/code>).<\/li>\n<li> Als eerder taggingopties op basis van Git-commits zijn gebruikt (<code>WERF_TAG_GIT_COMMIT<\/code> of optie <code>werf publish --tag-git-commit COMMIT<\/code>), dan moet de taggingstrategie worden gewijzigd <i>stages-signature<\/i>.<\/li>\n<li> Nieuwe projecten kunnen beter meteen worden omgeschakeld naar het nieuwe tagging-schema.<\/li>\n<li> Oude projecten die naar werf 1.1 worden overgezet, moeten idealiter worden omgeschakeld naar het nieuwe tagging-schema, maar het oude <i>tag-or-branch<\/i> wordt nog steeds ondersteund.<\/li>\n<\/ul>\n<p>\nContent-based tagging lost alle in het artikel besproken problemen op:<\/p>\n<ul>\n<li> De robuustheid van de Docker-tagnaam tegen lege Git-commits.<\/li>\n<li> De robuustheid van de Docker-tagnaam tegen Git-commits die irrelevante bestanden voor het beeld wijzigen.<\/li>\n<li> Leidt niet tot problemen met het overschrijven van de actuele versie van het beeld bij het opnieuw starten van builds voor oude Git-commits voor Git-takken.<\/li>\n<\/ul>\n<p>\nGebruik het! En vergeet niet om bij ons te kijken op <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">GitHub<\/a><\/noindex>, om een issue te cre\u00ebren of een bestaand te vinden, een plus te geven, een PR te maken of gewoon het project te volgen.<\/p>\n<h2>P.S.<\/h2>\n<p>\nLees ook op onze blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/493170\/\">Release van werf 1.1: verbeteringen in de builder vandaag en plannen voor de toekomst<\/a><\/noindex>\u00bb<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/481306\/\">We presenteren werf 1.0 stable: wat heeft GitOps ermee te maken, status en plannen<\/a><\/noindex>\u00bb<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/460351\/\">werf \u2014 onze tool voor CI\/CD in Kubernetes (overzicht en video van de presentatie)<\/a><\/noindex>\u00bb;<\/li>\n<li> Een cyclus van notities over de innovaties in werf:\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/476646\/\">3-way merge in werf: deployen in Kubernetes met Helm \"op stero\u00efden\"<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/468049\/\">Het gebruik van werf voor het uitrollen van complexe Helm-charts<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465131\/\">Ondersteuning voor monorepo en multirepo in werf en wat Docker Registry hiermee te maken heeft<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/463613\/\">Docker-images kunnen nu ook met werf worden gebouwd met een gewone Dockerfile.<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>Bron: <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.3 - 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\/nl\/blog\/administrirovanie\/content-based-tagging-v-sborshhike-werf-zachem-i-kak-eto-rabotaet\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"nl_NL\" \/>\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\/nl\/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 in de werf-builder: waarom en hoe werkt het? | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/nl\/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":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/76769","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=76769"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/76769\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/76770"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=76769"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=76769"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=76769"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}