Je viens de tomber sur ça aussi. Je souhaite normalement que la balise d'image soit spécifiée au moment de l'empaquetage du graphique, mais pour le débogage, l'application voulait effectuer une installation avec une balise différente.

Les problèmes deviennent obsolètes après 90 jours d'inactivité.
Marquez le problème comme récent avec /remove-lifecycle stale .
Les problèmes périmés pourrissent après 30 jours supplémentaires d'inactivité et finissent par se fermer.

Si ce problème peut être résolu en toute sécurité maintenant, veuillez le faire avec /close .

Envoyez vos commentaires à sig-testing, kubernetes/test-infra et/ou fejta .
/cycle de vie périmé

Remonter cela comme cela a été soulevé dans https://github.com/kubernetes/charts/pull/5919

Recopier des parties de mon récent commentaire :

Nous avons spécifiquement choisi de garder la version mineure de notre graphique alignée sur la version mineure de l'application (bien que les numéros de version des correctifs puissent s'éloigner et s'éloignent effectivement).

C'est parce que nous pouvons ajouter un nouveau drapeau à une nouvelle version de cert-manager, et en ajoutant sa prise en charge dans la charte Helm, cela romprait la compatibilité avec les anciennes versions de cert-manager, car elles ne prennent pas en charge le drapeau. Il s'agit d'une question assez fondamentale autour de la gestion des versions des chartes Helm dans l'OMI générale, et pour laquelle nous n'avons pas une bonne histoire.

Je sais qu'il n'est pas recommandé d'essayer d'aligner appVersion avec la version du graphique, mais de cette façon, un utilisateur sait qu'il peut utiliser Helm chart version 0.3.x avec n'importe quel cert-manager 0.3.x et chart version 0.4.x avec cert -gestionnaire 0.4.x. La compatibilité est définie dans la version mineure.

/supprimer le cycle de vie périmé

J'aimerais revenir sur ce sujet pour en discuter.

Dans l'ensemble, nous n'avons pas vu grand-chose en faveur de la gestion des versions des graphiques pour nos applications internes lorsque tout ce qui change est la balise d'image utilisée par certains composants. Lors de la mise à niveau d'une version, le champ appVersion semble être le bon endroit pour ces informations.

Copie sur ma proposition originale référencée ci-dessus :

Notre flux de travail actuel pour le déploiement de graphiques helm implique des tâches ansibles qui appellent la commande CLI helm upgrade et il serait bien de pouvoir passer un indicateur pour définir l'appVersion lors de la révision d'une version pour la même version du graphique.

Cela peut être un peu étrange sur le plan conceptuel car une appVersion est associée à un graphique plutôt qu'à une version, mais dans notre cas, nous ne faisons que mettre à jour la balise d'image utilisée pour certains conteneurs et notre flux de travail n'a pas intégré la version du graphique et/ou les référentiels de graphiques encore. Cela peut changer à l'avenir, mais pour l'instant, je ne vois aucun problème à ajouter un indicateur pour --app-version lors de l'installation et de la mise à niveau car le champ est purement informatif.

lors du développement de nos propres applications internes, l'application elle-même change beaucoup plus que le graphique qui la déploie. En règle générale, notre commande de déploiement continu est un helm upgrade avec rien de plus que --set imageTag=<new_version> (évidemment, utilisé ailleurs dans le tableau pour définir la version du conteneur) Si nous remplaçons cela par --app-version cela donnerait nous un autre point visuel dans helm ls pour voir quelles versions de code sont déployées avec la version du graphique qui est déployée.

Pour rendre cela plus visible, j'ai standardisé la définition d'une balise de métadonnées de imageTag qui est définie sur l'imageTag transmise lors de l'installation/de la mise à niveau. Cela me permet d'utiliser le tableau de bord K8s ou de créer facilement des tableaux de bord Graphana avec imageTag affiché, mais m'oblige à quitter la ligne de commande et à cliquer avec la souris.

Des nouvelles à ce propos?

Merci

Une mise à jour pour ceci. Il semble que les relations publiques de @Eraac fassent ce qui est demandé. Comme @TD-4242 mentionné, nous exécutons également helm upgrade --set imageTag=<imagetag> , mais cela ne met pas à jour la VERSION APP répertoriée dans la sortie de helm ls . Pouvoir --set app-version ou --set version nous permettra d'exécuter helm upgrade telle sorte que helm ls affiche correctement la version qui est déployée.

Les mises à jour?

Aaaaa n'importe quand bientôt ce serait beau !

ça sera très utile

J'adorerais également la possibilité de définir la version de l'application au moment de l'installation, car nous utilisons des graphiques communs pour déployer des applications

+1

+1

ce serait très utile

Demander la même chose

Merci de stopper le spam avec le +1. Il y a déjà un PR (https://github.com/helm/helm/pull/4961) et les gens discutent de la proposition. La dernière réponse remonte à 2 jours.

Salut @filipre

Il y a déjà un PR (#4961) et les gens discutent de la proposition.

Selon ce PR, cela a été déplacé ici :
https://github.com/helm/helm/pull/5492
Il s'agit du dernier PR au n° 4961 et on dirait que si nous attendons la fusion d'un avis...

@filipre Pourriez-vous s'il vous plaît dire : que se passe-t-il avec le PR ? On dirait que PR n'a pas bougé la moitié du mois

Ce serait très utile. J'ai rencontré quelque chose où je dois épingler la version 0.6.0 d'une application, et la version du graphique n'a aucun rapport avec la version de l'application.

Je suis d'accord, je pense aussi que ce serait très utile. Les mises à jour?

Voir https://github.com/helm/helm/pull/5492#issuecomment -509662190.

Je viens de frapper ce problème maintenant lorsque j'ai réalisé que ce serait un problème lors de la rédaction d'un graphique Helm que nous prévoyons de réutiliser pour de nombreuses applications. Compte tenu du manque de progrès pour résoudre ce problème de manière simple (c'est-à-dire avec le drapeau pour définir la version de l'application lors de l'installation), j'ai proposé une alternative qui devrait fonctionner pour le moment. C'est vraiment très simple - faites simplement un helm fetch abord avec l'option untar, puis helm package avec le drapeau --app-version qui existe, puis installez ce graphique local.

Ce n'est pas idéal, mais le résultat final dans helm list est correct, et c'est très simple de le faire sur un serveur CI. J'adorerais que --app-version soit disponible sur helm install et helm upgrade .

Le résumé de la discussion dans #5492 était qu'une commande qui enveloppe la logique de helm package et helm install résoudrait le cas d'utilisation initialement décrit dans ce numéro.

En d'autres termes, vous pouvez contourner ce problème en exécutant ce qui suit :

$ helm package myapp --app-version 1.0.0
$ helm install myapp-1.0.0.tgz

(Commentaire émouvant des relations publiques récemment fermées ici - afin que cela ne se termine pas dans le Nirvana)

Voici mes 2 cents à ce sujet :
En supposant que nous ayons un helm chart version X déployant un service avec appVersion Y .

Le graphique helm est utilisé pour décrire l'infrastructure à l'intérieur de Kubernetes sur chart version X qui est utilisé pour héberger un service de appVersion Y .

Au cours du développement initial, X et Y changeront régulièrement. Cependant, à un moment donné, X sera plus ou moins stable et Y continuera à changer (à moins que Y ait de nouvelles exigences en matière d'infrastructure, ce qui arrive probablement beaucoup moins souvent dans le cycle de développement de Y ).

Avec l'approche proposée dans ce ticket, on pourrait prendre un package helm chart stable sur la version X pour déployer une applicationVersion Y , Y+1 , Y+N , etc.

Cependant, ne pas autoriser ce drapeau à être remplacé lors de l'installation ou de la mise à niveau de helm et à la place uniquement dans le package, par exemple, lierait efficacement à la fois X et Y m'obligeant à toujours créer un nouveau X+1 pour Y+1 . Cela me semble inutile et entraînerait une tonne de packages helm qui n'ont effectivement pas changé à part le fait qu'ils font référence à un nouveau appVersion . De mon point de vue, une version d'une application et une version de l'infrastructure hébergeant cette application ont une relation, mais devraient ou pourraient toujours être versionnées indépendamment. La manière dont cela est fait doit être laissée aux équipes de développement respectives.

Résumé:

Cette approche fonctionne certainement, mais elle entraîne également de nombreux packages Helm inutiles où seul le AppVersion a changé :
$ helm package myapp --app-version 1.0.0 $ helm install myapp-1.0.0.tgz

Oui, mais je suppose que ce n'est pas vraiment un problème si vous adoptez l'approche que j'ai mentionnée ci-dessus. Poussez votre graphique vers un référentiel de graphique sans jeu de version d'application (ou 0.0.0 ou quelque chose), puis lorsque vous souhaitez l'utiliser, utilisez helm fetch , puis emballez-le avec la bonne version d'application, puis utilisez le local .tgz fichier et ne poussez pas ce graphique. De cette façon, votre dépôt de graphique reste propre et vous n'avez que les changements de graphique réels qui y sont représentés.

Oui, cela fonctionnerait. Dans ce cas, on ne pourrait jamais consommer directement l'artefact de déploiement (par exemple en l'installant directement à partir du référentiel Helm), mais il faut toujours l'envoyer via une étape supplémentaire qui mute l'artefact.

Là où il a été soutenu que le Charts.yaml devrait être immuable, je soutiens que l'artefact de déploiement devrait l'être.

_Résumé mes réflexions de https://github.com/helm/helm/pull/5492#issuecomment -520029902_

Il y a un problème dans la façon dont la communauté interprète le package, le graphique et les versions. @BenjaminSchiborr , j'espère que cela aura du sens pour vous.

Chart - est un code source de votre version. Comme un code source de votre application. Se compose de modèles, de fichiers de code.
Package - est une version de votre version, artefact. Comme un binaire, construit à partir de votre code source. Se compose de versions de production fixes : à la fois la version graphique et la version de l'application.
Release - est une version, déployée avec une configuration spécifiée.

Il n'y a aucun moyen de créer une version à partir de Chart . Cela ne fonctionne tout simplement pas de cette façon!

Avant de déployer votre application sur la scène, vous devez disposer d'un graphique. Ensuite, vous devez emballer votre application avec un graphique, en corrigeant les deux versions, en utilisant helm package . Il en résultera un package, déployable sur n'importe quelle scène. Ensuite, vous installez ce package sur, par exemple, QA stage, en le promouvant sur UA puis sur Production, en utilisant helm install .

C'est ainsi que fonctionne tout logiciel orienté paquet.

La confusion

helm install besoin d'une source, qui doit être installée. La source peut être :

1. Nom du package, disponible dans le registre
2. Chemin du fichier du package, si le package est déjà téléchargé ou créé
3. URL du package, si elle est disponible via HTTP
4. Chemin du répertoire du graphique

La 4ème approche ressemble à un mouton noir ici, vous ne trouvez pas ? C'est pourquoi ppl confond Package et Chart. Et c'est la racine des problèmes.

Raisonnement

Il existe deux types d'applications dans la nature :

Grand/moyen - c'est là que nous avons le temps, l'argent et les ressources pour configurer des flux détaillés et granulaires pour une meilleure introspection et des garanties de qualité.
Petit - un microservice, un projet animal de compagnie, un PoC, des projets à faible coût, des projets sans connaissances DevOps ou même des tests de processus de développement à la barre.

Avec de petits projets, vous n'avez pas le temps ni besoin de créer ou de gérer des emballages. Vous voulez écrire des fichiers modèles et les déployer avec une seule commande !

C'est pourquoi helm install permet une telle utilisation, comme helm package & helm install . Mais il ne fournit pas toutes les fonctionnalités helm package , telles que --app-version .

helm install peut être helm package & helm install , mais cela ferait helm install un gâchis, un enfer pour le support, les tests et les bonnes pratiques.

Proposition 1

Simplifiez helm install . Il devrait permettre uniquement de fournir des packages, pour simplifier la base de code, les tests et le rendre avisé, pour simplifier la compréhension du helm .

Proposition 2 - helm run

Introduire une nouvelle commande : helm run . Une commande, qui devrait juste fonctionner . Idéal pour les petites applications. Ou peut-être même moyen et grand.

Il devrait combiner helm package et helm install , fournissant les capacités des deux commandes, à l'exclusion de celles qui n'ont aucun sens dans un tel cas d'utilisation.

helm package crée un build, comme le fait go build . go run permet de démarrer l'application sans le processus de construction, donc helm run ressemble à un nom solide ici.

Éléments supplémentaires à prendre en compte :

• Devrait-il utiliser upgrade --install place ?
• Devrait-il avoir --atomic activé par défaut ?

@iorlas ,
vos commentaires ont du sens. Cependant, vous supposez qu'il ne peut y avoir qu'un seul package final qui lie par héritage à la fois la version de l'infrastructure et la version du logiciel, alors que je suppose que j'ai un package pour ma version du logiciel et un package pour mon infrastructure et que je veux les lier dans une version (par exemple via une configuration d'état souhaitée qui fait référence à la version du logiciel et à la version de l'infrastructure).

Je ne vois pas pourquoi un processus de développement devrait être forcé dans ce modèle où il pourrait également être laissé aux groupes de développement responsables de décider s'ils souhaitent lier l'infrastructure et la version logicielle au niveau du package de barre ou plus tard. Actuellement, un processus de déploiement doit toujours utiliser de nouveaux packages helm, alors que seule la version du logiciel change. Cela se traduit pour moi par des milliers de packages inutiles dans un référentiel.

Je vais bien s'il y a un avantage à long terme à cela. Je ne le vois tout simplement pas.

@BenjaminSchiborr D'accord, permettez-moi de le décomposer un peu.

Vous pouvez avoir votre Chart(== infrastructure), qui a la version X .
Vous pouvez avoir votre application, version Y .

Comment helm fonctionne actuellement, il relie les versions d'infrastructure et d'application à l'étape helm package . Ensuite, vous devez le lier à l'espace de noms k8s, produisant Release.

Donc la formule est : package(infra + app) + k8s = Release

Ce que vous voulez vraiment, c'est sauter cette étape intermédiaire et lier les 3 composants ensemble sur une seule étape - Release. Comme ceci : infra + app + k8s = Release . Ai-je raison?

C'est ce que helm run fera, en surface. Sous le capot, ce sera pareil.

Mais... j'ai l'impression que vous manquez peut-être l'intérêt de Helm . Bien que n'importe quel outil puisse être utilisé à sa guise, il y a toujours une idée qui influence la communauté, crée une "voie", donc un télescope ne finira pas comme un hummer capable de brasser une bière.

Permettez-moi d'essayer de décrire comment il devrait être utilisé et ce serait génial de le voir de votre point de vue.

Helm lui-même est créé pour faire abstraction de la modélisation et du déploiement de k8s, lier l'application et l'infrastructure, avec ses dépendances : au lieu de réécrire manuellement les modèles, de l'appliquer sur K8s puis de fournir une nouvelle balise d'image, vous n'avez besoin que d'une seule commande - helm upgrade . Comme un package MSI ou deb.

Lorsque vous devez installer une nouvelle version de l'application ou la rétrograder, vous êtes censé utiliser helm pour cela. Au lieu de gérer l'application, vous gérez l'ensemble du package. Ce serait pénible de restaurer la version et l'infrastructure de l'application séparément lorsque quelque chose ne va pas - j'y suis allé, je ne le suggérerai à personne.

C'est donc la bonne chose d'avoir de nombreux packages dans votre registre, puisque le package n'est pas l'infrastructure, le package est l'application, car l'application ne signifie rien dans K8s sans infrastructure.

Si votre problème est que vous avez trop de packages dans le référentiel, je suggérerais d'utiliser des artefacts au lieu de référentiels. Je le fais comme ça dans CI : créez l'application, envoyez-la au registre Docker, créez le package, enregistrez-le en tant qu'artefact pour la publication. CircleCI, Travis, Azure Pipelines prennent en charge la création de fichiers joints à générer en tant qu'artefacts. Pouvez-vous faire la même chose ?

Peut-être que je manque le point de Helm. Peut-être que Helm a raté un point ici. Je pense que ce billet vise à évaluer exactement cela. Et personnellement - aussi pour élargir mon horizon :)

Mais oui, de manière abstraite, ce que vous dites est correct. Je ne veux pas que la version du logiciel soit couplée au package/à la version helm, il s'agit donc essentiellement de infra + app + k8s = Release . Identique au fait que je ne veux pas que les propriétés de ma version logicielle soient liées à mon package/version helm (à part peut-être une valeur par défaut saine que je peux remplacer).

Concernant l'exemple que vous donnez plus bas. Je ne vois pas en quoi cela montre à quel point cette approche est problématique. Vous utiliseriez toujours la barre pour reculer ou avancer. Si l'infrastructure change, vous utilisez une version de graphique de barre modifiée. Si la version du logiciel change, vous utilisez une autre version d'application. Si un paramètre change, vous utilisez un paramètre différent. Il s'agirait toujours d'un (seul) appel de barre par service.

Pouvez-vous détailler ?

Si votre problème est que vous avez trop de packages dans le référentiel, je suggérerais d'utiliser des artefacts au lieu de référentiels.

Ce à quoi je faisais référence, c'était trop de graphiques de barre emballés (qui incluent déjà appVersion). Considérez-le comme une version de graphique de barre stable et une version d'application qui change des centaines de fois par jour. Donc quotidiennement quelques centaines de helm charts packagés par service dans un référentiel qui est ensuite consommé par une automatisation.

(Mes pipelines ressemblent généralement aux vôtres : Build App --> Image Docker (résultats dans appVersion) --> package chart (avec appVersion mis à jour) --> push vers le référentiel ?

Je pense que ce billet vise à évaluer exactement cela.

Avec certitude! À mon avis, nous avons déjà trop de niveaux d'abstraction, donc avoir un helm ici submerge un peu 😄En outre, il y a des opérateurs k8s ici, qui sont créés pour certains (peut-être la plupart ?) des problèmes que Helm résout. Mais c'est un sujet pour une autre fois, hehe.

Considérez-le comme une version de graphique de barre stable et une version d'application qui change des centaines de fois par jour. Donc quotidiennement quelques centaines de helm charts packagés par service dans un référentiel qui est ensuite consommé par une automatisation.

Oui, c'est vraiment trop, mais c'est voulu. Par exemple, vous avez une exécution de build, elle devrait produire des artefacts, puis l'enregistrer pour l'utiliser pour le déploiement sur scène. Comme... comment pouvons-nous avoir une exécution de build qui n'a pas de résultat de build ? Doit-on générer le build lors du déploiement ? Ce serait vraiment mal. Bien que certains pipelines CI le fassent pour les builds JS.

Le même problème que nous avons avec docker : chaque build génère une nouvelle image docker, qui va dans le registre docker. Nous devons le sauvegarder, comment nous sommes censés le déployer alors, si nous ne l'aurions pas ?

Bien sûr, nous pouvons docker save pour économiser de l'espace sur le registre et balayer plus tard dans la politique de rétention des arifacts de construction. Mais nous pouvons donc helm package le conserver et le conserver sous forme de fichier.

Mais je vois vraiment votre point de vue, nous pouvons avoir un "installateur", qui peut accepter une version d'application. Étant donné qu'un tel programme d'installation dispose d'une infrastructure, vous pouvez la conserver la même, en changeant simplement la version de l'application. Cela a l'air soigné et simple, mais il y a un problème.

L'application elle-même n'a pas de sens dans l'environnement k8s sans infrastructure .

Et si votre application reposait sur une infrastructure ? Exemple de base - configmap.

Et si vous deviez alors annuler l'application ?
Vous devrez rétrograder l'application, mais vous devrez également rétrograder l'infrastructure.

Et si vous deviez alors restaurer l'infrastructure ?
L'infrastructure précédente n'a aucune idée de la version de l'application que vous devez installer, car elle n'y est pas liée. Ainsi, vous devrez vous rappeler quelle application prend en charge quelle infrastructure et la définir manuellement.

Vraiment, ce serait un enfer. Et c'est un enfer en ce moment, quand vous n'avez pas de barre. Et ce n'est pas faux. Mais dans ce cas, vous avez peu de raisons d'utiliser la barre.

nous avons déjà trop de niveaux d'abstraction
Tout beau et simple clin d'oeil

Je pense que votre dernier point est très convaincant :

L'infrastructure précédente n'a aucune idée de la version de l'application que vous devez installer, car elle n'y est pas liée
C'est définitivement un problème si vous découplez ces choses et que vous avez le package/la version Helm comme source de vérité.

Cependant, pour beaucoup de gens, ce n'est probablement pas le cas. Il y a une orchestration au-dessus de Helm (oui, une autre couche d'abstraction) qui relie plusieurs graphiques de barre (et appVersions) ensemble (pensez barreur, harnais, ou similaire). Et cette couche elle-même est également versionnée. Dans ce cas, ce que vous décrivez n'est plus un problème, car vous ne reviendrez pas à une ancienne version d'un graphique de barre, mais à une ancienne version de la couche d'orchestration (cela donne un sens à l'application et à l'infrastructure).

Mais barrer seul, oui, 100% un problème 💣. Je pense que c'est la raison pour laquelle l'idée était d'autoriser explicitement le remplacement de l'appVersion et, par défaut, de ne pas l'autoriser.

Une chose que j'aime dans le couplage de la version du graphique et de la version de l'application, c'est qu'il devient clair quelle version de l'application appartient à quel graphique. Si vous devez redéployer une version spécifique, vous n'avez pas besoin de vous rappeler quelle version de l'application était compatible avec quelle version de la carte. Parce qu'ils sont liés entre eux, vous vous référez simplement à la bonne version du graphique et vous serez sûr que l'application et le graphique correspondent. Je pense que c'est essentiellement ce que @iorlas a décrit, n'est-ce pas ?

À la fin, la version graphique agira comme une "super" version :

• tout changement (peu importe s'il a changé l'application ou l'infrastructure, c'est-à-dire le graphique) entraînera une nouvelle version du graphique, c'est-à-dire que la nouvelle version de l'application impliquera que la version du graphique a également changé
• une nouvelle version du graphique n'implique pas que la version de l'application a changé

À des fins de documentation (et peut-être d'autres idées fantaisistes), vous pouvez introduire vous-même une autre version "uniquement graphique" qui ne fera référence qu'à la définition du graphique elle-même.

@filipre
Ouaip ! C'est ainsi que Helm était censé fonctionner, sur la base des décisions actuelles de conception d'architecture. Comme je le vois.

Le problème est que cela semble parfois étrange - trop pour la configuration et l'idée discutable d'avoir l'application et l'infra liées ensemble. Alors, est-ce la bonne approche - c'est une question.

@BenjaminSchiborr

Cependant, pour beaucoup de gens, ce n'est probablement pas le cas

Avec certitude! Même des k8 entiers, la mise en conteneur pourrait être trop.

Permettez-moi d'essayer de le décomposer d'un autre point de vue, en essayant de trouver le problème pour lequel la barre est créée :

• L'instance d'infrastructure est le fonctionnement de l'ensemble du produit : instances SaaS, pools de machines virtuelles, configurations k8s, versions d'applications (y compris les bases de données, les outils d'observabilité, les routeurs, les side-cars et les instances d'applications du produit)
• L'instance d'infrastructure a besoin d'une source de vérité. Maintenant, nous avons des utilitaires comme Terraform.
• Trop de choses dans un dossier = difficile. Nous devons le décomposer. Bonjour les modules Terraform.
• La plate-forme et l'application dans un seul dossier = dur. Nous avons besoin de nous décomposer. Bonjour plate-forme et conteneurs. K8s intervient.
  
  
  
  1. Ainsi, les modules Terraform peuvent gérer la plate-forme, y compris la création d'une couche de conteneurs vides et prêts à l'emploi
  
  
  2. K8s gère les conteneurs, permettant de créer des ressources de base en utilisant YAML
  
  
• De nombreux fichiers YAML pour de nombreuses applications K8s (y compris les bases de données et autres éléments) = dur. Divisez-le en dossier par application.
  
  
  
  1. Nous avons donc là des dossiers comme PostgreSQL, Redis, MyPetShop. Chacun d'eux contient des fichiers YAML pour les ressources dont nous disposons. Et il a besoin que ses versions d'applications soient définies pour être appliquées dans K8s.
  
  
• Bonjour Helm - instrument, qui permet de mettre en place ces dossiers (appelés Charts), mais plus encore : l'appliquer ensemble, rollback.
• Le graphique semble solide. Réutilisons-le en prenant en charge les variables. Now Chart n'est pas une infrastructure, mais un modèle d'infrastructure.
• Le graphique a l'air génial. Partageons-le avec des amis. Chaque fois que nous mettons à jour le graphique, nous devons le pousser vers le référentiel de fichiers avec index.

Donc, c'est génial et tout, sans aucun paquet. Vous devez donc appliquer ce graphique, puis fournir la version de l'application. Et ça devrait être ça.

Mais un problème se pose : personne ne veut se rappeler quel graphique est nécessaire pour quelle version de l'application. Quel graphique est mis à jour pour fournir une nouvelle valeur de configuration pour quelle version de l'application.

En fin de compte, tout ce que nous voulons, c'est "Configurer myApp version 1.4.2 en tant qu'application K8s" , qui encapsule tous les risques, dépendances, modifications dans un seul artefact - programme d'installation de l'application, qui est apps versions + hooks + setup logic + infrastructure to connect it all . C'est pourquoi nous avons des choses telles que MSI, Deb, RPM, même NPM, Go mod, Pip, Gem.

C'est là que Package entre en scène. Et le package, par définition, doit être créé en tant que version installable, dans le flux CI/CD. Nous pouvons donc l'envoyer dans le registre et/ou l'installer sur notre système (cluster k8s).

Et aucun autre projet n'est différent. Lorsque nous helm install Chart directement, sans package, nous faisons la même chose. Mais au lieu de créer un package, nous le créons à une étape différente. Au lieu de le construire sur le processus de création d'applications, nous le construisons sur l'étape de publication. Nous relions toujours les versions d'infrastructure et d'application . Implicitement .

Ce qui est amusant, c'est :

• Dépendance mise à jour = mettre à jour la version du modèle d'infrastructure (graphique)
• Application mise à jour = générer un fork, sous-ensemble du modèle d'infrastructure (graphique) - Package, avec sa propre version

Néanmoins, les opérateurs k8s doivent être projetés sur les problèmes actuels, il ne devrait donc y avoir qu'un seul instrument, qui devrait fonctionner comme les opérateurs, mais fournir un processus de libération facile, comme le fait helm.

Des pensées? Nous créons peut-être quelque chose de nouveau ici, mais mieux

Ce que vous décrivez a beaucoup de sens pour les applications destinées à être utilisées par d'autres personnes sur infra sur lesquelles vous n'avez aucun contrôle. Cependant, dans les scénarios d'entreprise, la création de packages devient une tâche ardue : nous pouvons avoir des dizaines de microservices à l'emporte-pièce, qui sont déployés dans les environnements partagés ou à l'emporte-pièce, et grâce à la définition du pipeline CI/CD qui réside dans le référentiel lui-même (pensez azure-pipelines.yaml), la "version du package" n'est qu'un build produit à partir d'une version particulière de la branche master. Cela signifie que je n'ai pas vraiment besoin de stocker le "package" n'importe où - ma version produira le même package, avec les mêmes bits et les mêmes variables utilisés dans les configmaps, etc. l'infra de service change, ce qui arrive assez rarement. Helm est dans cette image parce que 1) je dois déjà l'utiliser pour déployer des éléments d'infra (par exemple, nginx), 2) je n'ai pas à réinventer la roue avec le template k8s yaml.

@wasker

Projetons-le sur, par exemple, docker. L'image Docker est également un package. Il relie les binaires avec OS image = infrastructure. Je crois que la raison de créer une image docker à chaque fois que nous créons une construction est la même que pour créer un package helm.

Si l'on n'a pas besoin de tout faire abstraction des images docker, on n'a pas besoin de docker et peut vivre avec une simple VM.

Donc, si nous essayons de projeter l'utilisation de docker sur helm, utiliser helm comme instrument d'infrastructure uniquement reviendrait à utiliser docker uniquement pour créer une image initiale, puis à mettre à jour cette image sur l'hôte k8s lui-même, en envoyant de nouveaux binaires. C'est mauvais, le même genre de mauvais que d'utiliser la barre et de ne pas le reconditionner à chaque fois.

Quoi qu'il en soit, je pense que nous avons fait fausse route. Est-ce que quelqu'un utilise helm puis met à jour l'image manuellement ? Je crois que nous avons 3 cas d'utilisation généraux :

1. helm package chart -> helm install package
2. helm install chart
3. helm install -> kubectl set image

@wasker Lequel est le vôtre ? Je crois, pas le 3ème. Même s'il s'agit d'une véritable séparation de la configuration de l'infrastructure et de la gestion des versions des applications, il serait désagréable de travailler avec. Étant donné que cela signifierait que lorsque vous aurez besoin de mettre à jour l'infrastructure, vous perdrez toutes les versions. Vous devrez le mettre à jour dans Chart, manuellement, ou kubectl set image pour chaque déploiement.

Donc, nous parlons du second, helm install chart , "sans l'emballage". Ainsi, la barre est toujours en image . Le problème est que le package est construit, mais au moment de l'exécution - lorsque nous déployons notre application. Ainsi, le build CI est en charge de la création du package, implicitement, lorsque nous devons le déployer.

Et si le projeter sur golang, une telle pratique ressemble à l'envoi du code source et à son exécution en tant que go run dans le docker, au lieu de le construire et d'utiliser le binaire.

Ainsi, la vraie raison de sauter l'étape de l'emballage est de simplifier l' ensemble du tableau pour l'ingénieur. Est-ce ?

C'est là que nous pouvons commencer à parler. Ici https://github.com/helm/helm/issues/3555#issuecomment -529022699 est ma proposition. Ajoutez helm run et modélisez-le comme go run .

Si nous avons vraiment besoin de diviser l'infrastructure et la gestion des versions de l'application , cela signifierait d'utiliser helm uniquement pour mettre à jour / amorcer l'infrastructure. Même si j'aimerais voir un moyen de le faire, je peux voir celui qui n'ajoutera pas de maux de tête aux mises à jour. Nous pouvons ignorer les versions des déploiements actuels et tout... mais je pense que c'est tellement faux, ce serait une perte de temps à créer.

Projetons-le sur, par exemple, docker. L'image Docker est également un package. Il relie les binaires avec OS image = infrastructure. Je crois que la raison de créer une image docker à chaque fois que nous créons une construction est la même que pour créer un package helm.

Je suppose que le problème est que si vous créez une nouvelle image Docker, c'est parce que quelque chose dans cette image a changé. Dans le scénario décrit ici, le contenu du Helm Chart emballé n'a pas changé à l'exception d'une seule ligne - la version de l'application. Cela affecte le résultat final, mais cela ne change pas le comportement de la charte Helm en elle-même. Il fera la même chose, de la même manière, juste avec des valeurs différentes - le Helm Chart en tant qu'entité à part entière n'a pas le moins du monde changé à la suite du changement de version de l'application ; seul ce qui est publié à la fin l'a.

Vous pouvez faire des parallèles ici avec la possibilité de faire des choses comme utiliser la configuration pour Docker Images. Vous transmettez des variables d'environnement à une image Docker, cela affecte son exécution au moment de l'exécution et vous ne reconstruisez pas une image pour modifier ces variables. Le contenu de l'image n'a pas changé, mais le résultat final a une situation très similaire, mais dans ce cas, le comportement est souhaitable et normal.

Et si le projeter sur golang, une telle pratique ressemble à l'envoi du code source et à son exécution comme go run dans le docker, au lieu de le construire et d'utiliser le binaire. [...] Ainsi, la vraie raison de sauter l'étape de l'emballage est de simplifier l'ensemble du tableau pour l'ingénieur. Est-ce?

Pas à mon avis. De manière réaliste, l'argument ici est de savoir si les personnes envisageant ou non la version de l'application "fait partie du graphique", et également si elles considèrent qu'un graphique Helm est distinct des images Docker déployées à la suite du graphique. Mon point de vue à ce sujet est ce que j'ai mentionné ci-dessus. C'est comme prendre un binaire Go compilé, dans une image Docker, et l'exécuter avec différentes variables d'environnement.

Cela étant dit, les arguments avancés pour reconditionner un Helm Chart avec une nouvelle version d'application et utiliser la version de graphique comme une sorte de "super version" sont convaincants (notamment pour l'avantage d'avoir toujours une version d'application compatible déployée avec un graphique - à condition que la version de l'application ne soit pas personnalisable via des valeurs).

Ma question est - _pourquoi ne pas soutenir les deux approches ?_ Il y a des avantages et des inconvénients à chaque approche. Fondamentalement, ne pas prendre en charge cela ne fait que rendre plus difficiles certains flux de travail parfaitement valides. Par exemple, en utilisant Flux CD et son Helm Operator. Si vous avez un Helm Chart partagé (c'est-à-dire parce que vous avez un certain type de service que vous déployez beaucoup et qu'ils partagent bon nombre des mêmes caractéristiques), alors pour obtenir une sortie helm list utile, vous devez avoir un nouveau Helm Graphique pour chaque application, et chaque version a également besoin de son propre graphique Helm. Cela seul complique les pipelines, car si le graphique pouvait être partagé, il pourrait avoir son propre pipeline qui ne s'exécuterait que lorsque le graphique était mis à jour, et les pipelines d'application n'auraient même pas besoin d'exécuter une seule commande Helm (à condition que Flux CD ajoute la prise en charge de un indicateur de nouvelle version de l'application lors de l'installation/mise à niveau).

Ma question est - pourquoi ne pas soutenir les deux approches ?

C'est exactement ce que je pense.

Dans mon cas, la "super version" n'est pas le graphique de barre mais une autre couche qui utilise simplement une pléthore de graphiques de barre. Pour moi, une seule charte Helm n'a pas de sens car elle ne décrit qu'un petit service parmi tant d'autres. Seulement ensemble, ils forment une libération significative.
Ainsi, dans mon cas, la "super version" est le résumé de toutes ces versions ensemble (c'est ainsi qu'elle est réellement versionnée).

Pourtant, il existe un argument en faveur d'une charte Helm elle-même en tant que "super version" descriptive.

Revenons au @seeruk : pourquoi ne pas prendre en charge les deux ?

Il peut être utile pour le débat actuel d'avoir une voix extérieure. Pour un peu de contexte, j'ai utilisé helm pour une somme totale de _11 jours._ Je pense que cela me donne une perspective unique à ajouter car je n'ai été impliqué dans aucun apprentissage avancé. Tout ce que j'ai glané est venu de la documentation et de l'expérimentation.

Comment je vois Helm

Jusqu'à la lecture de ce débat actuel sur l'installation de packages par Helm plutôt que de graphiques, je pensais que Helm était principalement une interface pour décrire les ressources Kubernetes associées. Cette croyance vient principalement de la documentation Helm qui dit ceci :

Helm installe des graphiques dans Kubernetes, créant une nouvelle version pour chaque installation. Et pour trouver de nouvelles cartes, vous pouvez effectuer une recherche dans les référentiels de cartes Helm.

Pour le contexte, la documentation actuelle de la barre stable indique également :

Un graphique est un package Helm. Il contient toutes les définitions de ressources nécessaires pour exécuter une application, un outil ou un service à l'intérieur d'un cluster Kubernetes. Pensez-y comme l'équivalent Kubernetes d'une formule Homebrew, d'un dpkg Apt ou d'un fichier Yum RPM.

Alors maintenant, il y a une certaine confusion! La documentation Helm dit clairement qu'"un graphique est un package helm", mais si tel est le cas, alors pourquoi diable helm install accepte-t-il les dépôts Chart non emballés ?

C'est ce comportement qui a influencé ma vision actuelle de ce qu'est la barre et de la façon dont elle est censée fonctionner :

Helm agit comme un mappeur entre la structure de _quoi_ va dans le cluster et _quelles propriétés_ ces choses ont.

Alors maintenant, la question est : « Qu'est-ce que Helm déploie ? »

Qu'est-ce que Helm Deploy ?

Lorsque j'exécute helm install release-name ./local_chart je m'attends à ce que helm rende tous les modèles de graphiques localement avec les valeurs spécifiées (soit par défaut, soit par remplacement) et envoie les versions rendues dans Kubernetes. Je m'attends également à ce que Helm conserve les objets Kubernetes précédemment déployés en cas de restauration. Ce concept de « une collection de modèles rendus » (qui contient des métadonnées) est une version et un paquet. Toutes ces définitions de ressources (même si elles n'ont pas changé) doivent être dans _leur état décrit dans le bundle_ pour que la version existe (ou soit restaurée).

À partir de là, je suppose que helm ne déploie vraiment que des packages . Cela semble être la seule chose sémantiquement correcte que vous puissiez dire ; cependant, l'argument sur la façon dont ces paquets sont distribués semble être la cause première de ce débat dans la pratique. Plus précisément, « la mise à niveau ou le changement de version de l'application constitue-t-il un nouveau package ? »

Par _ma sémantique personnelle_ la réponse à cette question est oui . En partant du principe que vous ne modifieriez pas le numéro de version à moins que quelque chose ne change, vous n'auriez besoin d'ajuster le numéro de version de votre application que si certaines propriétés sous-jacentes étaient modifiées. Cela impliquerait probablement d'extraire une image docker différente d'un registre, ou de définir un indicateur de fonctionnalité via une variable d'environnement, ou un certain nombre de pratiques différentes pouvant être utilisées pour modifier le comportement de certains artefacts de code.

C'est pour cette raison que j'ai commencé à nettoyer nos registres et à ne jamais déployer à partir de :latest sauf en développement. L'utilisation d'une « balise méta » au lieu d'une balise de version à partir d'une image docker rend impossible la liaison d'un déploiement donné à une base de code donnée. Nous avons appris celui-ci à la dure (mais heureusement en test, et pas en prod).

Quel modèle doit être utilisé ?

C'est déjà une opinion de Helm : packages .

Étant donné que ce modèle est le modèle appliqué même s'il n'est pas évident à 100 %, il semble logiquement cohérent qu'un indicateur --appVersion soit fourni. Répondre au "pourquoi" de ceci est probablement plus important que toute autre chose, alors laissez-moi conclure ma contribution avec cette réponse.

Pourquoi prendre en charge --appVersion ?

Examinons un cas particulier de déploiement :

Une entreprise a une application avec deux versions principales. Certains des clients de cette société ne se sont pas engagés à passer à la dernière version majeure de cette application et utilisent la plus ancienne des deux. En raison des contrats de développement payants, le développement en direct a toujours lieu sur l'ancienne version majeure... mais le produit est le "même". L'infrastructure à déployer pour les deux versions de cette application est la même ; cependant, la version de l'application sera radicalement différente entre ces déploiements.

Quelle est cette entreprise à faire?

1. Créez deux graphiques de barre séparés, presque identiques, qui ne diffèrent que par appVersion ?
2. Utiliser un seul graphique de barre mais mettre constamment à jour appVersion alternant entre les principales versions de l'application ?
3. Remplacer le appVersion par un indicateur (actuellement non pris en charge) entraînant une erreur potentielle du développeur sur la ligne de commande ?
4. Rescoper appVersion sur Chart.yaml et dans values.yaml ?

La proposition 1 introduit un peu plus de frais généraux que les autres propositions, mais présente également l'avantage de séparer les graphiques de ces versions d'application si elles divergent. Il a un cas d'utilisation clair et serait probablement adopté dans de nombreux cas de ce problème.

La proposition 2 a moins de frais généraux que la proposition 1 mais introduit une grande variabilité dans un graphique. Que se passe-t-il si vous exécutez helm install release-name https://remote-repo.com/chart et que la version la plus récente du graphique est la mauvaise version de l'application ? Oups. Probablement pas la meilleure approche.

La proposition 3 est ce dont nous discutons actuellement. Personnellement, je n'aime pas l'option, mais uniquement parce que j'ai l'impression que c'est la mauvaise solution au problème. Est-ce que cela rend l'appVersion configurable ? Sûr. Mais il a également le même problème que vous rencontrez lorsque vous exécutez helm install release-name https://remote-repo/chart : Les métadonnées sont éphémères et UNIQUEMENT maintenues par Helm.

Je suis en fait assez choqué que personne n'ait encore proposé la proposition 4 ou quelque chose du genre. Il met l'appVersion dans un état où il peut être remplacé (permettant quelque chose qui ressemble à helm run ), peut être contenu dans le package généré par helm package , et démêle vraiment le concept d'une version d'application à partir d'une version graphique tout en gardant le concept de appVersion couplé à un déploiement helm (l'appVersion doit être quelque part, non ?).

J'espère que cela a été utile. ce PR.

@jrkarnes : Dans un sens 4) a déjà été proposé et est utilisé comme solution de contournement par de nombreuses personnes (voir ici https://github.com/helm/helm/pull/5492#issuecomment-517255692 ). Vous pouvez utiliser quelque chose comme ceci dans vos modèles de graphique :

{{ default .Values.appVersion .Chart.AppVersion }}

Cela vous permettrait d'utiliser le appVersion dans le Charts.yaml par défaut et de le remplacer par quelque chose dans le Values.yaml (qui peut être remplacé lors des appels d'installation/mise à niveau). L'inconvénient est que lorsque vous faites par exemple un helm ls cela vous montrera soit non, soit un appVersion incorrect.

@BenjaminSchiborr Merci de m'avoir informé à ce sujet. Comme je l'ai dit, je suis dans l'espace helm travail toute connaissance est une bonne connaissance à ce stade pour moi.

Je pense que ma quatrième proposition a été légèrement mal comprise. Plutôt que d'avoir quelque chose comme {{ default .Values.appVersion .Chart.AppVersion}} vous utiliseriez {{ .Values.Helm.AppVersion}} et le values.yaml contient appVersion au lieu de Chart.yaml

@jrkarnes
C'est ce que je pense en ce moment. Comme, pourquoi la version de l'application devrait être traitée comme un flocon de neige unique. C'est la valeur du graphique.

Le raisonnement derrière cela est simple : tout fait partie de l'infrastructure. Donc, infra a une version. Pourquoi deux versions ?

Mais je suis trop occupé pour me concentrer sur les valises latérales et les projections. Mais en général, c'est la question : pourquoi avons-nous besoin d'une version de l'application, alors qu'en résumé, il s'agit de toute l'infrastructure ? ou Pouvons-nous utiliser la version de Chart comme version d'infrastructure lorsque Chart est un modèle infra uniquement, et comme version d'application lorsque l'infra inclut la version d'application ?

je vais y réfléchir un peu plus

@jrkarnes
C'est ce que je pense en ce moment. Comme, pourquoi la version de l'application devrait être traitée comme un flocon de neige unique. C'est la valeur du graphique.

Le raisonnement derrière cela est simple : tout fait partie de l'infrastructure. Donc, infra a une version. Pourquoi deux versions ?

Fondamentalement, il est logique de séparer la version du graphique de la version de l'application . Un exemple rapide est probablement le meilleur moyen de prouver que c'est le cas.

Disons que vous avez déployé une application qui est ver 4.0.0 cours d'exécution sur votre graphique versionné ver 1.1.0 . Au cours de vos opérations, vous réalisez que vous allez devoir commencer à exécuter une tâche cron pour cette application. Plutôt que d'écrire l'objet cronJob et de l'appliquer au cluster, vous vous rendez compte que les autres personnes qui exécutent ce graphique auront probablement également besoin de la tâche cron... vous l'ajoutez donc à votre graphique. Votre graphique a maintenant progressé à ver 1.2.0 mais aucun changement n'a été apporté à l'application que gère le graphique, il est toujours à ver 4.0.0 .

L'inverse est également applicable et fait déjà l'objet d'un débat dans ce PR.

Mais je suis trop occupé pour me concentrer sur les valises latérales et les projections. Mais en général, c'est la question : pourquoi avons-nous besoin d'une version de l'application, alors qu'en résumé, il s'agit de toute l'infrastructure ? ou Pouvons-nous utiliser la version de Chart comme version d'infrastructure lorsque Chart est un modèle infra uniquement, et comme version d'application lorsque l'infra inclut la version d'application ?

je vais y réfléchir un peu plus

Plutôt que de penser à un cas secondaire ou à une projection, pensez à des choses comme MySql qui a trois versions de moteur largement utilisées et prises en charge : [5.6, 5.7, 8.0] . Pour déployer une instance mysql dans un cluster, vous aurez toujours :

• Un ou plusieurs Pod(s) exécutant une instance de MySql de la version choisie
• Un service qui permet la résolution de kube-dns au pod (ou aux pods s'il s'exécute en haute disponibilité)
• Un ou plusieurs PV pour les pods dans lesquels écrire leurs données avec les PVC d'accompagnement

Le tableau de déploiement de MySql 5.6, 5.7 ou 8.0 doit être relativement le même pour toutes les versions du moteur (application). La seule vraie différence est la version de l'application et l'image du docker (qui est probablement étiquetée sémantiquement selon la version du moteur).

Je vois ce que vous entendez par vous interroger sur le "besoin" d'une version d'application. Je pense que cela dépend de la commodité du développeur ou des opérations lors de l'exécution de helm ls ou helm inspect .

+1 au dernier message de @jrkarnes . Il est très utile de conserver les versions de graphique et d'application en tant que concepts distincts, précisément parce que la version de graphique est la "version d'infrastructure".

Si je publie le graphique pour que d'autres le consomment, il fait partie de l'infrastructure des projets qui en dépendent. Cependant, si je n'ai jamais l'intention de faire en sorte que mon application soit utilisée par d'autres, tout ce qui m'importe est de modifier ma propre version de graphique de temps en temps, lorsque le graphique lui-même change , mais sinon j'ai juste besoin que la version de mon application soit conforme à CI /Sortie CD. Dans cette version du graphique d'utilisation, les tours sont relativement rares, mais la version de l'application change à chaque occurrence de CI. Mon référentiel de code maintient la relation entre le code et la version infra qui s'applique à cette version du code à exécuter. En d'autres termes, au lieu d'annuler mon déploiement avec helm install last-known-good-chart-version , je réexécute simplement mon pipeline de CD avec un pointeur à un dernier bon ID de validation connu.

@iorlas J'ai lu votre proposition pour helm run et cela ne me pose aucun problème. Bien que je pense qu'il n'est pas nécessaire d'avoir la dichotomie installation/exécution, si cela rassure les responsables de la maintenance de la modification de la version de l'application, je suis d'accord avec cela. :)

@iorlas Avez-vous eu l'occasion de réfléchir à ce que vous aimeriez faire avec cette proposition ?

Je ne pense pas comprendre comment fonctionne la solution {{ default .Values.appVersion .Chart.AppVersion}} contournement impliquant

Erreur : erreur de conversion de YAML en JSON : yaml : clé de carte invalide : map[interface {}]interface {}{".Values.appVersion | default \"0.0.1\"":interface {}(nil)}[

Voici mon Chart.yaml :

name: demo-helm
version: 0.0.1
appVersion: {{ .Values.appVersion | default "0.0.1" }}
home: http://example.com
description: Demo Helm

@IRobL Vous devez mettre cet extrait dans templates/deployment.yaml , où la version est utilisée. Les fichiers comme values.yaml ne sont pas traités comme des modèles.

@jrkarnes Je ne suis pas un mainteneur, donc le dernier mot appartiendra aux autres, je suppose. Mais de toute façon, j'ai été assez occupé ces dernières semaines. La semaine prochaine, je réévaluerai notre approche actuelle pour gérer helm et ses packages .

Nous utilisons l'approche que j'ai décrite :

• Helm Chart fait partie du référentiel d'applications
• La construction de l'application produit :
  
  
  
  • Image Docker -> Registre Docker
  
  
  • Fichiers statiques -> service CDN
  
  
  • Pack Helm -> Stockage CI
  
  
• Ainsi, le package Helm est l'artefact principal, liant tous les artefacts d'application ensemble
• Lors du déploiement, install dit package

Préoccupations actuelles :

• Complexité du processus de construction.
  
  
  
  • Au lieu de l'image docker et des fichiers statiques, un fichier supplémentaire( helm package ) est généré
  
  
  • Quelles sont les principales raisons pour lesquelles nous avons besoin de quelque chose en plus du fichier go build / make install ?
  
  
  • Quel est le coût?
  
  
  • Pourquoi postuler ?
  
  
  • Quand postuler ?
  
  
• Durée de construction
  
  
  
  • Même si nous n'avons pas besoin de le déployer, nous perdons quand même du temps et de l'argent. 2-5 secondes. Pas grand-chose, mais un travail qui n'a pas de sens n'a pas de sens.
  
  
• Complexité des mises à jour des modèles d'infrastructure
  
  
  
  • Lorsque le graphique est mis à jour, les valeurs doivent également être mises à jour
  
  
  • Le graphique est un dépôt, les valeurs en sont un autre, chaque mise à jour des valeurs signifie un petit mal de tête
  
  

Une telle réévaluation pourrait conduire à des simplifications et des idées supplémentaires. Nous verrons :)
J'enverrai une mise à jour plus proche de vendredi prochain.

Ah, je vois pourquoi cette astuce ne fonctionnerait pas maintenant que vous me l'avez signalé, merci. Voici une astuce qui, je pense, fonctionne bien pour de nombreuses personnes utilisant Helm 2.x en supposant que vous êtes à l'aise d'envelopper votre outil de barre avec ce genre de pièces aériennes :

APP_VERSION=0.0.7
sed -i.bak "s/^appVersion:.*\\\$/appVersion: $APP_VERSION/" helm/Chart.yaml
helm install --name helm_demo helm/

@IRobL

En général, si vous enveloppez un déploiement avec sed, cela signifie qu'un moteur de modèles ne fait pas ce dont vous avez besoin, ce qui est tout l'objet de cette discussion.

Lorsque gitlab en était à ses balbutiements et n'avait pas de support helm, nous avons littéralement saisi des valeurs sur des cibles de remplacement sur un fichier manifeste fabriqué à la main.

C'est une mauvaise pratique pour quelque chose comme ça et je vous exhorte à vous en éloigner si possible.

Le 7 octobre 2019 à 15h33, IRobL [email protected] a écrit :

Ah, je vois pourquoi cette astuce ne fonctionnerait pas maintenant que vous me l'avez signalé, merci. Voici une astuce qui, je pense, fonctionne bien pour de nombreuses personnes utilisant Helm 2.x en supposant que vous êtes à l'aise d'envelopper votre outil de barre avec ce genre de pièces aériennes :

APP_VERSION=0.0.7
sed -i.bak "s/^a ppVersion:. *\\$/appVersion: $APP_VERSION/" helm/Chart.yaml
helm install --name helm_demo helm/
-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub ou coupez le fil de discussion.

@jrkarnes , quand vous dites mauvaise pratique, dites-vous qu'il n'est pas souhaitable d'avoir besoin d'envelopper la commande helm avec un script ? Si c'est le cas, je suis tout à fait d'accord. Je ne dis pas du tout que je suis contre l'ajout d'un drapeau --app-version ; au contraire, je pense que ce serait un ajout très pratique à la barre. Clairement basé sur ce PR, je ne suis pas la seule personne à utiliser helm qui souhaite garder la variable appVersion cohérente avec la version réelle en cours de déploiement. Il se trouve que je développe une bibliothèque de pipeline de build réutilisable qui regroupe divers outils de build pour produire des builds reproductibles -- c'est une pratique courante pour les grandes organisations technologiques. Dans mon cas d'utilisation, la bibliothèque de pipeline construit les conteneurs docker, les publie et les déploie finalement via helm à partir du pipeline de génération de l'application (par exemple, considérez la version 1.0.1-pr-3.1 l'application

Même après avoir résolu ce problème dans la bibliothèque de pipeline de construction de mon entreprise, je me sentirais certainement plus à l'aise d'avoir un commutateur --app-version intégré à Helm ; cela ressemble simplement à une manière plus flexible de gérer les déploiements. Je veux dire, pourquoi un système externe ou un ingénieur devrait-il entrer dans le fichier Chart et mettre à jour un fichier yaml avant chaque déploiement s'il peut être automatisé par une plate-forme de construction qui ne peut pas gâcher les chiffres accidentellement ? De mon point de vue, la fonctionnalité appVersion devrait être entièrement abandonnée par mon organisation, ou le contournement "bâclé" sed devrait être ajouté à notre code de bibliothèque de pipeline, alors j'ai pensé le partager pour toute autre personne qui résolvait ce problème.

@IRobL
En général, tout utilitaire doit être autosuffisant à son propre niveau d'abstraction : il doit faire abstraction du problème qu'il résout en fournissant suffisamment d'API. Helm ne fait pas exception. Donc, si vous avez besoin de personnaliser son comportement, vous devez d'abord vous demander : est-ce que cela correspond à l'architecture, aux principes de conception ou peut-être que quelque chose m'échappe ?

C'est pourquoi ce PR n'a pas été si facile à résoudre. Depuis, le correctif est évident, mais il n'est pas conforme à la conception de Helm. C'est pourquoi peu de solutions temporaires sont proposées.

Et vous avez raison pour le drapeau app-version . Vous devez le fournir, puis Helm doit tout gérer lui-même.

Puis-je vous poser une question? Comment utilisez-vous Helm dans votre produit ? Quand tu utilises helm install ? Comment l'utilisez-vous exactement ? Avez-vous pensé à utiliser helm package ?

J'ai revu helm package hier soir. Je n'étais pas vraiment convaincu. sed existe depuis très longtemps et est très stable. Toutes ces sous-commandes tiller / package / install sont relativement nouvelles et moins stables. Pour m'aider à articuler mon propos, il y a des mois, j'ai décidé « certain que tiller pourrait fonctionner » même si j'avais vu le plugin de quelqu'un qui contournait le besoin de Tiller. Je considérais le plugin comme quelque chose qui devait être moins grand public, mais je me suis battu depuis. Si j'avais fait confiance au plugin, je serais dans une bien meilleure position que maintenant. Les responsables de Helm ont même confirmé qu'ils étaient d'accord pour dire qu'il s'agissait d'une conception non maintenable et qu'elle disparaîtra dans les prochaines versions.

Je pense que ce serait une erreur de ma part d'utiliser helm package pour effectuer ces opérations sed simples. Quel est votre cas d'utilisation pour package toute façon ? J'ai l'impression que l'ensemble du concept de helm package manque l'intérêt des versions Web 2.0/contrôle de version en empaquetant dans un zip binaire en premier lieu lorsque les groupes technologiques modernes ont tiré parti de la puissance du balisage pour réaliser le même processus mais d'une manière plus simple et plus vérifiable.

Pour mon cas d'utilisation, je permets aux développeurs d'applications de codifier leurs applications conteneurisées et de les déployer de manière maintenable, de sorte que la réduction des frais généraux (administrateurs système ops/tiller, gestion des artefacts de version redondante, etc.) est d'une importance capitale. Je pense que mon utilisation suit de plus près la philosophie Unix de décider d'utiliser un outil pour ce qu'il fait le mieux, puis de passer à d'autres outils (etc. sed) le cas échéant. Je ne pense pas que vous trouverez jamais un outil pour tout faire parfaitement pour vous, mais si vous êtes satisfait de votre flux de travail actuel, ne me laissez pas vous dissuader de suivre votre propre philosophie.

@IRobL

lorsque vous dites mauvaise pratique, dites-vous qu'il n'est pas souhaitable d'avoir besoin d'envelopper la commande helm avec un script ?

Oui. Ceci justement.

Dans mon cas d'utilisation, la bibliothèque de pipeline crée les conteneurs Docker, les publie et les déploie finalement via helm à partir du pipeline de génération de l'application

C'est exactement ce que nous faisons aussi.

Même après avoir résolu ce problème dans la bibliothèque de pipeline de construction de mon entreprise, je me sentirais certainement plus à l'aise d'avoir un commutateur --app-version intégré à Helm

Je voudrais aller plus loin et dire que le fait que le appVersion soit une propriété du fichier Chart.yaml est probablement incorrect. Si la valeur peut être modifiée à la volée, elle ne devrait pas être dans ce qui est considéré comme un « ensemble de valeurs immuable ». Je crois que j'ai plaidé pour la même chose dans un commentaire précédent.

Toutes ces sous-commandes tiller/package/install sont relativement nouvelles et moins stables.

FWIW, Tiller ne va pas être une chose dans Helm 3. Vous y avez fait allusion plus tard dans votre message; cependant, je ne fais que répéter cela car cela montre que la syntaxe helm package de création d'un "binaire kubernetes" et de son envoi à Tiller est probablement une mauvaise pratique.

Je pense que ce serait une erreur de ma part d'utiliser le package helm pour effectuer ces opérations sed simples. Quel est votre cas d'utilisation pour le package de toute façon ?

Je peux probablement défendre l'équipe Helm sur celui-ci. Le sentiment que j'ai eu derrière la barre était une méthode pour que les développeurs d'applications spécifient comment exécuter correctement leur application depuis Kubernetes. C'est pourquoi les fournisseurs d'applications exécutent leurs propres référentiels Helm que vous pouvez ajouter pour télécharger une version donnée de leur déploiement. L'équipe Helm considérait probablement le code d'application et le code d'infrastructure comme étroitement liés, car leurs équipes de production cibles n'allaient pas utiliser Helm dans les flux de travail quotidiens comme nous le faisons dans CI/CD. Exemple : nous utilisons helm upgrade 130 fois par jour en moyenne. Je ne pense pas que cela ait jamais été l'utilisation prévue.

Il était probablement beaucoup plus courant pour les gens de dire: "Je veux juste installer mysql dans kubernetes" et helm était un moyen (relativement) facile de le faire pour les personnes qui connaissaient peu kubernetes et qui ne faisaient que jouer avec.

Ainsi, helm package était finalement destiné à être consommé par _ce public_. L'outil est certainement beaucoup plus utilisé dans des domaines que l'équipe (je pense) ne croyait pas pouvoir prendre l'outil, ou n'avait jamais eu l'intention de l'utiliser tel qu'il est.

Je pense que mon utilisation suit de plus près la philosophie Unix de décider d'utiliser un outil pour ce qu'il fait le mieux, puis de passer à d'autres outils (etc. sed) le cas échéant.

Je traite essentiellement Helm comme awk avec un tas de kubectl apply -f s après. C'est juste beaucoup plus propre d'avoir un outil automatisé qui s'occupe des valeurs pour éviter les erreurs humaines.

On dirait que vous et moi avons beaucoup des mêmes valeurs et pouvons faire beaucoup de choses similaires.

@IRobL

taller

Pour moi, tiller n'est pas acceptable. Puisqu'il ajoute un point d'exposition supplémentaire, des risques de sécurité supplémentaires et, le plus important, ne fait que créer une autre façon d'appliquer les fichiers yaml, mais avec une API différente. Tiller a été conçu pour sécuriser, aligner le processus d'application des packages Helm, mais avec tellement de risques, des logiciels supplémentaires (et la gestion des versions !). C'est pourquoi Helm 3e ne l'utilise pas.

Je pense que ce serait une erreur de ma part d'utiliser le package helm pour effectuer ces opérations sed simples.

Je pense que vous manquez mon point. Laissez-moi réessayer. À quoi sert le sed ? Transformer un flux de données. Il devrait éliminer le problème des transformations, vous donnant l'API et le résultat pour toute entrée donnée.

Et si vous faisiez un script, où votre commande sed ne fonctionne pas (c'est-à-dire que vous avez une erreur dans votre regex) ? Donc tu as fait une conclusion, ça ne marche pas. Essayerez-vous de comprendre pourquoi sed ne fonctionne pas tout seul, ou ajouteriez-vous un tube supplémentaire avec le script perl ?

La même chose vaut pour chaque solution : elle doit fournir une API, prendre des entrées et fournir des sorties, en éliminant un problème. Vous savez, le style Unix.

Projeté sur Helm, il est conçu pour versionner votre version et la pousser dans les K8. Il permet de personnaliser la configuration à l'aide de modèles. Donc, vous observez un problème, vous devez fournir une version. Helm fournit un mécanisme simple pour gérer les versions et permet de personnaliser facilement le fonctionnement de votre build. Alors, pourquoi ne pas essayer de comprendre comment cela fonctionne, au lieu d'ajouter une solution de contournement avec un logiciel supplémentaire ?

@jrkarnes

Oui, nous approchons tous les deux de la barre avec des intérêts similaires en tête. Je n'avais pas vraiment réalisé que la racine de la commande package était liée aux erreurs commises par tiller, merci de partager ces informations avec moi !

J'étais en train de passer en revue l'historique des raisons pour lesquelles cette fonctionnalité n'est pas simplement ajoutée et j'ai vu deux arguments expliquant pourquoi ils ne pouvaient pas ajouter cette fonctionnalité, l'un étant que, puisqu'il est déjà défini dans package ils ne devraient pas également devez également le définir dans install / upgrade . J'ai de la sympathie pour cela, cela ressemble à un problème de dette technologique. Il n'existe pas de logiciel d'utilisation publique qui n'ait pas de dette technologique. L'autre raison était que le fichier Chart.yml était une métadonnée et ne devait pas être mis à jour. Cela m'a semblé étrange... au fur et à mesure que les gens développent des graphiques de barre, ils mettent sûrement à jour ce fichier manuellement à mesure que les choses changent et il n'est donc pas lui-même immuable. Il m'est plus facile de visualiser le fichier Chart.yml comme un moyen d'introduire des paramètres dans le binaire helm car il crée les objets de déploiement qui, par contraste, sont en réalité immuables.

Quelle est votre plate-forme de construction d'ailleurs ? Le code de pipeline que j'écris est écrit pour Jenkins en tant que bibliothèque globale de pipelines.

@IRobL Le problème clé est le suivant : vous regardez Helm en tant que script de déploiement. Mais Helm n'est pas comme ça. Helm est une couche d'abstraction. Helm prend tous vos artefacts et s'applique comme une seule unité de travail sur K8s en tant que plate-forme.

Helm est un emballeur. Helm est conçu pour faciliter le déploiement. Il crée un "installateur" à partir de vos artefacts, vous pouvez donc "l'installer" sur votre système d'exploitation - K8.

app-version dans install n'a rien à voir avec la dette technologique. Ce n'est pas du tout nécessaire lorsque vous voulez le install ou upgrade . Idem pour le Chart.yml . Il ne doit pas être modifié du tout, car il s'agit d'un fichier de configuration par défaut, qui contient la version du graphique actuel, mais le graphique n'est pas votre logiciel. Vous l'utilisez simplement mal.

De ce point de vue, pourquoi n'envisageriez-vous pas d'utiliser package ? Ça a l'air trop complexe pour toi ou quoi ?

Je ne suis pas au courant de ce problème depuis un petit moment, mais j'ai vu ce genre de point surgir à quelques reprises :

Helm est un emballeur. Helm est conçu pour faciliter le déploiement. Il crée un "installateur" à partir de vos artefacts, vous pouvez donc "l'installer" sur votre système d'exploitation - K8.

Fondamentalement, Helm _ne crée en aucun cas_ un programme d'installation. Il ne crée pas de "binaire". Il ne crée pas quelque chose de similaire à un fichier ".deb" ou similaire. Il crée une archive de certains modèles de manifestes Kubernetes, avec des valeurs par défaut et/ou prédéfinies. Votre logiciel actuel ne vit pas dans ce Helm Chart. Il n'est pas emballé avec. Il n'est pas garanti qu'il soit immuable.

Je pense qu'il est juste de dire que dans la plupart des cas, votre Helm Chart va changer un peu moins que le logiciel que vous déployez via votre Chart.

C'est la raison fondamentale (OMI du moins) pour que --app-version soit disponible sur helm install et helm upgrade . Pourquoi devriez-vous reconditionner votre graphique si littéralement rien n'a changé ?

Je vois un Helm Chart comme une description versionnée des manifestes Kubernetes, décrivant un ensemble de composants Kubernetes qui exécuteront avec succès une application, et c'est tout ce que je vois. Si ces instructions doivent changer, c'est à ce moment-là que j'aimerais mettre à jour mon graphique - pas à chaque fois que mon application change et j'ai seulement besoin de mettre à jour une version d'image (que vous définissez souvent via des valeurs de toute façon).

Jetez un œil à Flux par exemple et au fonctionnement de leur opérateur de casque. Vous pouvez lui demander de mettre à jour automatiquement une valeur de balise d'image - cela ne met pas à jour le graphique, mais uniquement la balise d'image en cours de déploiement.

Il crée une archive de certains modèles de manifestes Kubernetes, avec des valeurs par défaut et/ou prédéfinies.

Mais le fichier deb est le même ensemble de fichiers de configuration, de commandes, de manifestes et/ou de valeurs prédéfinies. Identique à l'installateur MSI ou même, qui est le plus proche, ebuild dans le système de paquetages gento emerge. Aussi, même chose que les packages Brew.

Alors qu'est-ce que le Helm sinon un gestionnaire de paquets pour K8 ? Quelle est la différence que vous voyez?

Il n'est pas garanti qu'il soit immuable.

Pourquoi pas? Si vous modifiez le package après la génération du package, c'est faux. Si vous fournissez des options supplémentaires pendant le processus install/upgrade , cela est prévu, comme dans tous les systèmes d'emballage.

Je vois un Helm Chart comme une description versionnée des manifestes Kubernetes

Vous en avez déjà un - GIT. Alors, pourquoi auriez-vous besoin d'un casque ?

Je pense qu'il est juste de dire que dans la plupart des cas, votre Helm Chart va changer beaucoup moins que le logiciel que vous déployez via votre Chart.
C'est la raison fondamentale (au moins IMO) pour que --app-version soit disponible lors de l'installation et de la mise à niveau de helm. Pourquoi devriez-vous reconditionner votre graphique si littéralement rien n'a changé ?

Dans cette conception, appVersion ne doit pas être traité comme un attribut de la construction du package Helm. Il doit être traité comme un paramètre de configuration, en valeurs.

Jetez un œil à Flux par exemple et au fonctionnement de leur opérateur de casque. Vous pouvez lui demander de mettre à jour automatiquement une valeur de balise d'image - cela ne met pas à jour le graphique, mais uniquement la balise d'image en cours de déploiement.

Dans ce cas, vous perdrez le couplage des manifestes d'infrastructure d'application et de la version de l'application. Depuis, changer la balise d'image ne déclenchera pas une nouvelle mise à niveau de la barre (corrigez-moi si les gars de Flux le font autrement). Dans ce cas, vous aurez Helm comme modèle de configuration. Dans ce cas, vous n'avez pas du tout besoin de --app-version .

Mais le fichier deb est le même ensemble de fichiers de configuration, de commandes, de manifestes et/ou de valeurs prédéfinies. Identique à l'installateur MSI ou même, qui est le plus proche, ebuild dans le système de paquetages gento emerge. Aussi, même chose que les packages Brew.

Votre description ici pour les packages .deb et .msi manque un composant clé - la chose réelle qui est en cours d'installation. Si vous regardez le contenu d'un fichier .deb , vous trouverez le logiciel construit - _LE_ logiciel qui va être installé. De manière générale (toujours dans le cas de .deb ?) l'application en cours de déploiement est intrinsèquement liée et fait partie de ce package (pas le cas avec brew).

Les emballages de brassage sont différents et pas vraiment comparables de la même manière. Brew est en fait beaucoup plus similaire à Helm actuellement, car il ne s'agit que d'instructions sur la façon dont il doit être installé et où la source / le package doit être téléchargé.

Pour être absolument clair ici; un Helm Chart _n'est pas intrinsèquement lié à une version d'application spécifique_ et ne contient pas l'artefact en cours de déploiement (c'est-à-dire l'image Docker). Il ne contient qu'une référence à celui-ci, et la valeur derrière cette référence peut même changer (c'est-à-dire que vous pouvez pousser vers la même balise Docker, si vous le souhaitez). Donc, quoi qu'il en soit, un Helm Chart n'est pas une version packagée d'une application, et il n'est pas non plus strictement lié à une version spécifique de l'application.

Vous n'avez qu'à aller voir le repo des graphiques stables pour un exemple. Combien d'applications vous permettent de remplacer l'image utilisée via des valeurs ? (Beaucoup_)

Alors qu'est-ce que le Helm sinon un gestionnaire de paquets pour K8 ? Quelle est la différence que vous voyez?

C'est un outil qui permet de créer des modèles de manifeste Kubernetes, de les distribuer et de les installer facilement. La clé ici est que, c'est tout ce que Helm traite - les manifestes Kubernetes.

Tout cela revient à mon point principal - si ces manifestes changent, ou si le modèle doit changer pour ces manifestes pour une raison quelconque, alors c'est à ce moment-là qu'un Helm Chart doit vraiment être modifié.

La principale complication que je vois est qu'il y a 2 cas d'utilisation :

• Déploiement d'applications tierces.
• Déploiement d'applications propriétaires.

Dans le cas d'applications tierces, en tant que consommateur de Helm, il est souhaitable qu'un Helm Chart soit publié avec chaque nouvelle version d'application. Une différence clé ici réside dans la fréquence des versions. Il est probable qu'un graphique Helm tiers pour quelque chose comme MySQL ou autre ne changera pas plusieurs fois par jour. Dans ce cas, vous ne voulez pas non plus utiliser accidentellement une ancienne version d'un graphique avec une nouvelle version du logiciel - une erreur qui est beaucoup plus facile à commettre avec un logiciel et des graphiques que vous n'avez pas écrits vous-même.

Dans le cas d'applications propriétaires, vous pouvez disposer d'une méthode standard de déploiement d'une classe d'applications. Chez Icelolly par exemple, nous écrivons et déployons nos services Go à peu près de la même manière. À cette fin, nous sommes actuellement en mesure d'utiliser un seul graphique pour tous nos services Go déployés dans Kubernetes (nous utilisons actuellement la solution helm package contournement

Juste sur cette note ; notre graphique go-service été mis à jour pour la dernière fois il y a environ un mois. Pendant ce temps, nous avons probablement eu des dizaines à des centaines de déploiements - le tout sans que ce graphique change.

Dans un cas, vous voulez juste de la simplicité. Dans l'autre cas, vous voulez du contrôle et de la facilité de gestion.

Dans ce cas, vous perdrez le couplage des manifestes d'infrastructure d'application et de la version de l'application. Depuis, changer la balise d'image ne déclenchera pas une nouvelle mise à niveau de la barre (corrigez-moi si les gars de Flux le font autrement). Dans ce cas, vous aurez Helm comme modèle de configuration. Dans ce cas, vous n'avez pas du tout besoin de --app-version.

Flux modifiera en fait les valeurs qu'il utilise pour mettre à niveau le graphique, puis exécutera la mise à niveau avec la nouvelle valeur d'image. Votre point sur la perte du couplage des manifestes d'infrastructure et de la version de l'application est toujours valable. Le point que je soutiens est qu'il est en fait souhaitable que ce soit le cas dans certains cas d'utilisation. Vous avez raison cependant, dans ce cas d'utilisation, je n'ai pas besoin de --app-version , il ne serait pas utilisé car il n'existe pas actuellement. Si c'était le cas, peut-être que Flux pourrait l'utiliser. Dans ce cas, ce serait vraiment utile.

helm list est une commande utile. Pouvoir voir quelles versions d'applications sont déployées est en effet toujours utile. Pour nos applications actuellement installées via Helm avec l'approche helm package , nous définissons uniquement la version de l'application (via --app-version sur helm package ) de sorte que la sortie de helm list soit utile. C'est pourquoi si nous pouvions le définir sur helm install|upgrade ce serait simplement plus simple pour nous. Nous n'aurions pas besoin de récupérer le graphique et de le reconditionner juste pour changer la version.

En fait, helm list et la gestion des rollbacks sont probablement les seules raisons pour lesquelles nous utilisons Helm pour les logiciels propriétaires.

Votre description ici pour les packages .deb et .msi manque un composant clé - la chose réelle qui est en cours d'installation.

"Installer" est un processus de configuration des installations nécessaires (dossiers, configurations, binaires, récupération de base de données, actualisation/migration des données) sur la plate-forme cible.

deb gère tout cela. Il en va de même pour le package Helm. Que voulez-vous dire par paquet Helm n'est pas « réellement installé » ?

Si vous allez regarder le contenu d'un fichier .deb, vous trouverez le logiciel construit - LE logiciel qui va être installé.

Faux. Parfois, vous trouverez le logiciel lui-même. Parfois, vous trouverez des logiciels. Parfois, vous ne trouverez rien d'autre qu'un ensemble de scripts pour récupérer un tel logiciel. Donc, le point clé ici - cela n'a pas d'importance , puisque Linux et K8 sont des plates -

Brew est en fait beaucoup plus similaire à Helm actuellement, car il ne s'agit que d'instructions sur la façon dont il doit être installé et où la source / le package doit être téléchargé.

Exactement. Essayez-vous de me convaincre que Brew n'est pas un gestionnaire de paquets ?

Pour être absolument clair ici; un Helm Chart _n'est pas intrinsèquement lié à une version d'application spécifique ...
Combien d'applications vous permettent de remplacer l'image utilisée via des valeurs ? (Beaucoup)

Tu as tout à fait raison. Helm ne pourrait être qu'un moteur de templates pratique pour les templates k8s. L'existence d'un tel logiciel ne me pose aucun problème : cela aide un peu, ne changera pas les pratiques de livraison modernes.

Le problème est que Helm est plus qu'un moteur de modélisation. C'est un gestionnaire d'emballage, avec tous les avantages et inconvénients. Et dans l'écosystème où le gestionnaire de packages existe, il est déconseillé de faire gérer quelque chose par un autre package. Pire - travailler sans gestionnaire de paquets.

Je vois les raisons de la création de la version de l'application comme argument de package pour ces packages. Et je vois des raisons pour vous et vous tous de ne pas faire de colis. Le problème est qu'elle est obsolète, complexe et plus difficile à gérer. Chose amusante, le coût est faible, mais gagnez-le génial.

Le point que je soutiens est qu'il est en fait souhaitable que ce soit le cas dans certains cas d'utilisation.

Oui, c'est le point central : est-ce souhaitable pour n'importe quel produit ?

Votre argument est que Helm Chart change rarement, alors pourquoi devrions-nous le regrouper à chaque version. Je suis d'accord avec toi, c'est superflu. Mais de toute façon, nous empaquetons toujours d'anciens fichiers source, d'anciens side-cars (si Helm se compose de plusieurs applications), d'anciennes configurations, l'ancien Dockerfile.

Donc, la question est, si nous empaquetons l'ensemble du graphique en tant qu'artefact, sur chaque build, quel est le gain ? Pour Dockerfile c'est une évidence (mais c'est sûr que ce n'était pas évident quand la conteneurisation est apparue sur le marché). Pour les fichiers sources aussi.

À l'époque, nous avions le mécanisme de livraison le plus clair possible : téléchargez uniquement les fichiers modifiés via FTP. Maintenant, nous avons tellement de choses. Nous devons décider ce qui est bon, pourquoi c'est bon, qui doit l'utiliser. Je ne suis pas sûr que je serais content que Helm traite les deux approches en même temps - trop complexe.

Déploiement d'applications tierces.

Je serais tellement heureux si je pouvais installer n'importe quelle version PSQL/MySQL en utilisant uniquement Helm chart. Il serait tellement plus facile de maintenir des projets hérités, d'introduire des infrastructures pour les débutants. Il est encore plus facile d'être averti des mises à jour des graphiques. Pourquoi avons-nous autant de fichiers tar.gz pour chaque version des binaires, mais ne pouvons-nous pas avoir le même ensemble de fichiers tar.gz pour les packages Helm ?

@iorlas Je viens de lire ceci et le PR rejeté et vous faites de très bons points. Vous m'avez convaincu que je dois commencer à regrouper mes graphiques de barre comme un autre artefact de ma version/version.

Mais je voudrais mentionner que je ne savais même pas que helm avait une commande de package et je suppose que je ne suis pas seul. C'est probablement parce qu'il est si facile d'installer un graphique à partir du répertoire source, mais aussi la documentation ne vend pas vraiment le concept ni même l'explique en détail.

La commande package est évidemment documentée mais il n'y a que quelques mentions très générales de packages dans le guide de démarrage rapide , en fait, le mot package apparaît beaucoup dans le démarrage rapide mais il parle principalement de la façon d'installer Helm et les différents packages OS . L'emballage n'est pas non plus mentionné dans les meilleures pratiques et je pense que saisir ce qu'est l'emballage et pourquoi il est utile devrait y être inclus. J'ai également vérifié les documents v3 qui ont une structure légèrement différente mais semblent également être minces en suggérant aux utilisateurs de regrouper leurs graphiques.

Normalement, j'aimerais soumettre un PR et pas seulement avoir l'air de me plaindre de quelque chose, mais je ne suis pas sûr de ce qui se passe avec les modifications de la documentation 3.0.

@jonstelly Il y a certainement une lacune dans la documentation. Même moi, je pensais au début que --app-version est bon, mais ensuite, il ne pouvait tout simplement pas manquer sans raison.

Les docs ont certainement besoin de clarification et d'introduction aux problèmes courants. Ensuite, introduction au cycle de développement de Helm. Mais je crois que l'équipe est occupée sur la 3ème version. Et je suis trop occupé en ce moment aussi :(

"Installer" est un processus de configuration des installations nécessaires (dossiers, configurations, binaires, récupération de base de données, actualisation/migration des données) sur la plate-forme cible.

deb gère tout cela. Il en va de même pour le package Helm. Que voulez-vous dire par paquet Helm n'est pas « réellement installé » ?

Je ne veux pas dire qu'un Helm Chart lui-même n'est pas installé - tout ce que je dis, c'est que le Helm Chart ne contient pas l'application réelle que vous déployez. Une image Docker n'est pas emballée dans un Helm Chart. Il est extrait par Kubernetes d'une source externe.

Faux. Parfois, vous trouverez le logiciel lui-même. Parfois, vous trouverez des logiciels. Parfois, vous ne trouverez rien d'autre qu'un ensemble de scripts pour récupérer un tel logiciel. Donc, le point clé ici - cela n'a pas d'importance, puisque Linux et K8 sont des plates-formes pour héberger une application donnée, acceptant un format d'application universel. Et les noms d'images, les paramètres de configuration - sont les éléments du package.

Pour autant que je sache, en fait, vous vous trompez ici. Un fichier .deb est une archive AR. Vous pouvez l'extraire et regarder le contenu, et finalement ce sont des métadonnées et des fichiers. .deb fichiers .deb contient un script pour aller chercher le logiciel, cela signifie que c'est le script qui est installé par le fichier .deb , pas le logiciel lui-même. C'est comme installer un installateur.

Si vous avez un exemple de logiciel Linux emballé dans un .deb où le .deb va et télécharge le logiciel à installer dans le cadre du processus d'installation du fichier .deb , alors j'aimerais vraiment le voir - car c'est quelque chose que je n'ai littéralement jamais rencontré auparavant depuis de nombreuses années d'utilisation de Linux.

Exactement. Essayez-vous de me convaincre que Brew n'est pas un gestionnaire de paquets ?

Non. Tout ce que je dis, c'est que, comme Helm, les scripts fournis pour installer le logiciel via Brew ne sont que des scripts. Les applications sont créées, empaquetées et distribuées séparément et extraites par ces scripts. Cela ne fait pas de Brew un gestionnaire de packages moins, tout comme ce que je viens de dire ne fait pas Helm moins un gestionnaire de packages Kubernetes. Ce n'est pas le sujet de ce problème cependant, nous ne discutons pas si Helm est ou n'est pas un gestionnaire de packages, nous essayons de décider si un drapeau --app-version doit être ajouté à helm install|upgrade pour faciliter un cas d'utilisation commun.

Je vois les raisons de la création de la version de l'application comme argument de package pour ces packages. Et je vois des raisons pour vous et vous tous de ne pas faire de colis. Le problème est qu'elle est obsolète, complexe et plus difficile à gérer. Chose amusante, le coût est faible, mais gagnez-le génial.

Désolé, je ne comprends pas bien ce que vous entendez par là. Qu'est-ce qui est obsolète/complexe/plus difficile à gérer ?

Donc, la question est, si nous empaquetons l'ensemble du graphique en tant qu'artefact, sur chaque build, quel est le gain ? Pour Dockerfile c'est une évidence (mais c'est sûr que ce n'était pas évident quand la conteneurisation est apparue sur le marché). Pour les fichiers sources aussi.

Eh bien, encore une fois, la différence est fondamentalement que toutes ces choses que vous avez mentionnées sont intrinsèquement liées. Vous avez besoin de tout le code source pour exécuter l'application - pas seulement de ce qui a changé. Vous n'empaquetez pas le Dockerfile, donc vous ne savez pas de quoi il s'agit - mais vous utiliserez souvent le même Dockerfile sans le modifier pour créer de nouvelles versions d'images (je veux dire, pourquoi s'embêter avec l'automatisation si vous deviez changer quelque chose manuellement chaque temps, non ?). Avec tout ce genre de choses, vous créez quelque chose qui encapsule tout ce dont vous avez besoin, afin qu'il puisse être déployé de manière isolée. Ainsi, vous pouvez faire des choses comme faire tourner un nouveau nœud et le déployer de la même manière que vous le feriez pour un nœud existant, etc.

Comme vous le savez sûrement déjà, il y a beaucoup d'avantages à utiliser l'ancien téléchargement via FTP.

Quoi qu'il en soit, tout est dit en passant. Je pense qu'en fin de compte, comme je l'ai déjà mentionné, à mon avis, tout cela se résume à ; les mainteneurs de Helm veulent-ils activer cet autre cas d'utilisation, ou rendre plus difficile pour les gens de l'utiliser de cette façon ? En fin de compte, ce n'est pas _vraiment_ une énorme différence de toute façon. Pour moi, ce serait bien si je ne pouvais pas avoir à packager notre organigramme interne, qui change rarement, à chaque build juste pour définir une version d'application, qui encore une fois n'est utilisé que pour afficher la version actuelle dans une liste. Pour les applications propriétaires, je vais être honnête, je me suis demandé si Helm était la bonne approche de toute façon.

Une image Docker n'est pas emballée dans un graphique Helm

En fait, j'aimerais qu'il en soit ainsi. Mais ce n'est pas maintenant. Ma vision est que K8s sera/devrait être une plate-forme qui incorporera Helm (il n'y aura donc pas de Helm) en tant qu'API pour installer des packages : vous devrez emballer vos fichiers dans l'archive et l'installer. Retour à la simplicité des fichiers deb, mais avec une isolation appropriée et des ressources k8s en tant que citoyens de première classe.

Un fichier .deb est une archive AR
Vous pouvez l'extraire et regarder le contenu
et finalement ce sont des métadonnées
et quelques fichiers

Comme... un pack Helm !

Si vous avez... un .deb où le .deb va et télécharge le logiciel à installer dans le cadre du processus d'installation du fichier .deb...
C'est comme installer un installateur. ...

Oui, ce serait comme un installateur qui a un installateur à l'intérieur. Drôle, non? J'utiliserais un artefact si c'est possible , s'il suffirait de configurer l'instance de l'application. Mais nous avons différents logiciels, différentes sources de vérité, parfois c'est même pratique d'avoir plusieurs sources.

• Brew a YAML en tant que package, mais récupère les binaires du stockage distant
• Emerge (gentoo) a ebuild comme définition, qui télécharge même les clones git

Debian essaie de tout empaqueter à l'intérieur. Et c'est la bonne chose à faire, si possible. Mais pour prouver mon point, les métapaquets feront l'affaire. Avez-vous entendu parler de ce? C'est un package qui installe d'autres packages. N'est-ce pas un paquet ?

Mais s'il vous plaît, ne manquez pas l'essentiel : ce n'est pas grave ! Même un paquet vide, qui n'a qu'une référence à l'intérieur, est un paquet. Peut-être accepteriez-vous un autre terme, installateur ?

Je dis que, comme Helm, les scripts fournis pour installer le logiciel via Brew ne sont que cela - des scripts
Les applications sont construites, empaquetées et distribuées séparément et extraites par ces scripts

Et nous avons tous le même pipeline - pour créer une image Docker.

nous essayons de décider si un indicateur --app-version doit être ajouté à helm install|upgrade pour faciliter un cas d'utilisation courant.

C'est une clé. Mais comment décider ? Nous devons nous poser deux questions :

• C'est possible? Oui
• Est-ce la bonne chose à faire ? Oui? Non?

S'il y a des gens qui font quelque chose, cela signifie-t-il que c'est une bonne chose ? Pour avancer, il faut tout remettre en question.

Désolé, je ne comprends pas bien ce que vous entendez par là. Qu'est-ce qui est obsolète/complexe/plus difficile à gérer ?

laissez projeter sur Brew, puisque Brew est très proche du Helm et déjà largement utilisé avec succès. Vous pouvez projeter sur Gentroo Ebuilds ou deb, l'image ne changera pas.

• Dépassé. À quand remonte la dernière fois que vous avez dû installer MySQL/PSQL manuellement ? Pourquoi nous en sommes-nous éloignés ? Ces raisons, bourgeon.
• Complexe. C'est l'un des « pourquoi » : vous devez configurer l'infrastructure de manière indépendante, vous devez savoir laquelle fonctionne le mieux avec quelles versions de logiciel. Parfois, vous devrez personnaliser l'infrastructure pour exécuter certaines versions du logiciel. Pourquoi s'embêter? Pourquoi ne déléguerez-vous pas toute la question ?
• Plus difficile à gérer. Vous devrez gérer à la fois les versions d'infrastructure et d'application alors que vous ne pourriez avoir qu'un seul artefact. Pourquoi vous compliquer la vie ?

Désolé, un peu paresseux en ce moment pour décrire tous les cas d'utilisation, comme des restaurations nettes, des mises à niveau gracieuses, de toute façon ce sont les principaux bonus.

Eh bien, encore une fois, la différence est fondamentalement que toutes ces choses que vous avez mentionnées sont intrinsèquement liées.

Pas toujours. Par exemple, l'image docker pourrait avoir SSR BE et une référence à CDN.

Dockerfile, donc je ne sais pas de quoi il s'agit - mais vous utiliserez souvent le même Dockerfile sans le modifier pour créer de nouvelles versions d'images (je veux dire, pourquoi s'embêter avec l'automatisation si vous deviez changer quelque chose manuellement à chaque fois, n'est-ce pas ?).

C'est le but. Même lorsque Dockerfile n'est pas modifié, vous créez une nouvelle image. Si votre code source n'est pas modifié, mais que Dockerfile l'est, vous créez une nouvelle image. Donc, en bref, Dockerfile est aussi un package. Idem pour Helm. Ne pensez-vous pas?

Avec tout ce genre de choses, vous créez quelque chose qui encapsule tout ce dont vous avez besoin, afin qu'il puisse être déployé de manière isolée. Ainsi, vous pouvez faire des choses comme faire tourner un nouveau nœud et le déployer de la même manière que vous le feriez pour un nœud existant, etc.

Mais il s'avère que l'image docker n'est pas suffisante pour exécuter une application. Nous avons besoin d'une instance de configuration, nous avons besoin de définitions de service. Pourquoi ne pas tout emballer ?

En fin de compte, ce n'est pas vraiment une énorme différence de toute façon.

Je crois, ça l'est. Ce n'est peut-être pas un gros problème dans la base de code, mais cela fera stagner l'évolution de la conteneurisation.

Une image Docker n'est pas emballée dans un graphique Helm

L'image elle-même n'est pas emballée, mais la référence (lire comme: broche) l'est. Bien sûr, nous pouvons être pédants et nous demander si l'image littérale de taille variable (de Mo à Go) est incluse dans l'artefact de helm package (spoiler : ce n'est pas le cas), mais l'essence de la déclaration "Une version donnée du code d'une application est incluse dans un package helm" est toujours fondamentalement correcte. Que vous vouliez ou non vous laisser emporter par le comment n'a pas d'importance.

Pour revenir au pays des exemples, disons que vous avez une application que vous avez versionnée en interne en tant que 1.9.9 s'exécutant sur un graphique versionné à 1.2.5 . Pour qu'il n'y ait pas de confusion, l'image Docker sha pour le conteneur d'application est fakeshaA .

Votre équipe décide que dans la version 2.0.0 de votre application, il y aura une version du système de fichiers local d'un fichier que vous deviez référencer sur HTTP. La raison en est sans importance, mais la conséquence pour vous est assez grave. Vous avez maintenant besoin d'un pv et d'un pvc pour vos déploiements afin que ces fichiers désormais locaux ne soient pas perdus entre les mises à niveau. Voyant le besoin, vous allez de l'avant et mettez à jour votre graphique Helm pour avoir ces pv et pvc afin que le passage à 2.0.0 ne soit pas super perturbateur.

Avant de modifier le graphique, vous avez Artifact A reliant la version d'application 1.9.9 à la version d'infrastructure 1.2.5 . Maintenant vous changez le graphique... _votre Helm Chart est maintenant v. 1.3.0 _ et vous allez produire un artefact reliant 1.9.9 à la version d'infrastructure 1.3.0 . Nous appellerons cela Artifact B

Lorsque le déploiement de code pour 2.0.0 en ligne avec l'image Docker sha fakeShaB , vous créerez un autre artefact liant 2.0.0 à la version infra 1.3.0 . C'est Artifact C

Disons maintenant qu'il s'avère qu'il y a un problème que vous ne comprenez pas entièrement avec la version 2.0.0 et que vous devez revenir en arrière. Vous revenez en arrière en utilisant Artifact B ... mais cela ne résout pas le problème, vous revenez donc à Artifact A et le problème est résolu.

Le seul problème que vous rencontrez est de savoir si le registre Docker auquel vos artefacts font référence a toujours l'image référencée dans ces artefacts.

Quoi qu'il en soit, vous avez toujours un lien entre une version d'une application et une version d'infrastructure . C'est le but de Helm. Affirmer le contraire est une folie.

@iorlas :

Laissons de côté les comparaisons .deb . Je pense que c'est juste que nous nous laissons distraire.

Pas toujours. Par exemple, l'image docker pourrait avoir SSR BE et une référence à CDN.

C'est très vrai. Plus à ce sujet plus tard cependant.

C'est le but. Même lorsque Dockerfile n'est pas modifié, vous créez une nouvelle image. Si votre code source n'est pas modifié, mais que Dockerfile l'est, vous créez une nouvelle image. Donc, en bref, Dockerfile est aussi un package. Idem pour Helm. Ne pensez-vous pas?

Vous le faites, mais c'est parce que le produit à la fin de ce processus de construction (c'est-à-dire une image Docker) dépend à la fois du fichier Docker et de ce que vous y mettez. Une image ne peut pas exister sans ces deux composants.

D'un autre côté, un Helm Chart peut exister avant même qu'une application ne soit construite - littéralement avant qu'une seule ligne de code ne soit écrite. Vous pourriez en construire un imaginaire qui ne s'installerait pas - mais néanmoins, le Helm Chart pourrait exister entièrement sans rien d'autre. Comme je l'ai dit, ce serait inutile, mais j'essaie juste d'illustrer mon point selon lequel ils ne sont pas du tout liés.

Mon point ici, et comment cela est lié à ce problème particulier, c'est simplement que les graphiques Helm ne sont pas toujours intrinsèquement liés aux applications déployées par le graphique. Je ne pense pas que ce soit une affirmation audacieuse, cela arrive - c'est déjà un fait. Je le fais en ce moment avec des applications de production, tout comme d'autres qui ont commenté ce problème. Donc, comme je l'ai déjà dit, tout cela se résume à ; les mainteneurs de Helm veulent-ils ou non activer ce cas d'utilisation - il n'y a rien d'autre à cela.

Mais il s'avère que l'image docker n'est pas suffisante pour exécuter une application. Nous avons besoin d'une instance de configuration, nous avons besoin de définitions de service. Pourquoi ne pas tout emballer ?

En fait, j'aimerais qu'il en soit ainsi. Mais ce n'est pas maintenant.

Si tel était le cas, et qu'un Helm Chart a en fait empaqueté tout ce qu'il a déployé (vous avez mentionné le CDN plus tôt, mais vous ne le déployez pas sur Kubernetes à ce moment-là, donc il n'irait même pas dans votre graphique), alors je pense que cette conversation n'aurait pas lieu. Votre Helm Chart _serait_ intrinsèquement lié à la version de l'application en cours de déploiement - tout comme la création d'une image Docker. Pour créer un diagramme de barre dans ce scénario , vous seriez obligé de reconstruire lorsque vos changements d'application, à quel point il ne fait aucun doute. Vous ne pourriez pas utiliser Helm comme je l'utilise aujourd'hui - ce serait beaucoup plus clair de cette façon.

Ce n'est pas la réalité cependant. Ce n'est pas comme ça que Helm fonctionne, et je ne sais pas si ça finira jamais par être vraiment l'un ou l'autre. Mais ne jamais dire jamais, n'est-ce pas ?

@jrkarnes :

L'image elle-même n'est pas emballée, mais la référence (lire comme: broche) l'est.

Bien sûr, mais un cas d'utilisation courant consiste à utiliser des valeurs pour remplacer cette valeur. Je l'ai utilisé avec des graphiques tiers et propriétaires. Ce ne serait pas une option si ce n'était pas quelque chose que les gens utilisaient.

Bien sûr, nous pouvons être pédants et nous demander si l'image littérale de taille variable (de Mo à Go) est incluse dans l'artefact du package helm (spoiler : ce n'est pas le cas),

Je ne pense pas que nous soyons pédants à propos de quoi que ce soit - comme vous l'avez déjà souligné, il serait factuellement incorrect de dire que l'image Docker est emballée dans Helm Chart "construit".

"Une version donnée du code d'une application est incluse dans un package helm" est toujours fondamentalement correct.

Mais pas vraiment, car mon premier point serait contre. Vous pouvez modifier ce qui est déployé. Enfer, vous pouvez modifier la plupart des graphiques pour exécuter l'image hello-world si vous le souhaitez. Ce serait inutile, mais cela prouve bien mon point - le Helm Chart n'est pas lié à votre application. Il y a une _attente_ que vous l'utiliserez avec la bonne image, et probablement par défaut, cela fera l'affaire, mais ce n'est certainement pas _nécessaire_ - et en _aucune façon_ le code de l'application n'est inclus dans un graphique Helm, emballé autrement autrement.

Retour au pays des exemples, [...] et le problème est résolu.

Vous avez donné l'impression que cela n'est pas possible sans utiliser Helm de la manière apparemment prévue actuellement. Mais en réalité, vous ne pouvez avoir que 2 versions de la charte (c'est-à-dire vos deux versions d'infrastructure), et 3 versions de votre application. Si vous souhaitez revenir en arrière, faites-le, vous pouvez choisir assez facilement le graphique et l'image que vous souhaitez déployer. Exécutez Helm avec votre graphique, définissez vos valeurs en conséquence pour l'image et vous êtes prêt.

Quoi qu'il en soit, vous avez toujours un lien entre une version d'une application et une version de l'infrastructure. C'est le but de Helm. Affirmer le contraire est une folie.

Je pense que discuter (idéalement discuter) de la façon dont les choses pourraient changer conduit souvent à améliorer les choses. Je ne pense pas que le "but" de Helm soit de lier une version Chart et une application. Je pense que son objectif est de rendre plus facile et plus sûr le déploiement d'applications dans un cluster Kubernetes, tout en gardant vos manifestes Kubernetes SECS et réutilisables. Nulle part là-dedans vous n'avez besoin d'un graphique et d'une version d'application pour être strictement liés (comme dans la réalité en ce moment, vous n'avez pas besoin qu'ils le soient).

Encore une fois, comme je l'ai dit à @iorlas , la question est de savoir si Helm doit s'adapter ? Quelle est la raison pour laquelle ce cas d'utilisation n'est pas activé ? Si la raison est simplement "parce que ce n'est pas le cas actuellement", alors c'est une assez mauvaise raison si vous me demandez. Jusqu'à présent, aucune de ces discussions ne semble avoir répondu à cette question.

... le produit à la fin de ce processus de construction (c'est-à-dire une image Docker) dépend à la fois du Dockerfile et de ce que vous y mettez. ... Une image ne peut exister sans ces deux composants.

Donc... Le package Helm a besoin de la version Chart et de l'application (= image Docker) et ne peut pas exister sans elle.

un Helm Chart peut exister avant même qu'une application ne soit construite - littéralement avant qu'une seule ligne de code ne soit écrite. ... le Helm Chart pourrait exister entièrement sans rien d'autre. Comme je l'ai dit, ce serait inutile

Ce qui est amusant, c'est que sur un projet, nous utilisions des images docker de stub pour créer une architecture prototype. Nous avons littéralement utilisé Charts sans écrire une seule ligne de code. En outre, il est toujours possible d'avoir un graphique composé uniquement de sous-graphiques.

Donc, mon hypothèse est la suivante : le package Helm est presque inutile sans image Docker. L'image Docker est presque inutile sans code source. La différence est un niveau d'abstraction. Les deux choses sont des objets de type package .

mais j'essaie juste d'illustrer mon point selon lequel ils ne sont pas du tout liés.

Ouais, ouais ! C'est vraiment bien, nous avons des personnes prêtes à discuter de tout dans les détails. Sans vous, sans projections et affirmations, nous ne ferons pas vivre un futur moût

Je ne pense pas que ce soit une affirmation audacieuse, cela arrive - c'est déjà un fait. ... Donc, comme je l'ai déjà dit, tout cela se résume à ; les mainteneurs de Helm veulent-ils ou non activer ce cas d'utilisation - il n'y a rien d'autre à cela.

Fait. Afin de faire et d'accepter un tel changement, il doit être évalué : est-ce la bonne chose à faire ?

Laissez-moi vous raconter une histoire. Martini était un excellent framework Web largement utilisé. La raison n'était pas le manque d'heures dans lesquelles investir, la raison n'était pas quelques manigances avec les licences. Donc, la seule façon de rendre l'avenir plus radieux était de déprécier tout le framework, de mettre certains gars en colère, de laisser certains projets orphelins, de forcer certains gars à réévaluer ce qu'ils font.

Donc, je ne suis pas contre cette approche. Je vois comment ça peut vivre (voir ma proposition avec helm run ). Mais alors que nous avons une chance d'intervenir et, éventuellement, de réparer l'ensemble de l'industrie alors qu'il n'est pas trop tard, j'évaluerais chaque utilisation, discuterais des inconvénients et des problèmes.

Pour créer un Helm Chart dans ce scénario, vous devrez le reconstruire lorsque votre application change

Ouais. Même maintenant, cela pourrait être un cas. Nous avons un pipeline où au lieu de push nous faisons save / load de l'image docker. Et ça marche plutôt bien. Je n'en ai pas envie en ce moment, mais fondamentalement, c'est beaucoup plus propre. Le problème est que K8s aura toujours besoin d'un registre docker distant en tant que bus pour transférer l'image "starter" - docker.

Concentrons-nous sur les gars

Votre Helm Chart serait intrinsèquement lié à la version de l'application en cours de déploiement, tout comme la création d'une image Docker.

C'est une différence clé ici. Et @seeruk a réussi . Et nous pouvons nous concentrer dessus. Permettez-moi de paraphraser les faits :

1. Docker Image n'est pas lié au package Helm. Uniquement référence à celui-ci.
2. Cela donne la possibilité de libérer ces chemins de manière indépendante.

Questions clés:

1. Quels sont les risques d'une approche indépendante ? (c'est-à-dire si certains devops l'utiliseraient, quels arguments nous dirons contre)
2. Comment l'approche de l'emballage le résout?
3. Quel est le coût?
4. Comment voyons-nous un avenir de conteneurisation dans cette question particulière ?

@seeruk :

Encore une fois, comme je l'ai dit à @iorlas , la question est de savoir si Helm doit s'adapter ? Quelle est la raison pour laquelle ce cas d'utilisation n'est pas activé ? Si la raison est simplement "parce que ce n'est pas le cas actuellement", alors c'est une assez mauvaise raison si vous me demandez. Jusqu'à présent, aucune de ces discussions ne semble avoir répondu à cette question.

Vous apportez beaucoup de précisions et de points. Personnellement, je pense que Helm devrait s'adapter. CI/CD est l'avenir de la façon dont les logiciels seront construits, et honnêtement, avec des friandises comme --atomic helm devient déjà plus flexible en tant qu'outil de déploiement fiable. Cependant, ce problème est assez ancien, donc je pense que la fusion des relations publiques n'est pas "la prochaine étape" du processus.

La création d'un plugin, disons helm-ci-cd serait-elle faisable pour cette fonctionnalité particulière de --app-version ( @jrkarnes peut probablement parler à celui-ci en tant que contributeur aux relations publiques) ? Je pense que les besoins de la communauté concernant la sortie de Tiller n'ont été vraiment reconnus qu'après le démarrage de ce plugin. Il existe divers autres problèmes avec Helm qui sont facilement contournés et qui peuvent être d'autres bons candidats pour helm-ci-cd regardez la dualité install/ upgrade que nous CI/CD ppl avons déjà unifiée via l'emballage.

Même si le commutateur --app-version n'est pas une valeur ajoutée directe pour les utilisateurs finaux qui essaient d'installer une application k8s sans avoir à consulter les fichiers de modèle (qui, d'ailleurs, n'ont jamais réellement fonctionné pour moi en raison de la nécessité d'ajouter des politiques de réseau pour être conforme à mon infrastructure de travail k8s) l'utilisateur final obtient toujours plus de valeur parce que la personne qui a construit ce graphique a eu plus de facilité à le faire en raison des fonctionnalités helm ci/cd qui rendent la construction stable et un logiciel fiable plus facile.

Nous venons de lire Chart.yaml avec groovy, puis de définir la version de l'application et d'écraser le fichier pendant le temps de déploiement. Ensuite, effectuez la mise à niveau de la barre. Ce serait bien si ça faisait partie de la barre mais je ne compterais pas dessus.

Trouvé ceci via Google'ing. Même bateau, en fait.

Si verison: est la version du graphique, cela implique que cette version change lorsque les YAML du graphique changent. Étant donné qu'un graphique est un modèle avec des valeurs configurables, il est prudent de supposer que vous pouvez utiliser le graphique 1.3 pour déployer des applications de plusieurs versions, 1.2, 1.3, 1.6, 1.8, etc., sans modifier les fichiers YAML du graphique.

Vient maintenant en appVersion: codé en dur dans Chart.yaml -- vous obligeant à modifier un fichier graphique afin de mettre à jour (et de refléter) la version de l'application déployée.

Il y a certainement un besoin pour une option CLI --app-version nous pouvons utiliser dans les modèles de graphique pour référencer la version de l'_application_ afin de déployer différentes versions avec le même graphique version: 1.3.0 .

@seeruk

Je ne pense pas que le "but" de Helm soit de lier une version Chart et une application. Je pense que son objectif est de rendre plus facile et plus sûr le déploiement d'applications dans un cluster Kubernetes, tout en gardant vos manifestes Kubernetes SECS et réutilisables.

C'est notre point de discorde et je ne pense pas que l'un de nous convainc l'autre. Parfois, dans un cadre professionnel, il est acceptable d'avoir des divergences irréconciliables lorsqu'il s'agit d'une question d'opinion. Je ne suis certainement pas d'accord avec tout ce que Stallman dit et si nous devions entrer dans les tranchées sur tout ce sur quoi lui et moi ne sommes pas d'accord, nous mourrions avant d'atteindre un consensus.

Je l'ai dit plus haut dans la discussion et je pense qu'il vaut la peine de le répéter :

[...] Je suppose que helm ne déploie vraiment que des packages. Cela semble être la seule chose sémantiquement correcte que vous puissiez dire ; cependant, l'argument sur la façon dont ces paquets sont distribués semble être la cause première de ce débat dans la pratique. Plus précisément, « la mise à niveau ou le changement de version de l'application constitue-t-il un nouveau package ? »

Un graphique de barre de première partie (j'aime utiliser MySQL, je vais donc continuer à l'utiliser) sans configuration devrait installer une ressource dans un cluster tel que le créateur du graphique l'a décrit et l'a voulu . En regardant le graphique réel pour mysql, il y a deux propriétés qui sont configurables impliquant le moteur mysql réel :

• image (par défaut mysql )
• imageTag (par défaut 5.7.14 )

Ensuite, dans leur fichier Chart.yaml :

apiVersion: v1
name: mysql
version: 1.4.0
appVersion: 5.7.27

Notez que le appVersion et le imageTag par défaut ne correspondent pas . Si j'exécute helm list je vais obtenir un rapport indiquant que la "version de l'application" (lire ; version du moteur) est un état _qui ne reflète pas la version réelle de l'application installée dans le cluster_.

Nulle part là-dedans vous n'avez besoin d'un graphique et d'une version d'application pour être strictement liés (comme dans la réalité en ce moment, vous n'avez pas besoin qu'ils le soient).

C'est correct; et à mon avis, un défaut de conception.

Encore une fois, comme je l'ai dit à @iorlas , la question est de savoir si Helm doit s'adapter ?

Oui. J'aborderai quelques suggestions dans un instant.

@IRobL

La création d'un plugin, disons helm-ci-cd, serait-elle faisable pour cette fonctionnalité particulière --app-version ( @jrkarnes peut probablement parler à celui-ci en tant que contributeur aux relations publiques) ?

Vous répondez à votre propre question avec :

Même si le commutateur --app-version n'est pas une valeur ajoutée directe pour les utilisateurs finaux qui essaient d'installer une application k8s sans avoir à consulter les fichiers de modèle, l'utilisateur final obtient toujours plus de valeur parce que la personne qui construit ce graphique a eu plus de facilité à le faire en raison des fonctionnalités helm ci/cd qui facilitent la création de logiciels stables et fiables.

Si nous devons le faire en tant que plugin pour obtenir la fonction correcte, alors je recommanderais cette approche ; Cependant, je pense que cela résout le mauvais problème. Comme je l'ai dit plus tôt à @seeruk , je pense que le fait que le appVersion soit une propriété intrinsèque dans le fichier immuable Chart.yaml est un défaut de conception. appVersion est une propriété du image qui est installé dans le cluster via le graphique, et il est dérivé en quelque sorte de l'image référencée avec son tag .

En pensant à un plugin helm-ci , à quelles autres fonctionnalités ou compléments vous attendriez-vous ? Je ne pense pas que le simple fait de basculer les appVersion hors des propriétés immuables Chart.yaml soit une valeur ajoutée suffisante pour justifier d'être un plugin.

@IRobL et @seeruk ensemble :

Je pense que nos opinions divergentes viennent de l'utilisateur final de helm le plus courant. Si l'utilisateur final est censé être quelqu'un qui ne va pas faire beaucoup de configuration ou creuser dans des modèles, alors helm ls peut ne pas être particulièrement utile et le point est discutable.

Cependant... si vous utilisez helm comme outil administratif et assistant pour gérer un cluster OU si vous utilisez Helm dans un contexte CI/CD, alors le commutateur --appVersion finit par être beaucoup plus plus utile et donc un sujet de préoccupation (et de configuration),

Dans un monde parfait, je dirais que appVersion devrait être une propriété dérivée et provenir des métadonnées de l'image docker ; ce n'est pas possible pour la barre de faire, ergo, l'absence de conflit.

À ce que j'ai dit à propos de

Oui. Je vais aborder quelques suggestions dans un instant...
... en pensant à un plugin helm-ci , à quelles autres fonctionnalités ou compléments vous attendriez-vous ?

J'ai une liste personnelle qui pourrait être un bon point de départ :

• L'exécution de helm en mode CICD ne comparerait pas _seulement_ l'état des packages précédemment publiés avec ce qui est actuellement appliqué. . Au lieu de cela, chaque déploiement d'une version s'appliquerait pleinement à chaque modèle de manifeste lorsque upgrade est exécuté.
• helm-cicd devrait envelopper les commandes kubernetes de base. Je ne peux pas compter le nombre de fois où j'ai essayé d'exécuter helm describe ou helm logs .
• helm-cicd devrait me permettre de voir quels sont les résultats des commandes lorsqu'elles sont exécutées par un autre utilisateur. Si nous utilisons RBAC, j'aimerais voir ce qui se passe lorsqu'un utilisateur non autorisé tente de faire quelque chose.
• helm-cicd devrait être capable de décomposer un espace de noms en une collection de manifestes à éditer plus tard.
• helm-cicd devrait être capable de _transplanter_ une version dans un espace de noms.

Ce sont les plus gros... mais discuter d'un plugin helm-ci part entière n'entre pas dans le cadre de ce PR/issue (actuellement).

Je lis tout ce que vous tapez et j'apprécie le discours. J'attends vos réponses avec impatience.

Assez occupé sur mon temps en ce moment, mais je veux vous corriger sur quelques points. @jrkarnes

Je pense que faire de l'appVersion une propriété intrinsèque dans le fichier immuable Chart.yaml est un défaut de conception

Ce n'est pas. Quand quelque chose est fait de cette façon et pas d'une autre, il y a toujours une raison, même si elle est sauvage . Dans ce cas, c'est l'idéologie que je défends : un package = un build, chart = template pour les builds, package = app + infra.

Helm est conçu autour de cette idéologie, pour traiter les K8 comme un système d'exploitation et un package comme installateur/mise à jour pour votre application. Il a quelques problèmes, on a l'impression que c'est trop parfois, mais c'est certainement un avenir.

_Pourquoi je pense que c'est conçu comme ça ? Le même helm list est défini pour afficher les versions actuelles des packages installés._

D'accord, nous avons de nombreux graphiques (publics comme mysql et locaux, comme vous l'avez probablement) qui ne sont pas construits pour créer un package à chaque fois qu'une nouvelle version apparaît. Et j'admire ce besoin, car la migration vers une solution de haut niveau prend du temps. De plus, quelqu'un doit créer des packages et il serait difficile de convaincre les responsables de mysql de créer un package Helm pour chaque version.

Avec le graphique MySQL, il y a un problème supplémentaire. Vous avez raison, ce serait mieux de voir la version MySQL installée dans helm list , mais ce n'est qu'une partie de la version, car il y a aussi une balise Image, qui fait probablement partie de la version ici.

Encore une fois, comme je l'ai dit à @iorlas , la question est de savoir si Helm doit s'adapter ?
Oui. J'aborderai quelques suggestions dans un instant.

Encore une fois, il a été proposé d'ajouter helm run , ce que vous recherchez tous. Il est destiné à utiliser Chart comme package instantanément, permettant de fournir des versions d'applications et tout.

Dans un monde parfait, je soutiendrais que appVersion devrait être une propriété dérivée et provenir des métadonnées de l'image Docker ; ce n'est pas possible pour la barre de faire, ergo, l'absence de conflit.

Vous voyez l'image Docker comme un produit final, comme le dernier package, qui est la dernière source de vérité. Ce n'est pas. Lorsque vous n'avez rien d'autre qu'une image Docker, vous pouvez être amené à croire qu'il s'agit de votre logiciel. Lorsque vous écrivez un module dans votre code, vous êtes amené à croire que ce module est votre logiciel.

Le problème, c'est que non. C'est juste une partie, un artefact. Des petits aux gros produits, vous aurez de nombreux artefacts liés les uns aux autres. Parfois, vous passerez des versions dans un fichier docker dans le processus de construction, parfois vous aurez un ConfigMap, qui relie plusieurs artefacts. Et vous n'aurez pas un seul fichier docker qui aura tout.

J'ai une liste personnelle qui pourrait être un bon point de départ

Je crois que vous avez de nombreuses suggestions, mais cela ressemble plus à un fork Helm , plutôt à un plugin sauvage. Je dirais que cela n'a rien à voir avec CI de CD exclusivement. Je dirais de ne pas créer un tel fork/plugin, mais de discuter et de trouver des solutions appropriées. Personne n'a besoin de 3 fourches Helm, étant donné que la communauté actuelle n'est pas si grande en ce moment.

Attention, s'il vous plaît!

D'accord, nous avons beaucoup pensé ici et là. Je pense que le meilleur scénario serait d'avoir:

• Possibilité de changer la version de l'application, sans avoir besoin de créer d'abord des packages
• Possibilité de voir la version appropriée de l'application dans helm ls
• Autoriser n'importe quelle API (comme l'opérateur Helm) à spécifier/mettre à niveau la version de l'application sans état intermédiaire

Nous proposons deux approches :

1. helm install est créé pour installer un paquet. Il prend également en charge l'installation du graphique, mais il est limité. Simplifions helm install et laissons-le remplir son rôle - installer des packages. Deuxièmement, ajoutons helm run , dont l'intention est de fournir un flux simplifié : combinez helm package et helm run , fournissez les deux arguments de commandes, mais filtrez ceux qui n'ont aucun sens dans ce cas .
2. Ajoutez app-version dans helm install cmd. Cela gonflera cette API et masquera l'idée d'utiliser des packages, cela masquera (comme il le fait actuellement) l'idéologie d'utilisation de packages en tant qu'installateurs, ce qui est tout à fait logique au moins pour certains, sinon la plupart, des projets.

Pouvons-nous convenir que ces deux approches résoudront toutes les luttes que nous avons actuellement ?

Un plugin est une solution de contournement pour une fonctionnalité manquante que les développeurs principaux ne veulent pas prendre en charge ou n'ont pas le temps de le faire, donc je m'en fiche s'il s'agit d'un plugin.

Helm est conçu autour de cette idéologie, pour traiter les K8 comme un système d'exploitation et un package comme installateur/mise à jour pour votre application.

Ooh. Je comprends. Un helm chart [package] est censé être un "rpm" [per-say] pour Kubernetes. Ce n'est pas du tout l'impression que j'ai eue : helm utilise des graphiques pour déployer une application. Le graphique/package est l'application "formatée pour les k8".

Cela me convient. C'est logique - nous devons juste maintenant mettre à jour notre serveur de build pour augmenter l'appVersion lorsque nous construisons de nouveaux conteneurs :

• Conteneur de construction - balise "v1.2"
• Mettre à jour Chart.yaml - appVersion: "v1.2" --- Je vois qu'il y a même déjà une commande helm package --app-version .
• Tableau des packages : helm package --app-version v1.2 => package[chart]-v1.2.tgz (c'est-à-dire un "package[chart]-v1.2.rpm")
• Déployez le package à l'aide de serveurs de déploiement, helm install package[chart]-v1.2 (par exemple, apt install [email protected])

Maintenant, est-ce que je me trompe dans la compréhension de tout cela ? Si package-v1.2 n'est pas la v1.2 appVersion, pourquoi pas ? Ne serait-ce pas l'intention ? par exemple, rpm est la version de l'application, pas le package (graphique).

Éditer:

Si package-v1.2 n'est pas la v1.2 appVersion, pourquoi pas ? Ne serait-ce pas l'intention ?

Maintenant, je vois pourquoi les gens commentent Chart.version et Chart.appVersion étant à l'unisson. Les arguments peuvent aller dans les deux sens ici... une application avec une version stable de "graphique", vous vous attendriez à ce que package-v1.2 change ses numéros de version. Mais vous pouvez également affirmer que package-v1.2 serait le numéro de version de Chart - lorsque les fichiers yaml changent.

Comment gérez-vous une version stable de Chart (1.2), en se différenciant d'une version croissante de l'application (1.6) ? Est-ce que package-[version] sera de 1,2 ? ou 1,6 ? Supposons que vous déployiez une version 1.2 de Chart mais que l'appVersion ait changé lors de l'empaquetage : helm package --app-version 1.6 ?

➜  chart git:(master) ✗ helm package --app-version 1.5 nginx
Successfully packaged chart and saved it to: /Users/Documents/source/docker/nginx/chart/nginx-0.1.0.tgz

:(

.... Si confus.

Un helm chart [package] est censé être un "rpm" [per-say] pour Kubernetes

Exactement! Mais parfois, cela semble trop strict ou trop compliqué, c'est là qu'un raccourci est nécessaire.

Maintenant, est-ce que je me trompe dans la compréhension de tout cela ? Si package-v1.2 n'est pas la v1.2 appVersion, pourquoi pas ? Ne serait-ce pas l'intention ? par exemple, rpm est la version de l'application, pas le package (graphique).

C'est un problème pour une autre discussion, mais actuellement le package sera nommé d'après la version du graphique, pas la version de l'application. Je n'en connais pas la raison, je pense qu'il devrait en être autrement. Je pense que c'est une question historique, mais dans mon esprit, comme dans le vôtre, cela devrait être package-{app-version}.tgz .

Selon mes messages précédents, il y a 4 composants à la version :

• Graphique
• Application
• Paquet
• Libérer

C'est un casse-tête de versionner toutes ces choses de manière indépendante, mais c'est ainsi que cela fonctionne actuellement. À une exception près : le package est versionné après la version du graphique.

Si nous choisissons une idéologie d'empaquetage de l'application, la version de l'application aurait tout son sens, puisque le même processus produit à la fois l'application, l'image et le package. Ainsi, lorsque nous passerons à l'étape de livraison, il serait évident de savoir comment les fichiers sont appelés, quel fichier installer. À l'heure actuelle, nous devons coder en dur le nom du package dans les pipelines >_<

@iorlas

Vous voyez l'image Docker comme un produit final, comme le dernier package, qui est la dernière source de vérité. Ce n'est pas. Lorsque vous n'avez rien d'autre qu'une image Docker, vous pouvez être amené à croire qu'il s'agit de votre logiciel. Lorsque vous écrivez un module dans votre code, vous êtes amené à croire que ce module est votre logiciel.

J'ai pris quelques semaines pour réfléchir à cette affirmation et je suis à 100% d'accord avec vous. De plus, je comprends maintenant d'où vient notre différence d'opinions...

Je suis une philosophie de développement et de déploiement selon laquelle vous devriez construire un système à partir de petits composants qui font incroyablement bien une suite de choses (pensez à UNIX); cependant, les systèmes modernes peuvent traiter une "application" comme étant un regroupement de ces petits outils. Comment êtes-vous censé marquer la "version" d'une application lorsqu'elle dépend non seulement de l'artefact docker, mais également des autres sous-composants (qui peuvent également être des artefacts docker) ? Ce n'est pas une réponse si simple lorsque vous commencez à lancer ce type de couplage.

Répondre à cette question dépasse de loin le cadre de ce problème/demande. Pour revenir à la racine du problème, je voudrais faire une distinction entre install et run . Pour des raisons de sémantique, install ne devrait fonctionner que sur les packages, et run devrait "exécuter" helm tout au long du processus de génération de modèles et de leur application _sans maintenir l'état_.

Alors que nous devrions souvent utiliser helm template pour voir comment un graphique potentiel va se déployer, il est très utile de le regarder se produire vi-ca-vi run qui a un double objectif d'être une star dans les pipelines de développement (où l'on ne veut pas forcément garder un package car il n'a pas de valeur si la vélocité est très élevée).

Avec le graphique MySQL, il y a un problème supplémentaire. Vous avez raison, ce serait mieux de voir la version MySQL installée dans la liste helm, mais ce n'est qu'une partie de la version, car il y a aussi une balise Image, qui fait probablement partie de la version ici.

Comme je l'ai dit, dans un univers parfait, la version d'un objet installé serait introspectée. Cela me donne quand même une idée.

Si nous gardons à l'esprit ce que j'ai dit au début sur la façon dont les graphiques sont déployés, et si nous avions la possibilité d'étaler tous les sous-composants avec un indicateur sur helm describe ? Cela ne résout pas le besoin de spécifier la version de l'application, mais cela rend plus clair exactement ce qui est installé (ce qui fait partie de la force motrice derrière le fait de vouloir ajuster la version de l'application avec un indicateur).

J'ai lu tous les commentaires et je n'ai pas d'opinion pleinement qualifiée sur la question.

Je suis arrivé ici parce que mon entreprise gère un référentiel Helm privé et 90 % de nos graphiques sont principalement un déploiement qui a une spécification de conteneur. Dans ces cas, si nous pouvions utiliser appVersion pour lister la balise de l'image, nous éviterions de dupliquer une variable et nous pourrions voir cette version exécuter helm version .

Après avoir lu ce fil, il me semble que ce serait une commodité, bien que très agréable que j'utiliserais si jamais il était fusionné.

Comme demandé, je vais inclure ma dernière réponse du fil précédent pour que les autres puissent la voir

Hmm. C'est là que les choses commencent à entrer en conflit les unes avec les autres lorsque vous commencez à lier le appVersion à une balise Docker (une association logique). C'est là que nous avons des problèmes, c'est-à-dire le scénario de développement que j'ai mentionné ci-dessus. Étant donné que version doit être un SemVer, nous ne pouvons tout simplement pas utiliser les balises Docker en tant que Chart version .

Comment créer une différence de version visuelle pour les développeurs lorsque appVersion n'apparaît pas sur les graphiques ?

En raison de la façon dont k8s fonctionne avec ses applications : dans un monde de développement, il existe un moyen d'autoriser les versions de balises à tous les niveaux.

Il ne pouvait pas faire des choses comme SemVer en termes d'opérateurs ~ ou ^, car la version était purement ordonnée, sans sémantique.

Pourquoi pas? Nous le faisons tout le temps avec php composer . Nous pouvons utiliser SemVer ou nous pouvons utiliser des versions de chaînes qui sont simplement analysées ou ignorées dans le schéma de version, c'est-à-dire que si version n'est pas un numéro SemVer, ne l'incluez pas dans ~ et ^ correspondance de modèle.

Puisque vous citez mon commentaire sur #7299 , je vais clarifier "Ça ne pouvait pas" comme "Ça n'a pas été" (et peut-être pas encore).

Pour les packages .deb et .rpm, la chaîne de version est divisée de manières spécifiques (par des tirets), mais elles n'ont pas de signification sémantique telle que "Ceci est compatible avec l'API avec cela" et vous ne pouvez donc pas générer une expression comme "Donner me la dernière version compatible avec l'API" ou "Donnez-moi la dernière version avec une API inchangée", comme vous pouvez le faire avec SemVer.

Je me souviens que Debian et RedHat utilisaient des alias de paquet pour atteindre ces cas d'utilisation (et la compatibilité ABI) généralement basés sur les numéros de soversion. Cela a permis un comportement raisonnablement cohérent en utilisant uniquement des noms de packages et des comparaisons de commande uniquement.

Sur le sujet général, la façon dont nous utilisons les chartes Helm pour notre produit sert à emballer nos divers services. Les images Docker ne sont cependant qu'un simple artefact, et leur nommage est déterminé par la version du service, pour laquelle nous avons adopté SemVer car ils offrent des API.

Notre pipeline CI transforme les dépôts git du code et des scripts associés, et produit des graphiques Helm qui peuvent être installés et qui font référence aux images Docker. Les balises sur les images Docker ne sont pas intéressantes pour nos utilisateurs. Nous taguons ensuite avec le git SHA dont ils proviennent, puis nous remarquons les images utilisées dans une version. Le principal avantage du réétiquetage est que nous savons qu'il ne faut jamais les annuler, alors que nous pouvons annuler l'étiquetage des versions git-SHA après une courte période.

Je suis donc assez satisfait de la façon dont Helm fonctionne pour nous, car version contient la version exacte de notre logiciel, et appVersion contient la même chose mais sous forme de chaîne, et personne ne regarde jamais à notre repo Docker.

Je suis un peu moins satisfait de la façon dont les graphiques sont versionnés dans https://github.com/helm/charts/ , car c'est là que le graphique est versionné, pas le logiciel, ce qui conduit parfois à un graphique mineur (stable) version mises . Je pense que c'est une conséquence probable et difficile à éviter lorsque vous séparez les version d'un graphique de la version des éléments qu'il contient.

Nous avons un problème similaire avec le graphique stable/prometheus-operator , dans notre page interne "Bibliothèques et artefacts consommés en externe". Cela contient un tas de logiciels différents, donc la question « sur quelle version sommes-nous ? » et en particulier « Est-il sûr de mettre à niveau ? » sont beaucoup plus difficiles à répondre que pour Agones, qui versions de la même manière que nous.

@jrkarnes

Si nous gardons à l'esprit ce que j'ai dit au début sur la façon dont les cartes sont déployées, et si nous avions la possibilité de décrire tous les sous-composants avec un drapeau sur la barre ? Cela ne résout pas le besoin de spécifier la version de l'application, mais cela rend plus clair exactement ce qui est installé (ce qui fait partie de la force motrice derrière le fait de vouloir ajuster la version de l'application avec un indicateur).

J'aimerais vraiment voir ça. Il y a une demande de fonctionnalité connexe au #6932 par exemple.

Après avoir repris la discussion, l'idée que appVersion est liée aux métadonnées d'image Docker ne correspond certainement pas à notre cas d'utilisation, comme au moins certains de nos graphiques (ceux avec lesquels nos utilisateurs traitent principalement) le font ne contiennent pas d'images Docker, étant principalement des hôtes pour les ressources partagées (par exemple, des clés publiques JWT, values.yaml ) plus un requirements.yaml pour extraire d'autres graphiques.

l'idée que appVersion est liée aux métadonnées d'image Docker ne correspond certainement pas à notre cas d'utilisation, car au moins certains de nos graphiques

Je ne dis pas que c'était l'utilisation prévue. J'ai simplement déclaré que c'était une association logique. Vous utilisez toujours appVersion comme "conteneur logique" de vos yamls internes.

Je ne sais toujours pas en quoi le verrouillage de version sur SemVer présente des avantages. Est-ce que helm pourrait simplement analyser version (et appVersion ) et continuer à partir de là ?

Je suppose que mon point était que nous n'utilisons pas du tout appVersion , il n'est généralement pas présent dans notre Chart.yaml, et quand il est présent, il est identique à version .

L'avantage de verrouiller version sur SemVer est que vous pouvez utiliser les différents opérateurs SemVer dessus et l'analyser de manière fiable pour produire des commandes et des correspondances lors de l'installation.

Les systèmes d'empaquetage RPM et DEB ont la même chose, sauf que leurs systèmes de gestion de versions utilisent une syntaxe différente, mais sont toujours une syntaxe restreinte pour des raisons d'analyse sémantique. Ils ont également une sémantique différente dont ils se soucient.

Compte tenu de la façon dont le référentiel helm/charts a été exécuté, j'ai l'impression qu'un seul champ version avec une version de style DEB ou RPM aurait été un meilleur choix que SemVer plus une chaîne appVersion . Cependant, c'est un navire complètement différent, déjà navigué. Et ayant été à la fois un fournisseur en amont et un empaqueteur Debian dans ma jeunesse, j'apprécie de ne pas avoir à jongler entre « Lequel des numéros de version doit être remplacé ici ? » dans nos packages " version est la seule vérité".

Le problème avec "parfois c'est SemVer" est que SemVer ressemble beaucoup à quelque chose que vous pourriez écrire à la main, ou rencontrer ailleurs, comme une version de paquet Debian qui n'a pas d'époque, avec des résultats désastreux .

Salut. Il n'y a pas de nouvelles sur cette fonctionnalité.

Après avoir lu tous les commentaires, je vois que ce serait vraiment utile.

En effet, dans notre entreprise comme nous avons plusieurs applications qui utilisent les mêmes technologies et sont déployées de la même manière, nous avons une grille pour différentes applications pour éviter les duplications.
Nous emballons un nouveau graphique uniquement lorsqu'il y a des changements infra structurels.
Et ce n'est que lorsque nous mettons à niveau ou installons une version que nous appliquons des valeurs spécifiques comme balise, variables d'environnement...

Nous considérons que helm chart emballé est la couche d'abstraction représentant les ressources et la structure kubernetes attendues pour un type d'applications et ce n'est que lors du déploiement que nous disons "ok, je veux que ce type d'application soit déployé sur cet environnement avec ces valeurs spécifiques"

Comme la liste helm doit afficher les informations sur la version, nous devrions pouvoir voir la version de l'application déployée dans cette version.

J'ai laissé le commentaire dans un numéro similaire https://github.com/helm/helm/issues/7517
Pouvons-nous ajouter la possibilité de remplacer cela dans values.yaml ?
Ensuite, nous obtenons l'option de ligne de commande gratuitement --set

Si nous essayons d'utiliser helm pour n'importe quelle application, c'est absolument nul. Personne n'utilise la gestion des versions sémantique pour les applications de production.

Je suis d'accord. Nous sommes actuellement bloqués pour l'utilisation de Chart Museum pour des graphiques basés sur _application_ immuables. Version du graphique != version de l'application, ce qui nous empêche de publier via Chart Museum.

J'ai lu un tas (pas tous) de la discussion ci-dessus, donc désolé si je répète certains points / points de vue. J'essaie de proposer une réponse plus réfléchie.

J'aime voir appVersion quand je fais un helm ls et que passer conceptuellement de .Values.image.tag était un bon MAIS ne pas pouvoir le définir au moment du déploiement est un véritable obstacle et c'est quelque chose que j'ai eu pour revenir à.

Je suis fermement convaincu que (graphique) version est la version du graphique et appVersion est la balise docker. Dans notre processus CI, la balise docker est également une balise git.
Nous avons également plusieurs microservices et souhaitons que les choses restent aussi sèches que possible. Nous avons des graphiques génériques dans un référentiel de graphiques local car la grande majorité des applications java-springboot sont les mêmes. La plupart des applications Tomcat sont les mêmes (mais différentes de celles de Springboot). Rincer et répéter pour d'autres technologies. Nous avons ensuite des valeurs environnementales au fur et à mesure que le déploiement se fraie un chemin dans divers environnements
Chacun de ces microservices utilise ensuite le graphique générique via CI/CD
par exemple helm upgrade release-name private-repo/generic-chart --values <environment>.yaml --set image.tag=<docker tag from build step> --namespace <environment> --install Je préférerais utiliser .Chart.AppVersion plutôt que .Values.image.tag mais je DOIS être capable de déployer d'une manière efficace pour notre organisation.

Si je fais un helm ls j'ai à la fois CHART et APP VERSION donc toute la version du graphique doit correspondre à la version de l'application qui tombe à plat là-dessus. Continuer sur cette voie ne fera qu'aliéner les gens et à un moment donné, le projet sera fourchu parce que cette mentalité est trop stricte et pas ce que beaucoup de gens recherchent. Il commence également à suivre la voie de "Supprimons image.* , nameOverride & fullnameOverride . image.* peut être codé en dur dans deploy.yaml etc." pour des raisons TRES similaires.

Un dernier point est que de nombreux graphiques publics ne correspondront pas exactement à la version du conteneur Docker qu'ils utilisent. Jetez un œil à la plupart des conteneurs docker connus, par exemple alpine ou nginx, où les versions majeures et mineures sont des balises roulantes avec uniquement les versions de correctifs non roulantes. Avoir un mappage 1:1 pour chaque version de correctif introduit une surcharge assez importante pour peu ou pas d'avantages.
Il n'est pas rare que les environnements de production ne puissent pas mettre à niveau vers la dernière version pour une multitude de raisons. Ne parlez même pas à la plupart des endroits des versions roulantes en production.

Le résultat de tout ce qui précède soulève alors la question « Pourquoi helm peut-il utiliser un dépôt de carte ? ».
Ne pas être en mesure d'écraser appVersion au moment de l'installation/mise à niveau signifie que vous devez déjà télécharger et décompresser le graphique, éditer appVersion par installation/mise à niveau, ou vous pouvez aussi emballer les conteneurs Docker nécessaires dans le tableau.
L'exception est l'endroit où une installation complètement standard se produit, et il y a déjà beaucoup de débats autour de la génération automatique de mots de passe et autres.
Je sais que les derniers paragraphes semblaient être en train de descendre dans un terrier de lapin et de me peindre dans un coin, mais c'est là que "appVersion est la balise docker ET ne peut pas définir appVersion via la ligne de commande ou les valeurs" nous amène.

@timothyclarke : Ce que vous voudrez peut-être faire, pour le cas d'utilisation helm upgrade vous avez décrit ici, est helm package premier, ce qui vous permet de définir --version et --app-version , puis vous pouvez helm install l'archive tar et la conserver en tant qu'artefact CI, ce qui augmente la reproductibilité de l'installation, car aucun paramètre --set n'aura été ajouté. C'est vers cela que nous sommes passés, bien que sans l'aspect "graphique générique", car nos graphiques ne sont pas génériques.

C'est aussi une bonne occasion d'ajouter des métadonnées de construction au Version , avec quelque chose comme +g<shortCommitSHA> .

Par #7517, cela m'a permis de supprimer un tas d'appels sed qui réécrivaient image.tag avant de l'installer sur notre cluster de test CI, puis à nouveau lors de l'empaquetage ultérieur.

Cette approche pourrait en fait résoudre les problèmes que la plupart des gens ont rencontrés ici, s'ils créent leurs propres graphiques, et en particulier s'ils installent à partir de la source du graphique dans leur commande. Cela n'aide pas vraiment s'ils ont besoin de cette fonctionnalité pour un graphique provenant d'un dépôt, mais je pense que c'est un problème différent de celui que la plupart des gens ici rencontrent ?

Pour moi, le risque de remplacer une version d'application (ou une version) au moment de l'installation est que ce n'est pas aussi clairement visible pour quelqu'un d'autre essayant de recréer le graphique, que cela a été fait. À moins qu'il ne soit piraté d'une manière ou d'une autre dans le support des valeurs, il ne sera pas là lorsque l'on extraira la configuration actuelle du graphique à l'aide de helm get values -o yaml , donc cela devient _une chose de plus_ qui rend votre déploiement de graphique en direct différent de ce que vous obtenez avec helm install <some way to specify a particular package> --values <values from helm get values> , par exemple, lorsque vous essayez de reproduire un problème rencontré en production sur une configuration de test.

Pour moi, le risque de remplacer une version d'application (ou une version) au moment de l'installation est que ce n'est pas aussi clairement visible pour quelqu'un d'autre essayant de recréer le graphique, que cela a été fait. À moins qu'il ne soit piraté d'une manière ou d'une autre dans le support des valeurs, il ne sera pas là lorsque l'on extraira la configuration actuelle du graphique en utilisant helm get values -o yaml

Vous frappez le clou sur la tête. Cela devrait avoir abeille dans values.yml dès le premier jour.

Bien que je comprenne les arguments philosophiques contre cette fonctionnalité, la pratique sur le terrain montre que cela aiderait beaucoup les gens, y compris nous.

Il existe de nombreux graphiques dans la nature qui vous permettent de définir la version de l'application via values.yml , en particulier parce qu'elle ne peut pas être définie ici.

Je ne sais pas si cela a été discuté (fait un CTRL+F rapide et n'ai trouvé aucune trace), mais qu'en est-il de la suppression de appVersion tous ensemble comme solution alternative ? Il me semble que cela éviterait toute confusion.

À l'heure actuelle, appVersion est traité comme une sorte de valeur "spéciale". Je suppose qu'il est là pour fournir la visibilité, par exemple, je peux avoir la version graphique 123.5.6 de Prometheus, mais il aura appVersion: 2.17.1, donc je sais quelle version du correctif de sécurité a-t-il et à quelles fonctionnalités Prometheus s'attendre et je peut le rechercher en utilisant helm ls .

Je suppose que cela pourrait être fourni d'une manière différente. Peut-être via des labels de sortie ? Ou peut-être jsonPath requête kubectl par exemple :

kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}'

Ensuite, le support de cela serait déplacé vers les meilleures pratiques, au lieu d'être imposé par helm lui-même. Il peut aussi être pelucheux.

D'un autre côté, il se peut que de nombreuses personnes s'appuient sur l'implémentation existante de appVersion , cela doit également être pris en compte.

Peut-être que prendre du recul et comprendre pourquoi exactement appVersion a été ajouté aiderait à résoudre ce problème ?

@bokysan C'était auparavant dans values.yaml il a été déplacé vers Chart.yaml Je suppose que pour tout le helm ls montrant à la fois le graphique et la balise docker plutôt que d'avoir à exécuter une commande telle comme
kubectl get deployment <release name> -o jsonpath='{.spec.template.spec.containers[0].image}'

@TBBle J'aborderais chacun de vos points, mais cela rendrait ce post aussi long que le précédent. Je pense que tout ce problème revient à quelqu'un qui décide qu'un graphique générique n'est pas un cas d'utilisation valide uniquement en examinant les graphiques dans le référentiel public.

Toute la prémisse d'appVersion tombe à plat dès que vous devez commencer à utiliser initContainers et side-cars. Pour donner un exemple du monde réel, l'un des projets que je dois actuellement gérer a nginx avec un side-car php. Les balises nginx et php ne changent pas souvent. Le conteneur / la version php est très important pour les développeurs qui écrivent le code. Le conteneur qui change le plus fréquemment est le initContainer qui fournit le contenu.
Dois-je définir appVersion sur le initContainer , sur le conteneur php ou est-ce nginx , et en choisissant un seul de ces éléments, quelles informations ont été perdues ?

Si c'est important pour vos utilisateurs, alors ce devrait être la version PHP, sûrement ? C'est ce que vous faites de la publicité. Vous pouvez également coller les trois dans votre appVersion, c'est un champ de texte libre après tout.

Si vous voulez forcer la balise d'image de conteneur appVersion ==, alors vous allez trouver cela difficile avec des graphiques non triviaux, c'est-à-dire des graphiques avec plus d'un conteneur, ou sans conteneurs. Ce n'est pas vraiment le but, sinon ce serait imageVersion . Si vous empaquetez une seule application en amont, utilisez sa version. Si vous créez un package de plusieurs applications en amont, choisissez-en une, par exemple le graphique de prometheus-operator, ou ignorez appVersion, car il s'agit d'un champ facultatif.

Si la source de votre graphique fait _partie de_ l'application, par exemple Agones, laissez simplement appVersion vide, ou copiez-le à partir de version si vous avez des outils qui en dépendent.

Aucune de ces choses n'a besoin d'être des décisions de helm install -temps. Comme je l'ai mentionné plus tôt, helm package est assez tard pour tous les workflows, sauf "changer une version amont différente au moment de l'installation pour un graphique tiers" et cela devrait être dans --values ou --set comme toutes les autres actions "changer X au moment de l'installation".

Honnêtement, la fonctionnalité manquante est probablement "passer appVersion à tpl ", vous pouvez donc la lire à partir de .Values.image.tag ou de tout ce qui vous convient.

Si vous voulez forcer appVersion == balise image conteneur

Ensuite, nous sommes probablement dans https://github.com/helm/helm/issues/7517 C'est peut-être de là que tout cela vient.

Je ne comprends pas du tout cette discussion. Pourquoi ne pas donner aux gens la possibilité d'utiliser la version de l'application de la manière qui leur convient le mieux est un gros problème ?

Dans une forme actuelle, il vaudrait mieux pour moi ne pas avoir du tout ce APP VERSION . Cela n'apporte que de la confusion aux personnes dans notre projet. Nous avons >80 services qui utilisent le même graphique de barre et comme il n'est pas possible de changer facilement ce APP VERSION dans le helm upgrade -i ... je vois que toutes nos applications resteront pour toujours avec 1.0 ici. Et je ne prévois pas de reconditionner le graphique déjà emballé pour simplement changer la version de l'application. Pourquoi devrais-je compliquer mon CI pour qu'il s'adapte à votre conception ???

Je vois aussi que je dois juste dire à tout le monde de ne pas utiliser le helm list car ce sera quelque chose qui ne leur sera pas utile. Pour vérifier quelle version de nos applications ils ont, ils devront utiliser autre chose.

J'étais optimiste au début de la lecture de cette conversation, mais après avoir vu comment vous en discutez et comment vous vous battez pour forcer les utilisateurs à avoir votre façon de penser, j'ai perdu espoir maintenant :(.

Avoir deux sorties différentes "CHART(version)" et "APP VERSION" dans helm list , helm history et similaires est très utile et évite d'avoir à approfondir les options de ligne de commande et l'analyse de sortie pour obtenir les faits les plus importants.

Si "CHART(version)" et "APP VERSION" sont liés au moment de la construction ("helm package"), tout l'avantage d'avoir deux valeurs différentes est quelque peu perdu. Construire un graphique et mettre à jour la VERSION APP sans incrémenter/mettre à jour la VERSION CHART entraînera de gros problèmes car la même VERSION CHART vous donnera des résultats très différents. :-<

Donc, pour l'instant, nous sommes obligés de créer le package avec chaque version et d'incrémenter "CHART (version)" et "APP VERSION" en synchronisation pour ne pas nous retrouver dans une situation insensée / peu claire.

Comme je viens de l'apprendre, nous pourrions supprimer "APP VERSION", car il est facultatif et utiliser une valeur personnalisée et l'utiliser au lieu de {{ Chart.appVersion }} pour notre image... mais alors helm list ferait être beaucoup moins informatif. :-<

Du point de vue des utilisateurs (développeurs) :

• possibilité de définir une propriété/un indicateur/une valeur de version au moment de l' installation
• possibilité de voir la propriété/l'indicateur/la valeur de cette version dans la liste de la barre/l'historique de sortie avec l'étiquette « XX version »

Y a-t-il une chance que nous puissions le faire ?

Si "CHART(version)" et "APP VERSION" sont liés au moment de la construction ("helm package"), tout l'avantage d'avoir deux valeurs différentes est quelque peu perdu.

Je pense que c'est le nœud du désalignement. L'avantage de la version de l'application telle que je l'utilise, et comme cela semble être prévu par la configuration actuelle, est que vous connaissez la version d'une application encapsulée _pour cette version du graphique_, car la version du graphique est la version du graphique entier, pas la version des modèles dans le graphique. Je détesterais que chaque déclaration comme "Nous avons besoin de la version ~ XY du graphique Helm" pour exiger "Oh, et ne plaisante pas avec l'AppVersion" ajoutée à la fin.

Cet avantage est perdu de la version de l'application (et la version réelle de l'application) est modifiée au moment de l'installation, car maintenant la version graphique ne vous dit pas quelle application vous utilisez, et vous perdez la possibilité d'utiliser SemVer pour vous assurer, par exemple, vous disposez de la version la plus récente mais compatible avec l'API.

Pour le cas d' utilisation décrit par appVersion soit un modèle qui pointe vers une entrée de valeurs ferait que helm list fasse ce qui est souhaité, tant que le graphique prend en charge son la version de l'application (probablement une balise de conteneur) a changé au moment de l'installation, via --set ou --values comme toutes les autres options de configuration "modifiées au moment de l'installation".

Ici, j'ai eu un problème avec le AppVersion .

Nous utilisons à la fois la version Release et AppVersions.

Pour les définir maintenant, je dois appeler le helm package explicitement au préalable de helm upgrade --install pour créer une archive tar locale avec les deux versions définies.

Maintenant, j'ajoute le support helm-secrets , et...
Et son wrapper ne peut pas fonctionner avec le helm package !

Alors - et maintenant ?
Abandonner le support et le flux de toutes nos versions ?
Abandonner en utilisant Secrets ?
Des idées?

En fait, c'est plus un problème pour le helm-secrets , mais c'est également lié à la capacité --set app-version discutée ici, car si je pouvais l'utiliser de cette manière - je n'ai pas besoin d'appeler le helm package du tout.

UPD Oh, attendez... Je peux toujours utiliser helm secrets upgrade chart.tgz -f secrets.yaml ...
D'accord.
Mais quand même, +1 pour ajouter le --set app-version .

Alors - et maintenant ?
Abandonner le support et le flux de toutes nos versions ?
Abandonner en utilisant Secrets ?
Des idées?

Nous construisons deux packages : un package helm avec uniquement les graphiques, sans les valeurs env et le fichier secrets. Nous renommerons ce package en chart-{app-version}.tgz car chart-version ne signifie rien pour nous, et chart-version ne prend pas en charge notre syntaxe de version d'application. Nos mises à jour d'applications incluent toutes les mises à jour potentielles des graphiques (même référentiel, en utilisant le balisage git).

Ensuite, nous avons un deuxième tgz spécifique à l'environnement, chart-{app-version}-{env}.tgz qui inclut le graphique tgz, les valeurs yaml et le fichier de secrets cryptés. Ce fichier comprend également un "package.yaml" qui contient des valeurs telles que la balise, l'application et le nom de l'environnement pour nos scripts automatisés à déployer à l'aide de helm-secrets .

Nous avons l'habitude d'identifier les versions de nos applications, ou la plupart d'entre elles, avec un numéro de version sémantique. Utilisez ensuite ce numéro dans la VERSION APP pour l'identifier facilement dans la liste helm history pour les annulations ou d'autres opérations.
Comme le système ne permet pas de l'injecter automatiquement au moment du déploiement, nous exécutons cette simple commande automatiquement sur notre pipeline CI/CD avant la commande de déploiement :

sed -i -E "s/^appVersion: (.*)/appVersion: ${deploy.project.version}/" ${chartPath}/Chart.yaml

C'est délicat, mais cela fonctionne comme prévu.

@bvis
Le problème avec votre solution de contournement est que vous devez modifier le graphique dans votre pipeline CI/CD.
Si vous utilisez un dépôt de graphique centralisé, vous êtes obligé de helm pull repo/chart --untar

Des progrès supplémentaires avec l'injection par programme de Chart.yaml/appVersion ? Existe-t-il des solutions de contournement ? Cela donnerait un énorme coup de pouce à CI/CD Helm .

@jakovistuk pour autant que je nginx-ingress/Chart.yaml par exemple...

Je n'ai pas beaucoup réfléchi à ce problème depuis un certain temps, donc c'est peut-être une question vraiment stupide, mais existe-t-il un moyen d'utiliser Helm CLI pour remplacer appVersion ?

Il semble que beaucoup de gens ici demandent un moyen de remplacer le champ « appVersion ». L'intention/la demande d'origine dans ce problème est d'autoriser —app-version en remplacement de —version, afin qu'un utilisateur puisse exécuter 'helm fetch —app-version=v0.15.0' et Helm déterminerait la dernière version du graphique. spécifié v0.15.0 comme appVersion et récupérez-le.

Dans notre projet/tableau (cert-manager), nous voulons indiquer aussi clairement aux utilisateurs finaux que la version qu'ils installent, donc leur permettre d'installer par version d'application au lieu de la version de

Cela dit, ce problème a été ouvert il y a 2 ans maintenant, et depuis lors, nous avons choisi de garder ces deux numéros de version en synchronisation/verrouillage. Après quelques années à faire cela, cela a été étonnamment facile et sans douleur, bien que les utilisateurs doivent parfois attendre quelques semaines pour une nouvelle version officielle si des modifications sont apportées à nos manifestes de déploiement.

Compte tenu de l'âge de ce problème, de sa longueur, de la grande variété de portes de fonctionnalités légèrement différentes et des changements intervenus dans le projet Helm depuis lors (Helm 3, graphiques OCI, etc.), je ne pense pas que ce problème soit en bon état pour être poussé vers l'avant en tant que demande de fonctionnalité dans sa forme actuelle. Je vais fermer ce problème, mais toute autre personne ayant une demande de fonctionnalité similaire est préférable d' ouvrir un nouveau problème et de

Je pense également que ce type de fonctionnalité pourrait être, et est probablement le meilleur, implémenté en tant qu'outil externe ou wrapper autour
Helm, surtout en tenant compte des changements OCI qui, je pense, rendraient cela plus difficile à mettre en œuvre.

Jusqu'à ce que cela soit résolu (ou non) Voici comment j'ai résolu cela dans mon CI/CD (GitLab) :

empaquetez le graphique avec la version de l'application, puis déployez-le.
Je sais que la version Chart n'est pas censée être la même que l'appVersion, mais dans notre cas, c'est une solution de contournement.

deploy:
  image: alpine/helm:3.2.4
  stage: deploy
  environment:
    name: ${ENV}
  script:
    - helm package --app-version=${CI_COMMIT_TAG} --version=${CI_COMMIT_TAG} ${NAMESPACE}
    -  | 
       helm upgrade -i --wait ${CI_PROJECT_NAME} ./${NAMESPACE}-${CI_COMMIT_TAG}.tgz \
       --set image.repository="${CI_REGISTRY_IMAGE}" \
       --set image.tag="${CI_COMMIT_TAG}" \
       --set-string ingress.enabled="${INGRESS}" \
       --set service.port="${CONTAINER_PORT}" \
       --set service.targetPort="${CONTAINER_PORT}" \
       --set dc="${CI_ENVIRONMENT_NAME}" \
       --set project="${CI_PROJECT_NAME}" \
       --namespace ${NAMESPACE}
    - helm history ${CI_PROJECT_NAME} -n ${NAMESPACE}
  tags:
    - kubernetes
  only:
    - tags

Si vous par défaut votre image.tag à {{ .Chart.AppVersion }} alors vous n'aurez pas besoin de --set pendant l'installation, ce sera déjà correct. Cela fonctionne également bien pour les constructions automatiques, lorsque vos images Docker sont étiquetées avec SHA1 afin que l'AppVersion corresponde à la balise d'image Docker et que la version soit une SemVer à construction automatique.

Il n'y a aucun problème avec la version identique à AppVersion si votre AppVersion se trouve être SemVer.

Pour les packages produits par mon équipe, nous nous dirigeons vers des éléments qui recherchent AppVersion, par exemple image.tag, par défaut sur Version si AppVersion n'est pas défini. Ce n'est pas une énorme différence, juste un argument de moins à helm package pour les versions étiquetées, mais n'a de sens que si votre graphique est construit à partir du même SCM que ce que vous emballez.

@TBBle qui ne fonctionnera pas si vous utilisez un sous-diagramme pour définir votre balise d'image

Voulez-vous dire que l'image.tag se trouve dans un sous-graphique, mais que vous essayez d'utiliser la version d'un graphique parent ? Si c'est le cas, oui, c'est très gênant et ce ne sera pas facile à gérer. Je viens de rebondir exactement sur cette mise en page dans les graphiques Helm de https://github.com/googleforgames/open-match/ . Je suggère de remonter les sous-graphiques en question dans le graphique principal dans ce cas.

Les graphiques doivent être des unités isolées/utilisables indépendamment, ne s'appuyant pas sur les comportements du graphique parent pour fonctionner. Le sous-diagramme a sa propre version, _c'est_ celle que ses images devraient utiliser, sinon, pourquoi est-ce un sous-diagramme ?

Dans le cas d'Open Match, les sous-graphiques semblent être utilisés de sorte que XXX.enable puisse être utilisé comme raccourci dans values.yaml pour désactiver un tas de choses à la fois, mais cela introduit un tas de problèmes structurels comme celui-ci . Les sous-graphiques d'Open Match font tous un usage intensif du graphique parent nommé modèles, et ont également une version locale de 0.0.0-dev , il y a donc déjà deux odeurs de code que quelque chose n'est pas bien structuré.

Ou peut-être que j'ai mal compris l'observation que vous faites.

@haimari Malheureusement, cela ne fonctionne pas (

> helm package $DIR/deployment/chart --app-version="1111e8" --version="3454e5" --namespace stage
Error: Invalid Semantic Version

Mais ça marche :

> helm package $DIR/deployment/chart --app-version="0.0.0-1111e8" --version="0.0.0-3454e5" --namespace stage
Successfully packaged chart and saved it to: /Users/aws/service-0.0.0-3454e5.tgz

et même ça (mais ça a l'air sale) :

> helm package $DIR/deployment/chart --app-version="0-1111e8" --version="0-3454e5" --namespace stage
Successfully packaged chart and saved it to: /Users/aws/service-0-3454e5.tgz

helm version version.BuildInfo{Version:"v3.4.0", GitCommit:"7090a89efc8a18f3d8178bf47d2462450349a004", GitTreeState:"dirty", GoVersion:"go1.15.3"}

Je pense que la solution de

@a0s : Je suggère généralement :

helm package $DIR/deployment/chart --app-version="<container image tag>" --version="<semver version>"

Et puis faites en sorte que la valeur de votre balise d'image de conteneur soit quelque chose comme {{ Values.image.tag | default .Chart.AppVersion | default .Chart.Version , de sorte que vous n'ayez pas besoin de la modifier à la volée, comme le fait @haimari .

Dans vos exemples, vous avez ce qui semble être deux versions différentes de git, n'est-ce pas ? Est-ce un pour l'image du conteneur et un pour le graphique ?

Avec SemVer, vous ne pouvez pas vraiment mettre un git commit SHA dans la partie significative du semver, car semver implique un ordre et les git commit SHA ne sont pas triables.

Vous voudrez donc utiliser une version comme 0.0.1-alpha.<build-id>+g<gitcommitsha> où <build-id> est un peu comme le pipeline ou l'ID de travail de votre système CI, donc il augmente toujours votre engagement dans votre projet. De cette façon, vous obtenez toujours la dernière version lorsque vous la demandez.

Dans SemVer, l'utilisation d'un - signifie qu'il s'agit d'une pré-version pour cette version, donc 0.0.1-<anything> situe entre les versions 0.0.0 et 0.0.1. La partie après + est l'information de construction, et elle est ignorée pour le tri, c'est donc un bon endroit pour mettre des git SHA ou des noms de branche ou d'autres informations de suivi non triables.

Donc, avec ce que vous avez utilisé ici, 0-3454e5 semblera être plus récent que le prochain commit, si son SHA commence par un 2 , par exemple, 0-2764e1 .

Dans vos exemples, vous avez ce qui semble être deux versions différentes de git, n'est-ce pas ? Est-ce un pour l'image du conteneur et un pour le graphique ?

Oui, l'application et le graphique - il existe deux logiciels indépendants.

De cette façon, vous obtenez toujours la dernière version lorsque vous la demandez.

Que faire si je ne veux pas (et même pas imaginer) demander la dernière version.

0.0.1-alpha.<build-id>+g<gitcommitsha>

Cette chaîne (après interpolation) semble trop longue pour tenir dans une colonne de sortie standard helm list :)

Je sais toujours quelle version (sha hash) de l'application que je veux installer (passez-la avec --set args). Et je sais toujours quelle version du graphique j'utilise (comme @haimari l'a décrit, j'utiliserai toujours git checkout chart && helm pack && helm upgrade .tar.gz localement dans mon ci/cd)

Qu'est-ce qui pourrait mal se passer?
1) Une erreur pendant le helm upgrade régulier. Ok, je vais corriger l'erreur et réessayer (avec un autre commit sha de l'application - 99%) (ou en utilisant --atomic place)
2) Restauration manuelle : helm rollback <RELEASE_NAME> ou déploiement précédent sha commit via CI/CD.

Qu'est-ce que j'ai raté ?

PS Pour être honnête, je souhaite utiliser la partie sha courte dans la version et la version de l'application uniquement à des fins d'information (pendant helm list )

Si c'est juste à des fins d'information, alors il va après le + dans un SemVer, pas - . Si vous ne vous souciez _jamais_ de la commande des versions ou de la distribution des chartes Helm à qui que ce soit, et que votre charte ou application n'est pas déjà SemVer'd, alors 0+g<commitsha> est une SemVer valide (équivalent à 0,0.0).

C'est ce que font les graphiques Helm d'Open Match, par exemple ; ils sont tous actuellement 0.0.0-dev , et nous avons commencé à chercher à faire cela 0.0.0-dev+g<commitsha> afin que si vous regardez ce que vous avez installé, vous puissiez au moins dire _quel_ build maître vous avez.