es nuestra utilidad GitOps CLI de código abierto para crear y entregar aplicaciones a Kubernetes. Como fue prometido, marcó el comienzo de agregar nuevas características a werf y revisar los enfoques tradicionales. Ahora nos complace presentar la versión v1.1, que es un gran paso en el desarrollo y una base para el futuro. coleccionista werf. La versión está actualmente disponible en .
La base del lanzamiento es la nueva arquitectura de almacenamiento escénico y la optimización del trabajo de ambos recopiladores (para Stapel y Dockerfile). La nueva arquitectura de almacenamiento abre la posibilidad de implementar ensamblajes distribuidos desde múltiples hosts y ensamblajes paralelos en el mismo host.
La optimización del trabajo incluye deshacerse de cálculos innecesarios en la etapa de cálculo de firmas de etapa y cambiar los mecanismos para calcular las sumas de verificación de archivos por otros más eficientes. Esta optimización reduce el tiempo promedio de construcción de proyectos utilizando werf. Y compilaciones inactivas, cuando todas las etapas existen en el caché. almacenamiento-etapas, ahora son realmente rápidos. ¡En la mayoría de los casos, reiniciar la compilación tardará menos de 1 segundo! Esto también se aplica a los procedimientos de verificación de etapas en el proceso de trabajo de los equipos. werf deploy и werf run.
También en esta versión, apareció una estrategia para etiquetar imágenes por contenido: etiquetado basado en contenido, que ahora está habilitado de forma predeterminada y el único recomendado.
Echemos un vistazo más de cerca a las innovaciones clave en werf v1.1 y, al mismo tiempo, le informaremos sobre los planes para el futuro.
¿Qué ha cambiado en werf v1.1?
Nuevo formato de denominación de etapas y algoritmo para seleccionar etapas del caché
Nueva regla de generación de nombres artísticos. Ahora cada compilación de etapa genera un nombre artístico único, que consta de 2 partes: una firma (como lo era en la versión 1.0) más un identificador temporal único.
Por ejemplo, el nombre completo de la imagen del escenario podría verse así:
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
...o en general:
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Aquí:
-
SIGNATUREes una firma de etapa, que representa el identificador del contenido de la etapa y depende del historial de ediciones en Git que llevaron a este contenido; -
TIMESTAMP_MILLISECes un identificador de imagen único garantizado que se genera en el momento en que se crea una nueva imagen.
El algoritmo para seleccionar etapas del caché se basa en verificar la relación de las confirmaciones de Git:
- Werf calcula la firma de una determinada etapa.
- В almacenamiento-etapas Puede haber varias etapas para una firma determinada. Werf selecciona todas las etapas que coinciden con la firma.
- Si la etapa actual está vinculada a Git (git-archive, etapa personalizada con parches de Git:
install,beforeSetup,setup; o git-latest-patch), luego werf selecciona solo aquellas etapas que están asociadas con una confirmación que es un antecesor de la confirmación actual (para la cual se llama la compilación). - De las etapas restantes adecuadas, se selecciona una: la más antigua por fecha de creación.
Un escenario para diferentes ramas de Git puede tener la misma firma. Pero werf evitará que el caché asociado con diferentes ramas se use entre estas ramas, incluso si las firmas coinciden.
.
Nuevo algoritmo para crear y guardar etapas en el almacenamiento de etapas.
Si, al seleccionar etapas del caché, werf no encuentra una etapa adecuada, se inicia el proceso de ensamblaje de una nueva etapa.
Tenga en cuenta que varios procesos (en uno o más hosts) pueden comenzar a crear la misma etapa aproximadamente al mismo tiempo. Werf utiliza un algoritmo de bloqueo optimista almacenamiento-etapas en el momento de guardar la imagen recién recopilada en almacenamiento-etapas. De esta manera, cuando la construcción del nuevo escenario esté lista, los bloques werf almacenamiento-etapas y guarda una imagen recién recopilada allí solo si ya no existe una imagen adecuada allí (por firma y otros parámetros; consulte el nuevo algoritmo para seleccionar etapas del caché).
Se garantiza que una imagen recién ensamblada tendrá un identificador único mediante TIMESTAMP_MILLISEC (ver nuevo formato de nomenclatura de etapa). En caso de almacenamiento-etapas Se encontrará una imagen adecuada, werf descartará la imagen recién compilada y utilizará la imagen del caché.
En otras palabras: el primer proceso que termine de construir la imagen (el más rápido) obtendrá el derecho de almacenarla en etapas de almacenamiento (y luego será esta única imagen la que se utilizará para todas las compilaciones). Un proceso de compilación lento nunca impedirá que un proceso más rápido guarde los resultados de la compilación de la etapa actual y pase a la siguiente compilación.
.
Rendimiento mejorado del generador Dockerfile
Por el momento, el proceso de etapas para una imagen creada a partir de un Dockerfile consta de una etapa: dockerfile. Al calcular la firma, se calcula la suma de verificación de los archivos. context, que se utilizará durante el montaje. Antes de esta mejora, werf recorría recursivamente todos los archivos y obtenía una suma de comprobación sumando el contexto y el modo de cada archivo. A partir de la versión 1.1, werf puede utilizar sumas de comprobación calculadas almacenadas en un repositorio Git.
El algoritmo se basa en . El algoritmo tiene en cuenta los registros en .dockerignore y atraviesa el árbol de archivos de forma recursiva sólo cuando es necesario. Por lo tanto, nos hemos desacoplado de la lectura del sistema de archivos y de la dependencia del algoritmo del tamaño. context no es significativo.
El algoritmo también comprueba los archivos sin seguimiento y, si es necesario, los tiene en cuenta en la suma de comprobación.
Rendimiento mejorado al importar archivos
Las versiones de werf v1.1 utilizan un servidor rsync cuando . Anteriormente, la importación se realizaba en dos pasos mediante un montaje de directorio desde el sistema host.
El rendimiento de las importaciones en macOS ya no está limitado por los volúmenes de Docker y las importaciones se completan en la misma cantidad de tiempo que Linux y Windows.
Etiquetado basado en contenido
Werf v1.1 admite el llamado etiquetado por contenido de imagen: etiquetado basado en contenido. Las etiquetas de las imágenes de Docker resultantes dependen del contenido de estas imágenes.
Al ejecutar el comando werf publish --tags-by-stages-signature o werf ci-env --tagging-strategy=stages-signature imágenes publicadas del llamado firma escénica imagen. Cada imagen está etiquetada con su propia firma de las etapas de esta imagen, que se calcula de acuerdo con las mismas reglas que la firma normal de cada etapa por separado, pero es un identificador general de la imagen.
La firma de las etapas de la imagen depende de:
- el contenido de esta imagen;
- Historias de los cambios de Git que llevaron a este contenido.
Un repositorio Git siempre tiene confirmaciones ficticias que no cambian el contenido de los archivos de imagen. Por ejemplo, confirmaciones con solo comentarios o confirmaciones de fusión, o confirmaciones que cambian aquellos archivos en Git que no se importarán a la imagen.
Cuando se utiliza el etiquetado basado en contenido, se resuelven los problemas de reinicios innecesarios de los pods de aplicaciones 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 muchos microservicios de una 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 en ramas de Git, porque el contenido de las imágenes resultantes no depende del orden en que se ejecutan las canalizaciones en el sistema CI para ensamblar múltiples confirmaciones de la misma rama.
Es importante: empezando desde ahora firma-etapas - es la única estrategia de etiquetado recomendada. Se utilizará por defecto en el comando. werf ci-env (a menos que especifique explícitamente un esquema de etiquetado diferente).
. También se dedicará una publicación separada a esta característica. ACTUALIZADO (3 de abril): Artículo con detalles .
Niveles de registro
El usuario ahora tiene la oportunidad de controlar la salida, establecer el nivel de registro y trabajar con información de depuración. Opciones agregadas --log-quiet, --log-verbose, --log-debug.
De forma predeterminada, la salida contiene la información mínima:
Cuando se utiliza salida detallada (--log-verbose) puedes ver cómo funciona werf:
Salida detallada (--log-debug), además de información de depuración de werf, también contiene registros de bibliotecas utilizadas. Por ejemplo, puede ver cómo se produce la interacción con Docker Registry y también registrar los lugares donde se pasa una cantidad significativa de tiempo:
Planes adicionales
¡Atención! Las opciones que se describen a continuación están marcadas v1.1 Estarán disponibles en esta versión, muchas de ellas en un futuro próximo. Las actualizaciones se realizarán mediante actualizaciones automáticas. . Estas características no afectan la parte estable de las funciones v1.1; su apariencia no requerirá la intervención manual del usuario en las configuraciones existentes.
Soporte completo para varias implementaciones de Docker Registry (NUEVO)
- Versión: v1.1
- Fechas: marzo
El objetivo es que el usuario utilice una implementación personalizada sin restricciones al utilizar werf.
Actualmente, hemos identificado el siguiente conjunto de soluciones para las cuales vamos a garantizar soporte total:
- Predeterminado (biblioteca/registro)*,
- AWS ECR
- Azur*,
- Centro acoplable
- RCG*,
- Paquetes de GitHub
- Registro GitLab*,
- Puerto*,
- Muelle.
Las soluciones que actualmente son totalmente compatibles con werf están marcadas con un asterisco. Para otros hay apoyo, pero con limitaciones.
Se pueden identificar dos problemas principales:
- Algunas soluciones no admiten la eliminación de etiquetas mediante la API de Docker Registry, lo que impide que los usuarios utilicen la limpieza automática de werf. Esto es válido para los paquetes AWS ECR, Docker Hub y GitHub.
- Algunas soluciones no admiten los llamados repositorios anidados (Docker Hub, GitHub Packages y Quay) o lo hacen, pero el usuario debe crearlos manualmente utilizando la UI o API (AWS ECR).
Vamos a solucionar estos y otros problemas utilizando las API nativas de las soluciones. Esta tarea también incluye cubrir el ciclo completo de funcionamiento del werf con pruebas para cada uno de ellos.
Creación de imágenes distribuidas ( ↑ )
- Versión: v1.2 v1.1 (se ha aumentado la prioridad para implementar esta característica)
- Fechas: marzo-abril marzo
Por el momento, werf v1.0 y v1.1 solo se pueden usar en un host dedicado para las operaciones de creación y publicación de imágenes e implementación de la aplicación en Kubernetes.
Para abrir las posibilidades del trabajo distribuido de werf, cuando la compilación y la implementación de aplicaciones en Kubernetes se inician en varios hosts arbitrarios y estos hosts no guardan su estado entre compilaciones (corredores temporales), se requiere que werf implemente la capacidad de usar Docker Registry como almacén de escenario.
Anteriormente, cuando el proyecto werf todavía se llamaba dapp, tenía esa oportunidad. Sin embargo, nos hemos encontrado con una serie de problemas que deben tenerse en cuenta al implementar esta funcionalidad en werf.
Nota. Esta característica no requiere que el recopilador trabaje dentro de los pods de Kubernetes, porque Para hacer esto, debe deshacerse de la dependencia del servidor Docker local (en el pod de Kubernetes no hay acceso al servidor Docker local, porque el proceso en sí se ejecuta en un contenedor y werf no lo admite ni lo admitirá). trabajando con el servidor Docker a través de la red). La compatibilidad con la ejecución de Kubernetes se implementará por separado.
Soporte oficial para GitHub Actions (NUEVO)
- Versión: v1.1
- Fechas: marzo
Incluye documentación werf (secciones referencia и guía), así como la acción oficial de GitHub para trabajar con werf.
Además, permitirá a werf trabajar en corredores efímeros.
La mecánica de interacción del usuario con el sistema CI se basará en colocar etiquetas en las solicitudes de extracción para iniciar ciertas acciones para construir/implementar la aplicación.
Desarrollo local y despliegue de aplicaciones con werf (↓)
- Versión: v1.1
- Fechas: enero-febrero abril
El objetivo principal es lograr una única configuración unificada para implementar aplicaciones tanto localmente como en producción, sin acciones complejas, listas para usar.
También se requiere que werf tenga un modo de funcionamiento en el que sea conveniente editar el código de la aplicación y recibir instantáneamente comentarios de la aplicación en ejecución para su 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 existe ninguna disposición para limpiar imágenes para el esquema de etiquetado basado en contenido: estas imágenes se acumularán.
Además, la versión actual de werf (v1.0 y v1.1) utiliza diferentes políticas de limpieza para imágenes publicadas bajo esquemas de etiquetado: rama Git, etiqueta Git o confirmación Git.
Se ha inventado un nuevo algoritmo para limpiar imágenes basado en el historial de confirmaciones en Git, unificado para todos los esquemas de etiquetado:
- No mantenga más de N1 imágenes asociadas con las N2 confirmaciones más recientes para cada git HEAD (ramas y etiquetas).
- No almacene más de N1 imágenes de etapa asociadas con las N2 confirmaciones más recientes para cada git HEAD (ramas y etiquetas).
- Almacene todas las imágenes que se utilizan en cualquier recurso del clúster de Kubernetes (se analizan todos los contextos de kube del archivo de configuración y los espacios de nombres; puede limitar este comportamiento con opciones especiales).
- Almacene todas las imágenes que se utilizan en los manifiestos de configuración de recursos guardados en las versiones de Helm.
- Una imagen se puede eliminar si no está asociada con ningún HEAD de git (por ejemplo, porque se eliminó el HEAD correspondiente) y no se usa en ningún manifiesto en el clúster de Kubernetes y en las versiones de Helm.
Construcción de imágenes paralelas (↓)
- Versión: v1.1
- Fechas: enero-febrero abril*
La versión actual de werf recopila las imágenes y artefactos descritos en werf.yaml, secuencialmente. Es necesario paralelizar el proceso de ensamblaje de etapas independientes de imágenes y artefactos, así como proporcionar resultados convenientes e informativos.
* Nota: la fecha límite se cambió debido a una mayor prioridad para implementar el ensamblaje distribuido, lo que agregará más capacidades de escalamiento horizontal, así como el uso de werf con GitHub Actions. El ensamblaje paralelo es el siguiente paso de optimización, ya que proporciona escalabilidad vertical al ensamblar un proyecto.
Transición al timón 3 (↓)
- Versión: v1.2
- Fechas: febrero-marzo mayo*
Incluye migración a una nueva base de código. y una forma comprobada y cómoda de migrar instalaciones existentes.
* Nota: cambiar a Helm 3 no agregará características significativas a werf, porque todas las características clave de Helm 3 (fusión de 3 vías y sin timón) ya están implementadas en werf. Además, werf tiene además de los indicados. Sin embargo, esta transición permanece en nuestros planes y se implementará.
Jsonnet para describir la configuración de Kubernetes (↓)
- Versión: v1.2
- Fechas: enero-febrero abril-mayo
Werf admitirá descripciones de configuración para Kubernetes en formato Jsonnet. Al mismo tiempo, werf seguirá siendo compatible con Helm y se podrá elegir el formato de descripción.
La razón es que las plantillas de Go, según mucha gente, tienen una barrera de entrada alta y la comprensión del código de estas plantillas también se ve afectada.
También se está considerando la posibilidad de introducir otros sistemas de descripción de configuración de Kubernetes (por ejemplo, Kustomize).
Trabajando dentro de Kubernetes (↓)
- Versión: v1.2
- Fechas: abril-mayo mayo-junio
Objetivo: garantizar que las imágenes se creen y la aplicación se entregue mediante corredores en Kubernetes. Aquellos. Se pueden crear, publicar, limpiar e implementar nuevas imágenes directamente desde los pods de Kubernetes.
Para implementar esta capacidad, primero necesita la capacidad de crear imágenes distribuidas. (ver punto arriba).
También requiere soporte para el modo operativo del constructor sin un servidor Docker (es decir, compilación tipo Kaniko o compilación en el espacio de usuario).
Werf admitirá la creación de Kubernetes no solo con Dockerfile, sino también con su constructor Stapel con reconstrucciones incrementales y Ansible.
Un paso hacia el desarrollo abierto
Amamos a nuestra comunidad (, ) y queremos que cada vez más personas ayuden a mejorar werf, comprendan la dirección en la que nos estamos moviendo y participen en el desarrollo.
Recientemente se decidió cambiar a con el fin de revelar el proceso de trabajo de nuestro equipo. Ahora puedes ver los planes inmediatos, así como el trabajo actual en las siguientes áreas:
- ;
- ;
- ;
- .
Se ha trabajado mucho con los problemas:
- Se eliminaron los irrelevantes.
- Los existentes se llevan a un formato único, con un número suficiente de detalles y detalles.
- Se han agregado nuevos números con ideas y sugerencias.
Cómo habilitar la versión v1.1
La versión está actualmente disponible en (en canales estable и Roca sólida Las liberaciones aparecerán a medida que se produzca la estabilización, sin embargo ea en sí ya es lo suficientemente estable para su uso, porque pasó por los canales alfa и beta). Activado de la siguiente manera:
source $(multiwerf use 1.1 ea)
werf COMMAND ...Conclusión
La nueva arquitectura de almacenamiento en etapas y las optimizaciones de los constructores Stapel y Dockerfile abren la posibilidad de implementar compilaciones distribuidas y paralelas en werf. Estas funciones aparecerán pronto en la misma versión v1.1 y estarán disponibles automáticamente a través del mecanismo de actualización automática (para usuarios ).
En esta versión, se agregó una estrategia de etiquetado basada en el contenido de la imagen: etiquetado basado en contenido, que se ha convertido en la estrategia por defecto. El registro de comandos principal también ha sido reelaborado: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
El siguiente paso importante es agregar ensamblajes distribuidos. Las compilaciones distribuidas se han convertido en una prioridad más alta que las compilaciones paralelas desde la versión 1.0 porque agregan más valor a werf: escalamiento vertical de constructores y soporte para constructores efímeros en varios sistemas CI/CD, así como la capacidad de hacer soporte oficial para GitHub Actions. . Por lo tanto, se cambiaron los plazos de implementación de las asambleas paralelas. Sin embargo, estamos trabajando para implementar ambas posibilidades lo antes posible.
¡Sigue las novedades! Y no olvides visitarnos en para crear un problema, encontrar uno existente y agregar un plus, crear un PR o simplemente observar el desarrollo del proyecto.
PS
Lea también en nuestro blog:
- «»
- «";
- Una serie de notas sobre innovaciones en werf:
- «";
- «";
- «";
- «".
Fuente: habr.com