werf es nuestra utilidad CLI GitOps de código abierto para crear y entregar aplicaciones a Kubernetes. Como se prometió, el lanzamiento de v1.0 marcó el comienzo de agregar nuevas características a werf y revisar enfoques familiares. Ahora nos complace lanzar v1.1, que es un gran paso en el desarrollo y el futuro del werf de colección . La versión está actualmente disponible en el canal 1.1 ea .La base del lanzamiento es la nueva arquitectura del almacenamiento de escenarios y la optimización del trabajo de ambos colectores (para Stapel y Dockerfile). La nueva arquitectura de almacenamiento abre la posibilidad de implementar ensamblados distribuidos desde múltiples hosts y ensamblajes paralelos en un solo host.La optimización del trabajo incluye deshacerse de los cálculos innecesarios en la etapa de cálculo de las firmas de la etapa y cambiar los mecanismos para calcular las sumas de verificación de archivos a otras más eficientes. Esta optimización reduce el tiempo promedio de construcción de un proyecto usando werf. Y las compilaciones inactivas, cuando existen todas las etapas en el caché de almacenamiento de etapas , ahora son realmente rápidas. ¡En la mayoría de los casos, reiniciar el ensamblaje será más rápido que en 1 segundo! Esto también se aplica a los procedimientos para verificar las etapas durante el trabajo de los equipos werf deployy werf run.También en esta versión había una estrategia para etiquetar imágenes por contenido: etiquetado basado en contenido , que ahora está habilitado de forma predeterminada y es el único recomendado.Echemos un vistazo más de cerca a las innovaciones clave en werf v1.1, y al mismo tiempo hablemos sobre planes futuros.¿Qué ha cambiado en werf v1.1?
Nuevo formato de nombres de etapas y algoritmo de selección de etapas de caché
Nueva regla de generación de nombre artístico. Ahora cada ensamblaje de etapa genera un nombre de etapa único, que consta de 2 partes: una firma (como en v1.0) más un identificador temporal único.Por ejemplo, el nombre completo de la imagen del escenario puede verse así:werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835... o en forma general:werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISECAquí:SIGNATURE - esta es la firma del escenario, que representa el identificador del contenido del escenario y depende del historial de ediciones en Git que condujeron a este contenido;TIMESTAMP_MILLISEC - Esto garantiza un identificador único para la imagen que se genera en el momento del ensamblaje de la nueva imagen.
El algoritmo para seleccionar etapas de la memoria caché se basa en verificar la relación de las confirmaciones de Git:- Werf calcula la firma de alguna etapa.
- En el almacenamiento por etapas , puede haber varias etapas para una firma determinada. Werf selecciona todas las etapas que son adecuadas para la firma.
- Si la fase actual se asocia con Git (git-archivo, usuario paso c Git-parches:
install, beforeSetup, setup, o git-última-patch), entonces werf selecciona sólo aquellos pasos que se refieren a cometer, que es el antecesor de la corriente cometer (para el que causado conjunto ) - De las etapas adecuadas restantes, 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á el uso de un caché asociado con diferentes ramas entre estas ramas, incluso si las firmas coinciden.→ Documentación .Nuevo algoritmo para crear y guardar etapas en el almacenamiento de etapas
Si werf no encuentra una etapa adecuada durante la selección de etapas del caché, se inicia el proceso de ensamblar una nueva etapa.Tenga en cuenta que varios procesos (en uno o más hosts) pueden comenzar a ensamblar la misma etapa aproximadamente al mismo tiempo. Werf utiliza la etapas de almacenamiento de algoritmo de bloqueo optimista cuando una imagen recogida recién se almacena en etapas de almacenamiento . Por lo tanto, cuando el ensamblaje de la nueva etapa está listo, werf bloquea el almacenamiento de etapas y guarda la imagen recién recolectada allí solo si no hay una imagen adecuada allí (para la firma y otros parámetros; consulte el nuevo algoritmo para seleccionar etapas de la caché) .Se garantiza que una imagen recién seleccionada tendrá un identificador único TIMESTAMP_MILLISEC (consulte el nuevo formato de nombres de etapas) . Si se encuentra una imagen adecuada en el almacenamiento por etapas , werf descartará la imagen recién recopilada y usará la imagen del caché.En otras palabras: el primer proceso que termine de recopilar la imagen (el más rápido) recibirá el derecho de guardarlo en almacenamiento por etapas (y luego esta imagen en particular se usará para todos los ensamblajes). Un proceso de ensamblaje lento nunca impedirá que un proceso más rápido guarde los resultados del ensamblaje de la etapa actual y continúe con el siguiente ensamblaje.→ Documentación .Rendimiento mejorado del recopilador Dockerfile
Por el momento, la canalización de la etapa para una imagen compilada desde el Dockerfile consta de una etapa - dockerfile. Al calcular la firma, se considera la suma de comprobación de los archivos context, que se utilizará durante el ensamblaje. Antes de esta mejora, werf atravesó recursivamente todos los archivos y recibió una suma de verificación, resumiendo el contexto y el modo de cada archivo. A partir de v1.1, werf puede usar las sumas de verificación calculadas almacenadas en el repositorio de Git.El algoritmo se basa en git ls-tree . El algoritmo tiene en cuenta las entradas .dockerignorey pasa recursivamente a través del árbol de archivos solo si es necesario. Por lo tanto, nos deshicimos de leer el sistema de archivos, y la dependencia del algoritmo en el tamaño contextno es significativa.El algoritmo también verifica los archivos no rastreados y, si es necesario, los toma en cuenta en la suma de control.Rendimiento mejorado al importar archivos
Werf v1.1 usa el servidor rsync cuando importa archivos de artefactos e imágenes . Anteriormente, la importación se realizaba en dos pasos utilizando el montaje del directorio desde el sistema host.El rendimiento de la importación en macOS ya no se limita a los volúmenes de Docker, y las importaciones se realizan al mismo 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 para las imágenes Docker resultantes dependen del contenido de estas imágenes.Cuando ejecute el comando werf publish --tags-by-stages-signatureo werf ci-env --tagging-strategy=stages-signature, se probarán las imágenes publicadas de la llamada firma de etapa de 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 regular de cada etapa por separado, pero es un identificador generalizado de la imagen.La firma de las etapas de la imagen depende de:- el contenido de esta imagen;
- Historial de revisión de Git que condujo a este contenido.
Los repositorios de Git siempre tienen confirmaciones inactivas que no modifican el contenido de los archivos de imagen. Por ejemplo, confirma solo con comentarios, o combina confirmaciones o confirmaciones que cambian esos archivos en Git que no se importarán a la imagen.El uso del etiquetado basado en contenido resuelve el problema de reinicios innecesarios de 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 hace que sea difícil 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 por ramas Git, porque el contenido de las imágenes resultantes no depende del orden de ejecución de las tuberías en el sistema CI para ensamblar varias confirmaciones de la misma rama.Importante: De ahora en adelante, la firma por etapas es la única estrategia de etiquetado recomendada . Se usará de manera predeterminada en el equipo werf ci-env(a menos que especifique explícitamente un esquema de etiquetado diferente).→ Documentación . También se dedicará una publicación separada a esta función. ACTUALIZADO (3 de abril): se ha publicado un artículo con detalles .Niveles de registro
El usuario tiene la oportunidad de controlar la salida, establecer el nivel de registro y trabajar con información de depuración. Añade opciones --log-quiet, --log-verbose, --log-debug.De forma predeterminada, la salida contiene un mínimo de información:
al usar la salida detallada ( --log-verbose), puede rastrear cómo funciona werf: la
salida detallada ( --log-debug), además de la información de depuración de werf, también contiene los registros de las bibliotecas utilizadas. Por ejemplo, puede ver cómo se produce la interacción con el Registro de Docker y también corregir los lugares donde se dedica una cantidad de tiempo considerable:
Planes futuros
¡Atención! Las características descritas a continuación marcadas v1.1 estarán disponibles en esta versión, muchas de ellas en un futuro próximo. Las actualizaciones vendrán a través de actualizaciones automáticas cuando se usa multiwerf . 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 del Registro Docker (NUEVO)
El objetivo es que el usuario debe usar una implementación arbitraria sin restricciones al usar werf.Hasta la fecha, hemos identificado el siguiente conjunto de soluciones para las cuales vamos a garantizar un soporte completo:- Predeterminado (biblioteca / registro) *,
- AWS ECR,
- Azure *,
- Docker hub
- GCR *,
- Paquetes de Github
- Registro de GitLab *,
- Puerto *,
- Muelle.
Un asterisco indica soluciones que actualmente son totalmente compatibles con werf. Para el resto hay soporte, pero con limitaciones.Se pueden distinguir dos problemas principales:- Algunas soluciones no admiten la eliminación de etiquetas mediante la API de registro de Docker, que no permite a los usuarios utilizar la limpieza automática implementada en werf. Esto es cierto para los paquetes AWS ECR, Docker Hub y GitHub.
- Algunas soluciones no son compatibles con los denominados repositorios anidados (Docker Hub, GitHub Packages y Quay) o son compatibles, pero el usuario debe crearlos manualmente utilizando la UI o API (AWS ECR).
Vamos a resolver estos y otros problemas utilizando API nativas de soluciones. Esta tarea también incluye cubrir todo el ciclo werf con pruebas para cada uno de ellos.Conjunto de imagen distribuida (↑)
Por el momento, werf v1.0 y v1.1 se pueden usar en un solo host dedicado para el ensamblaje y publicación de imágenes y la implementación de la aplicación en Kubernetes.Para abrir las posibilidades de trabajo distribuido werf, cuando el ensamblaje y la implementación de aplicaciones en Kubernetes se inician en varios hosts arbitrarios y estos hosts no mantienen su estado entre ensamblajes (corredores temporales), se requiere que werf implemente la posibilidad de utilizar el Registro Docker como un repositorio de etapas.Anteriormente, cuando el proyecto werf todavía se llamaba dapp, tenía esa oportunidad. Sin embargo, encontramos una serie de problemas que deben considerarse al implementar esta función en werf.Nota. Esta característica no implica el trabajo del recolector dentro de los pods de Kubernetes, ya que para hacer esto, elimine la dependencia del servidor Docker local (en el pod Kubernetes no hay acceso al servidor Docker local, porque el proceso en sí mismo se está ejecutando en el contenedor, y werf no admite y no admitirá trabajar con el servidor Docker en la red). El soporte para el trabajo en Kubernetes se implementará por separado.Soporte oficial de acciones de GitHub (NUEVO)
Incluye documentación de werf (secciones de referencia y guía ), así como la acción oficial de GitHub para trabajar con werf.Además, permitirá que werf funcione en corredores efímeros.La mecánica de la interacción del usuario con el sistema CI se basará en poner etiquetas en las solicitudes de extracción para iniciar ciertas acciones para construir / implementar la aplicación.Desarrollo e implementación de aplicaciones locales con werf (↓)
- Versión: v1.1
- Fechas:
enero-febrero abril - Problema
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.Werf también necesita un modo de operación en el que sea conveniente editar el código de la aplicación y recibir instantáneamente comentarios de una aplicación que funcione para la depuración.Nuevo algoritmo de limpieza (NUEVO)
En la versión actual de werf v1.1, el procedimiento cleanupno proporciona imágenes de limpieza para el esquema de etiquetado basado en contenido; 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 las imágenes publicadas por esquemas de etiquetado: Git branch, Git tag o Git commit.Se inventó un nuevo algoritmo de limpieza de imagen unificado para todos los esquemas de etiquetado basado en el historial de confirmaciones en Git:- No almacene más de N1 imágenes asociadas con las últimas confirmaciones de N2 para cada git HEAD (ramas y etiquetas).
- No almacene más de N1 imágenes-etapas asociadas con las últimas confirmaciones de N2 para cada uno de git HEAD (ramas y etiquetas).
- , - Kubernetes ( kube- namespace'; ).
- , , Helm-.
- , HEAD git (, HEAD ) Kubernetes Helm.
(↓)
La versión actual de werf recopila las imágenes y artefactos descritos en forma werf.yamlsecuencial. Es necesario paralelizar el proceso de ensamblar etapas independientes de imágenes y artefactos, así como proporcionar una conclusión conveniente e informativa.* Nota: la fecha límite se modifica debido a la mayor prioridad para la implementación de un ensamblado distribuido, que agregará más funciones para el escalado horizontal, así como el uso de werf con las acciones de GitHub. El ensamblaje en paralelo es el siguiente paso de optimización, que brinda escalabilidad vertical al ensamblar un solo proyecto.Cambiar al timón 3 (↓)
- Versión: v1.2
- Fechas:
febrero-marzo mayo *
Incluye la transición a la nueva base de código Helm 3 y una forma conveniente y comprobada de migrar las instalaciones existentes.* Nota: cambiar a Helm 3 no agregará características significativas a werf, porque todas las características clave de Helm 3 (combinación de 3 vías y falta de timón) ya están implementadas en werf. Además, werf tiene características adicionales además de las indicadas. Sin embargo, esta transición permanece en nuestros planes y se implementará.Descripción de la configuración de Jsonnet para Kubernetes (↓)
- Versión: v1.2
- Fechas:
enero-febrero abril-mayo
Werf admitirá la descripción de la configuración de Kubernetes en formato Jsonnet. Al mismo tiempo, werf seguirá siendo compatible con Helm y será posible seleccionar un formato de descripción.La razón es el hecho de que los patrones de lenguaje Go, según muchas personas, tienen un umbral de entrada grande, y la inteligibilidad del código de estos patrones también se ve afectada.También se están considerando otras opciones para implementar sistemas de descripción de configuración de Kubernetes (como Kustomize).Trabajar dentro de Kubernetes (↓)
- Versión: v1.2
- Fechas:
abril-mayo mayo-junio
Propósito: Asegurar el ensamblaje de imágenes y la entrega de aplicaciones utilizando corredores en Kubernetes. Aquellos. El ensamblaje de nuevas imágenes, su publicación, limpieza y despliegue pueden realizarse directamente desde los pods de Kubernetes.Para realizar esta característica, primero necesita la capacidad de construir imágenes distribuidas (vea el párrafo anterior) .También requiere soporte para el modo de operación de compilación sin el servidor Docker (es decir, una compilación similar a Kaniko o una compilación en el espacio de usuario).Werf admitirá las compilaciones de Kubernetes no solo con el Dockerfile, sino también con su generador de Stapel con reconstrucciones incrementales y Ansible.Paso hacia el desarrollo de código abierto
Amamos a nuestra comunidad ( GitHub , Telegram ) y queremos que más y más personas nos ayuden a mejorar, entender en qué dirección nos estamos moviendo y participar en el desarrollo.Más recientemente, se decidió cambiar a los paneles de proyectos de GitHub para abrir el flujo de trabajo de nuestro equipo. Ahora puede ver los planes inmediatos, así como el trabajo en curso en las siguientes áreas:Se ha trabajado mucho con los problemas:- Eliminado irrelevante.
- Los existentes se reducen a un solo formato, un número suficiente de detalles y detalles.
- Se agregaron nuevos problemas con ideas y sugerencias.
Cómo habilitar la versión v1.1
La versión está actualmente disponible en el canal 1.1 ea (las versiones en canales estables y sólidos como una roca aparecerán a medida que se estabilicen, pero ea en sí ya es lo suficientemente estable como para usarse, ya que pasó a través de los canales alfa y beta ). Se activa a través de multiwerf de la siguiente manera:source $(multiwerf use 1.1 ea)
werf COMMAND ...
Conclusión
La nueva arquitectura de tienda de escenario y el rendimiento optimizado del colector para los colectores Stapel y Dockerfile abren la posibilidad de implementar ensambles distribuidos y paralelos en werf. Estas características pronto aparecerán 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 de múltiples respuestas ).En esta versión, se agregó una estrategia de etiquetado basada en contenido , que se convirtió en la estrategia predeterminada. Un registro también se rediseñó los comandos básicos: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.El siguiente paso significativo será agregar ensamblados distribuidos. Los ensamblajes distribuidos desde v1.0 se han convertido en una prioridad más alta que los ensamblajes paralelos, porque agregan más valor de werf: escalado vertical de colectores y soporte para colectores efímeros en varios sistemas de CI / CD, así como la capacidad de brindar soporte oficial para las acciones de GitHub. Por lo tanto, el momento de la implementación de ensamblajes paralelos ha cambiado. Sin embargo, estamos trabajando para realizar rápidamente ambas posibilidades.Sigue las noticias! Y no olvide pasar por nuestro GitHub para crear un problema, encontrar uno existente y poner un plus, crear un PR o simplemente ver el desarrollo del proyecto.PD
Lea también en nuestro blog: