Présentation de werf 1.0 stable: qu'est-ce que GitOps a à voir avec lui, son statut et ses plans

werf est un utilitaire CLI open source GitOps pour la création et la livraison d'applications à Kubernetes. werf prend en charge l'assemblage d'images d'application à l'aide de Dockerfile ou de son propre collecteur intégré (basé sur la syntaxe YAML, avec le support Ansible et la reconstruction incrémentielle basée sur Git). Le format de configuration compatible avec Helm est utilisé pour fournir l'application. Le code d'application, la configuration des images collectées et la configuration de déploiement de l'application sont stockés dans un référentiel Git.

La version stable tant attendue 1.0 est la version de base de l'utilitaire complétée par des fonctions (le numéro de version exact de la première version stable est 1.0.6) . Dans la version de base, werf prend en charge le cycle complet de livraison et de maintenance des applications. Cela inclut l'assemblage d'images d'application, le déploiement sur Kubernetes et le nettoyage des images inutilisées.

Il est important que dans la version 1.0, toutes les opérations sur un projet ( build , deploy , cleanup ) doivent être effectuées à partir d'un seul hôte. Cela signifie qu'un travailleur fixe doit être utilisé dans le système CI. Dans le même temps, il n'y a pas de restrictions sur le parallélisme des tâches: werf résout complètement ce problème. Vous pouvez également répartir différents projets entre différents travailleurs.

Dans cet article dédié à la sortie, nous allons voir de plus près ce que cette version fournit et ne fournit pas, ainsi que nos plans pour les futures versions. Mais nous commencerons par comprendre la compréhension du terme «GitOps» et le rôle de werf dans les processus d'intégration continue et de livraison d'applications (CI / CD).

Pourquoi Werf est GitOps

Alors, que voulons-nous dire par GitOps et quels sont les domaines couverts?

Le terme «GitOps» a été inventé par Weaveworks il y a environ 2,5 ans, et nous avons récemment traduit un article de ses auteurs qui révèle l'essence de ce nouveau phénomène pour le blog. À notre avis, l'idée principale et la signification principale de GitOps est que Git est une «source unique de vérité» . Magasins Git:

• code d'application
• toutes les dépendances;
• des informations sur la collecte des conteneurs;
• des informations sur la façon de déployer sur Kubernetes;
• et autres

Et puis il y a «quelque chose» qui fait que la réalité change en fonction des changements de Git . Cette approche peut être mise en œuvre non seulement en installant un opérateur dans Kubernetes qui surveille Git, mais également en utilisant un utilitaire de console qui peut être appelé à partir de n'importe quel système CI. De plus, de notre point de vue, l'approche avec l'utilitaire CLI n'impose pas de restrictions inutiles: nous pouvons faire du CI avec n'importe quel outil et avec un certain nombre de nuances, en appelant un utilitaire CLI qui synchronise la «réalité» (c'est-à-dire Kubernetes) avec l'état de Git .

werf fournit une interface CLI de haut niveau avec des commandes de base pour la création et la publication d'images, la livraison d'applications et le nettoyage d'images: werf build-and-publish , werf deploy , werf dismiss , werf cleanup . On suppose que ces commandes très basiques sont intégrées dans un système CI particulier et fournissent la synchronisation nécessaire avec la réalité. De plus, werf fournit également une interface CLI de bas niveau pour gérer divers sous-systèmes - voir les commandes de gestion de bas niveau dans la documentation.

Peu importe que le CI / CD intégré fonctionne selon le modèle push ou pull (en savoir plus ici ) , car werf peut être intégré à n'importe quel modèle . Dans le même temps, werf ferme des problèmes tels que le travail avec des utilitaires de bas niveau séparés tels que git , docker et kubernetes api-server, étant la «partie manquante» pour la configuration d'une application CI / CD unifiée.

Qu'est-ce que werf 1.0 stable

1. Assemblage, publication et nettoyage des images

Si votre application nécessite la création d'images Docker, alors en utilisant werf 1.0, vous pouvez:

• décrire les règles d'assemblage des images (vous pouvez en avoir plusieurs) dans une seule configuration werf.yaml ;
• Collectez des images et publiez-les dans le Docker Registry
• nettoyer périodiquement le Docker Registry pour les politiques personnalisées.

werf prend en charge deux façons de décrire l'assembly : connexion de werf.yaml Dockerfiles existants et instructions pour le collecteur Stapel . Construire avec Stapel a ses avantages: une reconstruction incrémentielle plus rapide lors du changement de code d'application dans Git, l'utilisation de la syntaxe Ansible pour l'assemblage, etc. Vous pouvez en savoir plus sur ce collecteur et cette syntaxe dans la documentation , et un exemple de son utilisation est présenté dans le manuel .

Différents schémas de balisage / versioning des images collectées sont disponibles en référence aux validations, branches et balises Git.

L'assemblage d'images est une étape facultative du déploiement d'applications et peut être ignoré en l'absence de vos propres images assemblées.

2. Stage de stockage sur un seul hôte

werf introduit le concept de stockage des étapes. Les principales commandes werf utilisent le stockage par étapes comme suit:

• Enregistrer les résultats de l'assemblage - images Docker dans le magasin de scène
• utiliser les images du magasin de scène comme cache pour la reconstruction et l'assemblage de nouvelles images;
• utiliser le référentiel pour obtenir des informations sur les images collectées pour leur utilisation ultérieure (par exemple, lors de la livraison d'une application à Kubernetes).

Lors du déploiement d'une seule application, un stockage en une seule étape doit être utilisé pour toutes les équipes (assemblage, publication, nettoyage d'image, déploiement d'application).

Dans la version 1.0, seul le stockage hôte local peut agir comme un stockage d'étape (le paramètre correspondant pour les commandes est: --stages-storage=:local ). Lors de l'utilisation :local étapes :local sont stockées sur disque. La conséquence de ceci: werf 1.0 ne peut être utilisé que sur un seul hôte pour organiser le déploiement d'une seule application . Cet hôte doit enregistrer les données entre les lancements de commandes pour que werf fonctionne correctement.

Dans la version 1.0, il n'y a pas de prise en charge pour le stockage des étapes dans le stockage externe, avec lequel vous pouvez organiser un assembly distribué. Cependant, une telle fonction apparaîtra dans les futures versions de werf (voir ci-dessous pour plus de détails) .

3. Déployez l'application et vérifiez la disponibilité

Pour déployer l'application, l'utilisateur décrit le graphique dans un format compatible avec Helm: un ensemble de manifestes Kubernetes et de paramètres de modèle.

werf lance l'application dans Kubernetes et garantit qu'il démarre et fonctionne avant de terminer le processus de déploiement de l'application. Cela inclut la sortie des journaux des composants et la réponse instantanée aux erreurs de déploiement en cas de problème - la commande de déploiement tombera avec un code différent de zéro. Ainsi, lorsque vous utilisez werf rollout dans CI / CD, nous obtenons des commentaires adéquats du logiciel : si l'application a été téléchargée ou non, et suffisamment d'informations pour déboguer et résoudre les problèmes (sans avoir à exécuter d'autres utilitaires pour trouver des problèmes comme kubectl ).

werf est entièrement compatible avec les installations existantes de Helm 2, mais werf présente plusieurs avantages. Par exemple, en tant que mécanisme de mise à jour des ressources, Kubernetes utilise des correctifs de fusion à 3 voies et il est également possible de recevoir des commentaires lorsque l'application est livrée au cluster. Une liste complète des différences est décrite sur cette page .

4. La relation des images collectées avec le processus de livraison de l'application

werf intègre les images collectées dans un seul système, le processus de balisage et de versioning avec le processus de livraison de l'application à Kubernetes. Les images collectées par werf peuvent être utilisées dans les modèles de description des ressources Kubernetes.

C'est grâce à ces fonctions que nous pouvons dire que werf fournit une interface de niveau supérieur à Helm, Docker et à d'autres constructeurs et utilitaires pour un déploiement séparé. Cette interface vous permet d'intégrer simplement werf dans n'importe quel système CI / CD existant et de ne pas résoudre les problèmes de combinaison de tous les composants utilisés - il se charge de cette tâche.

5. Intégration avec les systèmes CI / CD existants

Dans la version 1.0, l'intégration automatique n'est disponible qu'avec le système GitLab CI . Pour ce faire, la commande werf ci-env est fournie. Il reçoit les informations nécessaires du système CI / CD et configure automatiquement werf pour fonctionner correctement dans l'environnement CI.

Vous pouvez en savoir plus sur le fonctionnement de l'intégration avec n'importe quel système CI / CD dans les manuels ( revue , spécificités de GitLab CI , intégration avec d'autres systèmes ).

6. Développement multiplateforme pour Linux, Windows et macOS

werf 1.0 est un fichier binaire lié statiquement qui fonctionne indépendamment avec les versions Docker et Helm. Dépendances externes sur le système hôte:

• Démon Docker local
• utilitaire git.

werf peut fonctionner sur n'importe quel système d'exploitation et environnement GNU / Linux, Windows ou macOS. De plus, le résultat de l'assemblage sera le même quel que soit le système utilisé: même signature des étapes de cache, même remplissage des étapes, quel que soit le système où cette étape a été collectée. Des modifications dans la configuration pour travailler dans différents systèmes ne sont pas non plus nécessaires.

Ainsi, werf 1.0 fournit des outils multiplateformes pour créer et fournir des applications à Kubernetes.

Il convient également de noter ici que werf collecte des images Docker standard pour travailler dans un environnement Linux, mais les conteneurs Windows ne sont pas pris en charge dans la version 1.0.

7. Couvrir la fonctionnalité avec des tests

Actuellement, 60% du code werf est couvert par des tests d'intégration e2e et des tests unitaires.

werf est testé sur tous les systèmes d'exploitation pris en charge (Linux, Windows et macOS) à l'aide des actions GitHub pour organiser leur lancement. Certains détails des tests sont également disponibles sur Code Climate .

8. Versioning werf

À l'heure actuelle, par la sortie de la version 1.0, environ 700 versions ont été effectuées dans le projet.

werf utilise un système de libération avancé avec des canaux de stabilité: alpha , bêta , ea (accès anticipé) , stable et solide comme le roc . Cette publication est programmée pour coïncider avec la sortie de la première version 1.0 sur le canal stable . Les modifications instables de la version passent d'abord par une chaîne de canaux et finissent finalement par être solides . Les versions sont souvent effectuées (parfois plusieurs par jour) et les modifications sont livrées en continu en «petites portions».

Les canaux de stabilité et de nombreuses versions fréquentes vous permettent d'obtenir un retour d'information continu sur les nouveaux changements, la possibilité de les annuler rapidement et d'assurer généralement une grande stabilité du logiciel et en même temps une vitesse acceptable de son développement.

Le point important est que lors du basculement entre les versions 1.0-> 1.1, 1.1-> 1.2, des modifications de werf sont possibles qui nécessitent une intervention manuelle de l'utilisateur (cela peut être un script de migration ou simplement des instructions pour une exécution manuelle décrites dans la version). La mise à jour des versions à l'intérieur de 1.0 (1.0.1, 1.0.2, ... 1.0.6-alpha.1, 1.0.6-beta.2, etc.) garantit que de telles modifications manuelles ne sont pas nécessaires.

Vous pouvez en savoir plus sur la promesse de compatibilité descendante ici .

Plans supplémentaires

Voici à quoi ressemblent les principaux domaines de travail des futures versions et les termes approximatifs de leur implémentation:

1. Développement local et déploiement d'applications avec werf

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.

Version 1.1, janvier-février 2020

2. Balisage basé sur le contenu

Marquage des images lors de leur publication, uniquement sur la base du contenu de cette image. Contrairement aux modes avec liaison aux validations Git, ce mode supprimera complètement les reconstructions inutiles. Git-commit-id n'est pas un identifiant universel pour le contenu de l'arbre de travail (bien qu'il en dépende).

Dans le cas où le code d'application n'a pas changé, mais qu'une nouvelle validation a été effectuée, le mode de marquage actuel pour les validations Git créera une image avec un nouveau nom lors de sa publication. Cela entraînera également une restauration des ressources utilisant cette image dans Kubernetes. En même temps, le contenu de l'image elle-même n'a pas changé.

Pour résoudre ces problèmes, werf introduira un nouveau type de balisage basé sur les calculs des sommes de contrôle du contenu de l'application - le balisage basé sur le contenu .

Version 1.1, février-mars 2020

3. La transition vers Helm 3

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

Version 1.1, février-mars 2020

4. Assemblage parallèle d'images

À l'heure actuelle, werf 1.0 collecte séquentiellement toutes les étapes des images et des artefacts déclarés dans werf.yaml . Nécessite la possibilité de paralléliser le processus d'assemblage de la scène.

Version: 1.1, janvier-février 2020

5. Assemblage distribué d'images

Pour le moment, werf 1.0 ne peut être utilisé que sur un seul hôte dédié (voir le point ci-dessus sur le stockage de la scène sur un seul hôte) .

Pour ouvrir les possibilités d'un assemblage distribué, lorsque l'assembly est lancé sur plusieurs hôtes 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 également 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.

Version 1.2: mars-avril 2020

6. Jsonnet pour décrire la configuration de Kubernetes

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 le fait que les modèles de langage Go, selon de nombreuses personnes, ont un seuil d'entrée élevé, et l'intelligibilité du code de ces modèles souffre également.

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

Version 1.1: janvier-février 2020

7. Travailler à l'intérieur de Kubernetes

Objectif: Assurer l'assemblage des images et la livraison des applications à l'aide de runners dans Kubernetes. C'est-à-dire 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 démon Docker (c'est-à-dire une génération de type Kaniko ou une génération d'espace utilisateur ).

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

Version 1.2: avril-mai 2020

8. Autre

Il est également prévu:

• Mise à niveau de la version d'Ansible et possibilité d'utiliser différentes versions d'Ansible;
• soutien aux rôles ansibles;
• prise en charge des étapes d'assemblage arbitraires dans Stapel (actuellement, werf prend en charge un ensemble statique d'étapes: beforeInstall , install , beforeSetup , setup );
• amélioration de la syntaxe werf.yaml , passage à configVersion: 2 (associé, entre autres, aux deux points précédents), prise en charge de la spécification OpenAPI;
• Prise en charge de Git LFS dans Stapel pour le stockage de fichiers volumineux dans Git;
• amélioration des mécanismes de nettoyage des images (les défauts non critiques dans la version actuelle sont associés aux images non déclarées dans la configuration werf.yaml dans la branche principale principale - ces images seront supprimées par un nettoyage périodique);
• un travail plus correct avec l'espace de noms Kubernetes partagé, lorsque plusieurs applications sont déployées dans un même espace de noms;
• restauration automatique de l'application vers la dernière version de travail en cas d'échec du déploiement.

Total

Je serai bref en résumant. Nous sommes:

• longtemps marché jusqu'à l'avènement de la version 1.0;
• a pris en compte beaucoup d'expérience réelle;
• Nous présentons pour utilisation un utilitaire éprouvé avec des fonctionnalités stables, vérifié par des dizaines de milliers de déploiements.

La sortie de la version 1.0 marque le début d'une nouvelle phase de développement de werf, au sein de laquelle de nouvelles fonctionnalités fondamentales seront ajoutées. Suivez l'actualité! Et rejoignez également le canal tg werf_ru , dans la vie duquel participent à la fois les développeurs werf directs, ainsi que nos ingénieurs et utilisateurs de l'utilitaire en dehors de la société Flant.

PS

Lisez aussi dans notre blog:

• « Werf a de la documentation en russe »;
• Une série de notes sur les innovations dans werf:
  
  • « Fusion à 3 voies dans werf: déploiement dans Kubernetes avec Helm« sous stéroïdes » »;
  • « Utilisation de werf pour déployer des graphiques Helm complexes »;
  • « Prise en charge de monorepo et multirepo dans werf et qu'est-ce que le Docker Registry a à voir avec cela »;
  • « Vous pouvez maintenant assembler des images Docker en werf en utilisant le Dockerfile habituel »;
• « Werf est notre outil CI / CD à Kubernetes (revue et rapport vidéo) »;
• « Qu'est-ce que GitOps? "