{"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\/da\/blog\/administrirovanie\/content-based-tagging-v-sborshhike-werf-zachem-i-kak-eto-rabotaet","title":{"rendered":"Content-based tagging i werf-builder: hvorfor og hvordan det fungerer?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Content-based tagging i werf-builder: hvorfor og hvordan det fungerer?\" 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 vores GitOps CLI-v\u00e6rkt\u00f8j med \u00e5ben kildekode til at bygge og levere applikationer til Kubernetes. I <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/493170\/\">udgivelsen v1.1<\/a><\/noindex> blev der introduceret en ny funktion i billedbyggeren: tagging af billeder baseret p\u00e5 indhold eller <i>content-based tagging<\/i>. Indtil nu har den typiske tagging-schema i werf antaget tagging af Docker-billeder efter Git-tag, Git-gren eller Git-commit. Men alle disse ordninger har ulemper, som den nye tagging-strategi fuldst\u00e6ndigt l\u00f8ser. Flere detaljer om dette og hvad der er s\u00e5 godt ved det \u2014 l\u00e6ngst nede.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Udrulning af en suite af mikrotjenester fra et enkelt Git-repositorium<\/h2>\n<p>\nDet er ofte tilf\u00e6ldet, at en applikation er opdelt i mange mere eller mindre uafh\u00e6ngige tjenester. Udgivelser af disse tjenester kan finde sted uafh\u00e6ngigt: p\u00e5 \u00e9n gang kan \u00e9n eller flere tjenester blive udgivet, mens de \u00f8vrige forts\u00e6tter med at fungere uden \u00e6ndringer. Men set fra et opbevarings- og projektledelsesperspektiv er det mere praktisk at holde s\u00e5danne apptjenester i et enkelt repositorium.<\/p>\n<p>Der er tilf\u00e6lde, hvor tjenesterne faktisk er uafh\u00e6ngige og ikke relateret til \u00e9n applikation. I s\u00e5 fald vil de v\u00e6re placeret i separate projekter, og deres udgivelse vil finde sted gennem separate CI\/CD-processer i hvert af projekterne.<\/p>\n<p>Men i praksis opdeler udviklere ofte en samlet applikation i flere mikrotjenester, men at oprette et separat repositorium og projekt for hver\u2026 \u2014 ville v\u00e6re klart overkill. Det er netop dette scenarie, der vil blive omtalt n\u00e6ste gang: flere s\u00e5danne mikrotjenester ligger i et enkelt projektrepositorium, og udgivelserne sker gennem en samlet proces i CI\/CD.<\/p>\n<h3>Tagging efter Git-gren og Git-tag<\/h3>\n<p>\nAntag, at der anvendes den mest udbredte tagging-strategi \u2014 <i>tag-or-branch<\/i>. For Git-grene bliver billederne tagget med grennavnet, for \u00e9n gren eksisterer der p\u00e5 et givet tidspunkt kun \u00e9t offentliggjort billede med dette grennavn. For Git-tags bliver billederne tagget tilsvarende med tagnavnet.<\/p>\n<p>N\u00e5r der oprettes et nyt Git-tag \u2014 for eksempel n\u00e5r en ny version udgives \u2014 vil der for alle billeder i projektet i Docker Registry blive oprettet et nyt Docker-tag:<\/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>\nDisse nye billednavne overf\u00f8res via Helm-skabeloner til Kubernetes-konfigurationen. Ved lancering af deployment med kommandoen <code>werf deploy<\/code> opdateres feltet <code>billede<\/code> i Kubernetes-ressourcemanifesterne, hvilket resulterer i en genstart af de tilsvarende ressourcer p\u00e5 grund af det \u00e6ndrede billednavn.<\/p>\n<p><b>Problemet<\/b>: i tilf\u00e6lde af at indholdet fra den forrige version (Git-tag) faktisk ikke har \u00e6ndret sig, men kun dens Docker-tag, sker der <i>en un\u00f8dvendig<\/i> genstart af denne applikation, og der kan derfor opst\u00e5 visse problemer. Selvom der ikke var nogen reelle grunde til at udf\u00f8re denne genstart.<\/p>\n<p>Som f\u00f8lge heraf, under den nuv\u00e6rende tagging-ordning, er det n\u00f8dvendigt at oprette flere separate Git-repositorier, og der opst\u00e5r problemer med at organisere deployment af disse forskellige repositories. Generelt set bliver en s\u00e5dan ordning overbelastet og kompleks. Det er bedre at samle mange tjenester i et enkelt repository og oprette s\u00e5danne Docker-tags, s\u00e5 der ikke sker un\u00f8dvendige genstarter.<\/p>\n<h3>Tagging efter Git-commit<\/h3>\n<p>\nI werf findes der ogs\u00e5 en tagging-strategi, der er relateret til Git-commits.<\/p>\n<p>Git-commit er en identifikator for indholdet af Git-repositoriet og afh\u00e6nger af historikken for \u00e6ndringer i filer i Git-repositoriet, s\u00e5 det virker logisk at bruge det til tagging af billeder i Docker Registry.<\/p>\n<p>Dog har tagging efter Git-commit de samme ulemper som tagging efter Git-grene eller Git-tags:<\/p>\n<ul>\n<li> Der kunne v\u00e6re oprettet et tomt commit, som ikke \u00e6ndrer filer, og Docker-tagget for billedet vil blive \u00e6ndret.<\/li>\n<li> Der kunne v\u00e6re oprettet et merge-commit, som ikke \u00e6ndrer filer, og Docker-tagget for billedet vil blive \u00e6ndret.<\/li>\n<li> Der kunne v\u00e6re oprettet et commit, som \u00e6ndrer de filer i Git, der ikke importeres i billedet, og Docker-tagget for billedet vil igen blive \u00e6ndret.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Tagging efter navnet p\u00e5 Git-grenen afspejler ikke billedversionen<\/h2>\n<p>\nDer er ogs\u00e5 et andet problem forbundet med tagging-strategien baseret p\u00e5 Git-grene.<\/p>\n<p>Tagging efter grenens navn fungerer s\u00e5 l\u00e6nge, som commits af denne gren bliver samlet i kronologisk r\u00e6kkef\u00f8lge.<\/p>\n<p>Hvis brugeren i den nuv\u00e6rende plan k\u00f8rer en genopbygning af et gammelt commit, der er relateret til en bestemt gren, vil werf overskrive billedet med den nyopbyggede version af billedet for det gamle commit via den relevante Docker-tag. Deployments, der bruger denne tag, risikerer fra dette tidspunkt at tr\u00e6kke en anden version af billedet under genstarten af pods, hvilket medf\u00f8rer, at vores applikation mister forbindelsen til CI-systemet og bliver desynkroniseret.<\/p>\n<p>Desuden, ved f\u00f8lgende push til en gren med kort tidsinterval imellem, kan det gamle commit blive bygget senere end det nyere: den gamle version af billedet vil overskrive den nye i henhold til Git-grenen. S\u00e5danne problemer kan h\u00e5ndteres af CI\/CD-systemet (f.eks. i GitLab CI starter en pipeline for den seneste serie af commits). Dog underst\u00f8tter ikke alle systemer dette, og der b\u00f8r findes en mere p\u00e5lidelig metode til at forebygge s\u00e5dan en fundamental problem.<\/p>\n<h2>Hvad er content-based tagging?<\/h2>\n<p>\nS\u00e5 hvad er content-based tagging \u2014 tagging af billeder baseret p\u00e5 indhold.<\/p>\n<p>Docker-tags oprettes ikke ved hj\u00e6lp af Git-primitiver (Git-gren, Git-tag...), men ved hj\u00e6lp af en kontrolsum, der er relateret til:<\/p>\n<ul>\n<li> <i>indholdet af billedet<\/i>. Tag-id'et af billedet reflekterer dets indhold. Ved opbygningen af en ny version \u00e6ndres dette id ikke, hvis filerne i billedet ikke har \u00e6ndret sig;<\/li>\n<li> <i>historikken for opbygningen af dette billede i Git<\/i>. Billeder, der er relateret til forskellige Git-grene og forskellig opbygningshistorik gennem werf, vil have forskellige tag-id'er.<\/li>\n<\/ul>\n<p>\nSom et s\u00e5dant tag-id fungerer den s\u00e5kaldte <b>signatur af billedet i stadier<\/b>.<\/p>\n<p>Hvert billede best\u00e5r af et s\u00e6t stadier: <code>fra<\/code>, <code>f\u00f8r-installation<\/code>, <code>git-arkiv<\/code>, <code>installation<\/code>, <code>importer-efter-installation<\/code>, <code>f\u00f8r-ops\u00e6tning<\/code>,\u2026 <code>git-seneste-patch<\/code> osv. Hver fase har et id, der reflekterer dens indhold, \u2014 <b>fase-signatur<\/b> <i>(stage signature)<\/i>.<\/p>\n<p>Det endelige billede, der best\u00e5r af disse faser, tagges med den s\u00e5kaldte signatur af s\u00e6ttet af disse faser \u2014 <b>stages signature<\/b>, \u2014 som er generaliserende for alle faser af billedet.<\/p>\n<p>Hver billede fra konfigurationen <code>werf.yaml<\/code> vil generelt set have sin egen s\u00e5dan signatur, og dermed et Docker-tag.<\/p>\n<p>Signaturen af stadierne l\u00f8ser alle de n\u00e6vnte problemer:<\/p>\n<ul>\n<li> Den er modstandsdygtig over for tomme Git-commits.<\/li>\n<li> Den er modstandsdygtig over for Git-commits, der \u00e6ndrer filer, som ikke er relevante for billedet.<\/li>\n<li> Den medf\u00f8rer ikke en problem med at overskrive den aktuelle version af billedet, n\u00e5r man genstarter opbygninger for gamle Git-commits i grenen.<\/li>\n<\/ul>\n<p>\nNu er dette den anbefalede tagging-strategi, som bruges som standard i werf for alle CI-systemer.<\/p>\n<h2>Hvordan man aktiverer og bruger det i werf<\/h2>\n<p>\nDen relevante mulighed er tilg\u00e6ngelig for kommandoen <code>werf publish<\/code>: <code>--tag-by-stages-signature=true|false<\/code><\/p>\n<p>I CI-systemet angives tagging-strategien med kommandoen <code>werf ci-env<\/code>. Tidligere blev der angivet en parameter for den <code>werf ci-env --tagging-strategy=tag-or-branch<\/code>. Nu, hvis du angiver <code>werf ci-env --tagging-strategy=stages-signature<\/code> eller ikke angiver denne mulighed, vil werf som standard bruge tagging-strategien <code>stages-signature<\/code>. Kommandoen <code>werf ci-env<\/code> vil automatisk s\u00e6tte de n\u00f8dvendige flag for kommandoen <code>werf build-and-publish<\/code> (eller <code>werf publish<\/code>), s\u00e5 der er ikke behov for at angive yderligere muligheder for disse kommandoer.<\/p>\n<p>For eksempel, kommandoen:<\/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 oprette f\u00f8lgende billeder:<\/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>\nHer <code>4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d<\/code> \u2014 er billedets stages-signatur <code>backend<\/code>, og <code>f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6<\/code> \u2014 billedets stages-signatur <code>frontend<\/code>.<\/p>\n<p>N\u00e5r man bruger s\u00e6rlige funktioner <code>werf_container_image<\/code> og <code>werf_container_env<\/code> i Helm-skabeloner kr\u00e6ves der ikke \u00e6ndringer: disse funktioner vil automatisk generere de korrekte billednavne.<\/p>\n<p>Eksempelkonfiguration i CI-systemet:<\/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>\nMere information om konfigurationen er tilg\u00e6ngelig i dokumentationen:<\/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\">H\u00e5ndbog \u2192 Publikation (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\">Arbejde med CI\/CD \u2192 Overblik \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 med GitLab CI\/CD \u2192 .gitlab-ci.yml<\/a><\/noindex>.<\/li>\n<\/ul>\n<p><\/p>\n<h2>I alt<\/h2>\n<p><\/p>\n<ul>\n<li> Den nye mulighed <code>werf publish --tag-by-stages-signature=true|false<\/code>.<\/li>\n<li> Den nye v\u00e6rdi for indstillingen <code>werf ci-env --tagging-strategy=stages-signature|tag-or-branch<\/code> (hvis ikke angivet, vil standarden v\u00e6re <code>stages-signature<\/code>).<\/li>\n<li> Hvis der tidligere blev brugt taggingmuligheder baseret p\u00e5 Git-commits (<code>WERF_TAG_GIT_COMMIT<\/code> eller indstillingen <code>werf publish --tag-git-commit COMMIT<\/code>), s\u00e5 skal man bestemt skifte til tagging-strategien <i>stages-signature<\/i>.<\/li>\n<li> Nye projekter b\u00f8r straks skiftes til den nye tagging-scheme.<\/li>\n<li> Gamle projekter b\u00f8r ved opgradering til werf 1.1 skiftes til den nye tagging-scheme, men den gamle <i>tag-or-branch<\/i> underst\u00f8ttes stadig.<\/li>\n<\/ul>\n<p>\nContent-based tagging l\u00f8ser alle de problemer, der er beskrevet i artiklen:<\/p>\n<ul>\n<li> Modstandsdygtighed af Docker-tagget mod tomme Git-commits.<\/li>\n<li> Modstandsdygtighed af Docker-tagget mod Git-commits, der \u00e6ndrer irrelevante filer for billedet.<\/li>\n<li> For\u00e5rsager ikke problemer med at overskrive den aktuelle version af billedet ved genstart af bygninger for gamle Git-commits i Git-grene.<\/li>\n<\/ul>\n<p>\nBrug det! Og glem ikke at bes\u00f8ge os p\u00e5 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">GitHub<\/a><\/noindex>, for at oprette et issue eller finde et eksisterende, give et plus, oprette en PR eller blot f\u00f8lge udviklingen af projektet.<\/p>\n<h2>P.S.<\/h2>\n<p>\nL\u00e6s ogs\u00e5 p\u00e5 vores blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/493170\/\">Werf 1.1 udgivelse: forbedringer i samlerens dag i dag og planer for fremtiden<\/a><\/noindex>\u00bb<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/481306\/\">Vi pr\u00e6senterer werf 1.0 stable: hvad har GitOps, status og planer at g\u00f8re med det?<\/a><\/noindex>\u00bb<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/460351\/\">werf \u2014 vores v\u00e6rkt\u00f8j til CI\/CD i Kubernetes (oversigt og video af pr\u00e6sentationen)<\/a><\/noindex>\u00bb;<\/li>\n<li> Cykelnotater om nyheder i werf:\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/476646\/\">3-vejs sammensmeltning i werf: deployment til Kubernetes med Helm \"p\u00e5 steroider\"<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/468049\/\">Brug af werf til implementering af komplekse Helm-diagrammer<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465131\/\">Underst\u00f8ttelse af monorepo og multirepo i werf og hvad Docker Registry har at g\u00f8re med det<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/463613\/\">Byg Docker-billeder i werf kan nu ogs\u00e5 g\u00f8res med en almindelig Dockerfile<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>Kilde: <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\/da\/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=\"da_DK\" \/>\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\/da\/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\udd47Indholdsbaseret tagging i samleren werf: hvorfor og hvordan det fungerer? | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/da\/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":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/76769","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=76769"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/76769\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/76770"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=76769"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=76769"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=76769"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}