{"id":76764,"date":"2020-04-04T13:42:24","date_gmt":"2020-04-04T11:42:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee"},"modified":"2020-04-04T13:42:24","modified_gmt":"2020-04-04T11:42:24","slug":"reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee","title":{"rendered":"Lanzamiento de werf 1.1: mejoras en el compilador hoy y planes para el futuro","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Lanzamiento de werf 1.1: mejoras en el compilador hoy y planes para el futuro\" src=\"\/wp-content\/uploads\/2020\/04\/c7c26e4a0b7bddb90ba087a4db7175dc.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. Como prometimos, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/481306\/\">el lanzamiento de la versi\u00f3n v1.0<\/a><\/noindex> marc\u00f3 el inicio de la adici\u00f3n de nuevas capacidades a werf y la revisi\u00f3n de enfoques establecidos. Ahora nos complace presentar el lanzamiento v1.1, que representa un gran avance en el desarrollo y una base para el futuro <i>constructor<\/i> werf. La versi\u00f3n est\u00e1 disponible actualmente en <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf#backward-compatibility-promise\">el canal 1.1 ea<\/a><\/noindex>.<\/p>\n<p>La base del lanzamiento es una nueva arquitectura de almacenamiento de etapas y la optimizaci\u00f3n del funcionamiento de ambos constructores (para Stapel y Dockerfile). La nueva arquitectura de almacenamiento abre posibilidades para implementar compilaciones distribuidas desde varios hosts y compilaciones paralelas en un solo host.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>La optimizaci\u00f3n del trabajo incluye la eliminaci\u00f3n de c\u00e1lculos innecesarios en la etapa de c\u00e1lculo de las firmas de las etapas y el cambio de los mecanismos de c\u00e1lculo de sumas de verificaci\u00f3n de archivos a versiones m\u00e1s eficientes. Esta optimizaci\u00f3n reduce el tiempo promedio de compilaci\u00f3n del proyecto con werf. Y las compilaciones en vac\u00edo, cuando todas las etapas existen en la cach\u00e9 <i>stages-storage<\/i>, ahora son realmente r\u00e1pidas. En la mayor\u00eda de los casos, reiniciar la compilaci\u00f3n tomar\u00e1 menos de 1 segundo. Esto tambi\u00e9n se aplica a los procedimientos de verificaci\u00f3n de etapas durante el trabajo de los equipos <code>werf deploy<\/code> y <code>werf run<\/code>.<\/p>\n<p>Tambi\u00e9n en este lanzamiento se introdujo una estrategia de etiquetado de im\u00e1genes basada en contenido \u2014 <i>etiquetado basado en contenido<\/i>, que ahora est\u00e1 habilitada por defecto y es la \u00fanica recomendada.<\/p>\n<p>Veamos en detalle las novedades clave en werf v1.1, y tambi\u00e9n comentaremos sobre los planes futuros.<\/p>\n<h2>\u00bfQu\u00e9 ha cambiado en werf v1.1?<\/h2>\n<p><\/p>\n<h3>Nuevo formato de nomenclatura de etapas y algoritmo de selecci\u00f3n de etapas desde la cach\u00e9<\/h3>\n<p>\nNueva regla para la generaci\u00f3n del nombre de una etapa. Ahora, cada compilaci\u00f3n de una etapa genera un nombre \u00fanico, que consta de dos partes: la firma (como era en v1.0) m\u00e1s un identificador temporal \u00fanico.<\/p>\n<p>Por ejemplo, el nombre completo de la imagen de la etapa puede verse as\u00ed:<\/p>\n<p><code>werf-stages-storage\/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835<\/code><\/p>\n<p>\u2026 o en su forma general:<\/p>\n<p><code>werf-stages-storage\/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC<\/code><\/p>\n<p>Aqu\u00ed:<\/p>\n<ul>\n<li> <code>SIGNATURE<\/code> \u2014 es la firma de la etapa, que representa el identificador del contenido de la etapa y depende del historial de cambios en Git que condujeron a ese contenido;<\/li>\n<li> <code>TIMESTAMP_MILLISEC<\/code> \u2014 es un identificador de imagen garantizado como \u00fanico, que se genera en el momento de construir una nueva imagen.<\/li>\n<\/ul>\n<p>\nEl algoritmo de selecci\u00f3n de etapas desde la cach\u00e9 se basa en la verificaci\u00f3n de la relaci\u00f3n entre los commits de Git:<\/p>\n<ol>\n<li> Werf calcula la firma de una etapa determinada.<\/li>\n<li> En <i>stages-storage<\/i> puede haber varias etapas con esta firma. Werf selecciona todas las etapas adecuadas seg\u00fan la firma.<\/li>\n<li> Si la etapa actual est\u00e1 relacionada con Git (git-archive, etapa personalizada con parches de Git: <code>install<\/code>, <code>beforeSetup<\/code>, <code>configuraci\u00f3n<\/code>; o git-latest-patch), entonces werf elige solo aquellas etapas que est\u00e1n relacionadas con el commit que es antecesor del commit actual (para el cual se invoc\u00f3 la construcci\u00f3n).<\/li>\n<li> De las etapas restantes adecuadas, se selecciona una: la m\u00e1s antigua por fecha de creaci\u00f3n.<\/li>\n<\/ol>\n<p>\nLas etapas para diferentes ramas de Git pueden tener la misma firma. Pero werf evitar\u00e1 el uso de la cach\u00e9 relacionada con diferentes ramas entre s\u00ed, incluso si las firmas coinciden.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/reference\/stages_and_images.html#%D0%B8%D0%BC%D0%B5%D0%BD%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-%D1%81%D1%82%D0%B0%D0%B4%D0%B8%D0%B9\">\u2192 Documentaci\u00f3n<\/a><\/noindex>.<\/p>\n<h3>Nuevo algoritmo para crear y guardar etapas en el almacenamiento de etapas<\/h3>\n<p>\nSi durante la b\u00fasqueda de etapas en la cach\u00e9 werf no encuentra una etapa adecuada, se inicia el proceso de construcci\u00f3n de una nueva etapa.<\/p>\n<p>Cabe destacar que varios procesos (en uno o varios hosts) pueden comenzar a construir la misma etapa aproximadamente al mismo tiempo. Werf utiliza un algoritmo de bloqueo optimista <i>stages-storage<\/i> en el momento de guardar la imagen reci\u00e9n construida en <i>stages-storage<\/i>. As\u00ed, cuando se complete la construcci\u00f3n de una nueva etapa, werf bloquear\u00e1 <i>stages-storage<\/i> y guardar\u00e1 la imagen reci\u00e9n construida solo si no existe ya una imagen adecuada all\u00ed <i>(seg\u00fan la firma y otros par\u00e1metros \u2014 ver nuevo algoritmo de selecci\u00f3n de etapas de la cach\u00e9)<\/i>.<\/p>\n<p>La imagen reci\u00e9n construida tendr\u00e1 garantizado un identificador \u00fanico seg\u00fan <code>TIMESTAMP_MILLISEC<\/code> <i>(ver nuevo formato de nombrado de etapas)<\/i>. En caso de que se encuentre una imagen adecuada en <i>stages-storage<\/i> , werf descartar\u00e1 la imagen reci\u00e9n construida y utilizar\u00e1 la imagen de la cach\u00e9.<\/p>\n<p>En otras palabras: el primer proceso que termine de construir la imagen (el m\u00e1s r\u00e1pido) tendr\u00e1 el derecho de guardarla en stages-storage (y luego esta \u00fanica imagen ser\u00e1 utilizada para todas las construcciones). El proceso de construcci\u00f3n m\u00e1s lento nunca bloquear\u00e1 a un proceso m\u00e1s r\u00e1pido de guardar los resultados de la construcci\u00f3n de la etapa actual y pasar a construir la siguiente.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/reference\/stages_and_images.html#%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0-%D0%B8-%D1%81%D0%BE%D1%85%D1%80%D0%B0%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5-%D1%81%D1%82%D0%B0%D0%B4%D0%B8%D0%B9\">\u2192 Documentaci\u00f3n<\/a><\/noindex>.<\/p>\n<h3>Mejorado el rendimiento del constructor de Dockerfile<\/h3>\n<p>\nEn este momento, el canal de etapas para la imagen construida a partir del Dockerfile consiste en una sola etapa \u2014 <code>dockerfile<\/code>. Al calcular la firma se considera el hash de los archivos <code>contexto<\/code>, que se utilizar\u00e1n durante la construcci\u00f3n. Antes de esta mejora, werf recorr\u00eda recursivamente todos los archivos y obten\u00eda un hash de verificaci\u00f3n, sumando el contexto y el modo de cada archivo. Desde las versiones v1.1, werf puede utilizar los hashes de verificaci\u00f3n calculados que se almacenan en el repositorio de Git.<\/p>\n<p>La base del algoritmo es <noindex><a rel=\"nofollow\" href=\"https:\/\/git-scm.com\/docs\/git-ls-tree\">git ls-tree<\/a><\/noindex>. El algoritmo considera registros en <code>.dockerignore<\/code> y recorre recursivamente el \u00e1rbol de archivos solo cuando es necesario. De esta manera, nos hemos desvinculado de la lectura del sistema de archivos, y la dependencia del algoritmo en el tama\u00f1o <code>contexto<\/code> no es significativa.<\/p>\n<p>Adem\u00e1s, el algoritmo verifica archivos no rastreados y, si es necesario, los incluye en el hash de verificaci\u00f3n.<\/p>\n<h3>Se ha mejorado el rendimiento al importar archivos<\/h3>\n<p>\nEn las versiones de werf v1.1 se utiliza un servidor rsync para <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/configuration\/stapel_image\/import_directive.html\">la importaci\u00f3n de archivos desde artefactos e im\u00e1genes<\/a><\/noindex>. Anteriormente, la importaci\u00f3n se realizaba en dos pasos utilizando el montaje de un directorio desde el sistema host.<\/p>\n<p>El rendimiento de las importaciones en macOS ya no est\u00e1 limitado a los vol\u00famenes de Docker, y las importaciones se ejecutan en el mismo tiempo que en Linux y Windows.<\/p>\n<h3>Etiquetado basado en contenido<\/h3>\n<p>\nWerf v1.1 admite lo que se llama etiquetado por contenido de la imagen \u2014 <i>etiquetado basado en contenido<\/i>. Las etiquetas de las im\u00e1genes Docker resultantes dependen del contenido de esas im\u00e1genes.<\/p>\n<p>Al ejecutar el comando <code>werf publish --tags-by-stages-signature<\/code> o <code>werf ci-env --tagging-strategy=stages-signature<\/code> se etiquetar\u00e1n las im\u00e1genes publicadas con lo que se denomina <b>firma de etapas<\/b> de la imagen. Cada imagen se etiqueta con su propia firma de etapas de esa imagen, que se calcula seg\u00fan las mismas reglas que la firma regular de cada etapa por separado, pero es un identificador general de la imagen.<\/p>\n<p>La firma de etapas de la imagen depende de:<\/p>\n<ol>\n<li> el contenido de esta imagen;<\/li>\n<li> la historia de los cambios en Git, que condujeron a este contenido.<\/li>\n<\/ol>\n<p>\nEn el repositorio de Git siempre hay commits vac\u00edos que no cambian el contenido de los archivos de la imagen. Por ejemplo, commits con solo comentarios o merge commits, o commits que cambian archivos en Git que no ser\u00e1n importados en la imagen.<\/p>\n<p>Al utilizar el etiquetado basado en contenido, se resuelven problemas de reinicios innecesarios de los pods de la aplicaci\u00f3n en Kubernetes debido a cambios en el nombre de la imagen, incluso si el contenido de la imagen no ha cambiado. Por cierto, esta es una de las razones que impiden almacenar m\u00faltiples microservicios de una misma aplicaci\u00f3n en un \u00fanico repositorio de Git.<\/p>\n<p>Adem\u00e1s, el etiquetado basado en contenido es un m\u00e9todo de etiquetado m\u00e1s confiable que el etiquetado por ramas de Git, ya que el contenido de las im\u00e1genes resultantes no depende del orden de ejecuci\u00f3n de los pipelines en el sistema CI para compilar varios commits de la misma rama.<\/p>\n<p><b>Importante<\/b>: a partir de este momento <i>stages-signature<\/i> \u2014 es <b>la \u00fanica estrategia recomendada para el etiquetado<\/b>. Esta ser\u00e1 la que se utilizar\u00e1 por defecto en el equipo <code>werf ci-env<\/code> (a menos que se indique expl\u00edcitamente otro esquema de etiquetado).<\/p>\n<p><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\">\u2192 Documentaci\u00f3n<\/a><\/noindex>. Esta caracter\u00edstica tambi\u00e9n tendr\u00e1 una publicaci\u00f3n dedicada. <b>ACTUALIZADO<\/b> (3 de abril): Art\u00edculo con detalles <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/495112\/\">el a\u00f1o pasado<\/a><\/noindex>.<\/p>\n<h3>Niveles de registro<\/h3>\n<p>\nEl usuario tiene la posibilidad de controlar la salida, establecer el nivel de registro y trabajar con informaci\u00f3n de depuraci\u00f3n. Se han a\u00f1adido las opciones <code>--log-quiet<\/code>, <code>--log-verbose<\/code>, <code>--log-debug<\/code>.<\/p>\n<p>Por defecto, la salida contiene la m\u00ednima informaci\u00f3n:<\/p>\n<p><img decoding=\"async\" alt=\"Lanzamiento de werf 1.1: mejoras en el compilador hoy y planes para el futuro\" src=\"\/wp-content\/uploads\/2020\/04\/58e981b2e0c579ddde817eadc1732874.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAl usar salida detallada (<code>--log-verbose<\/code>) se puede ver c\u00f3mo funciona werf:<\/p>\n<p><img decoding=\"async\" alt=\"Lanzamiento de werf 1.1: mejoras en el compilador hoy y planes para el futuro\" src=\"\/wp-content\/uploads\/2020\/04\/487ed5dfc5df0178f7c09f8da697ceff.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa salida detallada (<code>--log-debug<\/code>), adem\u00e1s de la informaci\u00f3n de depuraci\u00f3n de werf, tambi\u00e9n contiene los logs de las bibliotecas utilizadas. Por ejemplo, se puede ver c\u00f3mo se interact\u00faa con el Docker Registry, as\u00ed como registrar los lugares donde se gastan tiempos significativos:<\/p>\n<p><img decoding=\"async\" alt=\"Lanzamiento de werf 1.1: mejoras en el compilador hoy y planes para el futuro\" src=\"\/wp-content\/uploads\/2020\/04\/99c1f3c2ab3803ff11fae1f2d5c9a5af.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Planes futuros<\/h2>\n<p>\n<b>\u00a1Atenci\u00f3n!<\/b> Las capacidades descritas a continuaci\u00f3n con la etiqueta <b>v1.1<\/b> estar\u00e1n disponibles en esta versi\u00f3n, muchas de ellas en breve. Las actualizaciones llegar\u00e1n a trav\u00e9s de actualizaciones autom\u00e1ticas <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/guides\/installation.html#%D1%81%D0%BF%D0%BE%D1%81%D0%BE%D0%B1-1-%D1%80%D0%B5%D0%BA%D0%BE%D0%BC%D0%B5%D0%BD%D0%B4%D1%83%D0%B5%D0%BC%D1%8B%D0%B9-multiwerf\">al usar multiwerf<\/a><\/noindex>. Estas capacidades no afectan la parte estable de las funciones v1.1, su aparici\u00f3n no requerir\u00e1 intervenci\u00f3n manual del usuario en las configuraciones existentes.<\/p>\n<h3>Soporte completo para diversas implementaciones de Docker Registry (NUEVO)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versi\u00f3n: v1.1<\/i><\/li>\n<li> <i>Cronograma: marzo<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2199\">Issue<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nEl objetivo es que el usuario deba utilizar cualquier implementaci\u00f3n sin restricciones al usar werf. <\/p>\n<p>En este momento, hemos identificado el siguiente conjunto de soluciones para las cuales garantizaremos soporte completo:<\/p>\n<ul>\n<li> Default (library\/registry)*,<\/li>\n<li> AWS ECR,<\/li>\n<li> Azure*,<\/li>\n<li> Docker Hub,<\/li>\n<li> GCR*,<\/li>\n<li> GitHub Packages,<\/li>\n<li> GitLab Registry*,<\/li>\n<li> Harbor*,<\/li>\n<li> Quay.<\/li>\n<\/ul>\n<p>\nLa estrella marca las soluciones que actualmente ya son totalmente compatibles con werf. Para los dem\u00e1s hay soporte, pero con limitaciones.<\/p>\n<p>Se pueden identificar dos problemas principales:<\/p>\n<ul>\n<li> Algunas soluciones no soportan la eliminaci\u00f3n de etiquetas mediante la API de Docker Registry, lo que impide que los usuarios utilicen la limpieza autom\u00e1tica implementada en werf. Esto es cierto para AWS ECR, Docker Hub y GitHub Packages.<\/li>\n<li> Algunas soluciones no admiten, los llamados, repositorios anidados (Docker Hub, GitHub Packages y Quay) o los admiten, pero el usuario debe crearlos manualmente utilizando la interfaz de usuario o la API (AWS ECR).<\/li>\n<\/ul>\n<p>\nVamos a abordar estos y otros problemas utilizando las API nativas de las soluciones. Esta tarea tambi\u00e9n implica cubrir con pruebas el ciclo completo de trabajo de werf para cada una de ellas.<\/p>\n<h3>Construcci\u00f3n distribuida de im\u00e1genes (\u2191)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versi\u00f3n: v1.2 v1.1 (se ha aumentado la prioridad para implementar esta funcionalidad)<\/i><\/li>\n<li> <i>Tiempos: marzo-abril marzo<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/1614\">Issue<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nActualmente, werf v1.0 y v1.1 solo se pueden utilizar en un \u00fanico host dedicado para operaciones de construcci\u00f3n y publicaci\u00f3n de im\u00e1genes y despliegue de aplicaciones en Kubernetes.<\/p>\n<p>Para habilitar la trabajo distribuido de werf, donde la construcci\u00f3n y el despliegue de aplicaciones en Kubernetes se inician en varios hosts arbitrarios, y estos hosts no mantienen su estado entre construcciones (runners temporales), se requiere que werf implemente la capacidad de utilizar Docker Registry como almacenamiento de etapas.<\/p>\n<p>Anteriormente, cuando el proyecto werf a\u00fan se llamaba dapp, exist\u00eda tal capacidad. Sin embargo, nos encontramos con una serie de problemas que deben tenerse en cuenta al implementar esta funci\u00f3n en werf.<\/p>\n<p><b>Nota<\/b>. Esta capacidad no supone que el compilador funcione dentro de los pods de Kubernetes, ya que para ello es necesario deshacerse de la dependencia del servidor Docker local (no hay acceso al servidor Docker local en el pod de Kubernetes, puesto que el proceso mismo se ejecuta en un contenedor, y la operaci\u00f3n con el servidor Docker a trav\u00e9s de la red no es admitida ni se admitir\u00e1 por werf). El soporte para trabajar en Kubernetes se implementar\u00e1 por separado.<\/p>\n<h3>Soporte oficial para GitHub Actions (NUEVO)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versi\u00f3n: v1.1<\/i><\/li>\n<li> <i>Cronograma: marzo<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2210\">Issue<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nIncluye la documentaci\u00f3n de werf (secciones <i>reference<\/i> y <i>gu\u00eda<\/i>), as\u00ed como una acci\u00f3n oficial de GitHub para trabajar con werf.<\/p>\n<p>Adem\u00e1s, permitir\u00e1 que werf funcione en runners ef\u00edmeros.<\/p>\n<p>La mec\u00e1nica de interacci\u00f3n del usuario con el sistema CI se basar\u00e1 en la asignaci\u00f3n de etiquetas a los pull requests para iniciar ciertas acciones de compilaci\u00f3n\/despliegue de la aplicaci\u00f3n.<\/p>\n<h3>Desarrollo y despliegue locales de aplicaciones con werf (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versi\u00f3n: v1.1<\/i><\/li>\n<li> <i>Tiempos: enero-febrero abril<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/1940\">Issue<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nEl objetivo principal es lograr una configuraci\u00f3n unificada y homog\u00e9nea para el despliegue de aplicaciones tanto localmente como en producci\u00f3n, sin acciones complicadas, \u2018listo para usar\u2019.<\/p>\n<p>Tambi\u00e9n se requiere de werf un modo de operaci\u00f3n que facilite la edici\u00f3n del c\u00f3digo de la aplicaci\u00f3n y proporcione una retroalimentaci\u00f3n instant\u00e1nea de la aplicaci\u00f3n en funcionamiento para depuraci\u00f3n.<\/p>\n<h3>Nuevo algoritmo de limpieza (NUEVO)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versi\u00f3n: v1.1<\/i><\/li>\n<li> <i>Fechas: abril<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2212\">Issue<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nEn la versi\u00f3n actual de werf v1.1 en el procedimiento <code>cleanup<\/code> no se prev\u00e9 la limpieza de im\u00e1genes para el esquema de etiquetado basado en contenido (content-based tagging) \u2014 estas im\u00e1genes se acumular\u00e1n.<\/p>\n<p>Adem\u00e1s, en la versi\u00f3n actual de werf (v1.0 y v1.1) se utilizan diferentes pol\u00edticas de limpieza para im\u00e1genes publicadas bajo esquemas de etiquetado: rama de Git, etiqueta de Git o commit de Git.<\/p>\n<p>Se ha ideado un nuevo algoritmo unificado para todos los esquemas de etiquetado que limpia im\u00e1genes bas\u00e1ndose en el historial de commits en Git:<\/p>\n<ul>\n<li> Conservar no m\u00e1s de N1 im\u00e1genes relacionadas con los N2 \u00faltimos commits para cada uno de los git HEAD (ramas y etiquetas).<\/li>\n<li> Conservar no m\u00e1s de N1 im\u00e1genes etapa relacionadas con los N2 \u00faltimos commits para cada uno de los git HEAD (ramas y etiquetas).<\/li>\n<li> Almacenar todas las im\u00e1genes que se utilizan en alg\u00fan recurso del cl\u00faster Kubernetes (se escanean todos los kube-contextos del archivo de configuraci\u00f3n y los namespaces; se puede limitar este comportamiento con opciones espec\u00edficas).<\/li>\n<li> Conservar todas las im\u00e1genes que se utilizan en los manifiestos de configuraci\u00f3n de recursos guardados en lanzamientos de Helm.<\/li>\n<li> Una imagen puede ser eliminada si no est\u00e1 relacionada con ning\u00fan HEAD de git (por ejemplo, porque el HEAD correspondiente fue eliminado) y no se utiliza en ning\u00fan manifiesto en el cl\u00faster de Kubernetes ni en lanzamientos de Helm.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Construcci\u00f3n paralela de im\u00e1genes (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versi\u00f3n: v1.1<\/i><\/li>\n<li> <i>Fechas: enero-febrero abril*<\/i><\/li>\n<\/ul>\n<p>\nLa versi\u00f3n actual de werf construye im\u00e1genes y artefactos descritos en <code>werf.yaml<\/code>, secuencialmente. Es necesario paralelizar el proceso de construcci\u00f3n de etapas independientes de im\u00e1genes y artefactos, as\u00ed como proporcionar una salida c\u00f3moda e informativa.<\/p>\n<p><i>* Nota: la fecha se ha desplazado debido a la priorizaci\u00f3n de la implementaci\u00f3n de la construcci\u00f3n distribuida, que a\u00f1adir\u00e1 m\u00e1s capacidades de escalado horizontal, as\u00ed como el uso de werf con GitHub Actions. La construcci\u00f3n paralela es el siguiente paso en la optimizaci\u00f3n, que proporciona escalabilidad vertical al construir un solo proyecto.<\/i><\/p>\n<h3>Migraci\u00f3n a Helm 3 (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versi\u00f3n: v1.2<\/i><\/li>\n<li> <i>Fechas: febrero-marzo mayo*<\/i><\/li>\n<\/ul>\n<p>\nIncluye la migraci\u00f3n a una nueva base de c\u00f3digo <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/news\/t\/475722\/\">Helm 3<\/a><\/noindex> y un m\u00e9todo comprobado y conveniente para migrar instalaciones existentes.<\/p>\n<p><i>* Nota: la transici\u00f3n a Helm 3 no a\u00f1adir\u00e1 capacidades significativas a werf, ya que todas las caracter\u00edsticas clave de Helm 3 (3-way-merge y la ausencia de tiller) ya est\u00e1n implementadas en werf. Adem\u00e1s, werf tiene <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/documentation\/reference\/deploy_process\/differences_with_helm.html\">capacidades adicionales<\/a><\/noindex> adem\u00e1s de las mencionadas. Sin embargo, esta transici\u00f3n permanece en nuestros planes y se llevar\u00e1 a cabo.<\/i><\/p>\n<h3>Jsonnet para describir la configuraci\u00f3n de Kubernetes (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versi\u00f3n: v1.2<\/i><\/li>\n<li> <i>Fechas: enero-febrero abril-mayo<\/i><\/li>\n<\/ul>\n<p>\nWerf soportar\u00e1 la descripci\u00f3n de la configuraci\u00f3n para Kubernetes en formato Jsonnet. Al mismo tiempo, werf seguir\u00e1 siendo compatible con Helm, permitiendo la elecci\u00f3n del formato de descripci\u00f3n.<\/p>\n<p>La raz\u00f3n es que las plantillas del lenguaje Go, seg\u00fan la opini\u00f3n de muchas personas, tienen un alto umbral de entrada, y la claridad del c\u00f3digo de estas plantillas tambi\u00e9n se ve afectada.<\/p>\n<p>Tambi\u00e9n se est\u00e1 considerando la posibilidad de implementar otros sistemas de descripci\u00f3n de la configuraci\u00f3n de Kubernetes (por ejemplo, Kustomize).<\/p>\n<h3>Trabajo dentro de Kubernetes (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Versi\u00f3n: v1.2<\/i><\/li>\n<li> <i>Fechas: abril-mayo mayo-junio<\/i><\/li>\n<\/ul>\n<p>\nObjetivo: asegurar la construcci\u00f3n de im\u00e1genes y el despliegue de aplicaciones utilizando runners en Kubernetes. Es decir, la construcci\u00f3n de nuevas im\u00e1genes, su publicaci\u00f3n, limpieza y despliegue pueden ocurrir directamente desde los pods de Kubernetes.<\/p>\n<p>Para implementar esta capacidad, se requiere primero la posibilidad de construcci\u00f3n distribuida de im\u00e1genes <i>(ver punto anterior)<\/i>.<\/p>\n<p>Tambi\u00e9n se requiere soporte para el modo de operaci\u00f3n del constructor sin un servidor Docker (es decir, construcci\u00f3n similar a Kaniko o construcci\u00f3n en userspace).<\/p>\n<p>Werf apoyar\u00e1 la construcci\u00f3n en Kubernetes no solo mediante Dockerfile, sino tambi\u00e9n a trav\u00e9s de su propio constructor Stapel con recompilaciones incrementales y Ansible.<\/p>\n<h2>Un paso hacia el desarrollo abierto<\/h2>\n<p>\nNos encanta nuestra comunidad (<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">GitHub<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/t.me\/werf_ru\">Telegram<\/a><\/noindex>) y queremos que cada vez m\u00e1s personas ayuden a mejorar werf, comprendan en qu\u00e9 direcci\u00f3n nos movemos y participen en el desarrollo.<\/p>\n<p>Recientemente se decidi\u00f3 hacer la transici\u00f3n a <noindex><a rel=\"nofollow\" href=\"https:\/\/help.github.com\/en\/github\/managing-your-work-on-github\/about-project-boards\">tableros de proyectos de GitHub<\/a><\/noindex> para abrir un poco el proceso de trabajo de nuestro equipo. Ahora se pueden ver los planes inmediatos, as\u00ed como los trabajos actuales en las siguientes \u00e1reas:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/9\">Documentaci\u00f3n y Sitio<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/7\">Pruebas<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/6\">Fallos y Mala UX<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/5\">1.1<\/a><\/noindex>.<\/li>\n<\/ul>\n<p>\nSe ha realizado un gran trabajo con los issues:<\/p>\n<ul>\n<li> Se han eliminado los no relevantes.<\/li>\n<li> Los existentes se han unificado en un formato, con un n\u00famero suficiente de detalles y precisiones.<\/li>\n<li> Se han a\u00f1adido nuevos issues con ideas y sugerencias.<\/li>\n<\/ul>\n<p><\/p>\n<h2>C\u00f3mo habilitar la versi\u00f3n v1.1<\/h2>\n<p>\nLa versi\u00f3n est\u00e1 disponible actualmente en <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf#backward-compatibility-promise\">el canal 1.1 ea<\/a><\/noindex> (en los canales <i>stable<\/i> y <i>rock-solid<\/i> los lanzamientos aparecer\u00e1n a medida que se estabilicen, sin embargo, <i>ea<\/i> ya es bastante estable para su uso, ya que ha pasado por canales. <i>alpha<\/i> y <i>beta<\/i>). Se activa <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/guides\/installation.html#%D1%81%D0%BF%D0%BE%D1%81%D0%BE%D0%B1-1-%D1%80%D0%B5%D0%BA%D0%BE%D0%BC%D0%B5%D0%BD%D0%B4%D1%83%D0%B5%D0%BC%D1%8B%D0%B9-multiwerf\">a trav\u00e9s de multiwerf<\/a><\/noindex> de la siguiente manera:<\/p>\n<pre><code class=\"bash\">source $(multiwerf use 1.1 ea)\nwerf COMMAND ...<\/code><\/pre>\n<p><\/p>\n<h2>Conclusi\u00f3n<\/h2>\n<p>\nLa nueva arquitectura del almacenamiento de etapas y la optimizaci\u00f3n del trabajo del constructor para Stapel y Dockerfile abren oportunidades para realizar construcciones distribuidas y paralelas en werf. Estas funciones estar\u00e1n disponibles pronto en la misma versi\u00f3n v1.1 y se activar\u00e1n autom\u00e1ticamente a trav\u00e9s del mecanismo de actualizaciones autom\u00e1ticas (para los usuarios <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/guides\/installation.html#%D1%81%D0%BF%D0%BE%D1%81%D0%BE%D0%B1-1-%D1%80%D0%B5%D0%BA%D0%BE%D0%BC%D0%B5%D0%BD%D0%B4%D1%83%D0%B5%D0%BC%D1%8B%D0%B9-multiwerf\">multiwerf<\/a><\/noindex>). <\/p>\n<p>En esta versi\u00f3n se ha a\u00f1adido una estrategia de etiquetado por el contenido de las im\u00e1genes \u2014 <i>etiquetado basado en contenido<\/i>, \u2014 que se convirti\u00f3 en la estrategia por defecto. Tambi\u00e9n se ha reestructurado el registro de los comandos principales: <code>werf build<\/code>, <code>werf publish<\/code>, <code>werf deploy<\/code>, <code>werf dismiss<\/code>, <code>werf cleanup<\/code>.<\/p>\n<p>El siguiente paso importante ser\u00e1 la adici\u00f3n de construcciones distribuidas. Las construcciones distribuidas se han convertido en una tarea prioritaria desde la v1.0, m\u00e1s que las construcciones paralelas, porque aportan m\u00e1s valor a werf: escalado vertical de los constructores y soporte para constructores ef\u00edmeros en varios sistemas CI\/CD, as\u00ed como la posibilidad de ofrecer soporte oficial para GitHub Actions. Por lo tanto, el plazo para implementar construcciones paralelas se ha pospuesto. Sin embargo, estamos trabajando para implementar ambas funciones lo antes posible.<\/p>\n<p>\u00a1Mantente atento a las novedades! Y no olvides visitarnos en <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">GitHub<\/a><\/noindex>, para crear un issue, encontrar uno ya existente y darle un like, crear un PR o simplemente seguir 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\/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\/493170\/\">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. \u041a\u0430\u043a \u0438 \u043e\u0431\u0435\u0449\u0430\u043b\u0438, \u0432\u044b\u0445\u043e\u0434 \u0432\u0435\u0440\u0441\u0438\u0438 v1.0 \u0437\u043d\u0430\u043c\u0435\u043d\u043e\u0432\u0430\u043b \u043d\u0430\u0447\u0430\u043b\u043e \u0434\u043e\u0431\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u0432 werf \u043d\u043e\u0432\u044b\u0445 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u0435\u0439 \u0438 \u043f\u0435\u0440\u0435\u0441\u043c\u043e\u0442\u0440\u0430 \u043f\u0440\u0438\u0432\u044b\u0447\u043d\u044b\u0445 \u043f\u043e\u0434\u0445\u043e\u0434\u043e\u0432. \u0422\u0435\u043f\u0435\u0440\u044c \u043c\u044b \u0440\u0430\u0434\u044b \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u0442\u044c \u0440\u0435\u043b\u0438\u0437 v1.1, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0431\u043e\u043b\u044c\u0448\u0438\u043c \u0448\u0430\u0433\u043e\u043c \u0432 \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u0438 \u0438 \u0437\u0430\u0434\u0435\u043b\u043e\u043c \u043d\u0430 \u0431\u0443\u0434\u0443\u0449\u0435\u0435 \u0441\u0431\u043e\u0440\u0449\u0438\u043a\u0430 werf. \u0412\u0435\u0440\u0441\u0438\u044f \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u0430 \u043d\u0430 \u0434\u0430\u043d\u043d\u044b\u0439 \u043c\u043e\u043c\u0435\u043d\u0442 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":76765,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-76764","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\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee\" \/>\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\udd47\u0420\u0435\u043b\u0438\u0437 werf 1.1: \u0443\u043b\u0443\u0447\u0448\u0435\u043d\u0438\u044f \u0432 \u0441\u0431\u043e\u0440\u0449\u0438\u043a\u0435 \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u0438 \u043f\u043b\u0430\u043d\u044b \u043d\u0430 \u0431\u0443\u0434\u0443\u0449\u0435\u0435 | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee\" \/>\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:24+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-04-04T11:42:24+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\udd47Lanzamiento de werf 1.1: mejoras en el constructor hoy y planes para el futuro | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee","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\udd47\u0420\u0435\u043b\u0438\u0437 werf 1.1: \u0443\u043b\u0443\u0447\u0448\u0435\u043d\u0438\u044f \u0432 \u0441\u0431\u043e\u0440\u0449\u0438\u043a\u0435 \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u0438 \u043f\u043b\u0430\u043d\u044b \u043d\u0430 \u0431\u0443\u0434\u0443\u0449\u0435\u0435 | ProHoster","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee","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:24+00:00","article:modified_time":"2020-04-04T11:42:24+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"76764","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:23","updated":"2022-09-28 14:39:02","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\/76764","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=76764"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/76764\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/76765"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=76764"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=76764"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=76764"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}