L'article est consacré au développement de graphiques Helm pour Kubernetes à l'aide de solutions prêtes à l'emploi à partir de référentiels de graphiques. Avec cette approche, l'utilisateur applique des recettes communautaires ou les siennes, assurant la mise à jour en temps opportun des composants standard de tous ses projets et la commodité de maintenir les solutions en général.
Une telle fonctionnalité pratique est désormais intégrée à notre utilitaire werf GitOps, qui devrait simplifier l'ensemble du processus d'exploitation de l'infrastructure pour les applications assemblées et déployées sur Kubernetes.
Heaume intégré
Peut-être que le principal succès de Helm - le "gestionnaire de paquets pour Kubernetes" - n'est pas tant lié à ses fonctionnalités qu'au
dépôt de cartes officiel
et au support des dépôts en général. Les recettes et les paramètres des graphiques sont accompagnés d'une énorme communauté. Les spécialistes prennent en charge les solutions à jour requises par les utilisateurs finaux. Chaque graphique du référentiel officiel est standardisé et bien documenté.
Dans des cas triviaux, l'utilisateur n'a même pas besoin de créer un graphique pour déployer l'application: il trouve juste une solution toute faite, lit la documentation, prépare les paramètres et utilise le graphique officiel.
Depuis longtemps, nous utilisons activement Helm inside werf pour déployer l'infrastructure applicative et nous allons maintenant plus loin.
Depuis la version
v1.0.4-alpha.10 , des
commandes pour travailler avec les dépendances et les référentiels de graphiques ont été ajoutées à werf pour abandonner complètement le client Helm.
Les commandes principales pour cela:
werf helm repo
add Add a chart repository fetch Download a chart from a repository and (optionally) unpack it in local directory init Init default chart repositories configuration list List chart repositories remove Remove a chart repository search Search for a keyword in charts update Update information of available charts locally from chart repositories
werf helm dependency
build Rebuild the charts/ directory based on the requirements.lock file list List the dependencies update Update charts/ based on the contents of requirements.yaml
De plus, la prise en charge de la
référence de graphique a été ajoutée à la
werf helm deploy-chart .
Et voici à quoi ressemble toute cette magie en action - plus précisément, nous montrons ici une comparaison du déploiement du même graphique dans werf (gauche) et dans Helm (droite):
Plus de pratique
Revenons à la commodité d'utiliser des solutions prêtes à l'emploi pour déployer des applications entières - un
exemple courant avec WordPress . DĂ©ployer son graphique Helm vers le cluster Kubernetes Ă l'aide de werf pourrait ressembler Ă ceci:
$ cat << EOF > values.yaml wordpressBlogName: flant wordpressUsername: admin wordpressPassword: password mariadb: mariadbRootPassword: password EOF $ werf helm deploy-chart --values values.yaml stable/wordpress my-web-app
→
Démonstration d'asciicinème .
Étant donné que les référentiels contiennent de
nombreuses solutions , vous pouvez
créer vos propres applications à partir d'eux sous forme de cubes, où les cubes seront les différents graphiques Helm dont dépend tout le système. Très probablement, il vous suffit de configurer correctement les composants selon vos besoins.
Par exemple, une application Web nécessite une file d'attente, un cache et un stockage de données. Comment déployer ces composants via werf?
Pour commencer - accélérons la recherche de tout ce dont vous avez besoin en utilisant la CLI:
$ werf helm repo search queue NAME CHART VERSION APP VERSION DESCRIPTION stable/rabbitmq 6.4.1 3.7.17 Open source message broker software that implements the A... stable/rabbitmq-ha 1.31.0 3.7.15 Highly available RabbitMQ cluster, the open source messag...
Par analogie, nous trouverons les composants restants pour tous les référentiels de graphiques enregistrés (la liste des référentiels utilisés peut être vue en exécutant la
werf helm repo list ).
Une fois que tout est trouvé, il ne reste plus qu'à les ajouter au graphique. Il existe plusieurs façons de procéder: ajoutez des diagrammes de composants au répertoire des diagrammes ou créez un fichier
requirements.yaml et décrivez les dépendances, puis interagissez avec eux à l'aide des
werf helm dependency build|list|update spéciales
werf helm dependency build|list|update .
Illustration du deuxième chemin:
$ cat << EOF > .helm/requirements.yaml dependencies: - name: mysql version: 0.3.4 repository: "@stable" - name: redis version: 1.1.11 repository: "@stable" - name: rabbitmq version: 0.6.16 repository: "@stable" EOF $ werf helm dependency build $ werf deploy --env test
→
Démonstration d'asciicinème .
Pendant le processus de déploiement, werf
créera toutes les dépendances et les suivra avec le reste des ressources - aucune action supplémentaire n'est requise.
Par conséquent, compte tenu de l'expertise de la communauté expérimentée, vous gagnez beaucoup de temps sur le développement et la maintenance des cartes. Cependant, personne ne vous limite à utiliser des graphiques publics: après tout, vous pouvez déployer vos graphiques avec un succès égal, dont les configurations sont préparées en tenant compte des spécificités requises.
La documentation sur les commandes de référentiel et de dépendance dans werf est présentée
ici . Vous pouvez également être intéressé par la lecture de la documentation pour plus de détails sur le
déploiement vers werf et les
principales différences avec Helm .
Conclusion
L'absence de fonctionnalités essentielles pour nous dans les solutions Open Source existantes nous oblige à créer les capacités, les liaisons et l'intégration correspondantes. Le projet werf a été créé et soutenu, tout d'abord, pour résoudre les tâches quotidiennes de nos ingénieurs DevOps.
A titre d'exemple, nous travaillons depuis longtemps (deuxième année!) Afin que
notre proposition de suivi des ressources dans Helm soit acceptée comme mode alternatif dans la base de code principale du projet (en amont). La communauté a accepté et soutenu l'idée, beaucoup ont besoin de cette opportunité. Cependant, des progrès dans cette direction ont commencé dans
Helm 3 et seulement maintenant ...
Jusqu'à présent, la mise en œuvre de cette idée dans Helm a été pratiquement bloquée par les développeurs. Cependant, pendant ce temps, nous avons développé les fonctions correspondantes pour le suivi des ressources dans une bibliothèque Open Source distincte -
kubedog - et nous l'utilisons déjà dans werf. Et à en juger par l'activité sur GitHub, la bibliothèque a trouvé un intérêt parmi d'autres utilisateurs de Kubernetes / Helm, ce qui est très agréable.
Vous pouvez soutenir notre idée (et implémentation) en plaçant une étoile sur le projet kubedog sur GitHub et / ou un coup de pouce dans le
numéro d'origine dans Helm. Je vous remercie!
PS
Lisez aussi dans notre blog: