— notre outil CLI GitOps open source pour la construction et la livraison d'applications dans Kubernetes. Comme promis, a marqué le début de l'ajout de nouvelles fonctionnalités à werf et de la révision des approches habituelles. Nous sommes maintenant ravis de présenter la version v1.1, qui représente une avancée majeure et une base pour l'avenir. du générateur werf. La version est actuellement disponible dans .
La base de la version est une nouvelle architecture de stockage des étapes et l'optimisation des deux générateurs (pour Stapel et Dockerfile). La nouvelle architecture de stockage ouvre des possibilités pour la mise en œuvre de constructions distribuées à partir de plusieurs hôtes et d'exécutions parallèles sur un même hôte.
L'optimisation inclut l'élimination des calculs inutiles lors du calcul des signatures des étapes et la modification des mécanismes de calcul des sommes de contrôle des fichiers vers des méthodes plus efficaces. Cette optimisation réduit le temps moyen de construction d'un projet avec werf. Et les constructions vides, lorsque toutes les étapes existent dans le cache stages-storage, sont désormais réellement rapides. Dans la plupart des cas, le redémarrage d'une construction s'effectue en moins d'une seconde ! Cela s'applique également aux procédures de vérification des étapes lors de l'exécution des équipes werf deploy et werf run.
Aussi, dans cette version, une stratégie de marquage des images basée sur le contenu est apparue — content-based tagging, qui est désormais activée par défaut et est la seule recommandée.
Examinons de plus près les nouvelles fonctionnalités clés de werf v1.1, tout en parlant de nos projets pour l'avenir.
Qu'est-ce qui a changé dans werf v1.1 ?
Un nouveau format de nommage des étapes et un algorithme de sélection des étapes à partir du cache
Une nouvelle règle de génération de nom d'étape. Maintenant, chaque construction d'étape génère un nom d'étape unique, qui se compose de 2 parties : la signature (comme dans v1.0) plus un identifiant temporel unique.
Par exemple, le nom complet de l'image d'étape peut ressembler à ceci :
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
… ou en général :
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Ici :
-
SIGNATURE— c'est 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— c'est un identifiant garanti unique de l'image, qui est généré au moment de la construction de la nouvelle image.
L'algorithme de sélection des étapes à partir du cache est basé sur la vérification de la parenté des commits Git :
- Werf calcule la signature d'un certain stade.
- Dans stages-storage Il peut y avoir plusieurs stades correspondant à cette signature. Werf sélectionne tous les stades appropriés selon la signature.
- Si le stade actuel est lié à Git (git-archive, stade personnalisé avec des patches Git :
install,beforeSetup,configuration; ou git-latest-patch), alors werf choisit uniquement les stades qui sont liés à un commit qui est un ancêtre du commit actuel (pour lequel la construction est invoquée). - Parmi les stades appropriés restants, un est sélectionné — le plus ancien par date de création.
Un stade pour différentes branches Git peut avoir la même signature. Mais werf empêchera l'utilisation du cache lié à différentes branches, même si les signatures coïncident.
.
Nouvel algorithme de création et de sauvegarde des stades dans le stockage des stades
Si, lors de la recherche de stades dans le cache, werf ne trouve pas de stade approprié, alors un processus de construction d'un nouveau stade est initié.
Notons que plusieurs processus (sur un ou plusieurs hôtes) peuvent commencer à construire le même stade à peu près au même moment. Werf utilise un algorithme de verrouillage optimiste stages-storage au moment de la sauvegarde de l'image fraîchement construite dans stages-storage. Ainsi, lorsque la construction d'un nouveau stade est prête, werf verrouille stages-storage et sauvegarde l'image fraîchement construite uniquement si aucune image appropriée n'existe déjà (selon la signature et d'autres paramètres — voir le nouvel algorithme de recherche de stades dans le cache).
L'image fraîchement construite aura garantissant un identifiant unique selon TIMESTAMP_MILLISEC (voir le nouveau format de nommage des stades). Dans le cas où une image appropriée serait trouvée dans stages-storage , werf rejettera l'image fraîchement construite et utilisera l'image du cache.
En d'autres termes : le premier processus qui terminera de construire l'image (le plus rapide) obtiendra le droit de la sauvegarder dans le stages-storage (et ensuite, cette unique image sera utilisée pour toutes les constructions). Le processus de construction plus lent ne bloquera jamais le processus le plus rapide dans la sauvegarde des résultats de la construction du stade actuel et dans le passage à la construction du suivant.
.
Amélioration des performances du constructeur Dockerfile
À l'heure actuelle, le pipeline des stades pour l'image construite à partir du Dockerfile se compose d'un seul stade — dockerfile. Lors du calcul de la signature, la somme de contrôle des fichiers est prise en compte. context, qui seront utilisés lors de la construction. Avant cette amélioration, werf parcourait récursivement tous les fichiers et obtenait un hash de contrôle en additionnant le contexte et le mode de chaque fichier. À partir des versions v1.1, werf peut utiliser les hashes de contrôle calculés, stockés dans le dépôt Git.
À la base de l'algorithme se trouve . L'algorithme prend en compte les enregistrements dans .dockerignore et parcourt récursivement l'arbre des fichiers uniquement si nécessaire. Ainsi, nous nous sommes détachés de la lecture du système de fichiers, et la dépendance de l'algorithme à la taille context n'est pas significative.
L'algorithme vérifie également les fichiers non suivis et les prend en compte dans le hash de contrôle si nécessaire.
Amélioration des performances lors de l'importation de fichiers
Dans les versions werf v1.1, un serveur rsync est utilisé lors . Auparavant, l'importation se faisait en deux étapes à l'aide du montage d'un répertoire à partir du système hôte.
Les performances des importations sur macOS ne sont plus limitées par les volumes Docker, et les importations se font dans le même temps que sur Linux et Windows.
Tagging basé sur le contenu
Werf v1.1 prend en charge ce que l'on appelle le tagging basé sur le contenu de l'image — content-based tagging. Les tags des images Docker résultantes dépendent du contenu de ces images.
Lors de l'exécution de la commande werf publish --tags-by-stages-signature ou werf ci-env --tagging-strategy=stages-signature taguera les images publiées par ce que l'on appelle la signature des étapes de l'image. Chaque image est tagué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 chacune des étapes individuellement, mais constitue un identifiant généralisé de l'image.
La signature des étapes de l'image dépend de :
- le contenu de cette image ;
- l'historique des modifications dans Git qui ont conduit à ce contenu.
Dans le dépôt Git, il y a toujours des commits vides qui ne modifient pas le contenu des fichiers de l'image. Par exemple, des commits uniquement avec des commentaires ou des commits de fusion, ou des commits qui modifient les fichiers dans Git qui ne seront pas importés dans l'image.
L'utilisation du tagging basé sur le contenu résout les problèmes de redémarrages inutiles des pods de l'application dans Kubernetes à cause de changements de nom de l'image, même si le contenu de l'image n'a pas changé. En fait, c'est l'une des raisons qui empêche de stocker plusieurs microservices d'une même application dans un seul dépôt Git.
Le balisage basé sur le contenu est une méthode de balisage plus fiable que le balisage par 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 construire plusieurs commits de la même branche.
Important: à partir de maintenant stages-signature — ce sont des la seule stratégie de balisage recommandée. C'est celle qui sera utilisée par défaut dans l'équipe werf ci-env (si aucune autre schéma de balisage n'est explicitement indiqué).
. Cette fonctionnalité aura également sa propre publication. MIS À JOUR (3 avril) : Article avec des détails .
Niveaux de journalisation
L'utilisateur a maintenant la possibilité de contrôler la sortie, de définir le niveau de journalisation et de travailler avec les informations de débogage. Options ajoutées --log-quiet, --log-verbose, --log-debug.
Par défaut, la sortie contient un minimum d'informations :
Lors de l'utilisation de la sortie détaillée (--log-verbose) on peut voir comment fonctionne 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, on peut voir comment se déroule l'interaction avec Docker Registry, ainsi que noter les endroits où un temps considérable est dépensé :
Plans futurs
Attention ! Les fonctionnalités décrites ci-dessous avec la mention v1.1 seront disponibles dans cette version, beaucoup d'entre elles — dans un avenir proche. Les mises à jour arriveront par des auto-mises à jour . Ces fonctionnalités ne touchent pas la partie stable des fonctions v1.1, leur apparition ne nécessitera pas d'intervention manuelle de l'utilisateur dans les configurations existantes.
Prise en charge complète des différentes implémentations de Docker Registry (NOUVEAU)
- Version : v1.1
- Délai : mars
L'objectif est que l'utilisateur puisse utiliser n'importe quelle implémentation sans restrictions lors de l'utilisation de werf.
Actuellement, nous avons sélectionné le jeu de solutions suivant pour lesquelles nous nous engageons à garantir une prise en charge complète :
- Default (library/registry)*,
- AWS ECR,
- Azure*,
- Docker Hub,
- GCR*,
- GitHub Packages,
- GitLab Registry*,
- Harbor*,
- Quay.
Les solutions marquées d'une étoile sont celles qui sont déjà complètement prises en charge par werf. Pour les autres, il existe un soutien, mais avec des restrictions.
On peut identifier deux problèmes majeurs :
- Certaines solutions ne prennent pas en charge la suppression de balises via l'API Docker Registry, ce qui empêche les utilisateurs d'utiliser le nettoyage automatique mis en œuvre dans werf. Cela est vrai pour AWS ECR, Docker Hub et GitHub Packages.
- Certain solutions do not support so-called nested repositories (Docker Hub, GitHub Packages, and Quay) or support it but the user must create them manually using the UI or API (AWS ECR).
We plan to address these and other issues using the native APIs of the solutions. This task also includes covering the full cycle of werf operation with tests for each of them.
Distributed image building (↑)
- Version: v1.2 v1.1 (the priority for implementing this feature has been increased)
- Timeline: March-April March
Currently, werf v1.0 and v1.1 can only be used on a single dedicated host for building and publishing images and deploying applications in Kubernetes.
To unlock distributed working capabilities of werf, where building and deploying applications in Kubernetes is launched on several arbitrary hosts and these hosts do not retain their state between builds (temporary runners), werf requires the implementation of using Docker Registry as a stage storage.
Previously, when the werf project was still called dapp, this possibility existed. However, we encountered several issues that need to be addressed when implementing this feature in werf.
Remarque. This feature does not imply the operation of the builder inside Kubernetes pods, as it requires eliminating the dependency on a local Docker server (there is no access to the local Docker server in the Kubernetes pod because the process itself is running in a container, and werf does not support and will not support working with a Docker server over the network). Support for working in Kubernetes will be implemented separately.
Official support for GitHub Actions (NEW)
- Version : v1.1
- Délai : mars
Includes werf documentation (sections reference et guide), as well as the official GitHub Action for working with werf.
In addition, it will allow werf to run on ephemeral runners.
The user interaction with the CI system will be based on setting labels on pull requests to initiate specific build/deployment actions.
Local development and deployment of applications with werf (↓)
- Version : v1.1
- Timeline: January-February April
The main goal is to achieve a single unified config for deploying applications both locally and in production, without complex actions, 'out of the box.'
Il est également nécessaire pour werf de disposer d'un mode de fonctionnement qui facilite la modification du code de l'application et permet de recevoir instantanément des retours d'informations sur l'application en cours d'exécution pour le débogage.
Nouvel algorithme de nettoyage (NOUVEAU)
- Version : v1.1
- Délais : avril
Dans la version actuelle de werf v1.1, la procédure cleanup ne prévoit pas le nettoyage des images pour le schéma de balisage basé sur le contenu (content-based tagging) — ces images vont s'accumuler.
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 selon des schémas de balisage : branche Git, tag Git ou commit Git.
Un nouvel algorithme de nettoyage unifié pour tous les schémas de balisage a été conçu, basé sur l'historique des commits dans Git :
- Conserver au maximum N1 images, liées aux N2 derniers commits pour chaque git HEAD (branches et tags).
- Conserver au maximum N1 images d'étape, liées aux N2 derniers commits pour chaque git HEAD (branches et tags).
- Conserver toutes les images qui sont utilisées dans des ressources Kubernetes (tous les contextes kube du fichier de configuration et les espaces de noms sont scannés ; ce comportement peut être limité par des options spéciales).
- Conserver toutes les images utilisées dans les manifestes de configuration des ressources enregistrées dans les releases Helm.
- Une image peut être supprimée si elle n'est liée à aucun HEAD dans git (par exemple, parce que le HEAD correspondant a été supprimé) et qu'elle n'est utilisée dans aucun des manifestes du cluster Kubernetes et dans les releases Helm.
Construction parallèle des images (↓)
- Version : v1.1
- Délais : janvier-février avril*
La version actuelle de werf construit les images et artefacts décrits dans werf.yaml, de manière séquentielle. Il est nécessaire de paralléliser le processus de construction des étapes d'images et d'artefacts indépendants, ainsi que de fournir une sortie pratique et informative.
* Remarque : le délai est décalé en raison de la priorité accrue accordée à la mise en œuvre de la construction distribuée, qui ajoutera davantage de possibilités de mise à l'échelle horizontale, ainsi que l'utilisation de werf avec GitHub Actions. La construction parallèle constitue la prochaine étape d'optimisation, offrant une scalabilité verticale lors de la construction d'un seul projet.
Migration vers Helm 3 (↓)
- Version : v1.2
- Délais : février-mars mai*
Comprend la migration vers une nouvelle base de code et un moyen éprouvé et pratique de migrer les installations existantes.
* Remarque : la migration vers Helm 3 n'ajoutera pas de fonctionnalités importantes à werf, car toutes les caractéristiques clés de Helm 3 (fusion à 3 voies et absence de tiller) sont déjà implémentées dans werf. De plus, werf dispose au-delà de celles-ci. Cependant, cette transition reste dans nos projets et sera mise en œuvre.
Jsonnet pour décrire la configuration de Kubernetes (↓)
- Version : v1.2
- Délais : janvier-février avril-mai
Werf prendra en charge la description de la configuration pour Kubernetes au format Jsonnet. Ainsi, werf restera compatible avec Helm et offrira la possibilité de choisir le format de description.
La raison est que les modèles du langage Go, selon de nombreuses personnes, ont un seuil d'entrée élevé et la clarté du code de ces modèles souffre également.
L'implémentation d'autres systèmes de description de configuration Kubernetes (par exemple, Kustomize) est également envisagée.
Travail au sein de Kubernetes (↓)
- Version : v1.2
- Délais : avril-mai mai-juin
Objectif : assurer la construction d'images et la livraison d'applications en utilisant des runners dans Kubernetes. C'est-à-dire que la construction de nouvelles images, leur publication, le nettoyage et le déploiement peuvent se faire directement depuis les pod Kubernetes.
Pour mettre en œuvre cette possibilité, il faut d'abord la possibilité de construction d'images distribuées (voir point ci-dessus).
Un support pour le mode de fonctionnement du constructeur sans serveur Docker (c'est-à-dire une construction similaire à Kaniko ou dans l’espace utilisateur) est également nécessaire.
Werf prendra en charge la construction dans Kubernetes non seulement à l'aide de Dockerfile, mais aussi avec son propre constructeur Stapel, avec des reconstructions incrémentales et Ansible.
Un pas vers le développement ouvert
Nous aimons notre communauté (, ) et souhaitons que de plus en plus de personnes aident à améliorer werf, comprennent la direction dans laquelle nous avançons et participent au développement.
Récemment, il a été décidé de passer à afin d'ouvrir un peu le processus de travail de notre équipe. Il est maintenant possible de consulter les plans à court terme, ainsi que les travaux en cours dans les domaines suivants :
- ;
- ;
- ;
- .
Un grand travail a été réalisé sur les problèmes :
- Les obsolètes ont été supprimés.
- Les existants ont été mis au format uniforme, avec un nombre suffisant de détails et d'explications.
- De nouveaux problèmes ont été ajoutés avec des idées et des suggestions.
Comment activer la version v1.1
La version est disponible actuellement dans (dans les canaux stable et rock-solid les versions apparaîtront à mesure qu'elles se stabilisent, mais ea elle est déjà suffisamment stable pour être utilisée, car elle a passé les canaux alpha et beta). S'active via de la manière suivante :
source $(multiwerf use 1.1 ea)
werf COMMAND ...Conclusion
La nouvelle architecture de stockage des étapes et l'optimisation du fonctionnement du constructeur pour les constructeurs Stapel et Dockerfile offrent des possibilités de réaliser des constructions distribuées et parallèles dans werf. Ces fonctionnalités seront bientôt disponibles dans la même version v1.1 et deviendront automatiquement accessibles via le mécanisme des mises à jour automatiques (pour les utilisateurs ).
Dans cette version, une stratégie de taggage basée sur le contenu des images a été ajoutée — content-based tagging, — qui est devenue la stratégie par défaut. De plus, le journal des principales commandes a été révisé : werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
La prochaine étape importante sera l'ajout de constructions distribuées. Les constructions distribuées sont devenues une tâche plus prioritaire depuis v1.0 par rapport aux constructions parallèles, car elles apportent plus de valeur à werf : mise à l'échelle verticale des constructeurs et support des constructeurs éphémères dans divers systèmes CI/CD, ainsi que la possibilité d'ajouter un support officiel pour GitHub Actions. Par conséquent, les délais de mise en œuvre des constructions parallèles ont été repoussés. Cependant, nous travaillons pour réaliser rapidement les deux fonctionnalités.
Restez à l'écoute ! Et n'oubliez pas de nous rendre visite sur , pour créer une issue, trouver une déjà existante et lui donner un coup de pouce, créer une PR ou simplement suivre le développement du projet.
P.S.
Lisez aussi dans notre blog :
- «»
- «»;
- Utilisation de werf pour le déploiement de charts Helm complexes
- «»;
- «»;
- «»;
- «».
Source : habr.com
