{"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\/en\/blog\/administrirovanie\/content-based-tagging-v-sborshhike-werf-zachem-i-kak-eto-rabotaet","title":{"rendered":"Content-based tagging in the werf collector: why and how it works?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Content-based tagging in the werf collector: why and how it works?\" 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 our open-source GitOps CLI utility for building and delivering applications to Kubernetes. In <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/493170\/\">release v1.1<\/a><\/noindex> a new feature was introduced in the image builder: <i>content-based tagging<\/i>. Until now, the typical tagging scheme in werf assumed tagging Docker images by Git tag, Git branch, or Git commit. However, all these schemes have disadvantages that are completely resolved by the new tagging strategy. Details about it and what makes it so good are below.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Deployment of microservices from a single Git repository<\/h2>\n<p>\nIt's often the case that an application is divided into many more or less independent services. Releases of these services can occur independently: one or several services can be released at once, while others should continue to operate without any changes. However, from the perspective of code storage and project management, it is convenient to keep such application services in a single repository.<\/p>\n<p>There are situations where services are truly independent and not related to a single application. In this case, they will be located in separate projects and their release will be carried out through separate CI\/CD processes in each of the projects.<\/p>\n<p>However, in reality, developers often break a single application into several microservices, but creating a separate repository and project for each one is clearly overkill. This discussion will focus on this situation: several such microservices reside in a single project repository, and releases occur through a unified process in CI\/CD.<\/p>\n<h3>Tagging by Git branch and Git tag<\/h3>\n<p>\nLet's assume the most common tagging strategy is <i>tag-or-branch<\/i>. For Git branches, images are tagged by the branch name; at any one time, there can be only one published image for that branch name. For Git tags, images are tagged by the tag name respectively.<\/p>\n<p>When a new Git tag is created \u2014 for example, when a new version is released \u2014 a new Docker tag will be created for all project images in 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>\nThese new image names are integrated into the Kubernetes configuration via Helm templates. When the deployment command is executed, <code>werf deploy<\/code> the field is updated <code>image<\/code> in the Kubernetes resource manifests, and the corresponding resources are restarted due to the changed image name.<\/p>\n<p><b>The Problem<\/b>: in cases where the content of the image hasn't actually changed from the previous release (Git tag), but only its Docker tag has, <i>an unnecessary<\/i> restart of this application occurs, potentially leading to some downtime, even though there was no real reason to initiate that restart.<\/p>\n<p>As a result, with the current tagging scheme, multiple separate Git repositories need to be maintained, raising the issue of how to organize the deployment of these multiple repositories. Overall, this scheme becomes overloaded and complex. It\u2019s better to consolidate many services into a single repository and create Docker tags to avoid unnecessary restarts.<\/p>\n<h3>Tagging by Git commit<\/h3>\n<p>\nWerf also offers a tagging strategy related to Git commits.<\/p>\n<p>A Git commit serves as the identifier for the content of the Git repository and depends on the history of file changes in the Git repository, so it seems logical to use it for tagging images in the Docker Registry.<\/p>\n<p>However, tagging by Git commit has the same drawbacks as tagging by Git branches or Git tags:<\/p>\n<ul>\n<li> An empty commit could have been created that does not change any files, but the Docker image tag would still be altered.<\/li>\n<li> A merge commit could have been created that does not change files, but the Docker image tag would still be altered.<\/li>\n<li> A commit could alter files in Git that are not included in the image, and again the Docker image tag would be changed.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Tagging by Git branch name does not reflect the version of the image.<\/h2>\n<p>\nThere is yet another issue related to the tagging strategy by Git branches.<\/p>\n<p>Tagging by branch name works as long as the commits in that branch are collected sequentially in chronological order.<\/p>\n<p>If the user initiates a rebuild of an old commit associated with a certain branch in the current scheme, werf will overwrite the image with the newly built version of the image for the old commit under the corresponding Docker tag. Deployments using this tag will then risk pulling a different version of the image during pod restarts, resulting in our application losing its connection to the CI system and becoming out of sync.<\/p>\n<p>Moreover, during consecutive pushes to one branch with a short time interval between them, an older commit may be processed later than a newer one: the old image version can overwrite the new one by the Git branch tag. Such problems can be addressed by a CI\/CD system (for example, in GitLab CI, a pipeline for a series of commits is triggered for the last one). However, not all systems support this, and there should be a more reliable way to prevent such a fundamental issue.<\/p>\n<h2>What is content-based tagging?<\/h2>\n<p>\nSo, what is content-based tagging \u2014 tagging images based on content.<\/p>\n<p>Docker tags are created not using Git primitives (Git branch, Git tag, etc.), but rather a checksum associated with:<\/p>\n<ul>\n<li> <i>the image content<\/i>. The image tag identifier reflects its content. When building a new version, this identifier will remain unchanged if no files in the image were modified;<\/li>\n<li> <i>the history of the image's creation in Git<\/i>. Images associated with different Git branches and different build histories via werf will have different tag identifiers.<\/li>\n<\/ul>\n<p>\nAs such a tag identifier, the so-called <b>stage signature<\/b>.<\/p>\n<p>is used. <code>from<\/code>, <code>Each image consists of a set of stages:<\/code>, <code>before-install<\/code>, <code>install<\/code>, <code>git-archive<\/code>, <code>imports-after-install<\/code>,\u2026 <code>before-setup<\/code> git-latest-patch <b>etc. Each stage has an identifier reflecting its content \u2014<\/b> <i>stage signature<\/i>.<\/p>\n<p>(stage signature) <b>The final image, consisting of these stages, is tagged by the so-called signature of the set of these stages \u2014<\/b>stages signature<\/p>\n<p>, which generalizes all the stages of the image. <code>werf.yaml<\/code> Each image from the configuration<\/p>\n<p>will generally have its own such signature and, accordingly, Docker tag.<\/p>\n<ul>\n<li> The stage signature resolves all the mentioned issues:<\/li>\n<li> It is resilient to empty Git commits.<\/li>\n<li> It is resilient to Git commits that change files irrelevant to the image.<\/li>\n<\/ul>\n<p>\nIt avoids the problem of overwriting the current image version when restarting builds for older Git commits of the branch.<\/p>\n<h2>This is now the recommended tagging strategy and is used by default in werf for all CI systems.<\/h2>\n<p>\nHow to enable and use in werf <code>werf publish<\/code>: <code>The relevant option appeared in the command<\/code><\/p>\n<p>--tag-by-stages-signature=true|false <code>In the CI system, the tagging strategy is set by the command<\/code>werf ci-env. <code>Previously, a parameter was defined for it<\/code>werf ci-env --tagging-strategy=tag-or-branch. <code>Now, if specified, it is changed to<\/code> if you do not specify this option, werf will default to using the tagging strategy <code>stages-signature<\/code>. The command <code>In the CI system, the tagging strategy is set by the command<\/code> will automatically set the necessary flags for the command <code>werf build-and-publish<\/code> (or <code>werf publish<\/code>), so no additional options need to be specified for these commands.<\/p>\n<p>For example, the command:<\/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... can create the following images:<\/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>\nHere <code>4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d<\/code> \u2014 this is the stage signature of the image <code>backend<\/code>, and <code>f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6<\/code> \u2014 this is the stage signature of the image <code>frontend<\/code>.<\/p>\n<p>When using special functions <code>werf_container_image<\/code> and <code>werf_container_env<\/code> no changes are required in Helm templates: these functions will automatically generate correct image names.<\/p>\n<p>Example configuration in the 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>\nMore information on configuration is available in the documentation:<\/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\">Reference \u2192 Publication (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\">Working with CI\/CD \u2192 General information \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 with 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> The new option <code>werf publish --tag-by-stages-signature=true|false<\/code>.<\/li>\n<li> The new value of the option <code>werf ci-env --tagging-strategy=stages-signature|tag-or-branch<\/code> (if not specified, it will default to <code>stages-signature<\/code>).<\/li>\n<li> If previously tagging options were used based on Git commits (<code>WERF_TAG_GIT_COMMIT<\/code> or the option <code>werf publish --tag-git-commit COMMIT<\/code>), it is necessary to switch to the tagging strategy <i>stages-signature<\/i>.<\/li>\n<li> New projects should be immediately switched to the new tagging scheme.<\/li>\n<li> Old projects transitioning to werf 1.1 should ideally be switched to the new tagging scheme; however, the old one <i>tag-or-branch<\/i> is still supported.<\/li>\n<\/ul>\n<p>\nContent-based tagging solves all the issues discussed in the article:<\/p>\n<ul>\n<li> Resilience of Docker tag names to empty Git commits.<\/li>\n<li> Resilience of Docker tag names to Git commits that change irrelevant files for the image.<\/li>\n<li> Does not lead to issues with overwriting the current image version when re-running builds for old Git commits on Git branches.<\/li>\n<\/ul>\n<p>\nUse it! And don't forget to visit us at <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">GitHub<\/a><\/noindex>, to create an issue or find an existing one, upvote, create a PR, or just follow the project's development.<\/p>\n<h2>P.S.<\/h2>\n<p>\nAlso read in our blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/493170\/\">Release of werf 1.1: improvements in the builder today and plans for the future<\/a><\/noindex>\u00bb<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/481306\/\">Introducing werf 1.0 stable: what does GitOps, status, and plans have to do with it?<\/a><\/noindex>\u00bb<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/460351\/\">werf is our tool for CI\/CD in Kubernetes (overview and video report)<\/a><\/noindex>\u00bb;<\/li>\n<li> Cycle of release notes for new features 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: deploying to Kubernetes with Helm \"on steroids\"<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/468049\/\">Using werf for deploying complex Helm charts<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465131\/\">Support for monorepo and multirepo in werf and its connection to Docker Registry<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/463613\/\">You can now build Docker images in werf using a regular Dockerfile<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>Source: <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\/en\/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=\"en_US\" \/>\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\/en\/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 the werf builder: why and how it works? | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/en\/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":"en_US","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\/en\/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\/en\/wp-json\/wp\/v2\/posts\/76769","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/comments?post=76769"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/76769\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media\/76770"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media?parent=76769"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/categories?post=76769"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/tags?post=76769"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}