Helm: Chart.yamlを編集せずに、インストールまたはアップグレード中に.Chart.AppVersionを設定する手段を提供します

明確にするために、＃3555はOP（ref https://github.com/helm/helm/issues/3555#issuecomment-633187773）によって次のコメントで閉じられました：

「ここの多くの人が「appVersion」フィールドをオーバーライドする方法を求めているようです。この問題の元の意図/要求は、ユーザーが実行できるように、-versionの代わりに-app-versionを許可することです。 helm fetch —app-version = v0.15.0 'とHelmは、最新のチャートバージョンが最後にv0.15.0をappVersionとして指定したものを計算し、それをフェッチします。

私たちのプロジェクト/チャート（cert-manager）では、エンドユーザーがインストールしているバージョンをできるだけ明確にしたいので、チャートバージョンではなくアプリバージョンごとにインストールできるようにする方がはるかに自然なインストールエクスペリエンスになります。

とは言うものの、この問題は2年前に発生し、それ以来、これらのバージョン番号の両方を同期/ロックステップで維持することを選択しました。 これを数年行った後、驚くほど簡単で痛みがなくなりました。ただし、デプロイメントマニフェストに変更が加えられた場合、ユーザーは新しい公式リリースを数週間待たなければならないことがあります。

この問題の時代、長さ、わずかに異なる機能ゲートの多種多様性、およびそれ以降のHelmプロジェクトの変更（Helm 3、OCIチャートなど）を考えると、この問題は良好な状態ではないと思います。現在の形式の機能要求として前進します。 私はこの問題を閉じるつもりですが、同様の機能要求を持っている他の人は、新しい問題を開き、証拠を提供するためにこの問題の他の関連するコメントにリンクするのが最善です。 うまくいけば、Helmチームのトリアージプロセスでうまく機能し、リクエストが必要な可視性を得ることができます。

また、この種の機能は、外部ツールまたはラッパーとして実装できる可能性があり、おそらく最適であると思います。
ヘルム、特にOCIの変更を考慮すると、これを実装するのが難しくなると思います。」

その醜いですが、それは機能しますが、舵に組み込まれた旗が大好きです

sed -i "s/^version:.*$/version: $(git describe)/" chart/Chart.yaml
sed -i "s/^appVersion:.*$/appVersion: $(git describe)/" chart/Chart.yaml
helm upgrade app ./chart

もっと似ていたらいいのに……。

helm upgrade --version "$(git describe)" --app-version "$(git describe)" app ./chart

@loaあなたの提案は、タイトルから次のようにはなりません（そしてこれが全体のポイントです "

Chart.yamlを編集せずに

@timothyclarkeユースケースを明確にしたかっただけです。

現在、アップグレード時にappVersionを変更する機能がない場合、 helm historyは次のようになります。

REVISION    UPDATED                     STATUS      CHART           APP VERSION DESCRIPTION
1           Mon Jun  8 11:39:51 2020    superseded  spring-1.0.0    1.0.0       Install complete
2           Mon Jun  8 12:19:21 2020    superseded  spring-1.0.0    1.0.0       Upgrade complete
3           Mon Jun  8 12:20:51 2020    deployed    spring-1.0.0    1.0.0       Upgrade complete

理想的に実行

helm upgrade --wait --app-version "$MY_AWESOME_VERSION" app ./chart

以下のように、よりユーザーフレンドリーなhelm historyになります。 これは、グラフが変更されていないが、アプリに新しいリリースがあったことを示しています。

REVISION    UPDATED                     STATUS      CHART           APP VERSION DESCRIPTION
1           Mon Jun  8 11:39:51 2020    superseded  spring-1.0.0    1.0.1       Install complete
2           Mon Jun  8 12:19:21 2020    superseded  spring-1.0.0    1.0.2       Upgrade complete
3           Mon Jun  8 12:20:51 2020    deployed    spring-1.0.0    1.0.3       Upgrade complete

このユースケースはヘルムプロセスに適合していますか？

理想的には、コマンドラインから提供されたアプリバージョンはテンプレート（ $.AppVersion ）でも利用できますか？

これにより、kubernetes構成のメタデータに追加できるようになります。

これは非常に便利です。 「アプリのバージョン」、つまりアプリとは何か、「アプリ」などに複数のDockerイメージがある場合のバージョンの定義方法、CI / CDの更新を自動化する方法について説明します。 2つのバージョンを定義することで、これらの問題を回避します。

1. チャートバージョン：テンプレートの_ソース_を表します。
   
   
   
   • テンプレートソースが変更された場合、チャートのバージョンが変更されます。 テンプレートソースとは、テンプレートフォルダー、Chart.yaml、デフォルト値.yaml、helmignore、notesなどを意味します。
   
   
   • チャートはいつでもgitから入手でき、helm installを介してインストールできるため、チャートリポジトリにヘルムチャートを保存しません。
   
   
2. インストールバージョン：インストール時に使用されたすべての値の組み合わせに基づく一意の値。つまり、すべての値ファイル（復号化されたシークレットファイルを含む）とセットおよびチャートのデフォルト値をマージした後。 これは、最終的な値のセットに基づいて、MD5またはSHA256を介して決定します。

helmにはインストールバージョンの概念がないため、アプリバージョンを使用してmd5を保持します。

これにより、インストールされているものを解釈できます。

REVISION    UPDATED                     STATUS      CHART           APP VERSION      DESCRIPTION
1           Mon Jun  8 11:39:51 2020    superseded  spring-1.0.0    3efe0e3...       Install complete
2           Mon Jun  8 12:19:21 2020    superseded  spring-1.0.0    ie21b02...       Upgrade complete
3           Mon Jun  8 12:20:51 2020    superseded  spring-1.0.0    3efe0e3...       Upgrade complete
4           Mon Jun  8 12:20:51 2020    deployed    spring-1.1.0    123abcd...       Upgrade complete

リビジョン1と3がまったく同じインストールであることが今ではかなり明白です。つまり、同じチャートソースと同じ最終的な値のツリーです。

誰かがこれを試すことに興味があるなら、 --app-versionは素晴らしいでしょう。 また、ドライランを不要にする--app-version-is-md5ようなものを実装したいのですが、それは別の問題（＃8453）にあります。

gitタグを使用していないときは、インストールの前にこれを使用しますyq w -i k8s/$CI_PROJECT_NAME/Chart.yaml appVersion "$CI_COMMIT_SHORT_SHA"

タグを使用する場合、ciプロセスでリビジョンをアップグレードします。これは、インストールするたびに使用しますyq w -i k8s/$CI_PROJECT_NAME/Chart.yaml appVersion "$CI_COMMIT_TAG"
次に、更新されたChart.yamlをバージョン管理にコミットします。

gitlabciの使用

チャートを公開する直前にアプリのバージョンを設定したいという人がたくさんいることを私は知っています。 しかし、実際には、特に今行った変更をまだテストしている場合は、チャートを公開したくありません。 開発環境へのインストールまたはアップグレードは、この機能の主な使用例です。

@woodcockjosh 、この問題がチャートバージョンにあるかどうかは

この機能の主な使用例は、チャートデザイナー、サーバー管理者、および開発者に次の機能を提供することです。

1. デプロイされているアプリケーションのバージョン（チャートバージョンではない）を簡単に確認できます。 アプリケーションがコードであり、必要なすべての依存関係がある場合。 注：appVersionは、リリースのアンインストール、ロールバック、または検索に使用される有効な値ではないと思います。
2. （個人的な要望）チャートに値を公開して、チャートのメンテナが自分の裁量で、インストール/更新時にappVersionを使用するかどうかを決定できるようにすること。 例として、Kubernetesデプロイメントのメタデータに追加します

上記の2つのユースケースであるIMOをカバーすることにより、ヘルムチャートの実装と使用がどのように行われるかについてヘルムが意見を持たないようにすることができます。

インストールバージョン：インストール時に使用されたすべての値の組み合わせに基づく一意の値。つまり、すべての値ファイル（復号化されたシークレットファイルを含む）とセットおよびチャートのデフォルト値をマージした後。 これは、最終的な値のセットに基づいて、MD5またはSHA256を介して決定します。

@scholliiインスタンスバージョンのアイデアは気に入っていますが、私が働いているヘルムチャートの作成者および実装者として、インスタンスバージョンとは別の人間が読めるアプリバージョンが必要です。 それらが分離する理由は
アプリケーションコードのみが変更され、チャートやチャートに適用された値が変更されていない場合、インストールバージョンは一意ではありません。

@rcampbelはい、もちろん、インストールされているアプリケーションのバージョンを確認したいと思います。 私が言っているのは、appVersionのバージョンをChart.yamlあるものとは異なるバージョンにしたい状況は、そのチャートが自分のものであり、開発レベルのバージョンを展開している場合です。アプリケーション。 開発レベルのバージョンでない場合は、アプリのバージョン番号をChart.yaml内に保持し、グラフのエンドユーザーにそのアプリのバージョンをデフォルトのアプリのバージョンとして使用させることができます。

たとえば、新しいマイクロサービスを開発している場合、デプロイされたバージョンのアプリケーションをテストするたびに、新しいヘルムチャートをパッケージ化してヘルムリポジトリにアップロードしたくありません。 ただし、リリースごとにデプロイされるバージョンまたはコミットIDも確認したいので、開発リリースではappVersionをオーバーライドしますが、本番リリースではオーバーライドしない可能性があります。

私が言っているのは、appVersionのバージョンをChart.yamlにあるものとは異なるバージョンにしたい状況は、そのチャートが自分のものであり、アプリケーションの開発レベルバージョンをデプロイしている場合です。 開発レベルのバージョンでない場合は、アプリのバージョン番号をChart.yaml内に保持し、チャートのエンドユーザーにそのアプリのバージョンをデフォルトのアプリのバージョンとして使用させることができます。

これがまさに、ヘルムチャートの実装と使用がどのように行われるかについてヘルムが意見を述べないままでいる必要がある理由です。
Helmは、ローカルおよびそれ以降への展開戦略、つまりチーム/プロジェクトのワークフローを理解するための展開戦略を気にする必要はありません。 ただし、これは要求されている機能とは異なります。 Chart.yamlを更新せずに、インストール/アップグレード時に.Chart.AppVersionを設定できるようにしてください。

デプロイされたバージョンのアプリケーションをテストするたびに、新しいヘルムチャートをパッケージ化してヘルムリポジトリにアップロードしたくない

私が言えることから、ヘルムはhelm upgrade呼び出すときにこれを正確に行う手段を持っているので、これについてはすでに意見がありません。

チャート引数は、チャート参照（ 'example / mariadb'）、チャートディレクトリへのパス、パッケージ化されたチャート、または完全修飾URLのいずれかになります。 〜https：//helm.sh/docs/helm/helm_upgrade/

@woodcockjosh多くのユースケースがあり、 @ rcampbelが述べているように、ヘルムはこれについて意見を述べずに、人々が独自の方法で作業できるようにする必要があります。
「チャートに公開する必要がある」というロジックに従うと（極端に）、ヘルムに--setまたは--values 、 -fフラグがあるのはなぜですか？ values.yamlファイルですか？ フラグによって提供されるものはすべて、公開されたチャートにあるはずの展開時間のオーバーライドです。 私はチャートに秘密を置くために悪いことを知っているが、それが唯一の理由だったならば、argがあるべき--secretsではなく--values 。

私の状況では、同じグラフを使用する多数のアプリをデプロイします。 これらのアプリは、CI / CD方式を使用する環境を通じて宣伝されます。 アプリは--valuesフラグを使用して、アプリ固有および環境固有の構成（通常は入力およびデータソースの詳細）を提供します。 すべての環境のすべてのアプリバージョンに対して新しいグラフを公開している場合、週に数百から数千のグラフバージョンを作成することになります。 ほとんどの場合、唯一の違いはアプリのバージョンです。 その後、チャートバージョンをバンプすることを余儀なくされます。 私にとって、この段落全体で導入された要件は、あるものが別のことをトリガーすることで論理的ですが、クレイジーです。

既存の.Chart.appVersionが機能していないため、静的な.Chart.appVersion戻し、 .Values.image.tag （これは、その議論を再開するための招待状ではありません）

appVersionは、ドキュメントを読んだ後、この有効なユースケースをすべて読むまで、アプリケーションのバージョンに関する方法であると確信していました。

チャートパッケージのユーザーにとっては、 image.tagを増やすのが簡単です。これは、値のみを変更することを意味し、チャートは別の場所に存在する可能性があります。 しかし、使用してimage.tag行うときに、パッケージのバージョンについての情報を得ることはありませんhelm history <release>

helm package <chart>がChart.version含むtarファイルを生成することにも気づきました。 アプリの新しいバージョンのみを配布したい場合で、 appVersionが使用されている場合は、 versionもバンプすることが予想されます。そうでない場合は、前のファイルが上書きされます。 appVersionとversionが異なる場合、 version自動ツールを使用して正しいsemverバンプを計算するのは困難です（ appVersionがコミットメッセージに基づいてバンプされると仮定します） ）。 人々はそれをどのように扱いますか？

デプロイされたチャートを一覧表示するときに表示できる実際のアプリバージョンであるものが必要です。

標準のマイクロサービスをデプロイするために作成されたヘルムチャートがあり、デプロイ中にこのマイクロサービスがデプロイ中に持つアプリのバージョンを選択したい場合。 現在、私のサービスはすべてappVersion 1.0.0を永久に使用しており、helmを使用して、使用しているアプリケーションのバージョンを確認していません。これを現在の方法（グラフの再パッケージ化）で可能にすると、私の人生は地獄になります。

ただ、このパラメータをどのように使用するかを決めましょう。 技術的な理由でこれが不可能な場合は、その理由をお知らせください。

8194で述べたように「sed」は使い
これが解決されるまで（または解決されないまで）これが私のCI / CD（GitLab）でこれを解決する方法です：

チャートをapp-versionでパッケージ化してから、デプロイします。
チャートバージョンがappVersionと同じであることを意図していないことは知っていますが、この場合、回避策としては問題ありません。

また、ヘルムリポジトリにアップロードする必要はありませんが、結果のCIアーティファクト（chart.tgz）を使用することは可能です。

したがって、最初にパッケージ化することが問題ではなく、今日の回避策が必要な場合は、次のようなものを使用できます。

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}" 
    - helm history ${CI_PROJECT_NAME} -n ${NAMESPACE}
  tags:
    - kubernetes
  only:
    - tags

出力には、利用可能なバージョンがあります。

 $ helm history ${CI_PROJECT_NAME} -n ${NAMESPACE}
 REVISION   UPDATED                     STATUS      CHART       APP VERSION DESCRIPTION                                                                                                         
 45         Sun Aug  9 15:40:42 2020    superseded  prd-0.1.0   1.16.0      Upgrade complete                                                     
 46         Mon Aug 10 11:38:56 2020    superseded  prd-v0.2.25 v0.2.25     Upgrade complete                                                     
 47         Mon Aug 10 11:55:41 2020    deployed    prd-v0.2.26 v0.2.26     Upgrade complete                                                     
 Job succeeded

@haimari
スニペットをありがとう、このトレッドの前半に同じ結果を達成する別の例https://github.com/helm/helm/issues/8194#issuecomment-635879040があります。

しかし、目前のこの問題は、チャートの再パッケージ化は望ましくなく、ヘルムメンテナはその意見と働き方を強制しているということです。 この要求は、ヘルムの意見が少なくなり、コミュニティの他の部分により適した方法でヘルムを使用できるようにすることです。
この問題とhttps://github.com/helm/helm/issues/3555は、 .Chart.versionと.Chart.appVersionの違い、特にほとんどの公開チャートがappVersionをどのように結び付けるかを調査しました。アプリの新バージョンがあるからといってチャートバージョンを強制的に変更させたコンテナタグがリリースされました。 これは大部分の公開チャートにとっては良い仮定かもしれませんが、この仮定はかなりの数のプライベートチャートには有効ではありません。 したがって、このアプローチをコミュニティに強制することをやめるように、ヘルムメンテナに要求します。

psコードスニペットは、リリースごと/環境ごとのチャートバージョンを意味します。これは、 image.repositoryおよびimage.tagを設定する必要性に取って代わります。 再デプロイが必要になった場合に備えて、再パッケージ化後、チャートをヘルムリポジトリに公開する手順を期待します。上記のください。穴

@haimari
スニペットをありがとう、探している人のために、同じ結果を達成するこのトレッド＃8194（コメント）の前半に別の例があります。

しかし、目前のこの問題は、チャートの再パッケージ化は望ましくなく、ヘルムメンテナはその意見と働き方を強制しているということです。 この要求は、ヘルムの意見が少なくなり、コミュニティの他の部分により適した方法でヘルムを使用できるようにすることです。
この問題と＃3555は、 .Chart.versionと.Chart.appVersionの違い、特にほとんどの公開チャートがappVersionをコンテナタグに結び付ける方法を調査しました。アプリの新しいバージョンがリリースされています。 これは大部分の公開チャートにとっては良い仮定かもしれませんが、この仮定はかなりの数のプライベートチャートには有効ではありません。 したがって、このアプローチをコミュニティに強制することをやめるように、ヘルムメンテナに要求します。

psコードスニペットは、リリースごと/環境ごとのチャートバージョンを意味します。これは、 image.repositoryおよびimage.tagを設定する必要性に取って代わります。 再デプロイが必要になった場合に備えて、再パッケージ化後、チャートをヘルムリポジトリに公開するためのステップを期待します。そのウサギの穴を探索する上記の＃8194（コメント）を参照してください。

@timothyclarke情報ありがとうございます。

1. これはベストプラクティスではありませんが、_ "Chart.yamlを編集せずにインストールまたはアップグレード中に.Chart.AppVersionを設定する手段を提供する" _の回避策です。
2. チャートをリポジトリにプッシュする必要はありません。これは、Gitlabから直接複数のk8sクラスターで機能します。
3. それは私がリリースを持つために必要なすべてを提供します：

image.repositoryとimage.tagは、パイプラインでもまったく同じ方法で設定されます。
したがって、パッケージングラインがなくても、これがgitlabのhelmを使用する方法です。

CI_COMMIT_TAG変数には、実行されているパイプラインの現在のリリースタグが含まれています。
そのため、ワンクリックでCIパイプラインから直接以前のバージョンにいつでもロールバックできます。

私の会社では、ヘルムチャートをコンテナタグから切り離しています。 コンテナのビルドごとにチャートを再パッケージ化する必要はまったくありません。

インストール中にappVersionを設定するオプションがない（したがって、常に同じ値に設定する）ことは、デプロイメントプロセスの大きな欠陥です。 ユーザーが「ヘルムリスト」を実行してもアプリケーションのバージョンが表示されないのは本当に迷惑です

「helminstall ... --app-version v1.2.3」のようなものを使用する機能があると、この場合のHelmの使用に多くの価値が追加されます。

私の提案は、 helm listまたはhelm history <name>実行するときに、 appVersionを非推奨にし、 chart versionとcontainer tagをリストすることです。
Helmは、コンテナー内に実際のアプリバージョンを提供しようとすべきではありません。手元にあるもの、タグ、およびチャートバージョンを提供する必要があります。ここでは、いくつかの例を示します。

| チャート| コンテナタグ|
| ----- | ----- |
| 0.1.0 | 0.3.0 |
| 0.1.0 | 0.4.0 |

上記の例では、チャートがさまざまなタグに再利用されていると推測できます

| チャート| コンテナタグ|
| ----- | ----- |
| 0.3.0 | 0.3.0 |
| 0.4.0 | 0.4.0 |

上記の例では、チャートがタグと同じバージョンを共有していると推測できる可能性があります。

appVersionの主な欠点は、チャートが変更されていなくても、パッケージを再公開する必要があることですが、コンテナー内のコードは変更されています。 一方、コンテナのタグはvalues.yamlを介して提供でき、再公開する必要はありません。

代替案

helm listまたはhelm history実行するときにコンテナタグをリストするのが最も簡単だと思いますが、 appVersionぶら下がっているのは奇妙です。 これは少なくとも、いくつかの追加情報を提供し、人々はappVersion無視する可能性があります。

別の解決策は、 appVersionを廃止する代わりに、 values.yamlに移動することで、チャートから切り離して、複数回の再発行を防ぐことができます。

考え？

@Woileアプリに複数のコンテナがある場合はどうなりますか？

@Woileアプリに複数のコンテナがある場合はどうなりますか？

そうです、そのユースケースも考慮して（申し訳ありませんが、私のユースケースについて考えていました）、 appVersionをvalues.yamlに移動すると状況が改善されると思います。

• helm listとhelm historyは同じままである可​​能性があります
• 複数のコンテナを持つことができます
• 毎回再公開する必要はありませんが、 ChartとappVersion同期を維持したい場合は再公開できます。

私は何が欠けていますか？

私の好みは、appVersionを明示的に制御できるようにすることです。 コンテナタグと等しい場合もあれば、別の値に設定する必要がある場合もあります（たとえば、インストールスクリプトが特定のコンテナリポジトリ/名前空間/タグを検索し、正規表現を適用してそれらをユーザーフレンドリーに変換しますアプリのバージョンを表示するためのフォーマット）

@woodcockjosh @Woile
私の$ 0.02。 appVersionの概念は、 helm ls観点からは良い概念です。 実装は私が修正してもらいたい問題です。 appVersion複数のタグ/バージョンがある場合は問題ありません（例： appVersion: nginx-1.16.0-php-7.5

ヘルム3.2.4には{{ .Values.image.tag | default .Chart.AppVersion }}ので、そのような切断が可能です。

インストール/アップグレード中にappVersionを選択する機能が、最も推奨されるアプローチです。 グラフ自体は変更されないため、appVersionが変更されるたびにグラフのバージョンをバンプしても意味がありません。 バージョニングの線形進行も常に適用できるとは限りません。特に、コンテナーバージョンのさまざまな組み合わせを使用してさまざまな環境にデプロイされるマルチコンテナーアプリケーションの場合はそうです。 同じappVersionとchartVersionを使用するという提案も悪いです。これは、appVersionがsemVerと互換性を持つようにするためです。 semVerはバージョニングの聖杯ではなく、appVersionは、アプリケーションに最も適したバージョニングスキームを自由に使用できる必要があります。

@bacongobblerこのコメントは、helmがそのようなフラグを実装することを計画し

app-version（コマンドラインopt内）とappVersion（Chart.yaml内）の導入は、チャートインスタンスでデプロイされたアプリケーションのバージョンを確認するための良い方法を効果的に提供すると思います。 しかし、これはまた、明確にする必要のある多くの異なる質問と実践を生み出します。

• helm（グラフ）の目標は、リソースをkubernetesクラスター（アプリケーション用）にパッケージ化してインストールすることです。
• アプリバージョンはパッケージフェーズでのみ提供できるため、この情報はチャートの一部になります。
• ヘルムリポジトリ（JavaまたはPythonアーティファクトなど）に保存されると、チャートは不変になります。 したがって、アプリのバージョンを上書きしないでください。
• インストールまたはアップグレードフェーズ中の反対側では、値を使用してグラフの値を上書きできますが（環境のカスタマイズ用）、appVersionはできません。
• 多くのユースケースでわかるように、アプリケーションの実際のバージョンは、インストールまたはアップグレードフェーズ中にimage.tagによって提供されるイメージバージョンです。

私の結論

• アンブレラチャートは、以下の複数のチャート（依存関係）の集合体と見なすことができ、適切なライフサイクルです。
• アンブレラチャートは、appVersionが使用される画像に直接リンクされていない唯一のケースです。
• アプリケーションは常にチャートを提供します。多くの場合、app-version = image tag（つまり、アプリケーションコードへの推移性による）
• アプリケーションコードとチャートコードの間のソースの分離は、Dockerイメージとチャートの間のコンプライアンスにいくつかの問題をもたらすだけです。
• 「スプリングブートチャート」のような共有チャートは、常にアプリケーションチャートの依存関係として使用する必要があります（アプリケーションがこの依存関係のみで構成されている場合でも）...共有チャートではなくアプリケーションをデプロイします。

私の現在の選択

• 共有チャートは、そのバージョンのチャートのみを生成し、アプリのバージョンは常に空です（使用されません）
• 共有チャートを直接使用して展開を行うことはありません。
• アプリケーション（コンポーネント）チャートは常に適切なチャートを生成します。ここで、チャートバージョン= app-version = imageタグ
• アンブレラチャートフォローは、チャートバージョンがアプリバージョンを表す適切なライフサイクルです

質問/アイデア

なぜアプリバージョンが導入されたのかわかりません（共有チャートの悪い使い方をカバーするためかもしれません）。
sedやyqのような回避策を使用せずに、それを削除して、パッケージフェーズでイメージタグを設定する機能を導入することをお勧めします。

投稿が長すぎるかもしれませんが、フィードバックが必要です

@grazius
あなたの投稿についての私の理解は、 --set 、 -f 、および--valuesフラグは不良であり、決して使用すべきではないということです。 すべてのデプロイメントは不変であり、チャートがvalues.yamlを少し超えており、アンブレラチャートが依存関係である場合でも、チャートにレンダリングする必要があります。 このチャートは、（アプリケーション）ビルド時にレンダリングされ、チャートリポジトリに公開される必要があります

上記の状況で、秘密または同様の機密情報をどこに保存していますか？ 私が働いたことのあるところはどこでも、それらは--valuesファイルを介して供給されてきました

一部のコンテキストでは、私のデプロイメントには、独立してバージョン管理された3つの要素が事実上あります。

• チャート
• 応用
• （環境）構成値

それらの1つを変更した場合、他のいずれかを再構築することを強制されるべきではありません。 私は通常、複数の環境を使用しているため、アプリケーションを_ライブ_する前にテストできます。 そのような展開では、gpgで保存されたenv設定ファイルを暗号化してchart-v1.0 application_build-50 config_non-prod-v1.3が必要です。
私のCIプラットフォームは、ビルドがソースからテスト、本番に流れるときに、アプリケーションのビルド、デプロイ、プロモートを管理しています。 アプリケーションの履歴バージョンを再デプロイする必要がある場合は、それらのジョブを再実行します。

質問：CIプラットフォームがすぐに処理できる状態を保存するために、チャートリポジトリを使用する必要があるのはなぜですか？ これを手作業でインストールすることは絶対にしないでください

@timothyclarkeは、暗号化された値ファイルを使用できるように、必ずシークレットプラグインを使用してください

@timothyclarkeこんにちは、この最初のフィードバックをありがとう;）

• リポジトリー（pypi、maven Central、開発用のdockerレジストリーなど）の利点は、生成されたアーティファクトを共有して公開できることです（helmの場合はtgzです）。
• 環境別の値（これは別の主題です）については、必要な場所に保存できます（scmリポジトリ、シークレット用のhashicorp、netpol用のillumioなどの専用ソリューション...）。

チャートは、チャートのコンシューマーが使用（またはオーバーライド）できるデフォルトのvalues.yaml（チャートのバージョンごとに不変）を提供します。
Chart.yamlの場合、これはチャートの不変部分でもあります...そしてapp-versionはに含まれています。

あなたの場合、アプリバージョンのヘルムリストには何が表示されますか？ 50？
はいの場合、パイプラインのチャートapp-versionにアプリケーションバージョンをどのように配置しましたか？

@grazius

チャートは、チャートのコンシューマーが使用（またはオーバーライド）できるデフォルトのvalues.yaml（チャートのバージョンごとに不変）を提供します。
Chart.yamlの場合、これはチャートの不変部分でもあります...そしてapp-versionはに含まれています。

ここであなたが言っていることを誤解しているかもしれませんが、これは、チャートのバージョンごとに不変であるのに、なぜアプリバージョンを持っているのかという疑問を提起します。 したがって、チャートに他の変更が加えられていなくても、アプリケーションのバージョンを変更するたびに、チャートのバージョンもバンプする必要がありますか？ もしそうなら、なぜチャートバージョンやアプリバージョンを持っているのですか？

これは、「Chart.yamlを編集せずにインストールまたはアップグレード中に.Chart.AppVersionを設定する手段を提供する」という要求にも反すると思います。@ timothyclarkeがこのチャットで前に言ったことは、非常に良いことを要約していると思います： https：/ /github.com/helm/helm/issues/8194#issuecomment -671331311

もう1つ覚えておくべき重要なことは、使用されているグラフをすべての人が制御できるわけではなく、展開時に使用されている画像やその他の値をグラフに渡すことができる場合があることです。 その場合、デプロイされているアプリのバージョンを更新することをどのように提案しますか？

ここで同じ問題！
helm listアプリケーションのバージョンを表示する方法を提供するための回避策として、 --descriptionフラグの使用を検討します🤔

アンブレラチャートを作成するときは、アプリバージョンが本当に必要です。 コンポーネントチャートの場合、チャートバージョンとアプリバージョンを別々に進化させることへの関心は非常に低いと思います。

おそらく主な問題は、Chart.yamlのタイプが十分に正確ではないということですか？ アンブレラチャート、共有チャート、またはアプリケーションチャートを区別する方法はありません

@graziusそれはかなり意見の
多くのオープンソースプロジェクトに適用できるかもしれませんが、多くのクローズドソースビルドには適用できません。 このリクエストはチャートの仕様から.Chart.AppVersionを削除するリクエストではないため、作成されたさまざまなステートメントとユースケースをすべて含めて、このスレッドを再確認してください。 helm ls出力からAPP VERSIONをマスクする要求でさえありません。
このスレッドは、チャートの使用時に（チャートを再構築したり変更したりせずに） Chart.AppVersion構成可能にして、 helm lsのAPP VERSIONフィールドを構成できるようにするためのリクエストです。誤解を招くものではありません。

現状では、 APP VERSIONはhelm ls不要なフィールドであり、 .Chart.AppVersionが.Chart.Versionと密接に関連しているため、ランタイムコマンドには表示されないはずです。 helm inspect chart --version <.Chart.Version> <.Chart.Name>は同じ情報を提供します。
また、コンテナタグとして使用する.Chart.AppVersionの使用にも拡張します。これらはすべて、正当な理由で個別にバージョン管理できるものとは少し異なりますが、現在は1つにまとめられています。
プロジェクトはそのようなリンクの完全に正当な理由を持っている可能性があるので、私はこのリクエストの外でそのリンクについての私の意見を維持しようとしました。 ヘルムを使用するすべての人に同じプロセスを強制しないことで、ヘルムをより優れた、より包括的なツールにします。
私は、これらの要求された変更が舵取りを弱めたり、他の人にそれらの使用を強制したりすることはないと思います。

@bacongobblerこれについてコメントしていただけますか？ その非常に要求された機能

その非常に要求された機能

こんにちは、 @ jasondamour-興味を持ってくれてありがとう！ 2つの良いオプション： helmプラグインの作成とHIPの作成。

こんにちは、おそらく最善の解決策は、インストール/アップグレードコマンドにrelease-app-version引数を提供することです。この引数が存在する場合は、ヘルムリストを実行するときにapp-version表示をオーバーライドします。