Get best of the week

Version Werf 1.1: améliorations du collecteur aujourd'hui et plans pour l'avenir



werf est notre utilitaire CLI GitOps open source pour la création et la livraison d'applications à Kubernetes. Comme promis, la sortie de la v1.0 a marqué le début de l'ajout de nouvelles fonctionnalités à werf et de la révision des approches familières. Nous sommes maintenant heureux de publier la v1.1, qui est une grande étape dans le développement et l'avenir du collecteur werf. La version est actuellement disponible dans le canal 1.1 ea .

La base de la sortie est la nouvelle architecture du stockage de scène et l'optimisation du travail des deux collectionneurs (pour Stapel et Dockerfile). La nouvelle architecture de stockage ouvre la possibilité de mettre en œuvre des assemblys distribués à partir de plusieurs hôtes et des assemblages parallèles sur un seul hôte.

L'optimisation du travail comprend la suppression des calculs inutiles au stade du calcul des signatures de stade et la modification des mécanismes de calcul des sommes de contrôle des fichiers par des mécanismes plus efficaces. Cette optimisation réduit le temps de construction moyen d'un projet utilisant werf. Et les versions inactives, lorsque toutes les étapes existent dans le cache de stockage des étapes , sont désormais très rapides. Dans la plupart des cas, le redémarrage de l'assemblage sera plus rapide qu'en 1 seconde! Cela vaut également pour les procédures de vérification des étapes du travail des équipes werf deployet werf run.

Dans cette version également, il y avait une stratégie pour le balisage des images par contenu - le balisage basé sur le contenu , qui est maintenant activé par défaut et est le seul recommandé.

Examinons de plus près les principales innovations de werf v1.1 et parlons en même temps des plans pour l'avenir.

Qu'est-ce qui a changé dans werf v1.1?


Nouveau format de dénomination d'étape et algorithme de sélection d'étape de cache


Nouvelle règle de génération de nom d'étape. Désormais, chaque assemblage d'étape génère un nom d'étape unique, qui se compose de 2 parties: une signature (comme dans la version 1.0) plus un identifiant temporaire unique.

Par exemple, le nom complet de l'image de la scène peut ressembler à ceci:

werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835

... ou sous une forme générale:

werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC

ici:

  • SIGNATURE - il s'agit de la signature de l'étape, qui représente l'identifiant du contenu de l'étape et dépend de l'historique des modifications dans Git qui ont conduit à ce contenu;
  • TIMESTAMP_MILLISEC - Ceci est garanti un identifiant unique pour l'image qui est générée lors de l'assemblage de la nouvelle image.

L'algorithme de sélection des étapes dans le cache est basé sur la vérification de la relation des validations Git:

  1. Werf calcule la signature d'une étape.
  2. Dans le stockage par étapes , il peut y avoir plusieurs étapes pour une signature donnée. Werf sélectionne toutes les étapes qui conviennent à la signature.
  3. Si l'étape actuelle est associée à Git (git-archive, utilisateur étape c Git-patches: install, beforeSetup, setupou git-dernière-patch), puis Werf sélectionne uniquement les étapes qui se rapportent à commettre, qui est l'ancêtre de l'engagement en cours (pour ce qui a provoqué l' assemblage )
  4. Parmi les étapes appropriées restantes, une est sélectionnée - la plus ancienne par date de création.

Une scène pour différentes branches Git peut avoir la même signature. Mais werf empêchera l'utilisation d'un cache associé à différentes branches entre ces branches, même si les signatures correspondent.

→ Documentation .

Nouvel algorithme de création et d'enregistrement d'étapes dans le stockage d'étapes


Si werf ne trouve pas d'étape appropriée lors de la sélection d'étapes dans le cache, le processus d'assemblage d'une nouvelle étape est lancé.

Notez que plusieurs processus (sur un ou plusieurs hôtes) peuvent commencer à assembler la même étape à peu près au même moment. Werf utilise l'algorithme de verrouillage optimiste des étapes de stockage lorsqu'une image fraîchement collectée est stockée dans les étapes de stockage . Ainsi, lorsque l'assemblage de la nouvelle étape est prêt, werf bloque le stockage des étapes et n'y enregistre l'image fraîchement collectée que s'il n'y a pas d'image appropriée (pour la signature et d'autres paramètres - voir le nouvel algorithme de sélection des étapes dans le cache) .

Une image fraîchement sélectionnée est garantie d'avoir un identifiant unique par TIMESTAMP_MILLISEC (voir le nouveau format de dénomination de la scène) . Si une image appropriée est trouvée dans stades-stockage , werf supprimera l'image fraîchement collectée et utilisera l'image du cache.

En d'autres termes: le premier processus qui termine la collecte de l'image (le plus rapide) recevra le droit de l'enregistrer dans les étapes de stockage (puis cette image particulière sera utilisée pour tous les assemblages). Un processus d'assemblage lent n'empêchera jamais un processus plus rapide d'enregistrer les résultats d'assemblage de l'étape en cours et de passer à l'assemblage suivant.

→ Documentation .

Amélioration des performances du collecteur Dockerfile


À l'heure actuelle, le pipeline des étapes pour une image compilée à partir du Dockerfile se compose d'une étape - dockerfile. Lors du calcul de la signature, la somme de contrôle des fichiers est prise en compte context, qui sera utilisée lors de l'assemblage. Avant cette amélioration, werf traversait récursivement tous les fichiers et recevait une somme de contrôle, résumant le contexte et le mode de chaque fichier. À partir de la version 1.1, werf peut utiliser les sommes de contrôle calculées stockées dans le référentiel Git.

L'algorithme est basé sur git ls-tree . L'algorithme prend en compte les entrées dans .dockerignoreet passe récursivement dans l'arborescence de fichiers uniquement si nécessaire. Ainsi, nous nous sommes débarrassés de la lecture du système de fichiers, et la dépendance de l'algorithme sur la taille n'est contextpas significative.

L'algorithme vérifie également les fichiers non suivis et, si nécessaire, les prend en compte dans la somme de contrôle.

Amélioration des performances lors de l'importation de fichiers


Werf v1.1 utilise le serveur rsync lors de l' importation de fichiers à partir d'artefacts et d'images . Auparavant, l'importation se faisait en deux étapes à l'aide du montage du répertoire à partir du système hôte.

Les performances d'importation sur macOS ne se limitent plus aux volumes Docker et les importations se font en même temps que Linux et Windows.

Balisage basé sur le contenu


Werf v1.1 prend en charge ce que l'on appelle le balisage par contenu d' image - balisage basé sur le contenu . Les balises des images Docker résultantes dépendent du contenu de ces images.

Lorsque vous exécutez la commande werf publish --tags-by-stages-signatureou werf ci-env --tagging-strategy=stages-signature, les images publiées de la soi-disant signature de l'étape d' image seront testées . Chaque image est étiquetée avec sa propre signature des étapes de cette image, qui est calculée selon les mêmes règles que la signature régulière de chaque étape séparément, mais est un identifiant généralisé de l'image.

La signature des étapes de l'image dépend:

  1. le contenu de cette image;
  2. Historique des révisions Git qui ont conduit à ce contenu.

Les référentiels Git ont toujours des validations inactives qui ne modifient pas le contenu des fichiers image. Par exemple, les validations avec des commentaires uniquement, ou les validations de fusion, ou les validations qui modifient les fichiers dans Git qui ne seront pas importés dans l'image.

L'utilisation du balisage basé sur le contenu résout le problème des redémarrages inutiles des modules d'application dans Kubernetes en raison des changements de nom d'image, même si le contenu de l'image n'a pas changé. Soit dit en passant, c'est l'une des raisons qui rend difficile le stockage de nombreux microservices d'une application dans un seul référentiel Git.

En outre, le balisage basé sur le contenu est une méthode de balisage plus fiable que le balisage par les branches Git, car le contenu des images résultantes ne dépend pas de l'ordre d'exécution des pipelines dans le système CI pour assembler plusieurs validations de la même branche.

Important: Désormais, la signature d'étapes est la seule stratégie de balisage recommandée . Il sera utilisé par défaut dans l'équipe werf ci-env(sauf si vous spécifiez explicitement un schéma de balisage différent).

→ Documentation . Une publication séparée sera également consacrée à cette fonctionnalité. MISE À JOUR (3 avril): Un article avec des détails a été publié .

Niveaux de journalisation


L'utilisateur a la possibilité de contrôler la sortie, de définir le niveau de journalisation et de travailler avec les informations de débogage. Ajout d' options --log-quiet, --log-verbose, --log-debug.

Par défaut, la sortie contient un minimum d'informations:



Lorsque vous utilisez la sortie détaillée ( --log-verbose), vous pouvez suivre le fonctionnement de werf: La



sortie détaillée ( --log-debug), en plus des informations de débogage de werf, contient également les journaux des bibliothèques utilisées. Par exemple, vous pouvez voir comment l'interaction avec le Docker Registry se produit, et également corriger les endroits où un temps important est passé:



Plans futurs


Attention! Les fonctionnalités décrites ci-dessous marquées v1.1 seront disponibles dans cette version, beaucoup d'entre elles dans un avenir proche. Les mises à jour proviendront des mises à jour automatiques lors de l'utilisation de multiwerf . Ces fonctionnalités n'affectent pas la partie stable des fonctions v1.1; leur apparence ne nécessitera pas d'intervention manuelle de l'utilisateur dans les configurations existantes.

Prise en charge complète de diverses implémentations de Docker Registry (NOUVEAU)



Le but est que l'utilisateur utilise une implémentation arbitraire sans restrictions lors de l'utilisation de werf.

À ce jour, nous avons identifié l'ensemble de solutions suivant pour lequel nous allons garantir un support complet:

  • Par défaut (bibliothèque / registre) *,
  • AWS ECR,
  • Azur *,
  • Docker hub
  • GCR *,
  • Forfaits Github
  • Registre GitLab *,
  • Port *,
  • Quai.

Un astérisque indique les solutions qui sont actuellement entièrement prises en charge par werf. Pour le reste, il y a du support, mais avec des limitations.

On peut distinguer deux problèmes principaux:

  • Certaines solutions ne prennent pas en charge la suppression des balises à l'aide de l'API Docker Registry, qui ne permet pas aux utilisateurs d'utiliser le nettoyage automatique implémenté dans werf. Cela est vrai pour AWS ECR, Docker Hub et GitHub Packages.
  • Certaines solutions ne prennent pas en charge les soi-disant référentiels imbriqués (Docker Hub, GitHub Packages et Quay) ou la prise en charge, mais l'utilisateur doit les créer manuellement à l'aide de l'interface utilisateur ou de l'API (AWS ECR).

Nous allons résoudre ces problèmes et d'autres en utilisant des API de solutions natives. Cette tâche comprend également la couverture du cycle werf complet avec des tests pour chacun d'eux.

Assemblage d'images distribuées (↑)



Pour le moment, werf v1.0 et v1.1 ne peut être utilisé que sur un seul hôte dédié pour l'assemblage et la publication d'images et déployer des applications dans Kubernetes.

Afin d'ouvrir les possibilités du travail distribué werf, lorsque l'assemblage et le déploiement d'applications dans Kubernetes est démarré sur plusieurs hôtes arbitraires et que ces hôtes ne maintiennent pas leur état entre les assemblys (coureurs temporaires), werf doit implémenter la possibilité d'utiliser le Docker Registry comme référentiel d'étape.

Auparavant, lorsque le projet werf s'appelait encore dapp, il avait une telle opportunité. Cependant, nous avons rencontré un certain nombre de problèmes qui doivent être pris en compte lors de l'implémentation de cette fonction dans werf.

Remarque. Cette fonctionnalité n'implique pas le travail du collecteur à l'intérieur des pods Kubernetes, car pour ce faire, débarrassez-vous de la dépendance à l'égard du serveur Docker local (dans le module Kubernetes, il n'y a pas d'accès au serveur Docker local, car le processus lui-même s'exécute dans le conteneur, et werf ne prend pas en charge et ne prend pas en charge le travail avec le serveur Docker sur le réseau). La prise en charge du travail dans Kubernetes sera mise en œuvre séparément.

Support officiel des actions GitHub (NOUVEAU)



Comprend la documentation werf ( références et sections de guide ), ainsi que l'action officielle GitHub pour travailler avec werf.

De plus, cela permettra à werf de travailler sur des coureurs éphémères.

La mécanique de l'interaction des utilisateurs avec le système CI sera basée sur la mise en place d'étiquettes sur les demandes d'extraction pour lancer certaines actions de création / déploiement de l'application.

Développement et déploiement d'applications locales avec werf (↓)


  • Version: v1.1
  • Dates: janvier-février avril
  • Problème

L'objectif principal est de réaliser une configuration unifiée unique pour déployer des applications à la fois localement et en production, sans actions complexes, hors de la boîte.

Werf a également besoin d'un mode de fonctionnement dans lequel il sera commode de modifier le code de l'application et de recevoir instantanément les commentaires d'une application qui fonctionne pour le débogage.

Nouvel algorithme de nettoyage (NOUVEAU)



Dans la version actuelle de werf v1.1, la procédure cleanupne prévoit pas de nettoyer les images pour le schéma de balisage basé sur le contenu - ces images s'accumuleront.

De plus, dans la version actuelle de werf (v1.0 et v1.1), différentes politiques de nettoyage sont utilisées pour les images publiées par les schémas de balisage: branche Git, balise Git ou validation Git.

Un nouvel algorithme de nettoyage d'image unifié pour tous les schémas de marquage a été inventé sur la base de l'historique des validations dans Git:

  • Ne stockez pas plus de N1 images associées aux N2 dernières validations pour chacun des git HEAD (branches et balises).
  • Ne stockez pas plus de N1 images-étapes associées aux N2 dernières validations pour chacun des git HEAD (branches et balises).
  • , - Kubernetes ( kube- namespace'; ).
  • , , Helm-.
  • , HEAD git (, HEAD ) Kubernetes Helm.

(↓)


  • : v1.1
  • : - *

La version actuelle de werf collecte les images et les artefacts décrits dans werf.yaml, séquentiellement. Il est nécessaire de paralléliser le processus d'assemblage d'étapes indépendantes d'images et d'artefacts, ainsi que de fournir une conclusion pratique et informative.

* Remarque: la date limite est décalée en raison de la priorité accrue pour la mise en œuvre d'un assemblage distribué, qui ajoutera plus de fonctionnalités pour la mise à l'échelle horizontale, ainsi que l'utilisation de werf avec les actions GitHub. L'assemblage parallèle est la prochaine étape d'optimisation, offrant une évolutivité verticale lors de l'assemblage d'un seul projet.

Passer à la barre 3 (↓)


  • Version: v1.2
  • Dates: février-mars mai *

Il comprend la transition vers la nouvelle base de code Helm 3 et un moyen éprouvé et pratique de migrer les installations existantes.

* Remarque: le passage à Helm 3 n'ajoutera pas de fonctionnalités importantes à werf, car toutes les fonctionnalités clés de Helm 3 (fusion à 3 voies et manque de barre) sont déjà implémentées dans werf. De plus, werf possède des fonctionnalités supplémentaires en plus de celles indiquées. Cependant, cette transition reste dans nos plans et sera mise en œuvre.

Description de la configuration de Jsonnet pour Kubernetes (↓)


  • Version: v1.2
  • Dates: janvier-février avril-mai

Werf prendra en charge la description de la configuration de Kubernetes au format Jsonnet. Dans le même temps, werf restera compatible avec Helm et il sera possible de sélectionner un format de description.

La raison en est que les modèles de langage Go, selon de nombreuses personnes, ont un seuil d'entrée important, et l'intelligibilité du code de ces modèles souffre également.

D'autres options pour l'implémentation de systèmes de description de configuration Kubernetes (comme Kustomize) sont également envisagées.

Travailler à l'intérieur de Kubernetes (↓)


  • Version: v1.2
  • Dates: avril-mai mai-juin

Objectif: Assurer l'assemblage des images et la livraison des applications à l'aide de coureurs dans Kubernetes. Ceux. l'assemblage de nouvelles images, leur publication, leur nettoyage et leur déploiement peuvent se faire directement à partir des modules Kubernetes.

Pour réaliser cette fonctionnalité, vous devez d'abord pouvoir créer des images de manière distribuée (voir le paragraphe ci-dessus) .

Il nécessite également la prise en charge du mode de fonctionnement de génération sans le serveur Docker (c'est-à-dire une construction de type Kaniko ou une construction dans l'espace utilisateur).

Werf prendra en charge les versions de Kubernetes non seulement avec le Dockerfile, mais aussi avec son générateur Stapel avec reconstructions incrémentielles et Ansible.

Un pas vers le développement open source


Nous aimons notre communauté ( GitHub , Telegram ) et nous voulons que de plus en plus de personnes contribuent à améliorer notre situation, à comprendre dans quelle direction nous allons et à participer au développement.

Plus récemment, il a été décidé de passer aux cartes de projet GitHub afin d'ouvrir le flux de travail de notre équipe. Vous pouvez maintenant voir les plans immédiats, ainsi que les travaux en cours dans les domaines suivants:


Beaucoup de travail a été fait sur les problèmes:

  • Supprimé non pertinent.
  • Les existants sont réduits à un seul format, un nombre suffisant de détails et de détails.
  • Ajout de nouveaux problèmes avec des idées et des suggestions.

Comment activer la version v1.1


La version est actuellement disponible dans le canal 1.1 ea (les versions dans les canaux stables et solides apparaîtront au fur et à mesure de leur stabilisation, mais ea lui-même est déjà suffisamment stable pour être utilisé, car il est passé par les canaux alpha et bêta ). Il est activé via multiwerf de la manière suivante:

source $(multiwerf use 1.1 ea)
werf COMMAND ...

Conclusion


La nouvelle architecture du magasin de scène et les performances optimisées du collecteur pour les collecteurs Stapel et Dockerfile ouvrent la possibilité de mettre en œuvre des assemblages distribués et parallèles dans werf. Ces fonctionnalités apparaîtront bientôt dans la même version v1.1 et deviendront automatiquement disponibles via le mécanisme de mise à jour automatique (pour les utilisateurs multiwerf ).

Dans cette version, une stratégie de balisage basée sur le contenu a été ajoutée , qui est devenue la stratégie par défaut. Un journal a également été repensé les commandes de base: werf build, werf publish, werf deploy, werf dismiss, werf cleanup.

La prochaine étape importante consistera à ajouter des assemblys distribués. Les assemblys distribués depuis la version 1.0 sont devenus une priorité plus élevée que les assemblages parallèles, car ils ajoutent plus de valeur werf: mise à l'échelle verticale des collecteurs et prise en charge des collecteurs éphémères dans divers systèmes CI / CD, ainsi que la possibilité de prendre officiellement en charge les actions GitHub. Par conséquent, le calendrier de mise en œuvre des assemblages parallèles a été décalé. Cependant, nous travaillons pour réaliser rapidement les deux possibilités.

Suivez l'actualité! Et n'oubliez pas de passer par notre GitHub pour créer un problème, en trouver un existant et mettre un plus, créer un PR ou simplement regarder le développement du projet.

PS


Lisez aussi dans notre blog:

More articles:


All Articles