est notre utilitaire CLI GitOps open source pour créer et fournir des applications sur Kubernetes. Comme promis, a marqué le début de l’ajout de nouvelles fonctionnalités à werf et de la révision des approches traditionnelles. Nous sommes désormais heureux de présenter la version v1.1, qui constitue une étape importante dans le développement et une base pour l'avenir. collectionneur werf. La version est actuellement disponible en .
La base de la version est la nouvelle architecture de stockage de scène et l'optimisation du travail des deux collecteurs (pour Stapel et Dockerfile). La nouvelle architecture de stockage ouvre la possibilité d'implémenter des assemblys distribués à partir de plusieurs hôtes et des assemblys parallèles sur le même hôte.
L'optimisation du travail comprend l'élimination des calculs inutiles au stade du calcul des signatures d'étape 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 moyen de construction des projets utilisant werf. Et les builds inactives, lorsque toutes les étapes existent dans le cache stockage-étapes, sont maintenant très rapides. Dans la plupart des cas, le redémarrage de la build prendra moins d’une seconde ! Cela s’applique également aux procédures de vérification des étapes du processus de travail des équipes. werf deploy и werf run.
Également dans cette version, une stratégie de marquage des images par contenu est apparue : balisage basé sur le contenu, qui est désormais activé par défaut et le seul recommandé.
Examinons de plus près les principales innovations de werf v1.1, tout en vous parlant des projets pour l'avenir.
Qu'est-ce qui a changé dans werf v1.1 ?
Nouveau format de dénomination des étapes et algorithme de sélection des étapes à partir du cache
Nouvelle règle de génération de nom de scène. Désormais, chaque étape de construction génère un nom d'étape unique, composé de 2 parties : une signature (comme c'était le cas dans la version 1.0) plus un identifiant temporaire unique.
Par exemple, le nom complet de l’image de scène pourrait ressembler à ceci :
werf-stages-storage/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835
...ou en général :
werf-stages-storage/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC
Ici:
-
SIGNATUREest une signature d'é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_MILLISECest un identifiant d'image unique garanti qui est généré au moment de la création d'une nouvelle image.
L'algorithme de sélection des étapes dans le cache est basé sur la vérification de la relation des commits Git :
- Werf calcule la signature d'une certaine étape.
- В stockage-étapes Il peut y avoir plusieurs étapes pour une signature donnée. Werf sélectionne toutes les étapes qui correspondent à la signature.
- Si l'étape actuelle est liée à Git (git-archive, étape personnalisée avec les patchs Git :
install,beforeSetup,setup; ou git-latest-patch), alors werf sélectionne uniquement les étapes associées à un commit qui est un ancêtre du commit actuel (pour lequel la construction est appelée). - Parmi les étapes appropriées restantes, une est sélectionnée - la plus ancienne par date de création.
Une étape pour différentes branches Git peut avoir la même signature. Mais werf empêchera que le cache associé aux différentes branches soit utilisé entre ces branches, même si les signatures correspondent.
.
Nouvel algorithme de création et de sauvegarde des étapes dans le stockage des étapes
Si, lors de la sélection des étapes dans le cache, werf ne trouve pas d'étape appropriée, le processus d'assemblage d'une nouvelle étape est lancé.
Notez que plusieurs processus (sur un ou plusieurs hôtes) peuvent commencer à créer la même étape à peu près au même moment. Werf utilise un algorithme de blocage optimiste stockage-étapes au moment de sauvegarder l'image fraîchement collectée dans stockage-étapes. De cette façon, lorsque la nouvelle construction de scène est prête, le werf bloque stockage-étapes et y enregistre une image fraîchement collectée uniquement si une image appropriée n'y existe plus (par signature et autres paramètres - voir le nouvel algorithme de sélection des étapes depuis le cache).
Une image fraîchement assemblée est garantie d'avoir un identifiant unique par TIMESTAMP_MILLISEC (voir le nouveau format de dénomination des étapes). Au cas où dans stockage-étapes une image appropriée sera trouvée, werf supprimera l'image fraîchement compilée et utilisera l'image du cache.
En d’autres termes : le premier processus à terminer la construction de l’image (le plus rapide) aura le droit de la stocker en stages-storage (et c’est ensuite cette unique image qui sera utilisée pour tous les builds). Un processus de build lent n’empêchera jamais un processus plus rapide d’enregistrer les résultats de build de l’étape en cours et de passer à la build suivante.
.
Amélioration des performances du générateur Dockerfile
À l'heure actuelle, le pipeline d'étapes pour une image créée à partir d'un Dockerfile se compose d'une étape : dockerfile. Lors du calcul de la signature, la somme de contrôle des fichiers est calculée context, qui sera utilisé lors du montage. Avant cette amélioration, Werf parcourait de manière récursive tous les fichiers et obtenait une somme de contrôle en additionnant le contexte et le mode de chaque fichier. À partir de la version 1.1, werf peut utiliser des sommes de contrôle calculées stockées dans un référentiel Git.
L'algorithme est basé sur . L'algorithme prend en compte les enregistrements dans .dockerignore et parcourt l'arborescence des fichiers de manière récursive uniquement lorsque cela est nécessaire. Ainsi, nous avons découplé de la lecture du système de fichiers, et de la dépendance de l'algorithme à la taille context n'est pas significatif.
L'algorithme vérifie également les fichiers non suivis et, si nécessaire, les prend en compte dans la somme de contrôle.
Performances améliorées lors de l'importation de fichiers
Les versions de werf v1.1 utilisent un serveur rsync lorsque . Auparavant, l'importation se faisait en deux étapes à l'aide d'un montage de répertoire à partir du système hôte.
Les performances d'importation sur macOS ne sont plus limitées par les volumes Docker et les importations se terminent dans le même laps de temps que Linux et Windows.
Balisage basé sur le contenu
Werf v1.1 prend en charge ce que l'on appelle le marquage par contenu d'image - balisage basé sur le contenu. Les balises 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 images publiées de ce qu'on appelle signature de scène image. 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 constitue un identifiant général de l'image.
La signature des étapes image dépend :
- le contenu de cette image ;
- historiques des modifications de Git qui ont conduit à ce contenu.
Un référentiel Git contient toujours des commits factices qui ne modifient pas le contenu des fichiers image. Par exemple, des commits avec uniquement 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.
Lors de l'utilisation du balisage basé sur le contenu, les problèmes de redémarrages inutiles des modules d'application dans Kubernetes en raison de modifications du nom de l'image sont résolus, même si le contenu de l'image n'a pas changé. Soit dit en passant, c'est l'une des raisons qui empêche de stocker de nombreux microservices d'une même application dans un seul référentiel Git.
De plus, le balisage basé sur le contenu est une méthode de balisage plus fiable que le balisage sur les branches Git, car le contenu des images résultantes ne dépend pas de l'ordre dans lequel les pipelines sont exécutés dans le système CI pour assembler plusieurs commits de la même branche.
Il est important: à partir de maintenant signature d'étapes - Est la seule stratégie de marquage recommandée. Il sera utilisé par défaut dans la commande werf ci-env (sauf si vous spécifiez explicitement un schéma de balisage différent).
. Une publication distincte sera également consacrée à cette fonctionnalité. MIS À JOUR (3 avril) : Article avec détails .
Niveaux de journalisation
L'utilisateur a désormais 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 les informations minimales :
Lors de l'utilisation d'une sortie détaillée (--log-verbose) vous pouvez voir comment fonctionne werf :
Sortie détaillée (--log-debug), en plus des informations de débogage werf, contient également les journaux des bibliothèques utilisées. Par exemple, vous pouvez voir comment se produit l'interaction avec le registre Docker et également enregistrer les endroits où une quantité importante de temps est passée :
Autres plans
Attention! Les options décrites ci-dessous sont marquées v1.1 seront disponibles dans cette version, dont beaucoup dans un avenir proche. Les mises à jour viendront via des mises à jour automatiques . Ces fonctionnalités n'affectent pas la partie stable des fonctions de la v1.1 ; leur apparition 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)
- Version: v1.1
- Dates : mars
L'objectif est que l'utilisateur puisse utiliser une implémentation personnalisée sans restrictions lors de l'utilisation de werf.
Actuellement, nous avons identifié l'ensemble de solutions suivant pour lequel nous allons garantir un support complet :
- Par défaut (bibliothèque/registre)*,
- AWSECR
- Azur*,
- Centre Docker
- GCR*,
- Forfaits GitHub
- Registre GitLab*,
- Port*,
- Quai.
Les solutions actuellement entièrement prises en charge par werf sont marquées d'un astérisque. Pour d’autres, il existe un soutien, mais avec des limites.
Deux problèmes principaux peuvent être identifiés :
- Certaines solutions ne prennent pas en charge la suppression des balises à l'aide de l'API Docker Registry, empêchant les utilisateurs d'utiliser le nettoyage automatique de Werf. Cela est vrai pour les packages AWS ECR, Docker Hub et GitHub.
- Certaines solutions ne prennent pas en charge les référentiels dits imbriqués (Docker Hub, GitHub Packages et Quay) ou le font, 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 les API natives des solutions. Cette tâche consiste également à couvrir le cycle complet d'exploitation du site avec des tests pour chacun d'eux.
Création d'images distribuées (↑)
- Version : v1.2 v1.1 (la priorité d'implémentation de cette fonctionnalité a été augmentée)
- Dates : mars-avril
Pour le moment, werf v1.0 et v1.1 ne peuvent être utilisés que sur un hôte dédié pour les opérations de création et de publication d'images et de déploiement de l'application sur Kubernetes.
Pour ouvrir les possibilités du travail distribué de werf, lorsque la construction et le déploiement d'applications dans Kubernetes sont lancés sur plusieurs hôtes arbitraires et que ces hôtes ne sauvegardent pas leur état entre les builds (exécuteurs temporaires), werf est nécessaire pour implémenter la possibilité d'utiliser le Docker Registry en tant que magasin de scène.
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 fonctionnalité dans werf.
Noter. Cette fonctionnalité ne nécessite pas que le collecteur fonctionne dans les pods Kubernetes, car Pour ce faire, vous devez vous débarrasser de la dépendance à l'égard du serveur Docker local (dans le pod Kubernetes, il n'y a pas d'accès au serveur Docker local, car le processus lui-même s'exécute dans un conteneur, et werf ne prend pas en charge et ne prendra pas en charge travailler avec le serveur Docker sur le réseau). La prise en charge de l'exécution de Kubernetes sera implémentée séparément.
Prise en charge officielle des actions GitHub (NOUVEAU)
- Version: v1.1
- Dates : mars
Comprend la documentation werf (sections référence и guide), ainsi que l'action GitHub officielle pour travailler avec werf.
De plus, cela permettra à Werf de travailler sur des coureurs éphémères.
Les mécanismes d'interaction de l'utilisateur avec le système CI seront basés sur le placement d'étiquettes sur les demandes d'extraction pour lancer certaines actions de création/déploiement de l'application.
Développement local et déploiement d'applications avec werf (↓)
- Version: v1.1
- Dates : janvier-février avril
L'objectif principal est de parvenir à une configuration unifiée unique pour déployer des applications à la fois localement et en production, sans actions complexes, prêtes à l'emploi.
werf doit également disposer d'un mode de fonctionnement dans lequel il sera pratique de modifier le code de l'application et de recevoir instantanément les commentaires de l'application en cours d'exécution pour le débogage.
Nouvel algorithme de nettoyage (NOUVEAU)
- Version: v1.1
- Dates : avril
Dans la version actuelle de werf v1.1 dans la procédure cleanup Il n'existe aucune disposition permettant de nettoyer les images pour le système de balisage basé sur le contenu : ces images s'accumuleront.
De plus, la version actuelle de werf (v1.0 et v1.1) utilise différentes politiques de nettoyage pour les images publiées sous des schémas de balisage : branche Git, balise Git ou commit Git.
Un nouvel algorithme de nettoyage des images basé sur l'historique des commits dans Git, unifié pour tous les schémas de balisage, a été inventé :
- Ne conservez pas plus de N1 images associées aux N2 commits les plus récents pour chaque git HEAD (branches et balises).
- Ne stockez pas plus de N1 images d’étape associées aux N2 commits les plus récents pour chaque git HEAD (branches et balises).
- Stockez toutes les images utilisées dans toutes les ressources du cluster Kubernetes (tous les contextes Kube du fichier de configuration et des espaces de noms sont analysés ; vous pouvez limiter ce comportement avec des options spéciales).
- Stockez toutes les images utilisées dans les manifestes de configuration des ressources enregistrés dans les versions Helm.
- Une image peut être supprimée si elle n'est associée à aucun HEAD de git (par exemple, parce que le HEAD correspondant lui-même a été supprimé) et n'est utilisée dans aucun manifeste du cluster Kubernetes et dans les versions Helm.
Création d'images parallèles (↓)
- Version: v1.1
- Dates : janvier-février avril*
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 sortie pratique et informative.
* Remarque : la date limite a été décalée en raison de la priorité accrue accordée à la mise en œuvre de l'assemblage distribué, ce qui ajoutera davantage de capacités de mise à l'échelle horizontale, ainsi que de 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 projet.
Transition vers Helm 3 (↓)
- Version: v1.2
- Dates : février-mars mai*
Inclut la migration vers une nouvelle base de code et un moyen éprouvé et pratique de migrer les installations existantes.
* Remarque : le passage à Helm 3 n'ajoutera pas de fonctionnalités significatives à werf, car toutes les fonctionnalités clés de Helm 3 (fusion à 3 voies et pas de barre franche) sont déjà implémentées dans werf. De plus, werf a en plus de ceux indiqués. Cependant, cette transition reste dans nos plans et sera mise en œuvre.
Jsonnet pour décrire la configuration de Kubernetes (↓)
- Version: v1.2
- Dates : janvier-février avril-mai
Werf prendra en charge les descriptions de configuration pour Kubernetes au format Jsonnet. Dans le même temps, werf restera compatible avec Helm et il y aura un choix de format de description.
La raison en est que les modèles Go, selon de nombreuses personnes, ont une barrière d'entrée élevée, et la compréhensibilité du code de ces modèles en souffre également.
La possibilité d'introduire d'autres systèmes de description de configuration Kubernetes (par exemple Kustomize) est également envisagée.
Travailler dans Kubernetes (↓)
- Version: v1.2
- Dates : avril-mai mai-juin
Objectif : garantir que les images sont créées et que l'application est livrée à l'aide d'exécuteurs dans Kubernetes. Ceux. De nouvelles images peuvent être créées, publiées, nettoyées et déployées directement à partir des pods Kubernetes.
Pour implémenter cette fonctionnalité, vous devez d'abord être capable de créer des images distribuées (voir point ci-dessus).
Cela nécessite également la prise en charge du mode de fonctionnement du constructeur sans serveur Docker (c'est-à-dire une construction de type Kaniko ou une construction dans l'espace utilisateur).
Werf prendra en charge la construction sur Kubernetes non seulement avec Dockerfile, mais également avec son constructeur Stapel avec reconstructions incrémentielles et Ansible.
Un pas vers un développement ouvert
Nous aimons notre communauté (, ) et nous voulons que de plus en plus de personnes contribuent à améliorer Werf, comprennent la direction dans laquelle nous avançons et participent au développement.
Tout récemment, il a été décidé de passer à afin de révéler le processus de travail de notre équipe. Vous pouvez désormais voir les plans immédiats, ainsi que les travaux en cours dans les domaines suivants :
- ;
- ;
- ;
- .
Beaucoup de travail a été fait avec les problèmes suivants :
- Suppression des éléments non pertinents.
- Ceux qui existent sont ramenés à un format unique, avec un nombre suffisant de détails et de détails.
- De nouveaux problèmes avec des idées et des suggestions ont été ajoutés.
Comment activer la version v1.1
La version est actuellement disponible en (dans les chaînes stable и solide comme le roc des rejets apparaîtront au fur et à mesure de la stabilisation, cependant ea lui-même est déjà suffisamment stable pour être utilisé, car je suis passé par les canaux Alpha и bêta). Activé de la manière suivante:
source $(multiwerf use 1.1 ea)
werf COMMAND ...Conclusion
La nouvelle architecture de stockage de scène et les optimisations du constructeur pour les constructeurs Stapel et Dockerfile ouvrent la possibilité d'implémenter des builds 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 ).
Dans cette version, une stratégie de balisage basée sur le contenu de l'image a été ajoutée : balisage basé sur le contenu, qui est devenue la stratégie par défaut. Le journal des commandes principal a également été retravaillé : werf build, werf publish, werf deploy, werf dismiss, werf cleanup.
La prochaine étape importante consiste à ajouter des assemblys distribués. Les builds distribués sont devenus une priorité plus élevée que les builds parallèles depuis la v1.0 car ils ajoutent plus de valeur à werf : mise à l'échelle verticale des builders et prise en charge des builders éphémères dans divers systèmes CI/CD, ainsi que la possibilité de prendre en charge officiellement les actions GitHub. . Les délais de mise en œuvre des assemblées parallèles ont donc été décalés. Cependant, nous travaillons à mettre en œuvre les deux possibilités le plus rapidement possible.
Suivez l'actualité ! Et n'oubliez pas de nous rendre visite à pour créer un problème, en trouver un existant et ajouter un plus, créer un PR ou simplement regarder l'évolution du projet.
PS
A lire aussi sur notre blog :
- «»
- «";
- Une série de notes sur les innovations dans le domaine du werf :
- «";
- «";
- «";
- «».
Source: habr.com