{"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\/es\/blog\/administrirovanie\/content-based-tagging-v-sborshhike-werf-zachem-i-kak-eto-rabotaet","title":{"rendered":"Etiquetado basado en contenido en el recolector werf: \u00bfpor qu\u00e9 y c\u00f3mo funciona?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Etiquetado basado en contenido en el recolector werf: \u00bfpor qu\u00e9 y c\u00f3mo funciona?\" 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 nuestra herramienta CLI de GitOps de c\u00f3digo abierto para la construcci\u00f3n y entrega de aplicaciones en Kubernetes. En <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/493170\/\">la versi\u00f3n v1.1<\/a><\/noindex> se present\u00f3 una nueva caracter\u00edstica en el generador de im\u00e1genes: etiquetado de im\u00e1genes basado en el contenido o <i>etiquetado basado en contenido<\/i>. Hasta ahora, el esquema t\u00edpico de etiquetado en werf presum\u00eda etiquetar im\u00e1genes de Docker por etiqueta de Git, rama de Git o commit de Git. Pero todos estos esquemas tienen desventajas, que son completamente resueltas por la nueva estrategia de etiquetado. Los detalles sobre esto y por qu\u00e9 es tan buena se encuentran a continuaci\u00f3n.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Despliegue de un conjunto de microservicios desde un solo repositorio de Git<\/h2>\n<p>\nA menudo se da la situaci\u00f3n en la que una aplicaci\u00f3n est\u00e1 dividida en m\u00faltiples servicios m\u00e1s o menos independientes. Las versiones de estos servicios pueden ocurrir de forma independiente: se puede liberar uno o varios servicios a la vez, mientras que los dem\u00e1s deben seguir funcionando sin ning\u00fan cambio. Pero desde el punto de vista del almacenamiento del c\u00f3digo y la gesti\u00f3n del proyecto, es m\u00e1s conveniente mantener tales servicios de aplicaci\u00f3n en un \u00fanico repositorio.<\/p>\n<p>Hay situaciones en las que los servicios son realmente independientes y no est\u00e1n relacionados con una \u00fanica aplicaci\u00f3n. En tal caso, estar\u00e1n ubicados en proyectos separados y su lanzamiento se realizar\u00e1 a trav\u00e9s de procesos CI\/CD separados en cada uno de los proyectos.<\/p>\n<p>Sin embargo, en la realidad, los desarrolladores a menudo dividen una sola aplicaci\u00f3n en varios microservicios, pero crear un repositorio y proyecto separados para cada uno... es un claro exceso. Precisamente sobre esta situaci\u00f3n trataremos a continuaci\u00f3n: varios de estos microservicios est\u00e1n en un \u00fanico repositorio del proyecto y los lanzamientos ocurren a trav\u00e9s de un \u00fanico proceso en CI\/CD.<\/p>\n<h3>Etiquetado por rama de Git y etiqueta de Git<\/h3>\n<p>\nSupongamos que se utiliza la estrategia de etiquetado m\u00e1s com\u00fan \u2014 <i>etiqueta-o-rama<\/i>. Para las ramas de Git, las im\u00e1genes se etiquetan con el nombre de la rama; para una rama, en un momento dado, solo existe una imagen publicada con el nombre de esa rama. Para las etiquetas de Git, las im\u00e1genes se etiquetan seg\u00fan el nombre de la etiqueta.<\/p>\n<p>Al crear una nueva etiqueta de Git \u2014 por ejemplo, al lanzarse una nueva versi\u00f3n \u2014 se crear\u00e1 una nueva etiqueta de Docker para todas las im\u00e1genes del proyecto en el 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>\nEstos nuevos nombres de imagen se integran a trav\u00e9s de plantillas de Helm en la configuraci\u00f3n de Kubernetes. Al iniciar el despliegue con el comando <code>werf deploy<\/code> se actualiza el campo <code>image<\/code> en los manifiestos de recursos de Kubernetes y se reinician los recursos correspondientes debido al cambio del nombre de la imagen.<\/p>\n<p><b>Problema<\/b>: en caso de que el contenido de la imagen no haya cambiado desde el despliegue anterior (etiqueta de Git), y solo se haya modificado su etiqueta de Docker, ocurre <i>un reinicio innecesario<\/i> de esta aplicaci\u00f3n y, por lo tanto, puede haber alg\u00fan tiempo de inactividad. Aunque no hab\u00eda razones reales para realizar este reinicio.<\/p>\n<p>Como consecuencia, con el esquema actual de etiquetado, es necesario crear varios repositorios de Git, y surge el problema de organizar el despliegue de estos m\u00faltiples repositorios. En t\u00e9rminos generales, este esquema resulta ser sobrecargado y complicado. Es mejor agrupar muchos servicios en un solo repositorio y crear etiquetas de Docker de manera que no haya reinicios innecesarios.<\/p>\n<h3>Etiquetado por commit de Git<\/h3>\n<p>\nEn werf tambi\u00e9n existe una estrategia de etiquetado relacionada con los commits de Git.<\/p>\n<p>El commit de Git es un identificador del contenido del repositorio de Git y depende del historial de modificaciones de archivos en el repositorio de Git, por lo que parece l\u00f3gico utilizarlo para etiquetar im\u00e1genes en el Docker Registry.<\/p>\n<p>Sin embargo, el etiquetado por commit de Git tiene las mismas desventajas que el etiquetado por ramas de Git o etiquetas de Git:<\/p>\n<ul>\n<li> Se podr\u00eda haber creado un commit vac\u00edo que no modifica archivos, pero la etiqueta de Docker de la imagen se cambiar\u00eda.<\/li>\n<li> Se podr\u00eda haber creado un commit de fusi\u00f3n que no modifica archivos, pero la etiqueta de Docker de la imagen se cambiar\u00eda.<\/li>\n<li> Se podr\u00eda haber creado un commit que modifica archivos en Git que no se importan en la imagen, y nuevamente se modificar\u00eda la etiqueta de Docker de la imagen.<\/li>\n<\/ul>\n<p><\/p>\n<h2>El etiquetado por nombre de rama de Git no refleja la versi\u00f3n de la imagen<\/h2>\n<p>\nHay otro problema relacionado con la estrategia de etiquetado por ramas de Git.<\/p>\n<p>El etiquetado por nombre de rama funciona siempre que los commits de esa rama se ata\u00f1an secuencialmente en orden cronol\u00f3gico.<\/p>\n<p>Si en el esquema actual el usuario inicia la reconstrucci\u00f3n de un antiguo commit relacionado con alguna rama, entonces werf sobrescribir\u00e1 la imagen correspondiente al Docker-tag con la nueva versi\u00f3n de la imagen para el antiguo commit. Los Deployments que usen este tag a partir de este momento corren el riesgo de hacer pull de otra versi\u00f3n de la imagen al reiniciar los pods, lo que resultar\u00e1 en que nuestra aplicaci\u00f3n pierda la conexi\u00f3n con el sistema de CI y se desincronice.<\/p>\n<p>Adem\u00e1s, al realizar push acumulados en una misma rama con un intervalo de tiempo corto, un commit antiguo puede ser construido despu\u00e9s que uno m\u00e1s reciente: la versi\u00f3n anterior de la imagen puede sobrescribir la nueva bajo la etiqueta de la rama de Git. Estos problemas pueden ser solucionados por un sistema CI\/CD (por ejemplo, en GitLab CI, se ejecuta un pipeline para la serie de commits m\u00e1s reciente). Sin embargo, no todos los sistemas lo soportan y debe haber una forma m\u00e1s confiable de prevenir un problema tan fundamental.<\/p>\n<h2>\u00bfQu\u00e9 es el etiquetado basado en contenido?<\/h2>\n<p>\nAs\u00ed que, \u00bfqu\u00e9 es el etiquetado basado en contenido? Se trata de etiquetar im\u00e1genes seg\u00fan su contenido.<\/p>\n<p>Para crear Docker-tags se utilizan no los primitivas de Git (rama Git, tag Git\u2026), sino un hash de control asociado con:<\/p>\n<ul>\n<li> <i>el contenido de la imagen<\/i>. El identificador-etiqueta de la imagen refleja su contenido. Al construir una nueva versi\u00f3n, este identificador no cambiar\u00e1, si no se modifican los archivos en la imagen;<\/li>\n<li> <i>la historia de creaci\u00f3n de esta imagen en Git<\/i>. Las im\u00e1genes asociadas a diferentes ramas de Git y diferentes historias de construcci\u00f3n a trav\u00e9s de werf tendr\u00e1n diferentes identificadores de etiqueta.<\/li>\n<\/ul>\n<p>\nComo tal identificador de etiqueta se utiliza la conocida <b>firma de las etapas de la imagen<\/b>.<\/p>\n<p>Cada imagen consta de un conjunto de etapas: <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> etc. Cada etapa tiene un identificador que refleja su contenido: <b>firma de la etapa<\/b> <i>(stage signature)<\/i>.<\/p>\n<p>La imagen final, compuesta por estas etapas, es etiquetada con la llamada firma del conjunto de estas etapas \u2014 <b>stages signature<\/b>, que es general para todas las etapas de la imagen.<\/p>\n<p>Cada imagen de la configuraci\u00f3n <code>werf.yaml<\/code> en general tendr\u00e1 su propia firma y, por lo tanto, una etiqueta de Docker correspondiente.<\/p>\n<p>La firma de las etapas resuelve todos los problemas mencionados:<\/p>\n<ul>\n<li> Es resistente a commits vac\u00edos de Git.<\/li>\n<li> Es resistente a commits de Git que modifican archivos que no son relevantes para la imagen.<\/li>\n<li> No conlleva el problema de sobrescribir la versi\u00f3n m\u00e1s actual de la imagen al reiniciar construcciones para commits antiguos de la rama de Git.<\/li>\n<\/ul>\n<p>\nAhora esta es la estrategia de etiquetado recomendada y se utiliza por defecto en werf para todos los sistemas CI.<\/p>\n<h2>C\u00f3mo habilitar y usar en werf<\/h2>\n<p>\nLa opci\u00f3n correspondiente ha sido a\u00f1adida al comando <code>werf publish<\/code>: <code>--tag-by-stages-signature=true|false<\/code><\/p>\n<p>En el sistema CI, la estrategia de etiquetado se establece con el comando <code>werf ci-env<\/code>. Anteriormente, se defin\u00eda un par\u00e1metro <code>werf ci-env --tagging-strategy=tag-or-branch<\/code>. Ahora, si se especifica <code>werf ci-env --tagging-strategy=stages-signature<\/code> o no especificar esta opci\u00f3n, werf por defecto utilizar\u00e1 la estrategia de etiquetado <code>stages-signature<\/code>. El comando <code>werf ci-env<\/code> autom\u00e1ticamente establecer\u00e1 las banderas requeridas para el comando <code>werf build-and-publish<\/code> (o <code>werf publish<\/code>), por lo que no es necesario especificar opciones adicionales para estos comandos.<\/p>\n<p>Por ejemplo, el comando:<\/p>\n<pre><code class=\"plaintext\">werf publish --stages-storage :local --images-repo registry.hello.com\/web\/core\/system --tag-by-stages-signature<\/code><\/pre>\n<p>\n\u2026 puede crear las siguientes im\u00e1genes:<\/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>\nAqu\u00ed <code>4ef339f84ca22247f01fb335bb19f46c4434014d8daa3d5d6f0e386d<\/code> \u2014 es la firma de las etapas de la imagen <code>backend<\/code>, y <code>f44206457e0a4c8a54655543f749799d10a9fe945896dab1c16996c6<\/code> \u2014 firma de las etapas de la imagen <code>frontend<\/code>.<\/p>\n<p>Al usar funciones especiales <code>werf_container_image<\/code> y <code>werf_container_env<\/code> en las plantillas de Helm no es necesario cambiar nada: estas funciones generar\u00e1n autom\u00e1ticamente los nombres correctos de las im\u00e1genes.<\/p>\n<p>Ejemplo de configuraci\u00f3n en un sistema CI:<\/p>\n<pre><code class=\"plaintext\">type multiwerf &amp;&amp; source &lt;(multiwerf use 1.1 beta)\ntype werf &amp;&amp; source &lt;(werf ci-env gitlab)\nwerf build-and-publish|deploy<\/code><\/pre>\n<p>\nM\u00e1s informaci\u00f3n sobre la configuraci\u00f3n est\u00e1 disponible en la documentaci\u00f3n:<\/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\">Manual \u2192 Publicaci\u00f3n (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\">Trabajo con CI\/CD \u2192 Informaci\u00f3n general \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\">Integraci\u00f3n con 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> La nueva opci\u00f3n <code>werf publish --tag-by-stages-signature=true|false<\/code>.<\/li>\n<li> Nuevo valor de opci\u00f3n <code>werf ci-env --tagging-strategy=stages-signature|tag-or-branch<\/code> (si no se especifica, por defecto ser\u00e1 <code>stages-signature<\/code>).<\/li>\n<li> Si anteriormente se usaron opciones de etiquetado por Git-commits (<code>WERF_TAG_GIT_COMMIT<\/code> o la opci\u00f3n <code>werf publish --tag-git-commit COMMIT<\/code>), es necesario cambiar a la estrategia de etiquetado <i>stages-signature<\/i>.<\/li>\n<li> Es mejor cambiar nuevos proyectos a la nueva esquema de etiquetado desde el inicio.<\/li>\n<li> Los proyectos antiguos al migrar a werf 1.1 deber\u00edan idealmente cambiar a la nueva esquema de etiquetado, sin embargo, la antigua <i>etiqueta-o-rama<\/i> sigue siendo compatible.<\/li>\n<\/ul>\n<p>\nEl etiquetado basado en contenido resuelve todos los problemas expuestos en el art\u00edculo:<\/p>\n<ul>\n<li> Resiliencia del nombre de la etiqueta Docker ante Git-commits vac\u00edos.<\/li>\n<li> Resiliencia del nombre de la etiqueta Docker ante Git-commits que modifican archivos no relevantes para la imagen.<\/li>\n<li> No provoca problemas de sobrescritura de la versi\u00f3n actual de la imagen al reiniciar compilaciones para antiguos Git-commits de ramas de Git.<\/li>\n<\/ul>\n<p>\n\u00a1\u00dasalos! Y no olvides visitarnos en <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">GitHub<\/a><\/noindex>, para crear un issue o encontrar uno existente, dar un thumbs up, crear un PR o simplemente observar el desarrollo del proyecto.<\/p>\n<h2>P.D.<\/h2>\n<p>\nTambi\u00e9n puedes leer en nuestro blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/493170\/\">Lanzamiento de werf 1.1: mejoras en el compilador hoy y planes para el futuro<\/a><\/noindex>\u00bb<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/481306\/\">Presentamos werf 1.0 estable: \u00bfqu\u00e9 tiene que ver GitOps, el estado y los planes?<\/a><\/noindex>\u00bb<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/460351\/\">werf: nuestra herramienta para CI\/CD en Kubernetes (rese\u00f1a y video de la presentaci\u00f3n)<\/a><\/noindex>\u00bb;<\/li>\n<li> Ciclo de notas sobre novedades en werf:\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/476646\/\">fusi\u00f3n de 3 v\u00edas en werf: despliegue en Kubernetes con Helm 'a tope'<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/468049\/\">Uso de werf para el despliegue de charts complejos de Helm<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465131\/\">Soporte para monorepos y multirepos en werf y qu\u00e9 tiene que ver Docker Registry<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/463613\/\">Ahora se pueden construir im\u00e1genes de Docker en werf utilizando un Dockerfile est\u00e1ndar<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>Fuente: <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\/es\/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=\"es_ES\" \/>\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\/es\/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\udd47Etiquetado basado en contenido en el compilador werf: \u00bfpor qu\u00e9 y c\u00f3mo funciona esto? | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/es\/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":"es_ES","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\/es\/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\/es\/wp-json\/wp\/v2\/posts\/76769","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=76769"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/76769\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/76770"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=76769"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=76769"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=76769"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}