— nuestra herramienta CLI de GitOps de código abierto para la construcción y entrega de aplicaciones en Kubernetes. Como prometimos, marcó el inicio de la adición de nuevas capacidades a werf y la revisión 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 constructor werf. La versión está disponible actualmente en .
La base del lanzamiento es una nueva arquitectura de almacenamiento de etapas y la optimización 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.
La optimización del trabajo incluye la eliminación de cálculos innecesarios en la etapa de cálculo de las firmas de las etapas y el cambio de los mecanismos de cálculo de sumas de verificación de archivos a versiones más eficientes. Esta optimización reduce el tiempo promedio de compilación del proyecto con werf. Y las compilaciones en vacío, cuando todas las etapas existen en la caché stages-storage, ahora son realmente rápidas. En la mayoría de los casos, reiniciar la compilación tomará menos de 1 segundo. Esto también se aplica a los procedimientos de verificación de etapas durante el trabajo de los equipos werf deploy y werf run.
También en este lanzamiento se introdujo una estrategia de etiquetado de imágenes basada en contenido — etiquetado basado en contenido, que ahora está habilitada por defecto y es la única recomendada.
Veamos en detalle las novedades clave en werf v1.1, y también comentaremos sobre los planes futuros.
¿Qué ha cambiado en werf v1.1?
Nuevo formato de nomenclatura de etapas y algoritmo de selección de etapas desde la caché
Nueva regla para la generación del nombre de una etapa. Ahora, cada compilación de una etapa genera un nombre único, que consta de dos partes: la firma (como era en v1.0) más un identificador temporal único.
Por ejemplo, el nombre completo de la imagen de la etapa puede verse así:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
… o en su forma general:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Aquí:
-
SIGNATURE— 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; -
TIMESTAMP_MILLISEC— es un identificador de imagen garantizado como único, que se genera en el momento de construir una nueva imagen.
El algoritmo de selección de etapas desde la caché se basa en la verificación de la relación entre los commits de Git:
- Werf calcula la firma de una etapa determinada.
- En stages-storage puede haber varias etapas con esta firma. Werf selecciona todas las etapas adecuadas según la firma.
- Si la etapa actual está relacionada con Git (git-archive, etapa personalizada con parches de Git:
install,beforeSetup,configuración; o git-latest-patch), entonces werf elige solo aquellas etapas que están relacionadas con el commit que es antecesor del commit actual (para el cual se invocó la construcción). - De las etapas restantes adecuadas, se selecciona una: la más antigua por fecha de creación.
Las etapas para diferentes ramas de Git pueden tener la misma firma. Pero werf evitará el uso de la caché relacionada con diferentes ramas entre sí, incluso si las firmas coinciden.
.
Nuevo algoritmo para crear y guardar etapas en el almacenamiento de etapas
Si durante la búsqueda de etapas en la caché werf no encuentra una etapa adecuada, se inicia el proceso de construcción de una nueva etapa.
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 stages-storage en el momento de guardar la imagen recién construida en stages-storage. Así, cuando se complete la construcción de una nueva etapa, werf bloqueará stages-storage y guardará la imagen recién construida solo si no existe ya una imagen adecuada allí (según la firma y otros parámetros — ver nuevo algoritmo de selección de etapas de la caché).
La imagen recién construida tendrá garantizado un identificador único según TIMESTAMP_MILLISEC (ver nuevo formato de nombrado de etapas). En caso de que se encuentre una imagen adecuada en stages-storage , werf descartará la imagen recién construida y utilizará la imagen de la caché.
En otras palabras: el primer proceso que termine de construir la imagen (el más rápido) tendrá el derecho de guardarla en stages-storage (y luego esta única imagen será utilizada para todas las construcciones). El proceso de construcción más lento nunca bloqueará a un proceso más rápido de guardar los resultados de la construcción de la etapa actual y pasar a construir la siguiente.
.
Mejorado el rendimiento del constructor de Dockerfile
En este momento, el canal de etapas para la imagen construida a partir del Dockerfile consiste en una sola etapa — dockerfile. Al calcular la firma se considera el hash de los archivos contexto, que se utilizarán durante la construcción. Antes de esta mejora, werf recorría recursivamente todos los archivos y obtenía un hash de verificación, sumando el contexto y el modo de cada archivo. Desde las versiones v1.1, werf puede utilizar los hashes de verificación calculados que se almacenan en el repositorio de Git.
La base del algoritmo es . El algoritmo considera registros en .dockerignore y recorre recursivamente el árbol 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ño contexto no es significativa.
Además, el algoritmo verifica archivos no rastreados y, si es necesario, los incluye en el hash de verificación.
Se ha mejorado el rendimiento al importar archivos
En las versiones de werf v1.1 se utiliza un servidor rsync para . Anteriormente, la importación se realizaba en dos pasos utilizando el montaje de un directorio desde el sistema host.
El rendimiento de las importaciones en macOS ya no está limitado a los volúmenes de Docker, y las importaciones se ejecutan en el mismo tiempo que en Linux y Windows.
Etiquetado basado en contenido
Werf v1.1 admite lo que se llama etiquetado por contenido de la imagen — etiquetado basado en contenido. Las etiquetas de las imágenes Docker resultantes dependen del contenido de esas imágenes.
Al ejecutar el comando werf publish --tags-by-stages-signature o werf ci-env --tagging-strategy=stages-signature se etiquetarán las imágenes publicadas con lo que se denomina firma de etapas de la imagen. Cada imagen se etiqueta con su propia firma de etapas de esa imagen, que se calcula según las mismas reglas que la firma regular de cada etapa por separado, pero es un identificador general de la imagen.
La firma de etapas de la imagen depende de:
- el contenido de esta imagen;
- la historia de los cambios en Git, que condujeron a este contenido.
En el repositorio de Git siempre hay commits vacíos 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án importados en la imagen.
El uso del etiquetado basado en contenido resuelve problemas de reinicios innecesarios de los pods de la aplicación 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 impide almacenar múltiples microservicios de una sola aplicación en un único repositorio de Git.
Además, el etiquetado basado en contenido es un método de etiquetado más confiable que el etiquetado por ramas de Git, ya que el contenido de las imágenes resultantes no depende del orden de ejecución de los pipelines en el sistema CI para construir múltiples commits de la misma rama.
Importante: a partir de este momento stages-signature — es la única estrategia recomendada para el etiquetado. Esta será la que se utilizará por defecto en el equipo werf ci-env (a menos que se indique explícitamente otro esquema de etiquetado).
. Esta característica también tendrá una publicación dedicada. ACTUALIZADO (3 de abril): Artículo con detalles .
Niveles de registro
El usuario tiene la posibilidad de controlar la salida, establecer el nivel de registro y trabajar con información de depuración. Se han añadido las opciones --log-quiet, --log-verbose, --log-debug.
Por defecto, la salida contiene la mínima información:
Al usar salida detallada (--log-verbose) se puede ver cómo funciona werf:
La salida detallada (--log-debug), además de la información de depuración de werf, también contiene los logs de las bibliotecas utilizadas. Por ejemplo, se puede ver cómo se interactúa con el Docker Registry, así como registrar los lugares donde se gastan tiempos significativos:
Planes futuros
¡Atención! Las capacidades descritas a continuación con la etiqueta v1.1 estarán disponibles en esta versión, muchas de ellas en breve. Las actualizaciones llegarán a través de actualizaciones automáticas . Estas capacidades no afectan la parte estable de las funciones v1.1, su aparición no requerirá intervención manual del usuario en las configuraciones existentes.
Soporte completo para diversas implementaciones de Docker Registry (NUEVO)
- Versión: v1.1
- Cronograma: marzo
El objetivo es que el usuario deba utilizar cualquier implementación sin restricciones al usar werf.
En este momento, hemos identificado el siguiente conjunto de soluciones para las cuales garantizaremos soporte completo:
- Default (library/registry)*,
- AWS ECR,
- Azure*,
- Docker Hub,
- GCR*,
- GitHub Packages,
- GitLab Registry*,
- Harbor*,
- Quay.
La estrella marca las soluciones que actualmente ya son totalmente compatibles con werf. Para los demás hay soporte, pero con limitaciones.
Se pueden identificar dos problemas principales:
- Algunas soluciones no soportan la eliminación de etiquetas mediante la API de Docker Registry, lo que impide que los usuarios utilicen la limpieza automática implementada en werf. Esto es cierto para AWS ECR, Docker Hub y GitHub Packages.
- 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).
Vamos a abordar estos y otros problemas utilizando las API nativas de las soluciones. Esta tarea también implica cubrir con pruebas el ciclo completo de trabajo de werf para cada una de ellas.
Construcción distribuida de imágenes (↑)
- Versión: v1.2 v1.1 (se ha aumentado la prioridad para implementar esta funcionalidad)
- Tiempos: marzo-abril marzo
Actualmente, werf v1.0 y v1.1 solo se pueden utilizar en un único host dedicado para operaciones de construcción y publicación de imágenes y despliegue de aplicaciones en Kubernetes.
Para habilitar la trabajo distribuido de werf, donde la construcción 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.
Anteriormente, cuando el proyecto werf aún se llamaba dapp, existía tal capacidad. Sin embargo, nos encontramos con una serie de problemas que deben tenerse en cuenta al implementar esta función en werf.
Nota. Esta funcionalidad no implica el trabajo del constructor dentro de pods de Kubernetes, ya que para ello es necesario eliminar la dependencia del servidor Docker local (no hay acceso al servidor Docker local en el pod de Kubernetes, ya que el propio proceso se ejecuta en un contenedor, y werf no admite ni admitirá el trabajo con el servidor Docker a través de la red). El soporte para trabajar en Kubernetes se implementará por separado.
Soporte oficial para GitHub Actions (NUEVO)
- Versión: v1.1
- Cronograma: marzo
Incluye la documentación de werf (secciones reference y guía), así como una acción oficial de GitHub para trabajar con werf.
Además, permitirá que werf funcione en runners efímeros.
La mecánica de interacción del usuario con el sistema CI se basará en el etiquetado de pull requests para iniciar ciertas acciones de construcción/despliegue de la aplicación.
Desarrollo y despliegue locales de aplicaciones con werf (↓)
- Versión: v1.1
- Tiempos: enero-febrero abril
El objetivo principal es lograr una configuración unificada y homogénea para el despliegue de aplicaciones tanto localmente como en producción, sin acciones complicadas, ‘listo para usar’.
También se requiere de werf un modo de operación que facilite la edición del código de la aplicación y proporcione una retroalimentación instantánea de la aplicación en funcionamiento para depuración.
Nuevo algoritmo de limpieza (NUEVO)
- Versión: v1.1
- Fechas: abril
En la versión actual de werf v1.1 en el procedimiento cleanup no se prevé la limpieza de imágenes para el esquema de etiquetado basado en contenido (content-based tagging) — estas imágenes se acumularán.
Además, en la versión actual de werf (v1.0 y v1.1) se utilizan diferentes políticas de limpieza para imágenes publicadas bajo esquemas de etiquetado: rama de Git, etiqueta de Git o commit de Git.
Se ha ideado un nuevo algoritmo unificado para todos los esquemas de etiquetado que limpia imágenes basándose en el historial de commits en Git:
- Conservar no más de N1 imágenes relacionadas con los N2 últimos commits para cada uno de los git HEAD (ramas y etiquetas).
- Conservar no más de N1 imágenes etapa relacionadas con los N2 últimos commits para cada uno de los git HEAD (ramas y etiquetas).
- Conservar todas las imágenes que se utilizan en recursos del clúster de Kubernetes (se escanean todos los kube-contextos del archivo de configuración y namespaces; se puede restringir este comportamiento con opciones específicas).
- Conservar todas las imágenes que se utilizan en los manifiestos de configuración de recursos guardados en lanzamientos de Helm.
- Una imagen puede ser eliminada si no está relacionada con ningún HEAD de git (por ejemplo, porque el HEAD correspondiente fue eliminado) y no se utiliza en ningún manifiesto en el clúster de Kubernetes ni en lanzamientos de Helm.
Construcción paralela de imágenes (↓)
- Versión: v1.1
- Fechas: enero-febrero abril*
La versión actual de werf construye imágenes y artefactos descritos en werf.yaml, secuencialmente. Es necesario paralelizar el proceso de construcción de etapas independientes de imágenes y artefactos, así como proporcionar una salida cómoda e informativa.
* Nota: la fecha se ha desplazado debido a la priorización de la implementación de la construcción distribuida, que añadirá más capacidades de escalado horizontal, así como el uso de werf con GitHub Actions. La construcción paralela es el siguiente paso en la optimización, que proporciona escalabilidad vertical al construir un solo proyecto.
Migración a Helm 3 (↓)
- Versión: v1.2
- Fechas: febrero-marzo mayo*
Incluye la migración a una nueva base de código y un método comprobado y conveniente para migrar instalaciones existentes.
* Nota: la transición a Helm 3 no añadirá capacidades significativas a werf, ya que todas las características clave de Helm 3 (3-way-merge y la ausencia de tiller) ya están implementadas en werf. Además, werf tiene además de las mencionadas. Sin embargo, esta transición permanece en nuestros planes y se llevará a cabo.
Jsonnet para describir la configuración de Kubernetes (↓)
- Versión: v1.2
- Fechas: enero-febrero abril-mayo
Werf soportará la descripción de la configuración para Kubernetes en formato Jsonnet. Al mismo tiempo, werf seguirá siendo compatible con Helm, permitiendo la elección del formato de descripción.
La razón es que las plantillas del lenguaje Go, según la opinión de muchas personas, tienen un alto umbral de entrada, y la claridad del código de estas plantillas también se ve afectada.
También se está considerando la posibilidad de implementar otros sistemas de descripción de la configuración de Kubernetes (por ejemplo, Kustomize).
Trabajo dentro de Kubernetes (↓)
- Versión: v1.2
- Fechas: abril-mayo mayo-junio
Objetivo: asegurar la construcción de imágenes y el despliegue de aplicaciones utilizando runners en Kubernetes. Es decir, la construcción de nuevas imágenes, su publicación, limpieza y despliegue pueden ocurrir directamente desde los pods de Kubernetes.
Para implementar esta capacidad, se requiere primero la posibilidad de construcción distribuida de imágenes (ver punto anterior).
También se requiere soporte para el modo de operación del constructor sin un servidor Docker (es decir, construcción similar a Kaniko o construcción en userspace).
Werf apoyará la construcción en Kubernetes no solo mediante Dockerfile, sino también a través de su propio constructor Stapel con recompilaciones incrementales y Ansible.
Un paso hacia el desarrollo abierto
Nos encanta nuestra comunidad (, ) y queremos que cada vez más personas ayuden a mejorar werf, comprendan en qué dirección nos movemos y participen en el desarrollo.
Recientemente se decidió hacer la transición a para abrir un poco el proceso de trabajo de nuestro equipo. Ahora se pueden ver los planes inmediatos, así como los trabajos actuales en las siguientes áreas:
- ;
- ;
- ;
- .
Se ha realizado un gran trabajo con los issues:
- Se han eliminado los no relevantes.
- Los existentes se han unificado en un formato, con un número suficiente de detalles y precisiones.
- Se han añadido nuevos issues con ideas y sugerencias.
Cómo habilitar la versión v1.1
La versión está disponible actualmente en (en los canales stable y rock-solid los lanzamientos aparecerán a medida que se estabilicen, sin embargo, ea ya es bastante estable para su uso, ya que ha pasado por canales. alpha y beta). Se activa de la siguiente manera:
source $(multiwerf use 1.1 ea)
werf COMMAND ...Conclusión
La nueva arquitectura del almacenamiento de etapas y la optimización del trabajo del constructor para Stapel y Dockerfile abren oportunidades para realizar construcciones distribuidas y paralelas en werf. Estas funciones estarán disponibles pronto en la misma versión v1.1 y se activarán automáticamente a través del mecanismo de actualizaciones automáticas (para los usuarios ).
En esta versión se ha añadido una estrategia de etiquetado por el contenido de las imágenes — etiquetado basado en contenido, — que se convirtió en la estrategia por defecto. También se ha reestructurado el registro de los comandos principales: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
El siguiente paso importante será la adición de construcciones distribuidas. Las construcciones distribuidas se han convertido en una tarea prioritaria desde la v1.0, más que las construcciones paralelas, porque aportan más valor a werf: escalado vertical de los constructores y soporte para constructores efímeros en varios sistemas CI/CD, así 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.
¡Mantente atento a las novedades! Y no olvides visitarnos en , para crear un issue, encontrar uno ya existente y darle un like, crear un PR o simplemente seguir el desarrollo del proyecto.
P.D.
También puedes leer en nuestro blog:
- «»
- «»;
- Ciclo de notas sobre novedades en werf:
- «»;
- «»;
- «»;
- «».
Fuente: habr.com
