🥇Ensamblaje y despliegue dinámico de imágenes Docker con werf usando el ejemplo del sitio de documentación versionada

Ya hemos hablado más de una vez de nuestra herramienta GitOps. patio, y esta vez nos gustaría compartir nuestra experiencia en el montaje del sitio con la documentación del proyecto en sí. werf.io (su versión rusa es es.werf.io). Este es un sitio estático ordinario, pero su ensamblaje es interesante porque está construido utilizando una cantidad dinámica de artefactos.

Adéntrate en los matices de la estructura del sitio: generación de un menú común para todas las versiones, páginas con información sobre lanzamientos, etc. - nosotros no. En lugar de ello, centrémonos en los problemas y características del ensamblaje dinámico y un poco en los procesos CI/CD que lo acompañan.

Introducción: cómo funciona el sitio

Para empezar, la documentación de werf se almacena junto con su código. Esto impone ciertos requisitos de desarrollo que generalmente están fuera del alcance de este artículo, pero como mínimo se puede decir que:

No se deben publicar nuevas funciones de werf sin actualizar la documentación y, a la inversa, cualquier cambio en la documentación implica el lanzamiento de una nueva versión de werf;
El proyecto tiene un desarrollo bastante intensivo: se pueden lanzar nuevas versiones varias veces al día;
Cualquier operación manual para implementar un sitio con una nueva versión de la documentación es al menos tediosa;
El proyecto adopta un enfoque semántico. versionando, con 5 canales de estabilidad. El proceso de lanzamiento implica el paso secuencial de versiones a través de canales en orden de estabilidad creciente: de alfa a sólido como una roca;
El sitio tiene una versión en ruso, que "vive y se desarrolla" (es decir, cuyo contenido se actualiza) en paralelo con la versión principal (es decir, en inglés).

Para ocultar toda esta “cocina interior” al usuario, ofreciéndole algo que “simplemente funciona”, hicimos herramienta de instalación y actualización de werf separada - es multiwerf. Sólo necesita especificar el número de versión y el canal de estabilidad que está listo para usar, y multiwerf verificará si hay una nueva versión en el canal y la descargará si es necesario.

En el menú de selección de versiones del sitio web, están disponibles las últimas versiones de werf en cada canal. Por defecto, por dirección werf.io/documentación Se abre la versión del canal más estable para la última versión; también está indexada por los motores de búsqueda. La documentación para el canal está disponible en direcciones separadas (por ejemplo, werf.io/v1.0-beta/documentación para la versión beta 1.0).

En total, el sitio tiene las siguientes versiones disponibles:

root (se abre de forma predeterminada),
para cada canal de actualización activo de cada versión (por ejemplo, werf.io/v1.0-beta).

Para generar una versión específica de un sitio, en general, basta con compilarlo usando Jekyllejecutando en el directorio /docs comando correspondiente al repositorio werf (jekyll build), después de cambiar a la etiqueta Git de la versión requerida.

Sólo queda agregar que:

la propia utilidad (werf) se utiliza para el montaje;
Los procesos CI/CD se construyen sobre la base de GitLab CI;
y todo esto, por supuesto, se ejecuta en Kubernetes.

Tareas

Ahora formulemos tareas que tengan en cuenta todos los detalles descritos:

Después de cambiar la versión werf en cualquier canal de actualización La documentación en el sitio debe actualizarse automáticamente..
Para el desarrollo es necesario poder a veces ver versiones preliminares del sitio.

El sitio debe recompilarse después de cambiar la versión en cualquier canal de las etiquetas Git correspondientes, pero en el proceso de creación de la imagen obtendremos las siguientes características:

Dado que la lista de versiones de los canales cambia, solo es necesario reconstruir la documentación de los canales donde la versión ha cambiado. Después de todo, reconstruir todo de nuevo no es muy agradable.
El conjunto de canales para lanzamientos puede cambiar. En algún momento, por ejemplo, es posible que no haya una versión en los canales más estable que la versión de acceso temprano 1.1, pero con el tiempo aparecerán; en este caso, ¿no debería cambiar el ensamblaje manualmente?

Resulta que El ensamblaje depende del cambio de datos externos..

implementación

Elegir un enfoque

Como alternativa, puede ejecutar cada versión requerida como un pod independiente en Kubernetes. Esta opción implica una mayor cantidad de objetos en el clúster, que crecerá con el aumento en la cantidad de lanzamientos de werf estables. Y esto, a su vez, implica un mantenimiento más complejo: cada versión tiene su propio servidor HTTP, y con poca carga. Por supuesto, esto también implica mayores costes de recursos.

tomamos el mismo camino ensamblando todas las versiones necesarias en una sola imagen. Las estadísticas compiladas de todas las versiones del sitio se encuentran en un contenedor con NGINX, y el tráfico a la implementación correspondiente llega a través de NGINX Ingress. Una estructura simple, una aplicación sin estado, le permite escalar fácilmente la implementación (según la carga) utilizando el propio Kubernetes.

Para ser más precisos, estamos recopilando dos imágenes: una para el circuito de producción y la segunda es adicional para el circuito de desarrollo. La imagen adicional se usa (lanza) solo en el circuito de desarrollo junto con el principal y contiene la versión del sitio de la confirmación de revisión, y el enrutamiento entre ellos se realiza utilizando recursos de Ingress.

werf vs git clon y artefactos

Como ya se mencionó, para generar estadísticas del sitio para una versión específica de la documentación, debe compilarla cambiando a la etiqueta de repositorio adecuada. También puedes hacer esto clonando el repositorio cada vez que lo crees, seleccionando las etiquetas apropiadas de una lista. Sin embargo, esta es una operación que consume muchos recursos y, además, requiere escribir instrucciones no triviales... Otra desventaja grave es que con este enfoque no hay forma de almacenar en caché algo durante el ensamblaje.

Aquí la propia utilidad werf viene en nuestra ayuda, implementando almacenamiento en caché inteligente y permitiéndote usar repositorios externos. Usar werf para agregar código desde el repositorio acelerará significativamente la compilación, porque werf esencialmente clona el repositorio una vez y luego lo ejecuta sólo fetch si necesario. Además, al agregar datos del repositorio, podemos seleccionar solo los directorios necesarios (en nuestro caso este es el directorio docs), lo que reducirá significativamente la cantidad de datos agregados.

Dado que Jekyll es una herramienta diseñada para compilar datos estáticos y no es necesaria en la imagen final, sería lógico compilar en artefacto werf, y en la imagen final importar solo el resultado de la compilación.

Escribimos werf.yaml

Entonces, decidimos compilar cada versión en un artefacto werf separado. Sin embargo, nos No sabemos cuántos de estos artefactos habrá durante el montaje., por lo que no podemos escribir una configuración de compilación fija (estrictamente hablando, todavía podemos, pero no será del todo efectiva).

werf te permite usar Ir plantillas en su archivo de configuración (werf.yaml), y esto hace posible generar configuración sobre la marcha dependiendo de datos externos (¡lo que necesitas!). Los datos externos en nuestro caso son información sobre versiones y lanzamientos, sobre la base de los cuales recopilamos la cantidad requerida de artefactos y como resultado obtenemos dos imágenes: werf-doc и werf-dev para correr en diferentes circuitos.

Los datos externos se pasan a través de variables de entorno. Aquí está su composición:

RELEASES — una línea con una lista de lanzamientos y la correspondiente versión actual de werf, en forma de una lista de valores separados por espacios en el formato <НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>. Un ejemplo: 1.0%v1.0.4-beta.20
CHANNELS — una línea con una lista de canales y la correspondiente versión actual de werf, en forma de una lista de valores separados por espacios en el formato <КАНАЛ>%<НОМЕР_ВЕРСИИ>. Un ejemplo: 1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22
ROOT_VERSION — la versión de lanzamiento de werf se mostrará de forma predeterminada en el sitio (no siempre es necesario mostrar la documentación con el número de lanzamiento más alto). Ejemplo: v1.0.4-beta.20
REVIEW_SHA — hash de la confirmación de revisión a partir del cual necesita crear la versión para el ciclo de prueba.

Estas variables se completarán en la canalización de GitLab CI y cómo se escribe exactamente a continuación.

En primer lugar, por conveniencia, definimos en werf.yaml Vaya a las variables de plantilla, asignándoles valores de las variables de entorno:

{{ $_ := set . "WerfVersions" (cat (env "CHANNELS") (env "RELEASES") | splitList " ") }}
{{ $Root := . }}
{{ $_ := set . "WerfRootVersion" (env "ROOT_VERSION") }}
{{ $_ := set . "WerfReviewCommit" (env "REVIEW_SHA") }}

La descripción del artefacto para compilar la versión estática del sitio es generalmente la misma para todos los casos que necesitamos (incluida la generación de la versión raíz, así como la versión para el circuito de desarrollo). Por lo tanto, lo moveremos a un bloque separado usando la función define - para su posterior reutilización utilizando include. Pasaremos los siguientes argumentos a la plantilla:

Version — versión generada (nombre de etiqueta);
Channel — el nombre del canal de actualización para el cual se genera el artefacto;
Commit — hash de confirmación, si el artefacto se genera para una confirmación de revisión;
contexto.

Descripción de la plantilla de artefacto

{{- define "doc_artifact" -}}
{{- $Root := index . "Root" -}}
artifact: doc-{{ .Channel }}
from: jekyll/builder:3
mount:
- from: build_dir
  to: /usr/local/bundle
ansible:
  install:
  - shell: |
      export PATH=/usr/jekyll/bin/:$PATH
  - name: "Install Dependencies"
    shell: bundle install
    args:
      executable: /bin/bash
      chdir: /app/docs
  beforeSetup:
{{- if .Commit }}
  - shell: echo "Review SHA - {{ .Commit }}."
{{- end }}
{{- if eq .Channel "root" }}
  - name: "releases.yml HASH: {{ $Root.Files.Get "releases.yml" | sha256sum }}"
    copy:
      content: |
{{ $Root.Files.Get "releases.yml" | indent 8 }}
      dest:  /app/docs/_data/releases.yml
{{- else }}
  - file:
      path: /app/docs/_data/releases.yml
      state: touch
{{- end }}
  - file:
      path: "{{`{{ item }}`}}"
      state: directory
      mode: 0777
    with_items:
    - /app/main_site/
    - /app/ru_site/
  - file:
      dest: /app/docs/pages_ru/cli
      state: link
      src: /app/docs/pages/cli
  - shell: |
      echo -e "werfVersion: {{ .Version }}nwerfChannel: {{ .Channel }}" > /tmp/_config_additional.yml
      export PATH=/usr/jekyll/bin/:$PATH
{{- if and (ne .Version "review") (ne .Channel "root") }}
{{- $_ := set . "BaseURL" ( printf "v%s" .Channel ) }}
{{- else if ne .Channel "root" }}
{{- $_ := set . "BaseURL" .Channel }}
{{- end }}
      jekyll build -s /app/docs  -d /app/_main_site/{{ if .BaseURL }} --baseurl /{{ .BaseURL }}{{ end }} --config /app/docs/_config.yml,/tmp/_config_additional.yml
      jekyll build -s /app/docs  -d /app/_ru_site/{{ if .BaseURL }} --baseurl /{{ .BaseURL }}{{ end }} --config /app/docs/_config.yml,/app/docs/_config_ru.yml,/tmp/_config_additional.yml
    args:
      executable: /bin/bash
      chdir: /app/docs
git:
- url: https://github.com/flant/werf.git
  to: /app/
  owner: jekyll
  group: jekyll
{{- if .Commit }}
  commit: {{ .Commit }}
{{- else }}
  tag: {{ .Version }}
{{- end }}
  stageDependencies:
    install: ['docs/Gemfile','docs/Gemfile.lock']
    beforeSetup: '**/*'
  includePaths: 'docs'
  excludePaths: '**/*.sh'
{{- end }}

El nombre del artefacto debe ser único. Esto lo podemos conseguir, por ejemplo, añadiendo el nombre del canal (el valor de la variable .Channel) como sufijo del nombre del artefacto: artifact: doc-{{ .Channel }}. Pero debe comprender que al importar desde artefactos, deberá hacer referencia a los mismos nombres.

Al describir un artefacto, se utiliza la siguiente característica werf: montaje. Montaje indicando el directorio de servicios. build_dir le permite guardar el caché de Jekyll entre ejecuciones de canalización, lo que acelera significativamente el reensamblaje.

También habrás notado el uso del archivo. releases.yml es un archivo YAML con datos de lanzamiento solicitados de Github.com (un artefacto obtenido al ejecutar una canalización). Es necesario al compilar el sitio, pero en el contexto del artículo nos resulta interesante porque depende de su estado. reensamblaje de un solo artefacto — un artefacto de la versión raíz del sitio (no es necesario en otros artefactos).

Esto se implementa usando la declaración condicional. if Ir plantillas y diseños {{ $Root.Files.Get "releases.yml" | sha256sum }} en el escenario etapas. Funciona de la siguiente manera: al construir un artefacto para la versión raíz (variable .Channel es igual root) hash de archivo releases.yml afecta la firma de toda la etapa, ya que forma parte del nombre de la tarea de Ansible (parámetro name). Así, al cambiar contenido expediente releases.yml se volverá a montar el artefacto correspondiente.

Preste también atención a trabajar con un repositorio externo. En la imagen de un artefacto de repositorio werf, solo se agrega el directorio /docsy, según los parámetros pasados, los datos de la etiqueta requerida o la confirmación de revisión se agregan inmediatamente.

Para utilizar la plantilla de artefacto para generar una descripción del artefacto de las versiones transferidas de canales y lanzamientos, organizamos un bucle en la variable .WerfVersions в werf.yaml:

{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ dict "Version" $VersionsDict._1 "Channel" $VersionsDict._0 "Root" $Root | include "doc_artifact" }}
---
{{ end -}}

Porque el bucle generará varios artefactos (eso esperamos), es necesario tener en cuenta el separador entre ellos: la secuencia --- (Para obtener más información sobre la sintaxis del archivo de configuración, consulte documentación). Como se definió anteriormente, cuando llamamos a una plantilla en un bucle, pasamos los parámetros de versión, la URL y el contexto raíz.

De manera similar, pero sin un bucle, llamamos a la plantilla de artefacto para "casos especiales": para la versión raíz, así como para la versión de la confirmación de revisión:

{{ dict "Version" .WerfRootVersion "Channel" "root" "Root" $Root  | include "doc_artifact" }}
---
{{- if .WerfReviewCommit }}
{{ dict "Version" "review" "Channel" "review" "Commit" .WerfReviewCommit "Root" $Root  | include "doc_artifact" }}
{{- end }}

Tenga en cuenta que el artefacto para la confirmación de revisión solo se creará si la variable está configurada .WerfReviewCommit.

Los artefactos están listos: ¡es hora de empezar a importar!

La imagen final, diseñada para ejecutarse en Kubernetes, es un NGINX normal al que se le ha añadido un archivo de configuración del servidor. nginx.conf y estática de los artefactos. Además del artefacto de la versión raíz del sitio, debemos repetir el ciclo en la variable .WerfVersions para importar artefactos de canales y versiones de lanzamiento + siga la regla de nomenclatura de artefactos que adoptamos anteriormente. Dado que cada artefacto almacena versiones del sitio para dos idiomas, las importamos a los lugares proporcionados por la configuración.

Descripción de la imagen final werf-doc

image: werf-doc
from: nginx:stable-alpine
ansible:
  setup:
  - name: "Setup /etc/nginx/nginx.conf"
    copy:
      content: |
{{ .Files.Get ".werf/nginx.conf" | indent 8 }}
      dest: /etc/nginx/nginx.conf
  - file:
      path: "{{`{{ item }}`}}"
      state: directory
      mode: 0777
    with_items:
    - /app/main_site/assets
    - /app/ru_site/assets
import:
- artifact: doc-root
  add: /app/_main_site
  to: /app/main_site
  before: setup
- artifact: doc-root
  add: /app/_ru_site
  to: /app/ru_site
  before: setup
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ $Channel := $VersionsDict._0 -}}
{{ $Version := $VersionsDict._1 -}}
- artifact: doc-{{ $Channel }}
  add: /app/_main_site
  to: /app/main_site/v{{ $Channel }}
  before: setup
{{ end -}}
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ $Channel := $VersionsDict._0 -}}
{{ $Version := $VersionsDict._1 -}}
- artifact: doc-{{ $Channel }}
  add: /app/_ru_site
  to: /app/ru_site/v{{ $Channel }}
  before: setup
{{ end -}}

La imagen adicional, que junto con la principal se inicia en el circuito de desarrollo, contiene solo dos versiones del sitio: la versión de la confirmación de revisión y la versión raíz del sitio (hay recursos generales y, si recuerdas , datos de publicación). Por lo tanto, la imagen adicional se diferenciará de la principal solo en la sección de importación (y, por supuesto, en el nombre):

image: werf-dev
...
import:
- artifact: doc-root
  add: /app/_main_site
  to: /app/main_site
  before: setup
- artifact: doc-root
  add: /app/_ru_site
  to: /app/ru_site
  before: setup
{{- if .WerfReviewCommit  }}
- artifact: doc-review
  add: /app/_main_site
  to: /app/main_site/review
  before: setup
- artifact: doc-review
  add: /app/_ru_site
  to: /app/ru_site/review
  before: setup
{{- end }}

Como se señaló anteriormente, el artefacto para la confirmación de revisión se generará solo cuando se ejecute la variable de entorno establecida. REVIEW_SHA. Sería posible no generar la imagen werf-dev si no hay una variable de entorno REVIEW_SHA, pero para limpieza por politicas Las imágenes de Docker en werf funcionaron para la imagen de werf-dev, dejaremos que se construya solo con el artefacto de la versión raíz (ya está compilado de todos modos), para simplificar la estructura de la canalización.

¡La asamblea está lista! Pasemos a CI/CD y matices importantes.

Canalización en GitLab CI y características de construcción dinámica

Al ejecutar la compilación, necesitamos configurar las variables de entorno utilizadas en werf.yaml. Esto no se aplica a la variable REVIEW_SHA, que configuraremos al llamar a la canalización desde el enlace de GitHub.

Generaremos los datos externos necesarios en un script Bash generate_artifacts, que generará dos artefactos de canalización de GitLab:

файл releases.yml con datos de lanzamiento,
файл common_envs.sh, que contiene las variables de entorno que se exportarán.

Contenido del archivo generate_artifacts lo encontrarás en nuestro repositorios con ejemplos. Recibir los datos en sí no es el tema del artículo, sino el archivo. common_envs.sh es importante para nosotros, porque el trabajo de werf depende de ello. Un ejemplo de su contenido:

export RELEASES='1.0%v1.0.6-4'
export CHANNELS='1.0-alpha%v1.0.7-1 1.0-beta%v1.0.7-1 1.0-ea%v1.0.6-4 1.0-stable%v1.0.6-4 1.0-rock-solid%v1.0.6-4'
export ROOT_VERSION='v1.0.6-4'

Puede utilizar la salida de dicho script, por ejemplo, utilizando la función Bash source.

Ahora viene la parte divertida. Para que tanto la compilación como la implementación de la aplicación funcionen correctamente, es necesario asegurarse de que werf.yaml era lo mismo al menos dentro de una tubería. Si no se cumple esta condición, las firmas de las etapas que calculamos durante el montaje y, por ejemplo, el despliegue, serán diferentes. Esto provocará un error de implementación, porque... faltará la imagen necesaria para la implementación.

En otras palabras, si durante el ensamblaje de la imagen del sitio la información sobre lanzamientos y versiones es la misma, y en el momento de la implementación se lanza una nueva versión y las variables de entorno tienen valores diferentes, entonces la implementación fallará con un error: después de todo, el artefacto de la nueva versión aún no se ha creado.

si generacion werf.yaml depende de datos externos (por ejemplo, una lista de versiones actuales, como en nuestro caso), entonces la composición y los valores de dichos datos deben registrarse dentro de la canalización. Esto es especialmente importante si los parámetros externos cambian con bastante frecuencia.

Lo haremos recibir y registrar datos externos en la primera etapa del proceso en GitLab (Preconstrucción) y transmitirlos más adelante en la forma Artefacto de CI de GitLab. Esto le permitirá ejecutar y reiniciar trabajos de canalización (compilación, implementación, limpieza) con la misma configuración en werf.yaml.

Contenido del escenario Preconstrucción expediente .gitlab-ci.yml:

Prebuild:
  stage: prebuild
  script:
    - bash ./generate_artifacts 1> common_envs.sh
    - cat ./common_envs.sh
  artifacts:
    paths:
      - releases.yml
      - common_envs.sh
    expire_in: 2 week

Una vez capturados los datos externos en el artefacto, puede compilarlo e implementarlo utilizando las etapas estándar de canalización de CI de GitLab: compilación e implementación. Lanzamos la canalización en sí usando enlaces del repositorio werf de GitHub (es decir, cuando hay cambios en el repositorio de GitHub). Los datos para ellos se pueden encontrar en las propiedades del proyecto GitLab en la sección Configuración de CI/CD -> Activadores de canalizacióny luego cree el Webhook correspondiente en GitHub (Configuración -> Webhooks).

La etapa de construcción se verá así:

Build:
  stage: build
  script:
    - type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
    - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - source common_envs.sh
    - werf build-and-publish --stages-storage :local
  except:
    refs:
      - schedules
  dependencies:
    - Prebuild

GitLab agregará dos artefactos desde el escenario a la etapa de construcción Preconstrucción, entonces exportamos variables con datos de entrada preparados usando la construcción source common_envs.sh. Iniciamos la etapa de construcción en todos los casos, excepto en el lanzamiento del oleoducto según un cronograma. Según el cronograma, llevaremos a cabo la limpieza de la tubería; en este caso, no es necesario realizar el montaje.

En la etapa de implementación, describiremos dos tareas, por separado para la implementación en circuitos de producción y desarrollo, utilizando una plantilla YAML:

.base_deploy: &base_deploy
  stage: deploy
  script:
    - type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
    - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - source common_envs.sh
    - werf deploy --stages-storage :local
  dependencies:
    - Prebuild
  except:
    refs:
      - schedules

Deploy to Production:
  <<: *base_deploy
  variables:
    WERF_KUBE_CONTEXT: prod
  environment:
    name: production
    url: werf.io
  only:
    refs:
      - master
  except:
    variables:
      - $REVIEW_SHA
    refs:
      - schedules

Deploy to Test:
  <<: *base_deploy
  variables:
    WERF_KUBE_CONTEXT: dev
  environment:
    name: test
    url: werf.test.flant.com
  except:
    refs:
      - schedules
  only:
    variables:
      - $REVIEW_SHA

Las tareas difieren esencialmente sólo en indicar el contexto del clúster en el que werf debe realizar la implementación (WERF_KUBE_CONTEXT) y configurar las variables de entorno del bucle (environment.name и environment.url), que luego se utilizan en las plantillas de gráficos de Helm. No proporcionaremos el contenido de las plantillas, porque... No hay nada interesante allí para el tema en cuestión, pero puedes encontrarlos en repositorios para el artículo.

Toque final

Dado que las versiones de werf se lanzan con bastante frecuencia, se crearán nuevas imágenes con frecuencia y el Registro Docker crecerá constantemente. Por tanto, es imperativo configurar la limpieza automática de imágenes en función de las políticas. Es muy fácil de hacer.

Para implementar necesitarás:

Agregue un paso de limpieza a .gitlab-ci.yml;
Agregar ejecución periódica de una tarea de limpieza;
Configure una variable de entorno con un token de acceso de escritura.

Agregar una etapa de limpieza a .gitlab-ci.yml:

Cleanup:
  stage: cleanup
  script:
    - type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
    - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - source common_envs.sh
    - docker login -u nobody -p ${WERF_IMAGES_CLEANUP_PASSWORD} ${WERF_IMAGES_REPO}
    - werf cleanup --stages-storage :local
  only:
    refs:
      - schedules

Ya hemos visto casi todo esto un poco más arriba: solo para limpiarlo primero debe iniciar sesión en el Registro Docker con un token que tiene derechos para eliminar imágenes en el Registro Docker (el token de tarea GitLab CI emitido automáticamente no tienen tales derechos). El token debe crearse en GitLab con anticipación y su valor debe especificarse en la variable de entorno. WERF_IMAGES_CLEANUP_PASSWORD proyecto (Configuración de CI/CD -> Variables).

Agregar una tarea de limpieza con el cronograma requerido se realiza en CI/CD ->
Horarios.

Eso es todo: un proyecto en Docker Registry ya no crecerá constantemente a partir de imágenes no utilizadas.

Al final de la parte práctica, déjame recordarte que los listados completos del artículo están disponibles en Git:

resultado

Recibimos una estructura de ensamblaje lógica: un artefacto por versión.
El ensamblaje es universal y no requiere cambios manuales cuando se lanzan nuevas versiones de werf: la documentación en el sitio web se actualiza automáticamente.
Se ensamblan dos imágenes para diferentes contornos.
Funciona rápidamente porque El almacenamiento en caché se utiliza tanto como sea posible: cuando se lanza una nueva versión de werf o se llama a un enlace de GitHub para una confirmación de revisión, solo se reconstruye el artefacto correspondiente con la versión modificada.
No es necesario pensar en eliminar las imágenes no utilizadas: la limpieza según las políticas de Werf mantendrá el Registro Docker en orden.

Hallazgos

El uso de werf permite que el ensamblado funcione rápidamente debido al almacenamiento en caché tanto del ensamblado como del almacenamiento en caché cuando se trabaja con repositorios externos.
Trabajar con repositorios Git externos elimina la necesidad de clonar todo el repositorio cada vez o reinventar la rueda con una complicada lógica de optimización. werf usa un caché y realiza la clonación solo una vez, y luego usa fetch y sólo cuando sea necesario.
Posibilidad de utilizar plantillas Go en el archivo de configuración de compilación werf.yaml le permite describir un ensamblaje cuyo resultado depende de datos externos.
El uso de mount en werf acelera significativamente la recopilación de artefactos, gracias al caché, que es común a todas las canalizaciones.
werf facilita la configuración de la limpieza, lo cual es especialmente importante cuando se construye dinámicamente.