Construction dynamique et déploiement des images Docker avec werf sur l'exemple d'un site de documentation versionnée

Nous avons déjà parlé à plusieurs reprises de notre outil GitOps werf, et cette fois, nous aimerions partager notre expérience de la construction du site avec la documentation du projet lui-même — werf.io (sa version en russe est — ru.werf.io). Il s'agit d'un site statique ordinaire, cependant, sa construction est intéressante car elle est réalisée en utilisant un nombre dynamique d'artefacts.

Nous ne plongerons pas dans les détails de la structure du site : génération du menu commun pour toutes les versions, pages d'information sur les versions, etc. — mais nous allons plutôt nous concentrer sur les questions et les particularités de la construction dynamique et un peu sur les processus connexes CI/CD.

Introduction : comment le site est organisé

Commençons par le fait que la documentation de werf est stockée avec son code. Cela impose certaines exigences au développement, qui dépassent globalement le cadre de cet article, mais nous pouvons au moins dire que :

• Les nouvelles fonctionnalités de werf ne doivent pas être publiées sans mise à jour de la documentation et, inversément, tout changement dans la documentation implique la sortie d'une nouvelle version de werf ;
• Le projet fait l'objet d'un développement assez intensif : de nouvelles versions peuvent sortir plusieurs fois par jour ;
• Toute opération manuelle de déploiement du site avec une nouvelle version de la documentation est au minimum fastidieuse ;
• Le projet adopte une approche de versioning sémantique versionning, avec 5 canaux de stabilité. Le processus de publication implique le passage successif des versions par les canaux dans l'ordre croissant de stabilité : d'alpha à rock-solid ;
• Le site dispose d'une version en russe, qui « vit et évolue » (c'est-à-dire que son contenu est mis à jour) parallèlement à la version principale (c'est-à-dire la version anglaise).

Pour cacher à l'utilisateur toute cette « cuisine interne », en lui proposant ce qui « fonctionne simplement », nous avons créé un outil séparé pour installer et mettre à jour werf — ce sont des multiwerf. Il suffit d'indiquer le numéro de version et le canal de stabilité que vous êtes prêt à utiliser, et multiwerf vérifiera s'il existe une nouvelle version sur le canal et la téléchargera si nécessaire.

Dans le menu de sélection des versions sur le site, les dernières versions de werf sont disponibles dans chaque canal. Par défaut, à l'adresse werf.io/documentation , s'ouvre la version du canal le plus stable pour la dernière version — elle est également indexée par les moteurs de recherche. La documentation pour le canal est disponible à des adresses distinctes (par exemple, werf.io/v1.0-beta/documentation pour la version beta 1.0).

En résumé, le site propose les versions suivantes :

1. racine (s'ouvre par défaut),
2. pour chaque canal actif de mises à jour de chaque version (par exemple, werf.io/v1.0-beta).

Pour générer une version spécifique du site, il suffit en général de le compiler avec Jekyll, en exécutant dans le répertoire /docs du dépôt werf la commande correspondante (jekyll build), après s'être préalablement configuré sur le Git-tag de la version nécessaire.

Il ne reste plus qu'à ajouter que :

• pour la compilation, on utilise l'outil lui-même (werf) ;
• les processus CI/CD sont basés sur GitLab CI ;
• et tout cela fonctionne, bien sûr, dans Kubernetes.

Objectifs

Formulons maintenant les tâches en tenant compte de toute cette spécificité :

1. Après le changement de version de werf sur n'importe quel canal de mise à jour, la documentation sur le site doit se mettre à jour automatiquement..
2. Pour le développement, il doit parfois être possible de consulter les versions préliminaires du site..

La recompilation du site doit être effectuée après le changement de version sur n'importe quel canal à partir des Git-tags correspondants, mais pendant le processus de construction de l'image, nous obtiendrons les particularités suivantes :

• Étant donné que la liste des versions sur les canaux change, il est nécessaire de ne recompter que la documentation pour les canaux où la version a changé. Recompiler tout de nouveau n'est pas très élégant.
• L'ensemble des canaux de release peut changer. À un moment donné, par exemple, il peut ne pas y avoir de version sur des canaux plus stables que la release early-access 1.1, mais au fil du temps, elles apparaîtront — ne pas changer la construction à la main dans ce cas ?

Il en résulte qu'un seul image provenant d'un registre lent peut bloquer le déploiement la construction dépend de données externes changeantes.

Mise en œuvre

Choix de l'approche

Comme option, on peut lancer chaque version nécessaire sur un pod séparé dans Kubernetes. Cette option implique un plus grand nombre d'objets dans le cluster, qui augmentera avec le nombre croissant de releases stables de werf. Cela entraîne à son tour une maintenance plus complexe : chaque version a son propre serveur HTTP, avec une charge par faible. Bien sûr, cela entraîne également des coûts en ressources plus élevés.

Nous avons cependant opté pour la compilation de toutes les versions nécessaires dans une seule image. La static compilée de toutes les versions du site se trouve dans un conteneur NGINX, et le trafic vers le Deployment correspondant passe par NGINX Ingress. Cette structure simple — application sans état — permet une scalabilité facile du Deployment (en fonction de la charge) grâce aux moyens de Kubernetes lui-même.

Pour être plus précis, nous générons deux images : l'une pour l'environnement de production, l'autre pour l'environnement de développement. L'image supplémentaire est utilisée (lancée) uniquement dans l'environnement de développement en parallèle avec la principale et contient la version du site issue du commit de révision, tandis que le routage entre elles est effectué à l'aide des ressources Ingress.

werf vs git clone et artefacts

Comme mentionné précédemment, pour générer la version statique du site pour une version spécifique de la documentation, il faut effectuer une compilation en basculant vers la balise correspondante du dépôt. On pourrait également le faire en clonant le dépôt chaque fois qu'une compilation est effectuée, en choisissant les balises appropriées selon une liste. Cependant, cela est une opération assez gourmande en ressources et nécessite également la rédaction d'instructions non triviales... Un autre inconvénient majeur est que cette approche ne permet pas de mettre quoi que ce soit en cache pendant la compilation.

Ici, nous avons le soutien de l'outil werf qui réalise le caching intelligent et permet d'utiliser des dépôts externes. L'utilisation de werf pour ajouter du code provenant du dépôt accélérera considérablement la compilation, car werf clone essentiellement le dépôt une fois, puis exécute uniquement fetch si nécessaire. De plus, lors de l'ajout de données depuis le dépôt, nous pouvons sélectionner uniquement les répertoires nécessaires (dans notre cas, c'est le dossier docs), ce qui réduit considérablement le volume des données ajoutées.

Puisque Jekyll est un outil destiné à la compilation de sites statiques et qu'il n'est pas nécessaire dans l'image finale, il serait logique de réaliser la compilation dans l'artefact werf, et d'importer dans l'image finale seulement le résultat de la compilation Écrivons werf.yaml.

Donc, nous avons décidé de compiler chaque version dans un artefact werf séparé. Cependant, nous

ne savons pas combien d'artefacts cela fera lors de la compilation , donc nous ne pouvons pas écrire une configuration de compilation fixe (strictement parlant, nous le pouvons, mais ce ne sera pas très efficace).werf permet d'utiliser

des modèles Go dans son fichier de configuration ( ), ce qui permet dewerf.yamlgénérer la configuration « à la volée » en fonction des données externes (ce qui est nécessaire !). Les données externes dans notre cas sont les informations sur les versions et les releases, sur la base desquelles nous assemblons le nombre nécessaire d'artefacts et obtenons en résultat deux images : werf-doc werf-dev et pour un déploiement sur différents environnements. pour le lancement sur différents contournements.

Les données externes sont transmises via des variables d'environnement. Voici leur composition :

• PUBLICATIONS — une chaîne contenant la liste des publications et leur version actuelle correspondante de werf, sous la forme d'une liste séparée par des espaces avec le format %. Exemple : 1.0%v1.0.4-beta.20
• CANAUX — une chaîne contenant la liste des canaux et leur version actuelle correspondante de werf, sous la forme d'une liste séparée par des espaces avec le format %. Exemple : 1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22
• VERSION_DE_BASE — la version de la publication werf à afficher par défaut sur le site (il n'est pas toujours nécessaire d'afficher la documentation pour le numéro de publication le plus élevé). Exemple : v1.0.4-beta.20
• HASH_DE_REVIEW — le hash du commit de review à partir duquel la version doit être construite pour le pipeline de test.

Ces variables seront peuplées dans le pipeline GitLab CI, et comment cela se fera est expliqué ci-dessous.

Tout d'abord, pour plus de commodité, nous allons définir dans werf.yaml les variables de modèle Go, en leur attribuant des valeurs provenant des variables d'environnement :

{{ $_ := set . "WerfVersions" (cat (env "CANAUX") (env "PUBLICATIONS") | splitList " ") }}
{{ $Root := . }}
{{ $_ := set . "WerfRootVersion" (env "VERSION_DE_BASE") }}
{{ $_ := set . "WerfReviewCommit" (env "HASH_DE_REVIEW") }}

La description de l'artefact pour la compilation de la version statique du site est globalement la même pour tous les cas nécessaires (y compris, la génération de la version racine et de la version pour le pipeline dev). Nous allons donc le déplacer dans un bloc séparé à l'aide de la fonction define — pour une réutilisation ultérieure via include. Le modèle recevra les arguments suivants :

• Version — la version générée (nom de la balise) ;
• Channel — le nom du canal de mise à jour pour lequel l'artefact est généré ;
• Commit — le hash du commit, si l'artefact est généré pour un commit de review ;
• contexte.

Description du modèle d'artefact

{{- 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: "Installer les Dépendances"
    shell: bundle install
    args:
      executable: /bin/bash
      chdir: /app/docs
  beforeSetup:
{{- if .Commit }}
  - shell: echo "Revoir 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/fr_site/
  - file:
      dest: /app/docs/pages_fr/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/_fr_site/{{ if .BaseURL }} --baseurl /{{ .BaseURL }}{{ end }} --config /app/docs/_config.yml,/app/docs/_config_fr.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 }}

Le nom de l'artefact doit être unique. Nous pouvons y parvenir, par exemple, en ajoutant le nom du canal (valeur de la variable .Channel) comme suffixe du nom de l'artefact : artifact: doc-{{ .Channel }}. Mais il est important de comprendre que lors de l'importation à partir des artefacts, il faudra se référer à ces mêmes noms.

Lors de la description de l'artefact, il existe une fonctionnalité de werf appelée montage. Le montage en spécifiant le répertoire de service build_dir permet de conserver le cache de Jekyll entre les exécutions du pipeline, ce qui accélère considérablement la reconstruction.

Vous avez également peut-être remarqué l'utilisation du fichier releases.yml — il s'agit d'un fichier YAML contenant des données sur les versions, demandé lors de github.com (artefact obtenu lors de l'exécution du pipeline). Il est nécessaire lors de la compilation du site, mais dans le contexte de cet article, il est intéressant de noter que son état influence la reconstruction d'un seul artefact — l'artefact de la version racine du site (il n'est pas nécessaire dans d'autres artefacts).

Cela est réalisé à l'aide d'un opérateur conditionnel if dans le modèle Go et de la construction {{ $Root.Files.Get "releases.yml" | sha256sum }} dans l'étape stade. Cela fonctionne de la manière suivante : lors de la création de l'artefact pour la version racine (la variable .Channel est égale à root) le hachage du fichier releases.yml influence la signature de toute la phase, car il fait partie du nom de la tâche Ansible (paramètre nom). Ainsi, lorsqu'il y a un changement de contenu, fichiers releases.yml l'artefact correspondant sera reconstruit.

Notez également le travail avec le dépôt externe. Dans l'image de l'artefact du dépôt werf, seul le répertoire est ajouté, /docset selon les paramètres passés, les données du tag ou du commit de révision nécessaires sont ajoutées immédiatement.

Pour utiliser le modèle d'artefact afin de générer la description de l'artefact des versions et des canaux transmis, organisons une boucle sur la variable .WerfVersions dans werf.yaml:

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

Comme la boucle générera plusieurs artefacts (nous l'espérons), il faut prendre en compte le séparateur entre eux — la séquence --- (voir plus sur la syntaxe du fichier de configuration dans documentation). Comme nous l'avons déterminé précédemment, lors de l'appel du modèle dans la boucle, nous passons les paramètres de version, l'URL et le contexte racine.

De manière similaire, mais sans boucle, nous appelons le modèle d'artefact pour les « cas particuliers » : pour la version racine, ainsi que pour la version du commit de révision :

{{ 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 }}

Remarque : l'artefact pour le commit de révision ne sera construit que si la variable .WerfReviewCommit.

Les artefacts sont prêts — il est temps de s'occuper de l'importation !

L'image finale, destinée à être exécutée dans Kubernetes, est un NGINX standard, auquel est ajouté un fichier de configuration de serveur nginx.conf et la partie statique de l'artefact. En plus de l'artefact de la version racine du site, nous devons répéter la boucle sur la variable .WerfVersions pour importer les artefacts des versions et des canaux, tout en respectant la règle de nommage des artefacts que nous avons adoptée précédemment. Puisque chaque artefact conserve les versions du site pour deux langues, nous les importons dans les emplacements prévus par la configuration.

Description de l'image finale 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 -}}

Une image supplémentaire qui s'exécute avec l'image principale sur le contour de développement contient uniquement deux versions du site : la version du commit de révision et la version racine du site (où se trouvent les assets communs et, si vous vous en souvenez, les données de version). Ainsi, l'image supplémentaire diffère de l'image principale uniquement par la section d'importation (et bien sûr, le nom) :

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 }}

Comme mentionné précédemment, l'artéfact pour le commit de révision ne sera généré que lors de l'exécution de la variable d'environnement configurée. HASH_DE_REVIEW. On aurait pu ne pas générer l'image werf-dev, s'il n'y a pas de variable d'environnement HASH_DE_REVIEW, mais pour que le nettoyage selon les politiques des images Docker dans werf fonctionne pour l'image werf-dev, nous laisserons celle-ci être construite uniquement avec l'artéfact de la version racine (de toute façon, elle est déjà construite), pour simplifier la structure du pipeline.

La construction est prête ! Passons au CI/CD et aux détails importants.

Le pipeline dans GitLab CI et les particularités de la construction dynamique

Lors du démarrage de la construction, nous devons configurer les variables d'environnement utilisées dans werf.yaml. Cela ne concerne pas la variable REVIEW_SHA, que nous allons configurer lors de l'appel du pipeline à partir du webhook GitHub.

La génération des données externes nécessaires sera effectuée dans un script Bash generate_artifacts, qui générera deux artefacts pour le pipeline GitLab :

• fichier releases.yml avec des informations sur les versions,
• fichier common_envs.sh, contenant les variables d'environnement pour l'exportation.

Contenu du fichier generate_artifacts que vous trouverez dans notre dépôt d'exemples. L'obtention des données elle-même n'est pas le sujet de l'article, mais le fichier common_envs.sh est important pour nous, car il affecte le fonctionnement de werf. Exemple de son contenu :

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'

Vous pouvez utiliser la sortie d'un tel script, par exemple, avec une fonction Bash source.

Et maintenant, la partie la plus intéressante. Pour que la construction et le déploiement de l'application fonctionnent correctement, il est nécessaire de faire en sorte que werf.yaml était identique au moins dans le cadre d'un pipeline. Si cette condition n'est pas remplie, les signatures des étapes, que werf calcule lors de la construction et, par exemple, lors du déploiement, seront différentes. Cela entraînera une erreur de déploiement, car l'image requise pour le déploiement sera absente.

En d'autres termes, si pendant la construction de l'image du site les informations sur les versions et releases sont identiques, mais qu'au moment du déploiement une nouvelle version sort et que les variables d'environnement prennent d'autres valeurs, alors le déploiement échouera : l'artefact de la nouvelle version n'est pas encore construit.

Si la génération werf.yaml dépend de données externes (par exemple, d'une liste de versions actuelles, comme dans notre cas), alors la composition et les valeurs de ces données doivent être fixées dans le cadre du pipeline. Cela est particulièrement important si les paramètres externes changent assez souvent.

Nous allons obtenir et fixer des données externes au cours de la première étape du pipeline dans GitLab (Prebuild) et les transmettre ensuite sous forme de d'artefact GitLab CI. Cela permettra de lancer et de relancer les tâches du pipeline (construction, déploiement, nettoyage) avec la même configuration dans werf.yaml.

Le contenu de l'étape Prebuild fichiers .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 weeks

Ayant fixé les données externes dans l'artefact, nous pouvons effectuer la construction et le déploiement, en utilisant les étapes standard du pipeline GitLab CI : Build et Deploy. Nous lançons le pipeline via des webhooks à partir du dépôt GitHub de werf (c'est-à-dire lors de changements dans le dépôt GitHub). Les données pour cela peuvent être trouvées dans les propriétés du projet GitLab dans la section CI / CD Settings -> Pipeline triggers, puis nous créerons dans GitHub un Webhook correspondant (Settings -> Webhooks).

L'étape de construction ressemblera à ceci :

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 ajoutera dans l'étape de construction deux artefacts de l'étape Prebuild, donc nous exportons les variables avec les données d'entrée préparées à l'aide de la construction source common_envs.sh. Nous lançons l’étape de construction dans tous les cas, sauf pour le démarrage du pipeline programmé. Un pipeline sera lancé pour le nettoyage - il n'est pas nécessaire d’exécuter la construction dans ce cas.

À l’étape de déploiement, nous allons décrire deux tâches - séparément pour le déploiement vers les environnements de production et de développement, en utilisant un modèle 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

Déployer en Production :
  <<: *base_deploy
  variables:
    WERF_KUBE_CONTEXT: prod
  environment:
    name: production
    url: werf.io
  only:
    refs:
      - master
  except:
    variables:
      - $REVIEW_SHA
    refs:
      - schedules

Déployer en Test :
  <<: *base_deploy
  variables:
    WERF_KUBE_CONTEXT: dev
  environment:
    name: test
    url: werf.test.flant.com
  except:
    refs:
      - schedules
  only:
    variables:
      - $REVIEW_SHA

Les tâches diffèrent essentiellement par la spécification du contexte du cluster dans lequel werf doit effectuer le déploiement (WERF_KUBE_CONTEXT), et par la définition des variables d'environnement pour le contour (environment.name et environment.url), qui sont ensuite utilisées dans les modèles de Helm chart. Nous ne fournirons pas le contenu des modèles car il n’y a rien d’intéressant pour le sujet en question, mais vous pouvez les trouver dans le dépôt lié à l’article.

Dernière touche

Étant donné que les versions de werf sortent assez fréquemment, de nouvelles images seront souvent construites, et le registre Docker continuera à croître. Il est donc impératif de configurer un nettoyage automatique des images selon des politiques. C'est très simple à mettre en œuvre.

Pour cela, il faudra :

• Ajouter une étape de nettoyage dans .gitlab-ci.yml;
• Ajouter l'exécution périodique de la tâche de nettoyage ;
• Configurer une variable d'environnement avec le token d'accès en écriture.

Nous ajoutons une étape de nettoyage dans .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

Nous avons déjà vu presque tout cela un peu plus haut - juste pour le nettoyage, il est nécessaire de se connecter au registre Docker avec un token ayant des droits pour supprimer des images dans le registre Docker (le token généré automatiquement pour les tâches GitLab CI n'a pas ces droits). Il faut obtenir le token à l’avance dans GitLab et en spécifier la valeur dans la variable d'environnement WERF_IMAGES_CLEANUP_PASSWORD du projet (CI/CD Settings -> Variables).

L'ajout de la tâche de nettoyage avec le programme requis se fait dans CI/CD ->
Schedules.

Tout : le projet dans Docker Registry ne va plus croître constamment à cause des images inutilisées.

En conclusion de la partie pratique, je rappelle que les listings complets de l'article sont disponibles dans Git:

• .gitlab-ci.yml;
• werf.yaml.

Résultat

1. Nous avons obtenu une structure de construction logique : un artefact pour une version.
2. La construction est universelle et n'exige pas de modifications manuelles lors de la sortie de nouvelles versions de werf : la documentation sur le site est mise à jour automatiquement.
3. Deux images sont construites pour différents contours.
4. Cela fonctionne rapidement, car le caching est utilisé au maximum : lors de la sortie d'une nouvelle version de werf ou d'un appel du webhook GitHub pour le commit de revue, seul l'artefact correspondant à la version modifiée est reconstruit.
5. Il n'est pas nécessaire de penser à la suppression des images inutilisées : le nettoyage selon les politiques de werf maintiendra l'ordre dans Docker Registry.

Conclusions

• L'utilisation de werf permet à la construction d'être rapide grâce à la mise en cache de la construction elle-même ainsi qu'à la mise en cache lors du travail avec des dépôts externes.
• Travailler avec des dépôts Git externes évite de devoir cloner le dépôt en entier à chaque fois ou d'inventer la roue avec une logique d'optimisation compliquée. werf utilise le cache et ne clone qu'une seule fois, puis utilise fetch et uniquement si nécessaire.
• La possibilité d'utiliser des modèles Go dans le fichier de configuration de la construction werf.yaml permet de décrire une construction dont le résultat dépend de données externes.
• L'utilisation du montage dans werf accélère considérablement la construction des artefacts - grâce à un cache qui est commun à tous les pipelines.
• werf permet de configurer facilement le nettoyage, ce qui est particulièrement pertinent lors de constructions dynamiques.

P.S.

Lisez aussi dans notre blog :

• «Lancement de commandes lors de la livraison d'une nouvelle version de l'application dans Kubernetes»;
• «Construction et déploiement de microservices similaires avec werf et GitLab CI.»;
• «Utilisation de werf pour le déploiement de charts Helm complexes»;
• «Nous vous présentons werf 1.0 stable : quel est le rapport avec GitOps, le statut et les plans».

Source : habr.com