私もこれに出くわしました。 通常、チャートのパッケージ化時に画像タグを指定したいのですが、デバッグのために、アプリは別のタグを使用してインストールを実行したいと考えていました。

90日間操作がないと、問題は古くなります。
/remove-lifecycle staleして、問題を新規としてマークします。
古い問題は、さらに30日間非アクティブになると腐敗し、最終的には閉じます。

この問題を今すぐ解決できる場合は、 /close 。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/ lifecycle stale

https://github.com/kubernetes/charts/pull/5919で発生したため、これを再度表示し

私の最近のコメントの一部をコピーする：

特に、チャートのマイナーバージョンをマイナーアプリケーションバージョンと一致させることを選択します（ただし、パッチバージョン番号はばらばらになる可能性があります）。

これは、cert-managerの新しいリリースに新しいフラグを追加する可能性があり、Helmチャートにサポートを追加すると、フラグをサポートしていないため、古いリリースのcert-managerとの互換性が失われるためです。 これは、一般的なIMOでのヘルムチャートのバージョン管理に関するかなり基本的な質問であり、私たちには良い話がありません。

appVersionをチャートバージョンに合わせるのはお勧めできませんが、このようにして、ユーザーはHelmチャートバージョン0.3.xをcert-manager 0.3.xのいずれかで使用でき、チャートバージョン0.4.xをcertで使用できることを知っています。 -マネージャー0.4.x。 互換性はマイナーバージョン内で定義されています。

/ remove-lifecycle stale

これを議論のために持ち帰りたいと思います。

全体として、一部のコンポーネントで使用されている画像タグだけが変更されている場合、内部アプリのグラフをバージョン管理することに賛成する説得力はあまりありません。 リリースをアップグレードする場合、appVersionフィールドはこの情報の適切な場所のように見えます。

上記で参照した元の提案をコピーします。

ヘルムチャートをデプロイするための現在のワークフローには、helm upgrade CLIコマンドを呼び出すansibleタスクが含まれます。同じチャートバージョンのリリースを改訂するときに、フラグを渡してappVersionを設定できると便利です。

appVersionはリリースではなくチャートに関連付けられているため、概念的には少し奇妙かもしれませんが、この場合、一部のコンテナーに使用される画像タグを更新しているだけで、ワークフローにチャートバージョンやチャートリポジトリが組み込まれていません。まだ。 これは将来変更される可能性がありますが、フィールドは純粋に情報提供であるため、今のところ、インストールとアップグレード時に--app-versionのフラグを追加しても問題はありません。

独自の内部アプリケーションを開発する場合、アプリ自体は、それをデプロイするチャートよりもはるかに大きく変化します。 通常、継続的デプロイコマンドはhelm upgradeで、 --set imageTag=<new_version>しかありません（明らかに、チャートの他の場所でコンテナのバージョンを設定するために使用されます）これを--app-versionに置き換えると、次のようになります。 helm ls別の視覚的なポイントを使用して、デプロイされているコードのバージョンと、デプロイされているチャートのバージョンを確認します。

これをより見やすくするために、インストール/アップグレード時に渡されるimageTagに設定されるimageTagメタデータタグの設定を標準化しました。 これにより、K8sダッシュボードを使用したり、imageTagが表示されたGraphanaダッシュボードを簡単に作成したりできますが、コマンドラインを離れてマウスをクリックする必要があります。

これについて何かニュースはありますか？

ありがとう

これに関する更新。 @EraacからのPRが要求されたことをhelm upgrade --set imageTag=<imagetag>も実行しますが、これはhelm ls出力にリストされているAPPバージョンを更新しません。 --set app-versionまたは--set versionを実行できると、 helm upgradeを実行して、 helm lsがデプロイされているバージョンを正しく表示できるようになります。

更新はありますか？

ああ、いつでもすぐに素敵になるでしょう！

とても便利です

また、一般的なグラフを使用してアプリケーションをデプロイするため、インストール時にアプリのバージョンを設定する機能も気に入っています

+1

+1

それは非常に役に立ちます

同じを要求する

+1でスパムを止めてください。 すでにPR（https://github.com/helm/helm/pull/4961）があり、人々は提案について話し合っています。 最後の返事は2日前でした。

こんにちは@filipre

すでにPR（＃4961）があり、人々はその提案について話し合っています。

そのPRによると、これはここに移動されました：
https://github.com/helm/helm/pull/5492
これは＃4961の最新のPRであり、レビューがマージされるのを待っているようです...

@filipre言って

これは非常に便利です。 アプリのバージョン0.6.0に固定する必要がある問題に遭遇しましたが、グラフのバージョンはアプリのバージョンとは関係ありません。

私も同意します。これも非常に役立つと思います。 更新はありますか？

https://github.com/helm/helm/pull/5492#issuecomment-509662190を参照して

多くのアプリケーションで再利用する予定のHelmチャートを作成しているときに、これが問題になることに気付いたときに、この問題が発生しました。 この問題を簡単な方法で解決すること（つまり、インストール時にアプリのバージョンを設定するフラグを使用すること）が進んでいないことを考えると、今のところ機能するはずの代替案を考え出しました。 それは本当にとても簡単です-最初にuntarオプションでhelm fetchを実行し、次にそこに存在する--app-versionフラグでhelm packageを実行してから、そのローカルチャートのインストールに進みます。

理想的ではありませんが、 helm listの最終結果は正しく、CIサーバーでこれを行うのは非常に簡単です。 --app-versionをhelm installとhelm upgradeで利用できるようにしたいと思います。

＃5492での議論の要約は、 helm packageとhelm installのロジックをラップするコマンドが、この問題で最初に説明されたユースケースを解決するというもの

つまり、次のコマンドを実行することでこれを回避できます。

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

（最近クローズされたPRからのコメントをここに移動します-したがって、ニルヴァーナで終わることはありません）

これが私の2セントです：
appVersion Yサービスをデプロイするヘルムchart version Xがあると仮定します。

ヘルムチャートは、 appVersion Yサービスをホストするために使用されるchart version X上のKubernetes内のインフラストラクチャを説明するために使用されます。

初期開発中、 XとY両方が定期的に変更されます。 ただし、ある時点でXは多かれ少なかれ安定し、 Yは変化し続けます（ Yにインフラストラクチャに対する新しい要件がない限り、これはほとんど発生しません。 Yの開発サイクルで）。

このチケットで提案されているアプローチでは、バージョンX安定したヘルムチャートパッケージを使用して、appVersion Y 、 Y+1 、 Y+Nなどをデプロイできます。

ただし、ヘルムのインストールまたはアップグレード中にこのフラグをオーバーライドできないようにし、代わりにパッケージなどでのみ、 XとY両方を効果的に結び付けて、常に新しいX+1作成する必要があります。 Y+1です。 これは私には不必要に思え、新しいappVersion参照していることを除けば、実質的に変更されていない大量のヘルムパッケージになります。 私の見解では、アプリケーションのバージョンとそのアプリケーションをホストしているインフラストラクチャのバージョンには関係がありますが、個別にバージョン管理する必要があります。 それがどのように行われているかは、それぞれの開発チームに任せるべきです。

概要：

このアプローチは間違いなく機能しますが、 AppVersionが変更された多くの不要なHelmパッケージも発生します。
$ helm package myapp --app-version 1.0.0 $ helm install myapp-1.0.0.tgz

ええ、でも、私が上で述べたアプローチをとれば、それはそれほど問題ではないと思います。 アプリのバージョンが設定されていない（または0.0.0など）チャートリポジトリにグラフをプッシュし、それを使用する場合は、 helm fetchを使用し、適切なアプリのバージョンでパッケージ化してから、ローカルを使用します.tgzファイルであり、そのチャートをプッシュしないでください。 そうすれば、チャートリポジトリはクリーンな状態に保たれ、実際のチャートの変更のみがそこに表示されます。

はい、動作します。 この場合、デプロイメントアーティファクトを直接消費することはできませんが（たとえば、Helmリポジトリから直接インストールすることによって）、アーティファクトを変更する追加の手順を実行する必要があります。

Charts.yamlは不変である必要があると主張された場合、デプロイメントアーティファクトは不変である必要があると私は主張します。

_https ： //github.com/helm/helm/pull/5492#issuecomment-520029902_からの私の考えの要約

コミュニティがパッケージ、チャート、バージョンをどのように解釈するかに問題があります。 @BenjaminSchiborr 、これがあなた

チャート-リリースのソースコードです。 アプリのソースコードのように。 テンプレート、コードファイルで構成されています。
パッケージ-リリース、アーティファクトのビルドです。 バイナリのように、ソースコードから構築されます。 固定の本番バージョンで構成されています：チャートバージョンとアプリバージョンの両方。
リリース-指定された構成でデプロイされたビルドです。

チャートからリリースを作成する方法はありません。 このようには機能しません！

アプリをステージにデプロイする前に、グラフを用意する必要があります。 次に、 helm packageを使用して、両方のバージョンを修正し、グラフを使用してアプリをパッケージ化する必要があります。 その結果、どの段階でも展開可能なパッケージになります。 次に、このパッケージをたとえばQAステージにインストールし、 helm installを使用して、UAでプロモートし、次に本番環境でプロモートします。

これは、パッケージ指向のソフトウェアが機能する方法です。

混乱

helm installは、インストールする必要のあるソースが必要です。 ソースは次のとおりです。

1. レジストリから入手可能なパッケージ名
2. パッケージがすでにダウンロードまたは作成されている場合は、パッケージファイルのパス
3. パッケージURL（HTTPを使用して利用可能な場合）
4. チャートディレクトリパス

4番目のアプローチはここでは黒い羊のように感じますね。 これが、pplがパッケージとチャートを混同する理由です。 そして、これが問題の根源です。

推論

野生のアプリには2種類あります。

大/中-これは、より良い内省と品質保証のために詳細で詳細なフローを設定するための時間、資金、およびリソースがある場所です。
小規模-マイクロサービス、ペットプロジェクト、PoC、低コストプロジェクト、DevOpsの知識がないプロジェクト、さらにはヘルム開発プロセスのテスト。

小さなプロジェクトでは、パッケージを作成したり処理したりする時間や必要はありません。 いくつかのテンプレートファイルを作成し、1つのコマンドでデプロイしたいとします。

これが、 helm installがhelm package & helm installなどの使用を許可する理由です。 ただし、 --app-versionなどの完全なhelm package機能は提供されません。

helm installはhelm package & helm installになる可能性がありますが、 helm installは混乱し、サポート、テスト、およびグッドプラクティスの作成に地獄になります。

提案1

helm install簡略化します。 コードベースを簡素化し、テストして意見を述べ、 helm理解を簡素化するために、パッケージのみを提供できるようにする必要があります。

提案2- helm run

新しいコマンドを導入します： helm run 。 ただ動作するはずのコマンド、。 小さなアプリに最適です。 あるいは、中規模から大規模の場合もあります。

helm packageとhelm install組み合わせて、そのようなユースケースで意味をなさないコマンドを除いて、両方のコマンドから機能を提供する必要があります。

helm packageは、 go buildと同様に、ビルドを作成します。 go run使用すると、ビルドプロセスなしでアプリを起動できるため、 helm runはここでは堅実な名前のように見えます。

考慮すべき追加事項：

• 代わりにupgrade --install使用する必要がありますか？
• デフォルトで--atomic有効にする必要がありますか？

@iorlas 、
あなたのコメントは理にかなっています。 ただし、インフラストラクチャバージョンとソフトウェアバージョンの両方を継承して結び付ける最終パッケージは1つだけであると想定していますが、ソフトウェアバージョン用のパッケージとインフラストラクチャ用のパッケージがあり、それらを結び付けたいと想定しています。リリース内（たとえば、ソフトウェアバージョンとインフラストラクチャバージョンを参照する目的の状態構成を介して）。

なぜ開発プロセスをそのパターンに強制する必要があるのか​​わかりません。責任ある開発グループが、インフラストラクチャとソフトウェアのバージョンをヘルムパッケージレベル以降で結び付けるかどうかを決定することもできます。 現在、展開プロセスでは常に新しいhelmパッケージを使用する必要がありますが、変更されるのはソフトウェアバージョンのみです。 これにより、リポジトリに何千もの役に立たないパッケージが作成されます。

これに長期的な利点があれば大丈夫です。 見えないだけです。

@BenjaminSchiborrわかりました、少し分解させてください。

バージョンX Chart（==インフラストラクチャ）を作成できます。
アプリケーション、バージョンYを持つことができます。

helm現在どのように機能するか、それはhelm packageステップでインフラストラクチャとアプリケーションのバージョンを結び付けます。 次に、それをk8s名前空間と結び付けて、Releaseを生成する必要があります。

したがって、式は次のようになります。 package(infra + app) + k8s = Release

本当に必要なのは、この中間ステップをスキップして、3つのコンポーネントすべてを1つのステップ（リリース）で結び付けることです。 このように： infra + app + k8s = Release 。 私は正しいですか？

これは、表面上、 helm runが行うことです。 ボンネットの下では、それは同じになります。

しかし...私はあなたがヘルムのポイントを逃しているかもしれないと感じます。 どのツールもユーザーの好みに合わせて使用​​できますが、コミュニティに影響を与え、「道」を作るというアイデアは常に存在するため、望遠鏡がビールを醸造する能力を備えたハマーになることはありません。

それがどのように使われるべきかを説明しようと思います、そしてあなたの視点からそれを見るのは素晴らしいでしょう。

Helm自体は、k8sのテンプレートとデプロイを抽象化し、アプリケーションとインフラストラクチャをその依存関係で結び付けるために作成されています。テンプレートを手動で書き直してK8sに適用し、新しいイメージタグを提供する代わりに、必要なコマンドは1つだけです- helm upgrade 。 MSIまたはdebパッケージのように。

新しいアプリのバージョンをインストールしたり、ダウングレードしたりする必要がある場合は、helmを使用することになっています。 アプリを管理する代わりに、パッケージ全体を管理します。 何かがうまくいかないときにアプリのバージョンとインフラストラクチャを別々にロールバックするのは低音の苦痛でしょう-私はそこに行ったことがありますが、誰にも提案しません。

したがって、レジストリに多くのパッケージを含めることは正しいことです。パッケージはインフラストラクチャではなく、パッケージはアプリです。アプリは、インフラストラクチャのないK8sでは意味がないためです。

リポジトリにパッケージが多すぎるという問題がある場合は、リポジトリの代わりにアーティファクトを使用することをお勧めします。 私はCIでそのようにしています：アプリをビルドし、Dockerレジストリに送信し、パッケージを作成し、リリース用のアーティファクトとして保存します。 CircleCI、Travis、Azure Pipelinesは、アーティファクトとしてビルドに添付されたファイルの作成をサポートしています。 あなたは同じことをすることができますか？

多分私はヘルムのポイントを逃しています。 たぶん、ヘルムはここでポイントを逃しました。 このチケットはまさにそれを評価するためのものだと思います。 そして個人的に-私の視野を広げることについても:)

しかし、ええ、抽象的な方法であなたが言っていることは正しいです。 ソフトウェアバージョンをhelmパッケージ/リリースに結合したくないので、基本的にはinfra + app + k8s = Releaseです。 ソフトウェアバージョンのプロパティをhelmパッケージ/リリースに関連付けたくないのと同じです（オーバーライドできる正常なデフォルトは別として）。

例に関しては、さらに下に提供します。 これがこのアプローチがどのように問題があるかをどのように示しているのかわかりません。 引き続きhelmを使用してロールバックまたはロールフォワードします。 インフラストラクチャが変更された場合は、変更されたヘルムチャートバージョンを使用します。 ソフトウェアバージョンが変更された場合は、別のappversionを使用します。 パラメータが変更された場合は、別のパラメータを使用します。 これは、サービスごとに常に（単一の）ヘルムコールになります。

詳細を教えていただけますか？

リポジトリにパッケージが多すぎるという問題がある場合は、リポジトリの代わりにアーティファクトを使用することをお勧めします。

私が言及していたのは、パッケージ化されたヘルムチャートが多すぎることでした（すでにappVersionが含まれています）。 安定した1つのヘルムチャートバージョンと、1日に数百回変更されるappVersionと考えてください。 したがって、リポジトリ内のサービスごとに毎日数百のパッケージ化されたヘルムチャートがあり、後で自動化によって消費されます。

（私のパイプラインは一般的にあなたのものと同じように見えます：ビルドアプリ-> Dockerイメージ（結果はappVersion）->パッケージチャート（更新されたappVersionを使用）->リポジトリにプッシュしますか？

このチケットはまさにそれを評価するためのものだと思います。

確かに！ 私の意見では、すでに抽象化のレベルが多すぎるため、ここにヘルムがあると少し圧倒されます😄また、ヘルムが解決する問題のいくつか（おそらくほとんど？）のために作成されたk8s演算子がここにあります。 しかし、それはまた別の話題です、へへ。

安定した1つのヘルムチャートバージョンと、1日に数百回変更されるappVersionと考えてください。 したがって、リポジトリ内のサービスごとに毎日数百のパッケージ化されたヘルムチャートがあり、後で自動化によって消費されます。

うん、それは間違いなく多すぎるように感じますが、それは意図されています。 同様に、ビルドを実行すると、いくつかのアーティファクトが生成され、それを保存してステージにデプロイするために使用する必要があります。 のように...ビルド結果がないビルドを実行するにはどうすればよいですか？ デプロイするときにビルドを生成する必要がありますか？ それは本当に間違っているでしょう。 一部のCIパイプラインは、JSビルドに対してこれを行います。

dockerで発生するのと同じ問題：ビルドごとに新しいdockerイメージが生成され、dockerレジストリに入ります。 保存する必要があります。保存しない場合は、どのように展開するのでしょうか。

もちろん、 docker saveを使用してレジストリのスペースを節約し、後でビルドarifacts保持ポリシーをスイープすることができます。 しかし、 helm packageして、ファイルとして保持することができます。

しかし、私は間違いなくあなたの主張を理解しています。アプリのバージョンを受け入れることができる「インストーラー」を1つ持つことができます。 このようなインストーラーにはインフラストラクチャがあるため、アプリのバージョンを変更するだけで、同じ状態を維持できます。 きちんとシンプルに見えますが、問題があります。

アプリ自体は、インフラストラクチャのないk8s環境では意味がありません。

アプリが何らかのインフラストラクチャに依存している場合はどうなりますか？ 基本的な例-configmap。

その後、アプリをロールバックする必要がある場合はどうなりますか？
アプリをダウングレードする必要がありますが、インフラストラクチャもダウングレードする必要があります。

インフラストラクチャをロールバックする必要がある場合はどうなりますか？
以前のインフラストラクチャは、それに関連付けられていないため、インストールする必要のあるアプリのバージョンの手がかりがありません。 そのため、どのアプリがどのインフラストラクチャをサポートしているかを覚えて、手動で設定する必要があります。

本当に、それは地獄でしょう。 そして、あなたが舵をとっていないとき、それは今地獄です。 そしてそれは間違いではありません。 しかし、その場合、ヘルムを使用する理由はほとんどありません。

すでに抽象化のレベルが多すぎます
すべての素晴らしくてシンプルなウィンク

あなたの最後のポイントは非常に説得力があると思います：

以前のインフラストラクチャは、それに関連付けられていないため、インストールする必要のあるアプリのバージョンの手がかりがありません
これらを切り離し、Helmパッケージ/リリースを信頼できる情報源として使用する場合、これは間違いなく問題になります。

しかし、多くの人にとって、これはおそらくそうではありません。 ヘルム（いや、抽象化の別のレイヤー）の上に、複数のヘルムチャート（およびappVersions）を結び付けるオーケストレーションがあります（ヘルムスマン、ハーネスなどを考えてください）。 そして、そのレイヤー自体もバージョン管理されています。 その場合、ヘルムチャートの古いバージョンに戻るのではなく、オーケストレーションレイヤーの古いバージョン（アプリとインフラストラクチャの意味を理解する）に戻るため、説明する内容は問題ではなくなります。

しかし、舵だけで、はい、100％問題です💣。 これが、appVersionのオーバーライドを明示的に許可し、デフォルトでは許可しないというアイデアの理由だと思います。

チャートバージョンとアプリケーションバージョンを結合することについて私が気に入っていることの1つは、どのアプリケーションバージョンがどのチャートに属しているかが明確になることです。 1つの特定のバージョンを再デプロイする必要がある場合、どのアプリケーションバージョンがどのチャートバージョンと互換性があるかを覚えておく必要はありません。 それらは相互にリンクされているため、適切なチャートバージョンを参照するだけで、アプリケーションとチャートが一致することが確実になります。 これは基本的に@iorlasが説明したことだと思いますよね？

最後に、チャートバージョンは「スーパー」バージョンとして機能します。

• 変更を加えると（アプリケーションまたはインフラストラクチャ、つまりグラフが変更されたかどうかに関係なく）、新しいグラフバージョンが作成されます。つまり、新しいアプリケーションバージョンは、グラフバージョンも変更されたことを意味します。
• 新しいチャートバージョンは、アプリケーションバージョンが変更されたことを意味するものではありません

文書化の目的で（そしておそらく他の素晴らしいアイデア）、チャート定義自体のみを参照する別の「チャートのみ」バージョンを自分で導入することができます。

@filipre
うん、うん！ これが、現在のアーキテクチャ設計の決定に基づいて、Helmが機能することになっている方法です。 私の考えでは。

問題は、それが時々奇妙に感じることです-セットアップと、アプリとインフラを一緒に結び付けるという疑わしいアイデアには多すぎます。 それで、それは正しいアプローチですか？それは問題です。

@BenjaminSchiborr

しかし、多くの人にとって、これはおそらくそうではありません

確かに！ k8全体でさえ、コンテナ化は多すぎる可能性があります。

ヘルムが作成された問題を見つけるために、もう少し別の観点からそれを分解してみましょう。

• インフラストラクチャインスタンスは、製品全体の仕組みです。SaaSインスタンス、VMプール、k8sセットアップ、アプリバージョン（データベース、可観測性ツール、ルーター、サイドカー、製品アプリインスタンスを含む）
• インフラストラクチャインスタンスには、信頼できる唯一の情報源が必要です。 これで、Terraformのようなユーティリティができました。
• 1つのフォルダにあるものが多すぎる=難しい。 分解する必要があります。 こんにちはTerraformモジュール。
• 1つのフォルダ内のプラットフォームとアプリケーションの両方=ハード。 分解する必要があります。 こんにちはプラットフォームとコンテナ。 K8sがステップインします。
  
  
  
  1. そのため、Terraformモジュールは、空のすぐに使用できるコンテナーレイヤーの作成など、プラットフォームを管理でき
  
  
  2. K8sはコンテナを管理し、YAMLを使用して基本的なリソースを作成できるようにします
  
  
• 多くのK8sアプリ（データベースなどを含む）の多くのYAMLファイル=ハード。 アプリごとにフォルダーに分割します。
  
  
  
  1. つまり、PostgreSQL、Redis、MyPetShopなどのフォルダがあり
  
  
• Hello Helm-これらのフォルダ（チャートと呼ばれる）を設定できる機器ですが、さらに：一緒に適用してロールバックします。
• チャートはしっかりしているように見えます。 変数をサポートして再利用しましょう。 現在、チャートはインフラストラクチャではなく、インフラストラクチャテンプレートです。
• チャートは素晴らしく見えます。 友達とシェアしましょう。 チャートを更新するたびに、インデックス付きのファイルリポジトリにチャートをプッシュする必要があります。

だから、それは素晴らしく、すべて、パッケージなしで感じます。 したがって、このチャートを適用してから、アプリケーションのバージョンを提供する必要があります。 そしてそれはそれであるはずです。

しかし、問題が発生します。どのアプリバージョンにどのチャートが必要かを誰も覚えたくないのです。 どのチャートが更新されて、どのアプリバージョンの新しい構成値が提供されるか。

結局のところ、必要なのは「myAppバージョン1.4.2をK8sアプリとしてセットアップする」ことです。これにより、すべてのリスク、依存関係、変更が1つのアーティファクト（アプリケーションインストーラー、つまりapps versions + hooks + setup logic + infrastructure to connect it allカプセル化されます。 これが、MSI、Deb、RPM、さらにはNPM、Go mod、Pip、Gemなどがある理由です。

ここでPackageが登場します。 また、パッケージは、定義上、CI / CDフロー内でインストール可能なリリースとして作成する必要があります。 そのため、システム（k8sクラスター）のレジストリやセットアップに送信できます。

そして、他のプロジェクトも違いはありません。 パッケージなしで直接helm installチャートを作成する場合も、同じことを行います。 ただし、パッケージを作成する代わりに、別の手順で作成します。 アプリ構築プロセスで構築するのではなく、リリースステップで構築します。 インフラストラクチャとアプリのバージョンは引き続き連携しています。 暗黙的に。

面白いことは：

• 依存関係の更新=インフラストラクチャテンプレート（チャート）のバージョンを更新
• アプリの更新=インフラストラクチャテンプレートのサブセットであるフォークを生成します（グラフ）-独自のバージョンのパッケージ

それでも、k8sオペレーターは現在の問題を予測する必要があるため、オペレーターのように機能するが、ヘルムのように簡単なリリースプロセスを提供する機器は1つだけにする必要があります。

何かご意見は？ ここで何か新しいものを作成している可能性がありますが、より良い

あなたが説明していることは、あなたが制御できないインフラで他の人々によって使用されることを意図されているアプリケーションにとって非常に理にかなっています。 ただし、エンタープライズシナリオでは、パッケージの作成が忙しくなります。共有環境またはCookieカッター環境にデプロイされ、リポジトリ自体に存在するCI / CDパイプライン定義により、数十のCookieカッターマイクロサービスが存在する可能性があります（考えてみてください）。 azure-pipelines.yaml）、「パッケージバージョン」は、マスターブランチの特定のバージョンから生成されたビルドです。 つまり、「パッケージ」をどこにでも保存する必要はありません。ビルドでは、構成マップなどで使用される同じビットと同じ変数を使用して同じパッケージが生成されます。このようなシナリオでは、ヘルムチャートを回転させるのは次の場合のみです。サービスインフラストラクチャの変更。これはめったに発生しません。 ヘルムがこの写真にあるのは、1）インフラストラクチャの一部（nginxなど）をデプロイするためにすでにそれを使用する必要があるためです。2）テンプレートk8syamlでホイールを再発明する必要がないためです。

@wasker

たとえば、dockerに投影してみましょう。 Dockerイメージもパッケージです。 バイナリをOSイメージ=インフラストラクチャと結び付けます。 ビルドを作成するたびにDockerイメージを作成する理由は、ヘルムパッケージを作成する理由と同じだと思います。

すべてをDockerイメージに抽象化する必要がない場合は、Dockerを必要とせず、プレーンVMで動作できます。

したがって、Dockerの使用状況をhelmに投影しようとすると、helmをインフラストラクチャ機器としてのみ使用することは、dockerのみを使用して初期イメージを作成し、新しいバイナリを送信してk8sホスト自体でそのようなイメージを更新することと同じです。 それは悪いことです。ヘルムを使用し、毎回再パッケージしないのと同じ種類の悪いことです。

とにかく、私たちは間違った方向に進んだと思います。 ヘルムを使用してから手動で画像を更新する人はいますか？ 私は、3つの一般的なユースケースがあると信じています。

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

@waskerどちらがあなたのものですか？ 私は、3番目ではないと信じています。 インフラストラクチャ構成とアプリケーションのバージョン管理を実際に分離したとしても、作業するのは面倒です。 つまり、インフラストラクチャを更新する必要がある場合、すべてのバージョンが失われることを意味します。 チャートで手動で更新するか、展開ごとにkubectl set imageを更新する必要があります。

つまり、2番目のhelm install chart 、「パッケージなし」について話します。 だから、舵は常に絵の中にあります。 問題は、パッケージがビルドされていることですが、実行時にアプリをデプロイするときです。 したがって、CIビルドは、デプロイする必要があるときに、暗黙的にパッケージの作成を担当します。

そして、それをgolangに投影する場合、そのようなプラクティスは、ソースコードを送信し、それをビルドしてバイナリを使用するのではなく、Dockerでgo runとして実行するように見えます。

したがって、パッケージ化の手順をスキップ単純化することです。 それですか？

ここから話し始めることができます。 ここでhttps://github.com/helm/helm/issues/3555#issuecomment-529022699が私の提案です。 helm runを追加し、 go runとしてモデル化します。

インフラストラクチャとアプリのバージョン管理を本当に分割する必要がある場合、それはインフラストラクチャへの更新/シードにのみhelmを使用することを意味します。 これを行う方法を見たいのですが、更新時に頭痛の種を追加しない方法を見ることができます。 現在のデプロイメントのバージョンなどは無視できます...しかし、それは非常に間違っていると感じており、作成するのは時間の無駄になります。

たとえば、dockerに投影してみましょう。 Dockerイメージもパッケージです。 バイナリをOSイメージ=インフラストラクチャと結び付けます。 ビルドを作成するたびにDockerイメージを作成する理由は、ヘルムパッケージを作成する理由と同じだと思います。

問題は、新しいDockerイメージを作成している場合、そのイメージ内の何かが変更されているためだと思います。 ここで説明するシナリオでは、パッケージ化されたHelm Chartの内容は、アプリのバージョンである1行を除いて変更されていません。 これは最終結果に影響しますが、それ自体のヘルムチャートの動作は変わりません。 同じことを同じように、異なる値で実行します。アプリのバージョンが変更された結果として、エンティティとしてのヘルムチャートは少しも変更されていません。 それの終わりにリリースされるものだけが持っています。

Dockerイメージの構成を使用するなどの機能を使用して、ここで類似点を描くことができます。 環境変数をDockerイメージに渡します。これは、実行時の実行方法に影響し、イメージを再構築してこれらの変数を変更することはありません。 画像の内容は変更されていませんが、最終的には非常によく似た状況になりますが、その場合の動作は望ましく、正常です。

そして、それをgolangに投影する場合、そのようなプラクティスは、ソースコードを送信し、それをビルドしてバイナリを使用するのではなく、dockerで実行するように実行するように見えます。 [...]したがって、パッケージ化の手順をスキップする本当の理由は、エンジニアの全体像を単純化することです。 それは...ですか？

私の見解ではありません。 現実的には、ここでの議論は、アプリのバージョンを「チャートの一部」と見なすかどうか、また、ヘルムチャートをチャートの結果としてデプロイされるDockerイメージとは異なると見なすかどうかです。 これについての私の見解は、私が上で述べたことです。 これは、コンパイルされたGoバイナリをDockerイメージで取得し、いくつかの異なる環境変数で実行するようなものです。

そうは言っても、Helm Chartを新しいアプリケーションバージョンで再パッケージ化し、Chartバージョンをある種の「スーパーバージョン」として使用するために行われた議論は説得力があります（つまり、互換性のあるアプリバージョンを常に展開するという利点がありますグラフ-アプリケーションのバージョンが値でカスタマイズできない場合）。

私の質問は-_なぜ両方のアプローチをサポートしないのですか？_それぞれのアプローチには賛否両論があります。 基本的に、これをサポートしないことは、いくつかの完全に有効なワークフローをより困難にするだけです。 たとえば、FluxCDとそのHelmOperatorを使用します。 共有ヘルムチャートがある場合（つまり、多くをデプロイする特定のタイプのサービスがあり、それらが同じ特性の多くを共有しているため）、有用なhelm list出力を取得するには、新しいヘルムが必要です。各アプリのチャート、および各リリースには独自のヘルムチャートも必要です。 これだけでパイプラインが複雑になります。チャートを共有できれば、チャートが更新されたときにのみ実行される独自のパイプラインを持つことができ、アプリケーションパイプラインは単一のHelmコマンドを実行する必要さえありません（Flux CDがサポートを追加した場合）インストール/アップグレード時の新しいアプリバージョンフラグ）。

私の質問は、両方のアプローチをサポートしないのはなぜですか？

それがまさに私が考えていることです。

私の場合、「スーパーバージョン」はヘルムチャートではなく、多数のヘルムチャートを使用する別のレイヤーです。 私にとって、単一のヘルムチャートは、他の多くのサービスの中で小さなサービスしか説明していないため、意味がありません。 一緒になって初めて、意味のあるリリースを形成します。
したがって、私の場合、「スーパーバージョン」は、これらすべてのリリースをまとめたものです（実際にバージョン管理される方法です）。

それでも、ヘルムチャート自体を記述的な「スーパーバージョン」として持つことに向けた議論があります。

@seerukのポイントに戻る：両方をサポートしないのはなぜですか？

現在の議論では、外部の意見を聞くことが役立つかもしれません。 少しコンテキストとして、私は合計_ 11日間helmを使用しています。_これは、高度な学習に関与したことがないため、追加する独自の視点を与えてくれると思います。 私が収集したものはすべて、ドキュメントと実験から得られたものです。

ヘルムの見方

チャートではなくhelmのインストールパッケージに関するこの現在の議論を読むまで、Helmは主に関連するKubernetesリソースを記述するためのインターフェイスであると信じていました。 この信念は、主にこれを述べているヘルムのドキュメントから来ています：

HelmはチャートをKubernetesにインストールし、インストールごとに新しいリリースを作成します。 また、新しいチャートを見つけるには、Helmチャートリポジトリを検索できます。

コンテキストとして、現在の安定したヘルムのドキュメントには次のようにも記載されています。

チャートはHelmパッケージです。 これには、Kubernetesクラスター内でアプリケーション、ツール、またはサービスを実行するために必要なすべてのリソース定義が含まれています。 これは、Homebrew式、Apt dpkg、またはYumRPMファイルに相当するKubernetesのように考えてください。

だから今、いくつかの混乱があります！ Helmのドキュメントには、「チャートはヘルムパッケージである」と明確に記載されていますが、その場合、なぜhelm installはパッケージ化されていないチャートリポジトリを受け入れるのでしょうか。

ヘルムとは何か、そしてそれがどのように機能するかについての私の現在の見方に影響を与えたのは、この振る舞いです。

Helmは、クラスターに入る_what_の構造とそれらが持つ_whatプロパティ_の間のマッパーとして機能します。

さて、問題は「Helmは何を展開しているのか」ということです。

Helm Deployingとは何ですか？

helm install release-name ./local_chartを実行すると、helmがすべてのグラフテンプレートを指定された値（デフォルトまたはオーバーライドのいずれか）でローカルにレンダリングし、レンダリングされたバージョンをKubernetesにプッシュすることを期待しています。 また、ロールバックした場合に備えて、Helmが以前にデプロイされたKubernetesオブジェクトを保持することを期待しています。 （いくつかのメタデータを含む）「レンダリングテンプレート集」のこの概念は、リリースで、パッケージです。 これらのリソース定義はすべて（変更されていない場合でも）、リリースが存在する（またはロールバックされる）には、_バンドルに記述されている状態_である必要があります。

このことから、helmはパッケージを本当にデプロイするだけだと思い

_私の個人的な意味論_によって、この質問への答えはイエスです。 何かが変更されない限りバージョン番号を上げないという議論に従えば、いくつかの基礎となるプロパティが変更された場合にのみ、アプリケーションのバージョン番号を調整する必要があります。 これには、レジストリから別のDockerイメージをプルするか、環境変数を介して機能フラグを設定するか、コードアーティファクトの動作を変更するために使用できるさまざまな方法が含まれる可能性があります。

このため、レジストリのクリーンアップを開始し、開発中を除いて:latestからデプロイすることはあり

どのパターンを使用する必要がありますか？

これはすでにHelm： packagesによって意見が述べられてい

このパターンが100％明白でなくても--appVersionフラグが提供されることは論理的に一貫しているように見えます。 この「理由」に答えることはおそらく何よりも重要なので、私の貢献をその答えで締めくくりましょう。

--appVersionをサポートする理由

デプロイメントの特殊なケースを見てみましょう。

ある会社には、2つのメジャーバージョンのアプリケーションがあります。 この会社のクライアントの一部は、このアプリケーションの最新のメジャーバージョンへのアップグレードを確約しておらず、2つのうち古いバージョンを使用しています。 有料の開発契約があるため、ライブ開発は古いメジャーバージョンで引き続き行われます...しかし、製品は「同じ」です。 このアプリケーションの両方のバージョンにデプロイするインフラストラクチャは同じです。 ただし、アプリのバージョンは、これらの展開間で大幅に異なります。

この会社は何をしますか？

1. appVersionだけが異なる2つの別々のほぼ同一のヘルムチャートを作成しますか？
2. 1つのヘルムチャートを使用しますが、主要なアプリバージョン間でappVersionフロップを常に更新しますか？
3. appVersionをフラグ（現在サポートされていない）でオーバーライドすると、コマンドラインで開発者エラーが発生する可能性がありますか？
4. Chart.yamlからvalues.yaml appVersion再スコープしますか？

提案1は、他の提案よりもわずかに多くのオーバーヘッドを導入しますが、これらのアプリケーションバージョンのチャートが異なる場合は別々に保つという利点もあります。 明確なユースケースがあり、おそらくこの問題の多くの場合に採用されるでしょう。

提案2は、提案1よりもオーバーヘッドが少ないですが、チャートに高い変動性をもたらします。 helm install release-name https://remote-repo.com/chartを実行し、チャートの最新バージョンがアプリケーションの間違ったバージョンである場合はどうなりますか？ おっと。 おそらく最善のアプローチではありません。

提案3は私たちが現在議論しているものです。 私は個人的にこのオプションが嫌いですが、それは問題の間違った解決策だと感じたからhelm install release-name https://remote-repo/chartを実行したときに発生するのと同じ問題もあります。メタデータは一時的なものであり、Helmによってのみ維持されます。

提案4などをまだ提供している人がいないことに、私は実際にかなりショックを受けています。 appVersionをオーバーライドできる状態にし（ helm runに似たものを有効にする）、 helm packageによって生成されたパッケージに含めることができ、アプリケーションバージョンの概念を真に解きほぐします。ヘルムデプロイメントに結合されたappVersionの概念を維持しながら、チャートバージョンから（appVersionはどこか正しい必要がありますか？）。

これがお役に立てば幸いです。 👀このPR。

@jrkarnes ：ある意味で4）はすでに提案されており、多くの人が回避策として使用しています（https://github.com/helm/helm/pull/5492#issuecomment-517255692を参照）。 チャートテンプレートでは、次のようなものを使用できます。

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

これは、あなたが使用できるようになるappVersionでCharts.yamlで何かをデフォルトとして、それを上書きValues.yaml （呼び出しをインストール/アップグレード時に上書きすることができます）。 欠点は、たとえばhelm lsすると、 appVersionが表示されないか正しくないことです。

@BenjaminSchiborrこれについて教えてくれてありがとう。 私が言ったように、私は非常に限られた時間だけhelmワークスペース内にいるので、どんな知識もこの時点で私にとって

私の4番目の提案は少し誤解されていたと思います。 {{ default .Values.appVersion .Chart.AppVersion}}ようなものを使用するのではなく、 {{ .Values.Helm.AppVersion}}を使用し、 values.yamlはappVersion代わりにChart.yaml

@jrkarnes
それが今私が考えていることです。 たとえば、アプリのバージョンをユニークなスノーフレークとして扱う必要があるのはなぜですか。 チャートの値です。

この背後にある理由は簡単です。すべてがインフラストラクチャの一部です。 だから、インフラにはバージョンがあります。 なぜ2つのバージョン？

しかし、忙しすぎてサイドケースやプロジェクションに頭を悩ませることはできません。 しかし、一般的には、それが問題です。一言で言えば、それがすべてのインフラストラクチャであるのに、なぜアプリバージョンが必要なのですか？ または、チャートがインフラテンプレートのみの場合はインフラストラクチャバージョンとして、インフラにアプリバージョンが含まれる場合はアプリバージョンとしてチャートバージョンを使用できますか？

もう少し考えてみます

@jrkarnes
それが今私が考えていることです。 たとえば、アプリのバージョンをユニークなスノーフレークとして扱う必要があるのはなぜですか。 チャートの値です。

この背後にある理由は簡単です。すべてがインフラストラクチャの一部です。 だから、インフラにはバージョンがあります。 なぜ2つのバージョン？

基本的に、チャートバージョンをアプリケーションバージョンから分離しておくことは理にかなっています。 簡単な例は、これが事実であることを証明するためのおそらく最良の方法です。

ver 4.0.0バージョン管理されたチャートver 1.1.0実行されているアプリケーションがデプロイされているとします。 操作中に、このアプリケーションのcronタスクの実行を開始する必要があることに気付きます。 cronJobオブジェクトを作成してクラスターに適用するのではなく、このグラフを実行する他のユーザーもcronタスクを必要とする可能性があることに気付きます...そのため、グラフに追加します。 グラフはver 1.2.0進みましたが、グラフが管理するアプリケーションに変更はなく、 ver 4.0.0です。

その逆も同様に適用可能であり、このPRではすでに議論の対象となっています。

しかし、忙しすぎてサイドケースやプロジェクションに頭を悩ませることはできません。 しかし、一般的には、それが問題です。一言で言えば、それがすべてのインフラストラクチャであるのに、なぜアプリバージョンが必要なのですか？ または、チャートがインフラテンプレートのみの場合はインフラストラクチャバージョンとして、インフラにアプリバージョンが含まれる場合はアプリバージョンとしてチャートバージョンを使用できますか？

もう少し考えてみます

サイドケースやプロジェクションについて考えるのではなく、広く使用されサポートされている3つのエンジンバージョンがあるMySqlのようなものを考えてください： [5.6, 5.7, 8.0] 。 mysqlインスタンスをクラスターにデプロイするには、常に次のことが必要です。

• 選択したバージョンのMySqlのインスタンスを実行しているポッド
• ポッド（またはHAで実行されている場合はポッド）へのkube-dns解決を可能にするサービス
• ポッドが付随するPVCとともにデータを書き込むためのPV

MySql 5.6、5.7、または8.0をデプロイするためのチャートは、すべてのエンジン（アプリケーション）バージョンでます。 唯一の本当の違いは、アプリケーションのバージョンとDockerイメージ（おそらくエンジンのバージョンに応じて意味的にタグ付けされている）です。

アプリバージョンの「必要性」について疑問に思うことについて、あなたが何を意味しているのかわかります。 helm lsまたはhelm inspect実行する場合、それは開発者または運用の利便性に帰着すると思います。

@jrkarnesの最後の投稿に+1。 チャートバージョンは「インフラストラクチャバージョン」であるため、チャートバージョンとアプリバージョンを別々の概念として保持することには多くの価値があります。

他の人が使用できるようにグラフを公開している場合、グラフは、グラフに依存するプロジェクトのインフラストラクチャの一部になります。 ただし、自分のアプリケーションを他の人に使用させるつもりがない場合は、チャート自体が変更されたときに自分のチャートバージョンを時々改訂するだけですが、それ以外の場合は、アプリのバージョンがCIに準拠している必要があります。 / CD出力。 このフレーバーの使用チャートでは、回転数は比較的まれですが、アプリのバージョンはCIが発生するたびに回転します。 私のコードリポジトリは、このバージョンのコードを実行するために適用できるコードとインフラバージョン間の関係を維持します。つまり、 helm install last-known-good-chart-versionてデプロイメントをロールバックする代わりに、ポインターを使用してCDパイプラインを再実行するだけです。最後の既知の正常なコミットIDに。

@iorlas helm run提案を読みましたが、問題はありません。 インストールと実行の二分法は必要ないと思いますが、アプリのバージョンを変更可能にすることについてヘルムメンテナが安心できるのであれば、それで問題ありません。 :)

@iorlasこの提案で何をしたいのか考える機会がありましたか？

{{ default .Values.appVersion .Chart.AppVersion}}含む回避策がどのように機能するかを理解していないと思います。 このエラーが発生します：

エラー：YAMLからJSONへの変換エラー：yaml：無効なマップキー：map [interface {}] interface {} {"。Values.appVersion| default \" 0.0.1 \ ""：interface {}（nil）} [

これが私のChart.yamlです：

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

@IRobLこのスニペットをtemplates/deployment.yamlに入れる必要があります。ここで、バージョンが使用されます。 values.yamlようなファイルはテンプレートとして扱われません。

@jrkarnes私はhelmとそのpackagesを管理するための現在のアプローチを再評価します。

私たちが説明したアプローチを使用します：

• Helm Chartはアプリリポジトリの一部です
• アプリケーションビルドは以下
  
  
  
  • Dockerイメージ-> Dockerレジストリ
  
  
  • 静的ファイル-> CDNサービス
  
  
  • ヘルムパッケージ-> CIストレージ
  
  
• したがって、Helmパッケージがメインのアーティファクトであり、すべてのアプリケーションアーティファクトをバインドします
• 展開時に、 installはパッケージを言いました

現在の懸念：

• ビルドプロセスの複雑さ。
  
  
  
  • Dockerイメージと静的ファイルの代わりに、追加のファイル（ helm package ）が生成されます
  
  
  • go build / make install結果のファイル以外に何かが必要な主な理由は何ですか？
  
  
  • コストは何ですか？
  
  
  • なぜ応募するのですか？
  
  
  • いつ申請しますか？
  
  
• ビルド期間
  
  
  
  • 展開する必要がない場合でも、時間とお金を浪費します。 2〜5秒。 それほど多くはありませんが、無意味な仕事は無意味です。
  
  
• インフラストラクチャテンプレートの更新の複雑さ
  
  
  
  • チャートが更新されると、値も更新される必要があります
  
  
  • チャートは1つのリポジトリであり、値は別のリポジトリです。値を更新するたびに、少し頭痛がします。
  
  

このような再評価は、追加の簡素化とアイデアにつながる可能性があります。 表示されます:)
来週の金曜日にアップデートを送信します。

ああ、あなたが私のためにこれを指摘したので、なぜそのトリックがうまくいかないのかわかります、ありがとう。 これは、Helm 2.xを使用している多くの人にとって、ヘルムツールをこれらの種類のオーバーヘッドピースで快適にラップできると仮定して、うまく機能すると思うトリックです。

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

@IRobL

一般に、デプロイメントをsedでラップしている場合、それはテンプレートエンジンが必要なことを実行していないことを意味します。これが、この議論の全体的なポイントです。

gitlabが初期段階にあり、ヘルムをサポートしていなかったとき、私たちは文字通り、手作りのマニフェストファイルの置換ターゲットの値をsedしました。

このようなことは悪い習慣です。可能な限り、それから逃れることをお勧めします。

2019年10月7日には、15:33で、IRobL [email protected]書きました：

ああ、あなたが私のためにこれを指摘したので、なぜそのトリックがうまくいかないのかわかります、ありがとう。 これは、Helm 2.xを使用している多くの人にとって、ヘルムツールをこれらの種類のオーバーヘッドピースで快適にラップできると仮定して、うまく機能すると思うトリックです。

APP_VERSION = 0.0.7
sed -i.bak "s / ^ a ppVersion：。 * \\ $ / appVersion：$ APP_VERSION /" helm / Chart.yaml
helm install --name helm_demo helm /
—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示するか、スレッドをミュートしてください。

@jrkarnesは、悪い習慣を言うとき、 helmコマンドをスクリプトでラップする必要があるのは望ましくないと言っていますか？ もしそうなら、私は完全に同意します。 --app-versionフラグを追加することに反対しているわけではありません。 それどころか、それはヘルムへの非常に便利な追加になると思います。 明らかにこのPRに基づいて、展開されている実際のビルドとappVersion変数の一貫性を維持したいhelmを使用しているのは私だけではありません。 私はたまたま、さまざまなビルドツールをラップして再現可能なビルドを生成する再利用可能なビルドパイプラインライブラリを開発しています。これは、大規模な技術組織では一般的な方法です。 私のユースケースでは、パイプラインライブラリがDockerコンテナをビルドして公開し、最終的にアプリケーションのビルドパイプラインからヘルムを介してデプロイします（たとえば、3番目のPRの最初のビルドのアプリバージョン1.0.1-pr-3.1を検討してくださいアプリ。バージョン1.0.1のプレリリースになる可能性があります）。

この問題が私の会社のビルドパイプラインライブラリで回避された後でも、Helmに--app-versionスイッチが組み込まれている方が間違いなく快適です。 展開を処理するためのより柔軟な方法のように感じます。 つまり、外部システムまたはエンジニアが、誤って数値を台無しにすることができないビルドプラットフォームによって自動化できる場合、すべてのデプロイの前にChartファイルにアクセスしてyamlを更新する必要があるのはなぜですか？ 私の見解では、appVersion機能は組織によって完全に放棄される必要があります。または、「ずさんな」 sed回避策をパイプラインライブラリコードに追加する必要があるため、この問題を解決していた他の人。

@IRobL
一般に、ユーティリティは、それ自体の抽象化レベルで自給自足である必要があります。十分なAPIを提供することにより、解決する問題を抽象化する必要があります。 ヘルムも例外ではありません。 したがって、動作をカスタマイズする必要がある場合は、最初に質問する必要があります。それは、アーキテクチャ、設計原則に沿っているのでしょうか、それとも何かが足りないのでしょうか。

これが、このPRがそれほど簡単に解決されなかった理由です。 以来、修正は明らかですが、Helmの設計と一致していません。 そのため、一時的な解決策はほとんど提供されていません。

そして、あなたはapp-versionフラグについて正しいです。 あなたはそれを提供するべきです、そしてそれからヘルムはそれ自身ですべてを扱うべきです。

質問してもいいですか？ 製品でHelmをどのように利用していますか？ helm installを使用する場合？ どのくらい正確に使用しますか？ helm package使用を検討しましたか？

昨夜、 helm packageをもう一度見てみました。 私はそれで本当に売られていませんでした。 sedは非常に長い間存在しており、非常に安定しています。 これらすべてのtiller / package / installサブコマンドは比較的新しく、安定性が低くなっています。 私の主張を明確にするために、数か月前、ティラーの必要性を回避する誰かのプラグインを見たにもかかわらず、「ティラーがうまくいくことを確認する」ことに決めました。 私はプラグインをそれほど主流ではなかったに違いないものと見なしていましたが、それ以来ずっと自分自身を蹴っています。 プラグインを信頼していたら、今よりもはるかに良い立場にいるでしょう。 Helmのメンテナは、それが保守不可能な設計であり、将来のリリースで廃止されることに同意していることを確認しています。

これらの単純なsed操作を行うためにhelm packageを使用するのは私の側の間違いだと思います。 とにかくpackageユースケースは何ですか？ 現代のテクノロジーグループが同じプロセスを達成するためにタグ付けの力を活用しているとき、 helm package概念全体が、そもそもバイナリzipにパッケージ化することにより、Web 2.0 /バージョン管理リリースのポイントを見逃しているように感じますしかし、よりスリムで監査可能な方法で。

私のユースケースでは、アプリ開発者がコンテナ化されたアプリケーションをコード化して保守可能な方法でデプロイできるようにしているため、オーバーヘッド（ops /ティラーシステム管理者、冗長リリースアーティファクト管理など）を最小限に抑えることが最も重要です。 私の使用法は、Unixの哲学に厳密に従っており、ツールを最適な方法で使用することを決定し、必要に応じて他のツール（sedなど）に切り替えます。 すべてを完璧に実行するためのツールが1つ見つかるとは思いませんが、現在のワークフローに満足している場合は、自分の哲学に従うことを思いとどまらせないでください。

@IRobL

悪い習慣を言うとき、helmコマンドをスクリプトでラップする必要があるのは望ましくないと言っていますか？

はい。 これは正確に。

私のユースケースでは、パイプラインライブラリがDockerコンテナをビルドして公開し、最終的にアプリケーションのビルドパイプラインからhelmを介してデプロイします。

これはまさに私たちが行っていることでもあります。

この問題が私の会社のビルドパイプラインライブラリで回避された後でも、Helmに--app-versionスイッチが組み込まれている方が間違いなく快適です。

これをさらに一歩進めて、 appVersion Chart.yamlファイルのプロパティにするのはおそらく正しくないと言います。 値をその場で変更できる場合は、「不変の値セット」と見なされる値に含めるべきではありません。 以前のコメントで同じことを主張したと思います。

これらのtiller / package / installサブコマンドはすべて比較的新しく、安定性が低くなっています。

FWIW、 TillerはHelm 3では問題になりません。これについては、投稿の後半でほのめかしました。 ただし、これを繰り返します。これは、「kubernetesバイナリ」を作成してTiller出荷するhelm package構文がおそらく悪い習慣であることを示しているためです。

これらの単純なsed操作を行うためにhelmパッケージを使用するのは私の側の間違いだと思います。 とにかくパッケージのユースケースは何ですか？

私はおそらくこれについてヘルムチームを擁護することができます。 私が主導権を握っているのは、アプリケーション開発者にKubernetes内からアプリケーションを正しく実行する方法を指定させる方法でした。 そのため、アプリケーションプロバイダーは独自のHelmリポジトリを実行します。このリポジトリを追加して、展開の特定のバージョンをダウンロードできます。 Helmチームは、アプリケーションコードとインフラストラクチャコードが絡み合っていると考えていました。これは、対象となる本番チームがCI / CDのように日常のワークフローでHelmを使用することはなかったためです。 例：1日に平均130回helm upgradeを使用します。 それが意図された用途ではなかったと思います。

おそらく、「mysqlをkubernetesにインストールしたい」と言うのがはるかに一般的であり、helmは、kubernetesについてほとんど知らず、それをいじっているだけの人々にとって、（比較的）簡単な方法でした。

したがって、 helm packageは、最終的には_そのオーディエンス_によって消費されることを目的としていました。 このツールは、チーム（私が思うに）がツールを手に入れるとは信じていなかったか、またはツールをそのまま使用することを意図していなかった領域で、間違いなく多くの使用が見られています。

私の使用法は、Unixの哲学に厳密に従っており、ツールを最適な方法で使用することを決定し、必要に応じて他のツール（sedなど）に切り替えます。

私は基本的にHelmをawkように扱い、その後にkubectl apply -fの束を付けています。 自動化されたツールで値を処理して人的エラーを回避する方がはるかにクリーンです。

あなたと私は同じ価値観をたくさん持っているように聞こえますし、似たようなことをたくさんしているかもしれません。

@IRobL

耕うん機

私にとって、 tillerは受け入れられません。 露出ポイントが1つ増えるため、セキュリティリスクが増え、最も重要なこととして、yamlファイルを適用する方法がもう1つ作成されますが、APIは異なります。 Tillerは、Helmパッケージの適用プロセスを保護および調整するように設計されていますが、非常に多くのリスクがあり、追加のソフトウェア（およびバージョン管理！）があります。 そのため、Helm the3rdは使用していません。

これらの単純なsed操作を行うためにhelmパッケージを使用するのは私の側の間違いだと思います。

あなたは私の主張を見逃していると思います。 もう一度やり直します。 sedは何のために作られていますか？ データのストリームを変換します。 変換の問題を抽象化し、特定の入力に対するAPIと結果を提供する必要があります。

sedコマンドが機能しない（つまり、正規表現に誤りがある）スクリプトを作成した場合はどうなりますか？ だからあなたは結論を出しました、それはうまくいきません。 sedが単独で機能しない理由を理解しようとしますか、それともperlスクリプトでパイプを1つ追加しますか？

すべてのソリューションに同じことが当てはまります。APIを提供し、入力を受け取り、出力を提供して、1つの問題を抽象化する必要があります。 ご存知のとおり、Unixスタイルです。

Helmに投影すると、リリースをバージョン管理してK8sにプッシュするように設計されています。 テンプレートを使用して構成をカスタマイズできます。 したがって、問題を観察しているので、バージョンを提供する必要があります。 Helmは、バージョンを管理するためのシンプルなメカニズムを提供し、ビルドの動作をカスタマイズする簡単な方法を提供します。 それでは、追加のソフトウェアで回避策を追加するのではなく、それがどのように機能するかを理解しようとしないのはなぜですか？

@jrkarnes

はい、私たちは両方とも同じような関心を念頭に置いて舵取りに近づいています。 packageコマンドのルートが、耕うん機によって舗装された間違いと絡み合っていることに気づいていませんでした。これらの洞察を私と共有していただきありがとうございます。

私は実際にこの機能が追加されなかった理由の歴史を検討し、なぜこの機能を追加できなかったのかについて2つの議論を見ました。1つは、すでにpackage定義されているため、追加すべきではないということでした。 install / upgradeでも定義する必要があります。 私はそれに同情しています、これは技術的負債の問題のように聞こえます。 技術的負債のない公的に使用されているソフトウェアのようなものはありません。 もう1つの理由は、Chart.ymlファイルがメタデータであり、更新すべきではないということでした。 それは奇妙なことに私を驚かせました...人々がヘルムチャートを開発するとき、確かに彼らは物事が変化するにつれてそのファイルを手動で更新するので、それ自体は不変ではありません。 Chart.ymlファイルは、コントラストが実際には不変であるデプロイメントオブジェクトを構築するため、パラメーターをhelmバイナリにフィードする方法として表示する方が簡単です。

ところで、あなたのビルドプラットフォームは何ですか？ 私が書いているパイプラインコードは、グローバルパイプラインライブラリとしてJenkins用に書かれています。

@IRobL重要な問題は次のとおりです

ヘルムはパッケージャーです。 Helmは、展開を容易にするように設計されています。 アーティファクトから「インストーラー」を作成するため、OS（K8s）に「インストール」できます。

app-versionでinstallハイテク債務とは何の関係もありません。 installまたはupgradeしたい場合は、まったく必要ありません。 Chart.yml同じです。 これはデフォルトの構成ファイルであり、実際のチャートのバージョンが含まれているため、まったく変更しないでください。ただし、チャートはソフトウェアではありません。 あなたはそれを間違って使用しているだけです。

その観点から、 package使用を検討してみませんか？ それはあなたにとって複雑すぎるように見えますか？

この問題についてはしばらくの間ループから外れていましたが、この種のポイントが数回発生するのを見てきました。

ヘルムはパッケージャーです。 Helmは、展開を容易にするように設計されています。 アーティファクトから「インストーラー」を作成するため、OS（K8s）に「インストール」できます。

基本的に、Helmはインストーラーを作成しません。 「バイナリ」は作成されません。 「.deb」ファイルなどに類似したものは作成されません。 Kubernetesマニフェストのいくつかのテンプレートのアーカイブを、いくつかのデフォルト値やプリセット値とともに作成します。 実際のソフトウェアは、そのヘルムチャートには存在しません。 同梱されていません。 不変であるとは限りません。

ほとんどの場合、Helm Chartは、Chartを介して展開しているソフトウェアよりも変更が少なくなると言っても過言ではありません。

これが、 --app-versionがhelm installとhelm upgradeで利用可能になる根本的な理由です（少なくともIMO）。 文字通り何も変わっていないのに、なぜチャートを再度パッケージ化する必要があるのですか？

ヘルムチャートは、Kubernetesマニフェストのバージョン管理された説明であり、アプリケーションを正常に実行する一連のKubernetesコンポーネントを説明していると思いますが、それだけです。 これらの手順を変更する必要がある場合は、チャートを更新したいときです。アプリケーションが変更されるたびに更新する必要はなく、画像バージョンを更新するだけで済みます（とにかく値を使用して設定することがよくあります）。

たとえば、Fluxと、HelmOperatorがどのように機能するかを見てみましょう。 画像タグの値を自動的に更新するように設定できます。これにより、グラフは更新されず、デプロイされている画像タグのみが更新されます。

Kubernetesマニフェストのいくつかのテンプレートのアーカイブを、いくつかのデフォルト値やプリセット値とともに作成します。

ただし、debファイルは、構成ファイル、コマンド、マニフェスト、および/またはプリセット値の同じセットです。 MSIインストーラーと同じか、より近いものでさえ、gentoemergeパッケージシステムでebuildします。 また、Brewパッケージと同じです。

では、K8sのパッケージマネージャーではない場合、Helmとは何ですか？ あなたが見る違いは何ですか？

不変であるとは限りません。

なぜだめですか？ パッケージの生成後にパッケージを変更すると、それは間違っています。 install/upgradeプロセス中に追加のオプションを提供する場合は、すべてのパッケージングシステムと同様に意図されています。

ヘルムチャートは、Kubernetesマニフェストのバージョン化された説明として表示されます

すでに1つあります-GIT。 では、なぜヘルムが必要なのですか？

ほとんどの場合、Helm Chartは、Chartを介して展開しているソフトウェアよりも大幅に変更が少ないと言っても過言ではありません。
これが、helmのインストールとhelmのアップグレードで--app-versionを使用できる基本的な理由（少なくともIMO）です。 文字通り何も変わっていないのに、なぜチャートを再度パッケージ化する必要があるのですか？

この設計では、appVersionはHelmPackageビルドの属性として扱われるべきではありません。 値では、構成パラメーターとして扱う必要があります。

たとえば、Fluxと、HelmOperatorがどのように機能するかを見てみましょう。 画像タグの値を自動的に更新するように設定できます。これにより、グラフは更新されず、デプロイされている画像タグのみが更新されます。

この場合、アプリインフラストラクチャマニフェストとアプリバージョンの結合が緩くなります。 以来、画像タグを変更しても、新しいヘルムのアップグレードはトリガーされません（Fluxの人が他の方法で行っている場合は修正してください）。 その場合、構成テンプレートとしてHelmを使用します。 その場合、 --app-versionはまったく必要ありません。

ただし、debファイルは、構成ファイル、コマンド、マニフェスト、および/またはプリセット値の同じセットです。 MSIインストーラーと同じか、より近いものでさえ、gentoemergeパッケージシステムでebuildします。 また、Brewパッケージと同じです。

ここでの.debおよび.msiパッケージの説明には、インストールされている実際のものという1つの重要なコンポーネントがありません。 .debファイルの内容を見ると、ビルドされたソフトウェア、つまりインストールされる_THE_ソフトウェアが見つかります。 一般的に言えば（常に.deb ？の場合）、デプロイされるアプリケーションは本質的にリンクされており、そのパッケージの一部です（brewの場合はそうではありません）。

醸造パッケージは異なり、同じように実際には比較できません。 Brewは、実際にはHelmに非常によく似ています。これは、Brewをインストールする方法と、ソース/パッケージをどこからダウンロードするかについての指示にすぎないためです。

ここで絶対に明確にするために; Helm Chartは、_特定のアプリケーションバージョンに本質的に関連付けられておらず_、デプロイされているアーティファクト（つまり、Dockerイメージ）を含んでいません。 それへの参照のみが含まれ、その参照の背後にある値も変更できます（つまり、必要に応じて、同じDockerタグにプッシュできます）。 したがって、何があっても、Helm Chartはアプリケーションのパッケージ化されたバージョンではなく、特定のバージョンのアプリケーションにも厳密にリンクされていません。

例として、安定したチャートリポジトリを確認するだけです。 値を介して使用されている画像をオーバーライドできるアプリケーションはいくつありますか？ （たくさん_）

では、K8sのパッケージマネージャーではない場合、Helmとは何ですか？ あなたが見る違いは何ですか？

これは、Kubernetesマニフェストをテンプレート化し、それらを簡単に配布およびインストールする機能を備えたツールです。 ここで重要なのは、Helmが扱うのはそれだけです-Kubernetesマニフェスト。

これはすべて私の要点に戻ります。これらのマニフェストが変更された場合、または何らかの理由でこれらのマニフェストのテンプレートを変更する必要がある場合は、ヘルムチャートを実際に変更する必要があります。

私が目にする主な問題は、2つのユースケースがあることです。

• サードパーティアプリケーションの展開。
• ファーストパーティアプリケーションの展開。

サードパーティのアプリケーションの場合、Helmコンシューマーとして、HelmChartが新しいアプリケーションバージョンごとにリリースされることが望ましいです。 ここでの重要な違いの1つは、リリースの頻度です。 MySQLなどのサードパーティのHelmChartは、1日に数回変更されない可能性があります。 この場合、古いバージョンのグラフを新しいバージョンのソフトウェアで誤って使用することも望ましくありません。自分で作成していないソフトウェアやグラフを使用すると、間違いを犯しやすくなります。

ファーストパーティアプリケーションの場合、アプリケーションのクラスを展開する標準的な方法がある場合があります。 たとえば、Icelollyでは、Goサービスをすべてほぼ同じ方法で作成およびデプロイしています。 そのために、KubernetesにデプロイされているすべてのGoサービスに対して、現在1つのチャートを実際に使用できます（現在、 helm package回避策を使用しています）。 独自のアプリケーションをデプロイするためのアプローチが変更された場合は、グラフを更新します。 チャートはSemVerでバージョン管理されているため、更新されないアプリケーションは、更新するまで影響を受けません。

このメモだけです。 go-serviceチャートは、約1か月前に最後に更新されました。 その間、おそらく数十から数百の展開がありましたが、そのすべてがチャートを変更することはありませんでした。

あるケースでは、単純さが必要なだけです。 それ以外の場合は、制御と管理のしやすさが必要です。

この場合、アプリインフラストラクチャマニフェストとアプリバージョンの結合が緩くなります。 以来、画像タグを変更しても、新しいヘルムのアップグレードはトリガーされません（Fluxの人が他の方法で行っている場合は修正してください）。 その場合、構成テンプレートとしてHelmを使用します。 その場合、-app-versionはまったく必要ありません。

Fluxは、チャートのアップグレードに使用する値を実際に変更してから、新しいイメージ値でアップグレードを実行します。 インフラストラクチャマニフェストとアプリバージョンの結合を失うことについてのあなたのポイントはまだ立っています。 私が主張しているポイントは、いくつかのユースケースではそれが事実であることが実際に望ましいということです。 確かに、このユースケースでは、 --app-versionは必要ありません。現在存在しないため、使用されません。 もしそうなら、多分フラックスはそれを使うことができるでしょう。 その場合、それは実際に役立つでしょう。

helm listは便利なコマンドです。 デプロイされているアプリケーションのバージョンを確認できることは、確かに有用です。 helm packageアプローチでHelmを介して現在インストールされているアプリケーションの場合、 helm list出力が次のようになるようにアプリケーションバージョンのみを設定します（ helm package --app-versionを介して）。使える。 そのため、 helm install|upgradeに設定できれば、もっと簡単になります。 バージョンを変更するためだけに、チャートをフェッチして再パッケージ化する必要はありません。

実際、 helm listとロールバックの処理が、ファーストパーティソフトウェアにHelmを使用している唯一の理由である可能性があります。

ここでの.debおよび.msiパッケージの説明には、インストールされている実際のものという1つの重要なコンポーネントがありません。

「インストール」は、ターゲットプラットフォームに必要な機能（フォルダ、構成、バイナリ、データベースのフェッチ、データの更新/移行）を設定するプロセスです。

debはそのすべてを処理します。 Helmパッケージもそうです。 Helmパッケージが「実際にインストールされていない」とはどういう意味ですか？

.debファイルの内容を見ると、ビルドされたソフトウェア、つまりインストールされるソフトウェアが見つかります。

誤り。 時々あなたはソフトウェア自体を見つけるでしょう。 時々あなたはいくつかのソフトウェアの断片を見つけるでしょう。 そのようなソフトウェアをフェッチするための一連のスクリプトしか見つからない場合があります。 したがって、ここでの重要なポイントは重要ではありません。LinuxとK8は特定のアプリケーションをホストするプラットフォームであり、1つのユニバーサルアプリケーション形式を受け入れるからです。 そして、イメージ名、構成パラメーター-はパッケージの一部です。

Brewは、実際にはHelmに非常によく似ています。これは、Brewをインストールする方法と、ソース/パッケージをどこからダウンロードするかについての指示にすぎないためです。

その通り。 ブリューはパッケージマネージャーではないことを私に納得させようとしていますか？

ここで絶対に明確にするために; ヘルムチャートは、本質的に特定のアプリケーションバージョンに関連付けられていません...
値を介して使用されている画像をオーバーライドできるアプリケーションはいくつありますか？ （たくさん）

あなたは、絶対に正しい。 Helmは、k8sテンプレート用の便利なテンプレートエンジンにすぎません。 私はそのようなソフトウェアの存在に問題はありません。それは少し役に立ちますが、現代の配信慣行を変えることはありません。

問題は、Helmはテンプレートエンジン以上のものであるということです。 それはパッケージングマネージャーであり、すべての長所と短所があります。 また、パッケージマネージャーが存在するエコシステムでは、他のパッケージマネージャーが何かを管理することは悪い習慣です。 さらに悪い-パッケージマネージャーなしで動作します。

これらのパッケージのパッケージ引数としてアプリバージョンを作成する理由がわかります。 そして、私はあなたとあなたたち全員がパッケージを作る必要がない理由を理解しています。 問題は、それが時代遅れで、複雑で、アプローチを管理するのが難しいということです。 おかしなことに、コストは小さいですが、それを素晴らしいものにしましょう。

私が主張しているポイントは、いくつかのユースケースではそれが事実であることが実際に望ましいということです。

うん、これが中心点です：それはどんな製品にとっても望ましいですか？

ヘルムチャートはめったに変更されないというあなたの主張は、リリースごとにまとめる必要があるのはなぜですか。 私はあなたに同意します、それは冗長に感じます。 ただし、とにかく、古いソースファイル、古いサイドカー（Helmが複数のアプリで構成されている場合）、古い構成、古いDockerfileをパッケージ化します。

したがって、問題は、チャート全体をアーティファクトとしてパッケージ化する場合、ビルドごとに、どのようなメリットがあるかということです。 Dockerfileの場合、それは明らかです（ただし、コンテナー化が市場に登場したときは明らかではありませんでした）。 ソースファイルの場合も。

昔は、可能な限り明確な配信メカニズムがありました。変更されたファイルのみをFTP経由でアップロードしていました。 今、私たちはたくさんのものを持っています。 何が良いのか、なぜそれが良いのか、誰がそれを使うべきかを決める必要があります。 Helmが両方のアプローチを同時に処理することに満足できるかどうかはわかりません-複雑すぎます。

サードパーティアプリケーションの展開。

Helmチャートのみを使用してPSQL / MySQLバージョンをインストールできれば、とてもうれしいです。 レガシープロジェクトを維持し、初心者にインフラストラクチャを導入する方がはるかに簡単です。 チャートの更新について通知を受けるのはさらに簡単です。 バイナリのリリースごとに非常に多くのtar.gzファイルがあるのに、Helmパッケージ用に同じtar.gzファイルのセットを使用できないのはなぜですか？

@iorlas私はこれと拒否されたPRを読み

しかし、ヘルムにパッケージコマンドがあることすら知らなかったので、私は一人ではないと思います。 これはおそらく、ソースディレクトリからチャートをインストールするのがとても簡単であるためですが、ドキュメントは実際には概念を販売しておらず、詳細に説明していません。

packageコマンドは明らかに文書化されていますが、クイックスタートガイドにはパッケージに関する非常に一般的な言及がいくつかあります。実際、パッケージという言葉はクイックスタートに多く表示されますが、主にHelmとさまざまなOSパッケージのインストール方法について説明しています。 。 パッケージングもベストプラクティスで言及されていないので、パッケージングとは何か、なぜそれが役立つのかを把握することをそこに含める必要があると思います。 また、構造が少し異なるv3ドキュメントも確認しましたが、ユーザーがチャートをパッケージ化することを提案することについてもスリムなようです。

通常、私はPRを提出したいと思っており、何かについて不平を言っているように聞こえるだけでなく、3.0のドキュメントの変更で何が起こっているのかわかりません。

@jonstellyドキュメントには間違いなくギャップがあります。 最初は--app-versionがいいと思っていたのですが、理由がないので見逃せませんでした。

ドキュメントには、いくつかの説明と一般的な問題の紹介が必要です。 次に、ヘルム開発サイクルの紹介。 しかし、私はチームが第3バージョンで忙しいと信じています。 そして、私も今忙しすぎます:(

「インストール」は、ターゲットプラットフォームに必要な機能（フォルダ、構成、バイナリ、データベースのフェッチ、データの更新/移行）を設定するプロセスです。

debはそのすべてを処理します。 Helmパッケージもそうです。 Helmパッケージが「実際にインストールされていない」とはどういう意味ですか？

Helm Chart自体がインストールされていないという意味ではありません。つまり、Helm Chartには、デプロイしている実際のアプリケーションが含まれていません。 DockerイメージはHelmチャートにパッケージ化されていません。 これは、Kubernetesによって外部ソースから取得されます。

誤り。 時々あなたはソフトウェア自体を見つけるでしょう。 時々あなたはいくつかのソフトウェアの断片を見つけるでしょう。 そのようなソフトウェアをフェッチするための一連のスクリプトしか見つからない場合があります。 したがって、ここでの重要なポイントは重要ではありません。LinuxとK8は特定のアプリケーションをホストするプラットフォームであり、1つのユニバーサルアプリケーション形式を受け入れるからです。 そして、イメージ名、構成パラメーター-はパッケージの一部です。

私の知る限り、実際にはあなたはここで間違っています。 .debファイルはARアーカイブです。 あなたはそれを抽出して内容を見ることができます、そして最終的にそれはいくつかのメタデータといくつかのファイルです。 .debファイルには理論的にはパッチが含まれている可能性がありますが、含まれていないことがよくあります。 .debファイルにソフトウェアをフェッチするためのスクリプトが含まれている場合、それはソフトウェア自体ではなく、 .debファイルによってインストールされているスクリプトであることを意味します。 これは、インストーラーをインストールするようなものです。

.debにパッケージ化されたLinuxソフトウェアの例がある場合、 .debは、 .debファイルをインストールするプロセスの一部としてインストールするソフトウェアをダウンロードします。 、それなら私は本当にそれを見たいと思っています-それは私がLinuxを長年使用してきた中で文字通りこれまで出会ったことがないものだからです。

その通り。 ブリューはパッケージマネージャーではないことを私に納得させようとしていますか？

いいえ。私が言っているのは、Helmのように、Brewを介してソフトウェアをインストールするために提供されるスクリプトはまさにそのスクリプトです。 アプリケーションは個別に構築、パッケージ化、配布され、それらのスクリプトによって取り込まれます。 私が言っているように、Brewがパッケージマネージャーを少なくすることはありません。HelmがKubernetesパッケージマネージャーを少なくすることはありません。 それはこの問題のポイントではありませんが、Helmがパッケージマネージャーであるかどうかについては議論していません。 --app-versionフラグをhelm install|upgrade追加する必要があるかどうかを判断しようとしています。一般的なユースケースを容易にするための

これらのパッケージのパッケージ引数としてアプリバージョンを作成する理由がわかります。 そして、私はあなたとあなたたち全員がパッケージを作る必要がない理由を理解しています。 問題は、それが時代遅れで、複雑で、アプローチを管理するのが難しいということです。 おかしなことに、コストは小さいですが、それを素晴らしいものにしましょう。

申し訳ありませんが、これが何を意味するのかわかりません。 時代遅れ/複雑/管理が難しいものは何ですか？

したがって、問題は、チャート全体をアーティファクトとしてパッケージ化する場合、ビルドごとに、どのようなメリットがあるかということです。 Dockerfileの場合、それは明らかです（ただし、コンテナー化が市場に登場したときは明らかではありませんでした）。 ソースファイルの場合も。

繰り返しになりますが、違いは基本的に、あなたが言及したものはすべて本質的に関連しているということです。 アプリを実行するには、変更されたものだけでなく、すべてのソースコードが必要です。 Dockerfileをパッケージ化していないので、そのポイントが何であるかはわかりませんが、新しいバージョンのイメージをビルドするために、変更せずに同じDockerfileを使用することがよくあります（つまり、毎回手動で何かを変更する必要がある場合は、自動化に煩わされるのはなぜですか？時間ですよね？） そのようなものすべてを使用して、必要なものすべてをカプセル化するものを作成し、それを分離して展開できるようにします。 したがって、新しいノードを起動して、既存のノードにデプロイするのと同じ方法でそのノードにデプロイするなどのことができます。

FTP経由の古いアップロードを使用することについては、すでにご存知のとおり、多くの特典があります。

とにかく、これはすべてbyによるものです。 すでに述べたように、最終的には、私の意見では、これはすべてです。 Helmのメンテナは、この他のユースケースを有効にしたいのでしょうか、それとも人々がこのように使用するのをより困難にしたいのでしょうか。 結局のところ、どちらにしても大きな違いではありません。 私にとっては、アプリケーションのバージョンを設定するためだけにビルドごとに変更されることはめったにない内部チャートをパッケージ化する必要がなく、リストに現在のバージョンを表示するためだけに使用されると便利です。 ファーストパーティのアプリについては、正直に言うと、Helmがとにかく正しいアプローチであるかどうか疑問に思っています。

DockerイメージはHelmチャートにパッケージ化されていません

実はそういう風になりたいです。 しかし、今はそうではありません。 私のビジョンは、K8sは、パッケージをインストールするためのAPIとしてHelm（Helmは存在しない）を組み込むプラットフォームになる/すべきであるということです。アーカイブにコンテンツをパックしてインストールする必要があります。 debファイルの単純さに戻りますが、第一級市民として適切な分離とk8sリソースを使用します。

.debファイルはARアーカイブです
抽出して中身を見ることができます
そして最終的にはそれはいくつかのメタデータです
といくつかのファイル

のように....ヘルムパッケージ！

.debがあり、.debファイルをインストールするプロセスの一部としてインストールするソフトウェアをダウンロードする.debがある場合..。
これは、インストーラーをインストールするようなものです。 ..。

はい、それは内部にインストーラーを持っているインストーラーのようになります。 おかしいですよね？ アプリインスタンスをセットアップするのに十分であれば、可能であれば1つのアーティファクトを

• BrewにはYAMLがパッケージとして含まれていますが、リモートストレージからバイナリをフェッチします
• Emerge（gentoo）には定義としてebuildがあり、gitクローンもダウンロードします

Debianはすべてを内部にパッケージ化しようとします。 そして、可能であれば、それは正しいことです。 しかし、私の主張を証明するために、

しかし、要点をお見逃しなく：それは問題ではありません！ 参照のみが含まれる空のパッケージでさえ、パッケージです。 多分あなたは別の用語、インストーラーを受け入れるだろうか？

私が言っているのは、Helmのように、Brewを介してソフトウェアをインストールするために提供されるスクリプトはまさにそれです-スクリプト
アプリケーションは個別に構築、パッケージ化、配布され、それらのスクリプトによって取り込まれます

そして、Dockerイメージを構築するための同じパイプラインがあります。

一般的なユースケースを容易にするために、helm install | upgradeに--app-versionフラグを追加する必要があるかどうかを判断しようとしています。

それが鍵です。 しかし、どうすれば決定できますか？ 2つの質問をする必要があります。

• 出来ますか？ はい
• それは正しいことですか？ はい？ 番号？

何かをしているpplがいる場合、それはそれが良いことであることを意味しますか？ 進歩を遂げるためには、すべてに疑問を投げかける必要があります。

申し訳ありませんが、これが何を意味するのかわかりません。 時代遅れ/複雑/管理が難しいものは何ですか？

ブリューはヘルムに非常に近く、すでに広く使用されているので、ブリューに投影してみましょう。 Gentroo Ebuildsまたはdebに投影できますが、画像は変更されません。

• 時代遅れ。 MySQL / PSQLを手動で最後にインストールしなければならなかったのはいつですか？ なぜ私たちはそこから移動したのですか？ これらの理由、芽。
• 複雑。 これは「理由」の1つです。インフラストラクチャを個別にセットアップする必要があり、どのソフトウェアバージョンでどれが最適に機能するかを知る必要があります。 特定のソフトウェアバージョンを実行するには、インフラストラクチャをカスタマイズする必要がある場合があります。 なぜわざわざ？ 質問全体を委任しないのはなぜですか？
• 管理が難しい。 アーティファクトが1つしかない場合は、インフラストラクチャとアプリの両方のバージョンを管理する必要があります。 なぜあなたの人生を難しくしているのですか？

申し訳ありませんが、クリーンなロールバック、優雅なアップグレードなど、すべてのユースケースを説明するのは今のところ怠惰ですが、とにかくこれらが主なボーナスです。

繰り返しになりますが、違いは基本的に、あなたが言及したものはすべて本質的に関連しているということです。

常にではない。 たとえば、DockerイメージにSSRBEとCDNへの参照を含めることができます。

Dockerfileなので、そのポイントが何であるかはわかりませんが、新しいバージョンのイメージを構築するために変更せずに同じDockerfileを使用することがよくあります（つまり、毎回手動で何かを変更する必要がある場合は、なぜ自動化に煩わされるのですか？）。

それがポイントです。 Dockerfileを変更しない場合でも、新しいイメージをビルドします。 ソースコードが変更されていないが、Dockerfileが変更されている場合は、新しいイメージをビルドします。 つまり、一言で言えば、Dockerfileもパッケージです。 ヘルムについても同じことが言えます。 そう思いませんか？

そのようなものすべてを使用して、必要なものすべてをカプセル化するものを作成し、それを分離して展開できるようにします。 したがって、新しいノードを起動して、既存のノードにデプロイするのと同じ方法でそのノードにデプロイするなどのことができます。

しかし、Dockerイメージはアプリを実行するのに十分ではないことがわかりました。 構成インスタンスが必要であり、サービス定義が必要です。 すべてをパッケージ化してみませんか？

結局のところ、どちらにしてもそれほど大きな違いではありません。

そうだと思います。 たぶんそれはコードベースでの取引の多くではありませんが、それはコンテナ化の進化を停滞させるでしょう。

DockerイメージはHelmチャートにパッケージ化されていません

イメージ自体はパッケージ化されていませんが、参照（ピンとして読み取られます）はパッケージ化されています。 確かに、私たちは衒学者であり、さまざまなサイズ（MBからGBまで）の文字通りの画像がhelm packageのアーティファクトに含まれているかどうかに巻き込まれる可能性があります（ネタバレ：そうではありません）が、本質「アプリケーションのコードの特定のバージョンがhelmパッケージに含まれている」というステートメントは、基本的に正しいものです。 どのように巻き込まれたいかどう

例の世界に戻って、 1.2.5バージョン管理されたチャート上で実行されている1.9.9として内部的にバージョン管理されたアプリケーションがあるとします。 混乱しないように、アプリケーションコンテナのDockerイメージshaはfakeshaAです。

チームは、アプリケーションのバージョン2.0.0に、HTTP経由で参照する必要があったファイルのローカルファイルシステムバージョンがあると判断しました。 この理由は重要ではありませんが、あなたへの影響はかなり深刻です。 ここで、これらのローカルファイルがアップグレード間で失われないように、デプロイメントにpvとpvc必要です。 必要に応じて、Helmチャートを更新して、このpvとpvc使用し、 2.0.0への移動がそれほど混乱しないようにします。

グラフを変更する前に、アプリケーションバージョン1.9.9をインフラストラクチャバージョン1.2.5リンクするArtifact Aがあります。 ここでチャートを変更します..._ヘルムチャートはv。 1.3.0 _になり、 1.9.9をインフラストラクチャバージョン1.3.0リンクするアーティファクトを生成します。 これをArtifact Bと呼びます

2.0.0のコードデプロイメントがDockerイメージsha fakeShaBでライブになると、 2.0.0をインフラバージョン1.3.0リンクする別のアーティファクトを作成します。 これはArtifact C

ここで、2.0.0リリースでは完全に理解しておらず、ロールバックする必要があるという問題があることが判明したとします。 Artifact Bを使用してロールバックします...しかし、これでは問題が解決しないため、もう一度Artifact Aロールバックすると、問題は解決します。

発生する唯一の問題は、アーティファクトが参照するDockerレジストリに、それらのアーティファクトで参照されているイメージがまだあるかどうかです。

いずれにせよ、アプリケーションのバージョンとインフラストラクチャのバージョンの間にあります。 これがヘルムの目的です。 そうでなければ議論するのは愚かです。

@iorlas ：

.deb比較は取っておきましょう。 それは私たちが脇道に追いやられているだけだと思います。

常にではない。 たとえば、DockerイメージにSSRBEとCDNへの参照を含めることができます。

それは非常に真実です。 それについては後で詳しく説明します。

それがポイントです。 Dockerfileを変更しない場合でも、新しいイメージをビルドします。 ソースコードが変更されていないが、Dockerfileが変更されている場合は、新しいイメージをビルドします。 つまり、一言で言えば、Dockerfileもパッケージです。 ヘルムについても同じことが言えます。 そう思いませんか？

あなたはそうしますが、それはそのビルドプロセスの最後の製品（つまりDockerイメージ）がDockerfileとそれに入れているものの両方に依存しているためです。 これらの2つの要素がなければ画像は存在できません。

一方、Helmチャートは、アプリケーションが構築される前、つまり文字通り1行のコードが記述される前に存在する可能性があります。 インストールに失敗する架空のものを作成することもできますが、それでも、ヘルムチャートは他に何もなしで完全に存在する可能性があります。 私が言ったように、これは役に立たないでしょう、しかし私はそれらが全くリンクされていないという私のポイントを説明しようとしているだけです。

ここでの私のポイント、およびそれがこの特定の問題にどのように関連しているかは、ヘルムチャートがチャートによって展開されているアプリケーションに本質的にリンクされているとは限らないということです。 私はそれが大胆な主張だとは思いません、それは起こります-それはすでに事実です。 私は現在本番アプリケーションでそれを行っているので、この問題についてコメントしている他の人もいます。 だから私が前に言ったように、これはすべてに帰着します。 Helmのメンテナは、このユースケースを有効にしたいのか、そうでないのか。他に何もありません。

しかし、Dockerイメージはアプリを実行するのに十分ではないことがわかりました。 構成インスタンスが必要であり、サービス定義が必要です。 すべてをパッケージ化してみませんか？

実はそういう風になりたいです。 しかし、今はそうではありません。

これが事実であり、Helm Chartが実際にデプロイされたすべてのものをパッケージ化した場合（前述のCDNについて言及しましたが、それをKubernetesにデプロイしていないため、チャートにはまだ含まれていません）、この会話は起こらないでしょう。 Helmチャートは、Dockerイメージを構築するのと同じように、デプロイされるアプリケーションバージョンに本質的にリンクされます。 そのシナリオでヘルムチャートを作成するには、アプリケーションが変更されたときにそれを再構築する必要が

しかし、それは現実ではありません。 それはヘルムがどのように機能するかではありません、そして私はそれが実際にどちらかになることになるかどうかわかりません。 しかし、決して決して言わないでくださいね？

@jrkarnes ：

イメージ自体はパッケージ化されていませんが、参照（ピンとして読み取られます）はパッケージ化されています。

もちろんですが、一般的なユースケースは、値を使用してこの値をオーバーライドすることです。 サードパーティのチャートとファーストパーティのチャートの両方で使用しました。 それが人々が使用するものでなければ、それは選択肢ではないでしょう。

確かに、私たちは衒学者であり、さまざまなサイズ（MBからGBまで）の文字通りの画像がヘルムパッケージのアーティファクトに含まれているかどうかに巻き込まれる可能性があります（ネタバレ：そうではありません）、

すでに指摘したように、Dockerイメージが「構築された」ヘルムチャート内にパッケージ化されていると言うのは事実上正しくありません。

「アプリケーションのコードの特定のバージョンがhelmパッケージに含まれている」というのは基本的に正しいことです。

しかし、実際にはそうではありません。私の最初のポイントとして、反対するでしょう。 展開するものを変更できます。 必要に応じて、ほとんどのグラフを変更してhello-world画像を実行できます。 それは役に立たないでしょうが、それは私の主張をうまく証明しています-ヘルムチャートはあなたのアプリケーションにリンクされていません。 正しい画像で使用するという_期待_があり、おそらくデフォルトで使用できますが、確かにそうする必要はありません-そして、他の方法でパッケージ化されたヘルムチャートに含まれるアプリケーションのコードです。

例の国に戻って、[...]そして問題は解決されました。

明らかに現在意図されている方法でHelmを使用しないと、これは不可能であるように聞こえるようにしました。 ただし、実際には、チャートの2つのバージョン（つまり、2つのインフラストラクチャバージョン）と3つのバージョンのアプリケーションを使用できます。 ロールバックしたい場合は、それを実行します。デプロイするチャートとイメージを非常に簡単に選択できます。 チャートでHelmを実行し、画像に応じて値を設定すると、すべて設定されます。

いずれにせよ、アプリケーションのバージョンとインフラストラクチャのバージョンの間にはリンクがあります。 これがヘルムの目的です。 そうでなければ議論するのは愚かです。

物事がどのように変化するかを議論する（理想的には議論する）ことは、物事を改善することにつながることが多いと思います。 Helmの「目的」は、チャートとアプリケーションバージョンをリンクすることではないと思います。 KubernetesマニフェストをDRYで再利用可能に保ちながら、アプリケーションをKubernetesクラスターに簡単かつ安全にデプロイできるようにすることが目的だと思います。 チャートとアプリケーションのバージョンを厳密にリンクする必要はありません（現在の実際のように、リンクする必要はありません）。

繰り返しになりますが、 ように、問題は、Helmが適応する必要があるかどうかです。 このユースケースを有効にしない理由は何ですか？ 理由が「現在はないため」である場合、私に言わせれば、それはかなり悪い理由です。 これまでのところ、この議論のどれもこの質問に答えていないようです。

...そのビルドプロセスの最後の製品（つまり、Dockerイメージ）は、Dockerfileとそれに入れるものの両方に依存します。 ...これらの2つのコンポーネントがないと画像は存在できません。

つまり... Helmパッケージにはチャートとアプリバージョン（= Dockerイメージ）が必要であり、それなしでは存在できません。

ヘルムチャートは、アプリケーションが構築される前、つまり文字通り1行のコードが記述される前に存在する可能性があります。 ...ヘルムチャートは他に何もなしで完全に存在する可能性があります。 私が言ったように、これは役に立たないでしょう

面白いことに、あるプロジェクトでは、スタブDockerイメージを使用してプロトタイプアーキテクチャを作成していました。 私たちは文字通り、1行のコードを記述せずにチャートを使用しました。 また、サブチャートのみで構成されるチャートを作成することは常に実行可能なケースです。

したがって、私の仮説は次のとおりです。HelmパッケージはDockerイメージではほとんど役に立たない。 Dockerイメージは、ソースコードではほとんど役に立ちどちらもパッケージのようなオブジェクトです。

しかし、私はそれらがまったくリンクされていないという私の主張を説明しようとしているだけです。

うん、うん！ それは本当に素晴らしいことです。私たちはpplがすべてを詳細に議論する準備ができています。 あなたがいなくても、予測や主張がなくても、私たちは将来の麦汁を生きることはできません😃

私はそれが大胆な主張だとは思いません、それは起こります-それはすでに事実です。 ...前に言ったように、これはすべてです。 Helmのメンテナは、このユースケースを有効にしたいのか、そうでないのか。他に何もありません。

実際。 そのような変更を行い、受け入れるためには、それを評価する必要があります。

話をさせてください。 マティーニは素晴らしい、広く使われているウェブフレームワークでした。 その理由は、投資する時間の不足ではなく、ライセンスを持っている一部のシェナニガンではありませんでした。 したがって、未来を明るくする唯一の方法は、フレームワーク全体を非推奨にし、一部の人を怒らせ、一部のプロジェクトを孤立させ、一部の人に自分のしていることを再評価させることでした。

だから、私はこのアプローチに反対しているわけではありません。 私はそれがどのように生きることができるかを理解しています（ helm run私の提案を参照してください）。 しかし、私たちには介入を行う機会があり、おそらく手遅れではない間に業界全体を修正する機会がありますが、私はそれぞれの使用法を評価し、不利な点や問題について話し合います。

そのシナリオでヘルムチャートを作成するには、アプリケーションが変更されたときにヘルムチャートを再構築する必要があります

うん。 今でもそうかもしれません。 push代わりにDockerイメージのsave / loadを実行するパイプラインが1つあります。 そして、それは非常にうまく機能します。 今は気が進まないのですが、基本的にはもっときれいな方法です。 問題は、K8sが「スターター」（Dockerイメージ）を転送するためのバスとしてリモートDockerレジストリを必要とすることです。

焦点を絞りましょう、みんな

Helmチャートは、Dockerイメージを構築するのと同じように、デプロイされているアプリケーションバージョンに本質的にリンクされます。

これがここでの重要な違いです。 そして@seerukはそれを釘付けにしました。 そして、それに集中することができます。 それを事実に言い換えさせてください：

1. DockerImageはHelmパッケージにバインドされていません。 それへの参照のみ。
2. これにより、これらのパスを個別に解放する機会が与えられます。

重要な質問：

1. 独立したアプローチのリスクは何ですか？ （つまり、一部のDevOpsがそれを使用する場合、それに対してどのような議論をするか）
2. パッケージングアプローチはそれをどのように解決しますか？
3. コストは何ですか？
4. この特定の質問で、コンテナ化の将来をどのように見ていますか？

@seeruk ：

繰り返しになりますが、 ように、問題は、Helmが適応する必要があるかどうかです。 このユースケースを有効にしない理由は何ですか？ 理由が「現在はないため」である場合、私に言わせれば、それはかなり悪い理由です。 これまでのところ、この議論のどれもこの質問に答えていないようです。

あなたは多くの素晴らしい説明とポイントを作ります。 個人的には、ヘルムは適応すべきだと思います。 CI / CDは、ソフトウェアの構築方法の未来であり、正直なところ、 --atomicような扱いで、ヘルムは信頼性の高い展開ツールとしてすでにより柔軟になっています。 しかし、この問題はかなり古いものなので、PRをマージすることはプロセスの「次のステップ」ではないと思います。

この特定の--app-version機能に対してhelm-ci-cdが実行可能であると言うプラグインを作成しますか（ @jrkarnesはおそらくPR寄稿者としてこれにhelm-ci-cd他の適切な候補であり、CI / CDpplがラッピングによってすでに統合しているinstall/ upgrade二重性に見えます。

--app-versionスイッチが直接的な付加価値ではない場合でも、テンプレートファイルを確認せずにk8sアプリをインストールしようとしているエンドユーザーにとっては、これは実際にはうまくいきませんでした。仕事のk8sインフラストラクチャに準拠するためにネットワークポリシーを追加する必要があるため）エンドユーザーは、構築を安定させるヘルムci / cd機能により、チャートを作成した人が簡単に作成できるため、より多くの価値を得ることができます信頼性の高いソフトウェアが簡単になります。

Chart.yamlをgroovyで読み込んでから、アプリのバージョンを設定し、デプロイ時にファイルを上書きします。 次に、ヘルムのアップグレードを行います。 それが舵の一部であるならばそれは素晴らしいでしょう、しかし私はそれを当てにしません。

Googleでこれを見つけました。 実は同じ船。

verison:がチャートバージョンである場合、チャートのYAMLが変更されるとこのバージョンが変更されることを意味します。 グラフは構成可能な値を持つテンプレートであるため、グラフのYAMLファイルを変更することなく、グラフ1.3を使用して複数のバージョン（1.2、1.3、1.6、1.8など）のアプリをデプロイできると考えて間違いありません。

Chart.yaml内にハードコーディングされたappVersion:で提供されるようになりました。デプロイされたアプリケーションのバージョンを更新（および反映）するために、チャートファイルを編集する必要があります。

チャートテンプレート内で使用できる--app-version CLIオプションが確実に必要であり、_application_のバージョンを参照して、同じversion: 1.3.0チャートで異なるバージョンをデプロイします。

@seeruk

Helmの「目的」は、チャートとアプリケーションバージョンをリンクすることではないと思います。 KubernetesマニフェストをDRYで再利用可能に保ちながら、アプリケーションをKubernetesクラスターに簡単かつ安全にデプロイできるようにすることが目的だと思います。

これが私たちの論点であり、私たちのどちらかがもう一方を納得させることはないと思います。 専門家の設定では、意見の問題になると、和解できない違いがあるのは「大丈夫」な場合があります。 私は確かにストールマンが言うすべてに同意しません、そして私たちが彼と私が同意しないすべてについて塹壕に入るならば、私たちは合意に達する前に死ぬでしょう。

私はそれを議論の中でさらに上に述べました、そして私はそれが繰り返されることに耐えると思います：

[...] helmは本当にパッケージをデプロイするだけだと思います。 それはあなたが言うことができる唯一の意味的に正しいことのようです。 ただし、これらのパッケージがどのように配布されるかについての議論は、実際のこの議論の根本的な原因のようです。 具体的には、「アプリのバージョンをアップグレードまたは変更することは、新しいパッケージを構成しますか？」

構成なしのファーストパーティヘルムチャート（MySQLを使用するのが好きなので、これからも使用し続けます）は、チャート作成者が説明し、意図したとおりにリソースをクラスターにインストールする必要があります。 mysqlの実際のチャートを見ると、実際のmysqlエンジンに関連して構成可能な2つのプロパティがあります。

• image （デフォルトmysql ）
• imageTag （デフォルトは5.7.14 ）

次に、 Chart.yamlファイルで：

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

appVersionとデフォルトのimageTagは一致しないことに注意してください。 helm listを実行すると、「アプリのバージョン」（読み取り;エンジンのバージョン）が_クラスターにインストールされている実際のアプリのバージョンを反映していない_状態であるというレポートが表示されます。

チャートとアプリケーションのバージョンを厳密にリンクする必要はありません（現在の実際のように、リンクする必要はありません）。

これは正しいです; 私の意見では、設計上の欠陥があります。

繰り返しになりますが、 ように、問題は、Helmが適応する必要があるかどうかです。

はい。 いくつかの提案については、すぐに説明します。

@IRobL

プラグインを作成しますか？たとえば、helm-ci-cdはこの特定の--app-version機能で実行可能ですか（ @jrkarnesはおそらくPRコントリビューターとしてこれに

あなたはあなた自身の質問に次のように答えます：

--app-versionスイッチが、テンプレートファイルを確認せずにk8sアプリをインストールしようとしているエンドユーザーにとって直接的な付加価値ではない場合でも、エンドユーザーは、安定した信頼性の高いソフトウェアの構築を容易にするhelmci / cd機能により、チャートの構築はより簡単に行えました。

関数を正しくするためにプラグインとしてそれを行う必要がある場合、私はそのアプローチを提唱します。 しかし、それは間違った問題に対処していると思います。 @seerukに先に述べたように、 appVersion不変のChart.yamlファイルの固有のプロパティにすることは、設計上の欠陥だと思います。 appVersionの特性であるimageチャートを介してクラスタにインストールされ、それはそので参照画像から何らかの方法で導出されるtag 。

helm-ciプラグインについて考えるとき、他にどのような機能やアドインが必要だと思いますか？ 不変のChart.yamlプロパティからappVersion切り替えるだけでは、プラグインであることを保証するのに十分な付加価値があるとは思いません。

@IRobLと@seerukを一緒に：

私たちの異なる意見は、ヘルムのより一般的なエンドユーザーであると私たちが見ている人から来ていると思います。 エンドユーザーが、多くの構成を行ったり、テンプレートを掘り下げたりすることのない人であると想定される場合、 helm lsは特に有用ではない可能性があり、要点は重要ではありません。

ただし、ヘルムを管理ツールおよびクラスターを管理するためのアシスタントとして使用している場合、またはより多くのCI / CDコンテキストでヘルムを使用している場合、 --appVersionスイッチは非常に多くなります。より有用であり、したがって懸念事項（および構成）、

完璧な世界では、 appVersionは派生プロパティであり、Dockerイメージメタデータから取得する必要があると私は主張します。 これは、ヘルムが行うことは不可能です、エルゴ、競合の欠如。

私が言ったことに

はい。 すぐにいくつかの提案に対処します...
... helm-ciプラグインについて考えるとき、他にどのような機能やアドインが期待できますか？

私は良い出発点になるかもしれない個人的なリストを持っています：

• helmをCICDモードで実行しても、以前にリリースされたパッケージの状態が現在適用されているものと_only_比較されません。 。 代わりに、リリースのすべてのデプロイメントは、 upgradeが実行されるときにテンプレート化されたすべてのマニフェストを完全に適用します。
• helm-cicdは、基本のkubernetesコマンドをラップする必要があります。 helm describeまたはhelm logsを実行しようとした回数を数えられません。
• helm-cicdを使用すると、別のユーザーがコマンドを実行したときのコマンドの結果を確認できます。 RBACを使用している場合、認証されていないユーザーが何かを行おうとするとどうなるかを確認したいと思います。
• helm-cicdは、名前空間をマニフェストのコレクションに分解して、後で編集できるようにする必要があります。
• helm-cicdは、リリースを名前空間に_移植_できる必要があります。

それらは大きなものです...しかし、本格的なhelm-ciプラグインについて議論することは、このPR / Issueの範囲外です（現在）。

私はあなたたちがタイプするすべてを読みます、そして私は談話に感謝します。 ご返信をお待ちしております。

今の私の時間はかなり忙しいですが、いくつかの点であなたを訂正したいと思います。 @jrkarnes

appVersionを不変のChart.yamlファイルの固有のプロパティにすることは設計上の欠陥だと思います

そうではない。 何かがこのように作られ、別のものではない場合、それが野生のものであっても、常に理由があります。 この場合、それは私が立っているイデオロギーです：1つのパッケージ= 1つのビルド、チャート=ビルドのテンプレート、パッケージ=アプリ+インフラ。

Helmはこのイデオロギーに基づいて設計されており、K8をOSとして扱い、パッケージをアプリのインストーラー/アップデーターとして扱います。 いくつか問題があり、多すぎるように感じることもありますが、それは確かに未来です。

_なぜそのように設計されていると思いますか？ 同じhelm listが、インストールされている現在のパッケージバージョンを表示するように設定されてい

さて、新しいリリースが表示されるたびにパッケージを作成するためにビルドされていない多くのチャート（mysqlのようにパブリックとローカルのように）があります。 高レベルのソリューションへの移行には時間がかかるため、私はこのニーズに感心しています。 また、誰かがパッケージをビルドする必要があり、ビルドごとにHelmパッケージを作成するようにmysqlメンテナを説得するのは難しいでしょう。

MySQLチャートには、追加の問題があります。 そうです、MySQLバージョンがhelm listにインストールされているのを見る方が良いでしょうが、おそらくここのバージョンの一部であるImageタグもあるので、それはバージョンの一部にすぎません。

繰り返しになりますが、 ように、問題は、Helmが適応する必要があるかどうかです。
はい。 いくつかの提案については、すぐに説明します。

繰り返しになりますが、 helm runを追加するという提案がありました。これは、皆さんが探しているものです。 チャートをパッケージとして即座に使用し、アプリのバージョンなどを提供できるようにすることを目的としています。

完璧な世界では、appVersionは派生プロパティであり、Dockerイメージメタデータから取得する必要があると私は主張します。 これは、ヘルムが行うことは不可能です、エルゴ、競合の欠如。

Dockerイメージは、信頼できる唯一の情報源である最後のパッケージとして、最終製品として表示されています。 そうではない。 Dockerイメージしか持っていない場合、それが自分のソフトウェアであると信じ込ませることができます。 あなたがあなたのコードでモジュールを書いているとき、あなたはこのモジュールがあなたのソフトウェアであると信じるようにだまされます。

問題は、そうではないということです。 それはほんの一部、アーティファクトです。 小さな製品から大きな製品まで、多くのアーティファクトが結び付けられます。 ビルドプロセス内でdockerファイルのバージョンを渡す場合もあれば、複数のアーティファクトを結び付けるConfigMapを使用する場合もあります。 そして、すべてを含む1つのDockerファイルはありません。

私は良い出発点になるかもしれない個人的なリストを持っています

多くの提案があると思いますが、ワイルドなプラグインではなく、 Helmフォークの方がライブ感があります。 CDのCIだけとは関係ないと思います。 私はそのようなフォーク/プラグインを構築しないことを主張しますが、適切な解決策について話し合い、考え出します。 現在のコミュニティは今のところそれほど大きくないことを考えると、3つのヘルムフォークは必要ありません。

注目してください！

さて、私たちはあちこちで多くの考えを持っています。 最良のシナリオは次のようになると思います。

• アプリのバージョンを変更する機能、最初にパッケージを作成する必要はありません
• helm lsで適切なアプリのバージョンを確認する機能
• すべてのAPI（Helmオペレーターなど）が中間状態なしでアプリのバージョンを指定/アッ​​プグレードできるようにする

2つのアプローチが提供されています。

1. helm installは、パッケージをインストールするために作成されます。 チャートのインストールもサポートしていますが、制限があります。 helm installを単純化して、その目的を果たすために残しておきましょう-パッケージをインストールします。 次に、 helm run追加しましょう。これは、単純化されたフローを提供することを目的としています。 helm packageとhelm run組み合わせて、両方のコマンド引数を提供しますが、そのような場合に意味のないものを除外します。 。
2. app-versionをhelm install cmdに追加します。 これは、このAPIを肥大化させ、パッケージを使用するという考えを隠します。パッケージをインストーラーとして使用するというイデオロギーを隠します。これは、ほとんどではないにしても、少なくとも一部のプロジェクトにとっては完全に理にかなっています。

これらの両方のアプローチが私たちが今持っているすべての闘争を解決することに同意できますか？

プラグインは、コア開発者がサポートしたくない、またはサポートする時間がない、不足している機能の回避策であるため、プラグインであるかどうかは気にしません。

Helmはこのイデオロギーに基づいて設計されており、K8をOSとして扱い、パッケージをアプリのインストーラー/アップデーターとして扱います。

ああ。 わかった。 ヘルムチャート[パッケージ]は、Kubernetesの「rpm」[言うまでもなく]を意味します。 私が得た印象はまったくありません。helmはチャートを使用してアプリをデプロイします。 チャート/パッケージは「k8s用にフォーマットされた」アプリです。

私はそれで大丈夫です。 それは理にかなっています-新しいコンテナをビルドするときに、ビルドサーバーを更新してappVersionをアップする必要があります。

• ビルドコンテナ-タグ「v1.2」
• Chart.yamlを更新します--appVersion： "v1.2" --- helm package --app-versionコマンドもすでにあるようです。
• パッケージチャート： helm package --app-version v1.2 => package [chart] -v1.2.tgz（つまり、「package [chart] -v1.2.rpm」）
• デプロイメントサーバーを使用してパッケージをデプロイします。helminstallpackage[chart] -v1.2（apt install [email protected]など）

さて、私はこれのいずれかの理解に誤りがありますか？ package-v1.2がv1.2appVersionでない場合は、どうしてですか？ それが意図ではないでしょうか？ たとえば、rpmはアプリのバージョンであり、パッケージではありません（グラフ）。

編集：

package-v1.2がv1.2appVersionでない場合は、どうしてですか？ それが意図ではないでしょうか？

これで、Chart.versionとChart.appVersionが一致していると人々がコメントしている理由がわかります。 ここでは、引数は双方向になります...安定した「チャート」ビルドを備えたアプリ。package-v1.2でバージョン番号が変更されることが期待されます。 しかし、yamlファイルが変更されたときにpackage-v1.2がChartのバージョン番号になると主張することもできます。

増加するアプリバージョン（1.6）とは異なり、安定したチャートバージョン（1.2）をどのように管理しますか？ package-[version]は1.2になりますか？ または1.6？ Chartバージョン1.2をデプロイしたが、appVersionがパッケージ化で変更されたとします： 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

:(

....とても混乱します。

ヘルムチャート[パッケージ]は、Kubernetesの「rpm」[per-say]を意味します

その通り！ しかし、時にはそれが厳しすぎたり、面倒だと感じたりすることがあります。これはショートカットが必要な場所です。

さて、私はこれのいずれかの理解に誤りがありますか？ package-v1.2がv1.2appVersionでない場合は、どうしてですか？ それが意図ではないでしょうか？ たとえば、rpmはアプリのバージョンであり、パッケージではありません（グラフ）。

これは別の議論の問題ですが、現在、パッケージはアプリバージョンではなくチャートバージョンにちなんで名付けられます。 理由はわかりませんが、逆のはずだと思います。 これは歴史的な問題だと思いますが、私の考えでは、あなたと同じように、 package-{app-version}.tgzである必要があります。

以前のメッセージによると、バージョンには4つのコンポーネントがあります。

• チャート
• アプリ
• パッケージ
• リリース

これらすべてを個別にバージョン管理するのは頭痛の種ですが、それが現在の仕組みです。 1つの例外を除いて、パッケージはチャートバージョンの後にバージョン管理されます。

アプリをパッケージ化するというイデオロギーを選択する場合、同じプロセスでアプリ、イメージ、パッケージの両方が生成されるため、アプリのバージョンは完全に理にかなっています。 したがって、配信ステップに入ると、ファイルがどのように呼び出され、どのファイルをインストールするかが明らかになります。 今のところ、パイプラインでパッケージ名をハードコーディングする必要があります> _ <

@iorlas

Dockerイメージは、信頼できる唯一の情報源である最後のパッケージとして、最終製品として表示されています。 そうではない。 Dockerイメージしか持っていない場合、それが自分のソフトウェアであると信じ込ませることができます。 あなたがあなたのコードでモジュールを書いているとき、あなたはこのモジュールがあなたのソフトウェアであると信じるようにだまされます。

私はこの声明について考えるのに数週間かかりました、そして私はあなたに100％同意します。 さらに、私たちの意見の違いがどこから来ているのかがわかりました...

私は、一連のことを信じられないほどうまく実行する小さなコンポーネントからシステムを構築する必要があるという開発と展開の哲学に従います（UNIXを考えてください）。 ただし、最近のシステムでは、「アプリケーション」をこれらの小さなツールのグループとして扱う場合があります。 Dockerアーティファクトだけでなく、他のサブコンポーネント（Dockerアーティファクトの場合もある）に依存している場合、アプリケーションの「バージョン」をどのようにマークする必要がありますか？ このタイプのカップリングを投げ始めたとき、それはそれほど簡単な答えではありません。

この質問に答えることは、この問題/要求の範囲をはるかに超えています。 問題の根本に立ち返るために、 installとrun区別したいと思います。 セマンティクスの理由から、 installはパッケージに対してのみ動作する必要があり、 runは、テンプレートを生成して_状態を維持せずに_適用するプロセスを通じてヘルムを「実行」する必要があります。

多くの場合、将来のチャートがどのように展開されるかを確認するためにhelm templateを使用する必要がありますが、vi-ca-vi runが発生するのを監視することには多くの用途があります。開発パイプラインのスターになるという二重の目的（速度が非常に速い場合はパッケージに価値がないため、必ずしもパッケージを保持する必要はありません）。

MySQLチャートには、追加の問題があります。 そうです、ヘルムリストにMySQLバージョンがインストールされているのを見る方が良いでしょうが、おそらくここのバージョンの一部であるImageタグもあるので、それはバージョンの一部にすぎません。

私が言ったように、完璧な宇宙では、インストールされたオブジェクトのバージョンがイントロスペクトされます。 しかし、これは私にアイデアを与えます。

チャートがどのように展開されるかについて私が早い段階で言ったことを念頭に置いておくと、 helm describeフラグを付けてすべてのサブコンポーネントを広げることができたらどうなるでしょうか。 （フラグ付きのアプリバージョンを調整したいの原動力の一部である）それはアプリバージョンを指定する必要が解決しないが、それがインストールされている、まさにそれがより明確ありません。

私はすべてのコメントを読みましたが、この問題について完全に適格な意見を持っていません。

私の会社がプライベートHelmリポジトリを維持していて、チャートの90％が主に1つのコンテナ仕様を持つ1つのデプロイメントであるため、ここに到着しました。 このような場合、 appVersionを使用して画像のタグを一覧表示できれば、変数の重複を避け、このバージョンがhelm version実行していることを確認できます。

このスレッドを読んだ後、これは便利だと思いますが、マージされた場合に使用するのは本当に素晴らしいスレッドです。

リクエストに応じて、前のスレッドからの最後の返信を他の人が閲覧できるように含めます

うーん。 これは、 appVersionをDockerタグ（論理的な関連付け）に結び付け始めると、物事が互いに対立し始めるところです。 これは私たちが問題を抱えているところです、すなわち私が上で述べた開発シナリオ。 versionはSemVerである必要があるため、Dockerタグをグラフversionとして使用することはできません。

appVersionがチャートに表示されていない場合、開発者に視覚的なバージョンの違いをどのように作成しますか？

k8sがアプリケーションとどのように連携するかにより、開発者の世界では、タグバージョンを全面的に許可する方法がいくつかあります。

バージョンはセマンティクスなしで純粋に順序付けられていたため、〜または^演算子に関してSemVerのようなことはできませんでした。

なぜだめですか？ これは、php composerを使用して常に行います。 SemVerを使用することも、バージョン管理スキーマで単純に解析または無視される文字列バージョンを使用することもできます。つまり、 versionがSemVer番号でない場合は、 ~および^含めないでください。

＃7299についての私のコメントを引用し

.debおよび.rpmパッケージの場合、バージョン文字列は特定の方法で（ハイフンによって）分割されますが、「これはAPI互換です」などの意味的な意味がないため、「Give」のような式を生成することはできません。 SemVerの場合と同様に、「最新のAPI互換バージョンを教えてください」または「APIが変更されていない最新バージョンを教えてください」。

DebianとRedHatの両方がパッケージエイリアスを使用して、一般的にバージョン番号に基づいてこれらのユースケース（およびABI互換性）を実現したことを思い出します。 これにより、パッケージ名と順序付けのみの比較のみを使用して、合理的に一貫した動作が可能になりました。

一般的なトピックとして、製品にHelmチャートを使用する方法は、さまざまなサービスをパッケージ化することです。 ただし、Dockerイメージは単なるアーティファクトであり、その名前はサービスバージョンによって決まります。サービスバージョンでは、APIを提供するためSemVerを採用しています。

私たちのCIパイプラインは、コードと関連スクリプトのgitリポジトリを変換し、インストール可能なHelmチャートを生成し、Dockerイメージを参照します。 Dockerイメージのタグは、ユーザーにとって興味深いものではありません。 次に、それらが由来するgit SHAでタグ付けし、リリースで使用されたイメージにタグを付け直します。 再タグ付けの主な利点は、それらのタグを解除しないことを知っている一方で、短時間でgit-SHAバージョンのタグを解除できることです。

versionにはソフトウェアの正確なバージョンが含まれており、 appVersionには同じものが文字列として含まれているため、Helmの動作に非常に満足しています。 Dockerリポジトリで。

https://github.com/helm/charts/でチャートがバージョン管理される方法には少し不満がありチャートがソフトウェアではなくバージョン管理されているため、マイナーな（安定した）チャートがときどき発生するためですversionを、チャートに含まれているもののバージョンから分離すると、これは起こりやすく、回避するのが難しい結果だと思います。

内部の「外部で消費されるライブラリとアーティファクト」ページで、 stable / prometheus-operatorチャートにも同様の問題があります。 これにはさまざまなソフトウェアが含まれているため、「どのバージョンを使用していますか？」という質問があります。 特に「アップグレードしても安全ですか？」 私たちと同じバージョンのAgonesよりも答えるのがはるかに難しいです。

@jrkarnes

チャートがどのように展開されるかについて私が早い段階で言ったことを念頭に置いておくと、ヘルムにフラグが付いたすべてのサブコンポーネントを展開できるとしたらどうでしょうか。 これでアプリのバージョンを指定する必要はなくなりますが、インストールされているものがより明確になります（これは、フラグを使用してアプリのバージョンを調整することの背後にある原動力の一部です）。

絶対に見たいです。 たとえば、＃6932に関連する機能リクエストがあります。

ディスカッションを振り返ったところ、 appVersionがDockerイメージのメタデータに関連しているという考えは、少なくとも一部のグラフ（ユーザーが主に扱っているグラフ）のように、私たちのユースケースに完全には適合しません。 Dockerイメージは含まれていません。ほとんどの場合、共有リソース（JWT公開鍵、 values.yaml ）のホストに加えて、他のグラフを取得するためのrequirements.yamlれます。

appVersionがDockerイメージのメタデータに関連しているという考えは、少なくとも一部のグラフのように、私たちのユースケースには絶対に適合しません。

私はそれが意図された使用であったと言っているのではありません。 私はそれが論理的な関連であると述べただけです。 あなたはまだappVersionを内部yamlの「論理コンテナ」として使用しています。

versionをSemVerにロックすることでどのようなメリットがあるのか​​まだわかりません。 ヘルムはversion （およびappVersion ）を解析テストして、そこから先に進むことができますか？

私のポイントは、 appVersionをまったく使用していないことだと思います。通常、Chart.yamlには存在せず、存在する場合はversionと同じです。

versionをSemVerにロックする利点は、さまざまなSemVer演算子を使用でき、インストールによって順序付けと一致を生成するために確実に解析できることです。

RPMとDEBのパッケージングシステムは、バージョン管理システムが異なる構文を使用することを除いて同じものですが、セマンティック解析の理由から制限された構文です。 また、気になるセマンティクスも異なります。

helm / chartsリポジトリがどのように実行されたかを考えると、DEBまたはRPMスタイルのバージョンを持つ単一のversionフィールドは、SemVerとappVersion文字列よりも良い選択だったと思います。 しかし、それは完全に異なる、すでに航海された船です。 そして、私の若い頃はアップストリームベンダーとDebianパッケージャーの両方を務めていたので、「ここでバンプする必要があるバージョン番号はどれですか？」 私たちの「 versionは1つの真実です」パッケージで。

「SemVerの場合もある」の問題は、SemVerが、手書きで書いたものや、エポックのないDebianパッケージバージョンなど、他の場所で遭遇したものとパーサーで区別できない

こんにちは。 この機能に関するニュースはありません。

すべてのコメントを読んだ後、私はそれが本当に役立つだろうことがわかります。

実際、私たちの会社では、同じテクノロジーを使用し、同じ方法で展開される複数のアプリケーションを入手したため、重複を避けるために、異なるアプリケーションに対して1つのチャートがあります。
新しいチャートは、インフラストラクチャに変更があった場合にのみパッケージ化されます。
そして、特定の値をタグ、環境変数として適用するのは、リリースをアップグレードまたはインストールするときだけです...

パッケージ化されたヘルムチャートは、ある種類のアプリケーションに期待されるkubernetesリソースと構造を表す抽象化レイヤーであると考えており、「この種のアプリケーションをこれらの特定の値でその環境にデプロイしたい」と言うのは、デプロイ中のみです。

ヘルムリストにはリリース情報が表示されるはずなので、このリリース内でデプロイされたアプリのバージョンを確認できるはずです。

同様の問題にコメントを残しましたhttps://github.com/helm/helm/issues/7517
これをvalues.yamlでオーバーライドする機能を追加できますか？
次に、無料のコマンドラインオプションを取得します--set

私たちがどんなアプリケーションにもヘルムを使おうとすると、これは絶対にひどいことです。 本番アプリケーションにセマンティックバージョニングを使用する人は誰もいません。

同意します。 現在、不変の_application_ベースのチャートにChartMuseumを使用することはブロックされています。 チャートバージョン！=アプリバージョン。チャートミュージアムからのリリースは不可能です。

私は上記の議論の多く（すべてではない）を読んだので、いくつかのポイント/ビューを繰り返している場合は申し訳ありません。 もっと考え抜かれた対応を提案しようとしています。

helm lsを実行するときにappVersionを見るのが好きで、概念的に.Values.image.tagから移動するのは良いこと

（チャート） versionはチャートのバージョンであり、 appVersionはdockerタグであると確信しています。 CIプロセスでは、dockerタグはgitタグでもあります。
また、複数のマイクロサービスがあり、可能な限りドライな状態を維持したいと考えています。 java-springbootアプリの大部分は同じであるため、ローカルチャートリポジトリに汎用チャートがあります。 Tomcatアプリの大部分は同じです（ただし、springbootアプリとは異なります）。 他のテクノロジーについては、すすぎ、繰り返します。 次に、展開がさまざまな環境を通過するときに、環境価値があります。
これらの各マイクロサービスは、CI / CDを介して一般的なチャートを利用します
例えばhelm upgrade release-name private-repo/generic-chart --values <environment>.yaml --set image.tag=<docker tag from build step> --namespace <environment> --install私が使用することを好むだろう.Chart.AppVersionではなく.Values.image.tagが、私は私たちの組織のための効率的な方法で展開することができなければなりません。

helm lsを実行すると、 CHARTとAPP VERSION両方があるため、グラフのバージョン全体がアプリのバージョンと一致する必要があります。 そのルートを続けると、人々は疎外され、ある時点でプロジェクトは分岐します。なぜなら、その考え方は厳しすぎて、多くの人々が求めているものではないからです。 また、「 image.* 、 nameOverride fullnameOverride削除しましょう。image。*はdeployment.yamlなどにハードコーディングできます」というルートをたどり始めています。 非常に似た理由で。

最後のポイントは、多くのパブリックチャートは、使用するDockerコンテナのバージョンと正確に一致しないということです。 メジャーバージョンとマイナーバージョンがローリングタグであり、パッチバージョンのみがローリングされていないalpineやnginxなどの最もよく知られているDockerコンテナを見てください。 すべてのパッチバージョンに1：1のマッピングがあると、ほとんどまたはまったくメリットがないため、かなりのオーバーヘッドが発生します。
さまざまな理由で本番環境が最新バージョンにアップグレードできないことは珍しくありません。 本番環境でのローリングバージョンについては、ほとんどの場所に話さないでください。

上記のすべての結果は、「なぜヘルムはチャートリポジトリを使用できるのか」という疑問を投げかけます。
インストール/アップグレード時にappVersionを上書きできないということは、チャートをダウンロードして解凍するか、インストール/アップグレードごとにappVersion編集する必要があることを意味します。または、必要なDockerコンテナをにパッケージ化することもできます。チャート。
例外は、完全に標準的なインストールが行われている場合であり、パスワードの自動生成などをめぐってすでに多くの議論があります。
最後の段落は、うさぎの穴を下りて自分自身を隅に描いているように見えましたが、「appVersionはdockerタグであり、コマンドラインまたは値を介してappVersionを設定することはできません」というところです。

@timothyclarke ：ここで説明したhelm upgradeユースケースでは、最初にhelm packageを使用すると、 --versionと--app-versionを設定できます。 helm installにして、CIアーティファクトとして保持できます。これにより、 --setパラメーターを追加する必要がなくなるため、インストールの再現性が向上します。 チャートはジェネリックではないため、「ジェネリックチャート」の側面はありませんが、これに移行しました。

+g<shortCommitSHA>ようなビルドメタデータをVersionに追加する良い機会でもあります。

＃7517によると、CIテストクラスターにインストールする前にimage.tagを書き換えていた一連のsed呼び出しを削除し、後でパッケージ化するときに再び削除することができました。

このアプローチは、独自のチャートを作成している場合、特にチェックアウト時にチャートソースからインストールしている場合、ほとんどの人がここで直面している問題を実際に解決する可能性があります。 リポジトリからのチャートにこの機能が必要な場合は実際には役に立ちませんが、これはここにいるほとんどの人が直面している問題とは異なる問題だと思いますか？

私にとって、インストール時にアプリのバージョン（またはバージョン）をオーバーライドすることによるリスクは、チャートを再作成しようとしている他の誰かには、これが行われたほどはっきりと見えないことです。 値のサポートに何らかの形でハッキングされていない限り、 helm get values -o yamlを使用してグラフの現在の構成を抽出しても存在しないため、ライブグラフのデプロイが得られるものとは異なるものになります。 helm install <some way to specify a particular package> --values <values from helm get values> 、たとえば、テストセットアップで本番環境で見られる問題を再現しようとする場合。

私にとって、インストール時にアプリのバージョン（またはバージョン）をオーバーライドすることによるリスクは、チャートを再作成しようとしている他の誰かには、これが行われたほどはっきりと見えないことです。 値のサポートに何らかの形でハッキングされていない限り、 helm get values -o yamlを使用してグラフの現在の構成を抽出すると、そこには存在しません。

あなたは頭に釘を打ちました。 これは、初日からvalues.yml蜂がいるはずです。

私はこの機能に対する哲学的な議論を理解していますが、フィールドプラクティスは、それが私たちを含む人々に大いに役立つことを示しています。

特にここでは設定できないため、 values.ymlを介してアプリのバージョンを設定できるチャートが数多くあります。

それが議論されているかどうかはわかりませんが（Ctrl + Fをすばやく押してもトレースが見つかりませんでした）、代替ソリューションとしてappVersionまとめて削除するの

現在、 appVersionは一種の「特別な」値として扱われています。 可視性を提供するためにあると思います。たとえば、Prometheusのチャートバージョン123.5.6を使用できますが、appVersion：2.17.1を使用するので、どのセキュリティパッチバージョンがあり、どのPrometheus機能が期待できるかがわかります。 helm lsを使用して検索できます。

私はそれがいくつかの異なる方法で提供される可能性があると思います。 たぶんリリースラベル経由？ または、 kubectl可能なことと同様に、すべてのリリースでjsonPathクエリを実行することもできます。例：

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

次に、そのサポートは、 helm自体によって強制されるのではなく、ベストプラクティスにシフトされます。 それもリントすることができます。

一方、多くの人がappVersion既存の実装に依存している可能性があり、これも考慮する必要があります。

たぶん一歩下がって、なぜ正確にappVersionが追加されたのかを理解することが、この問題の解決に役立つでしょうか？

@bokysan以前はvalues.yamlにありましたが、 Chart.yamlに移動されました。 helm ls全体で、次のようなコマンドを実行するのではなく、チャートとDockerタグの両方が表示されていると思います。なので
kubectl get deployment <release name> -o jsonpath='{.spec.template.spec.containers[0].image}'

@TBBle私はあなたのそれぞれのポイントに対処しますが、それは前の投稿と同じくらいこの投稿になります。 この問題全体は、公開リポジトリのチャートを見るだけでは、一般的なチャートは有効なユースケースではないと判断した人に帰着すると思います。

initContainersとサイドカーの使用を開始する必要があるとすぐに、appVersionの前提全体がフラットになります。 実際の例を挙げると、現在管理する必要のあるプロジェクトの1つに、phpサイドカーを備えたnginxがあります。 nginxタグとphpタグは頻繁には変更されません。 phpコンテナ/バージョンは、コードを作成する開発者にとって非常に重要です。 最も頻繁に変更されるコンテナは、コンテンツを提供するinitContainerです。
appVersionをinitContainer 、 phpコンテナに設定しますか、それともnginxに設定しますか？これらのいずれかを選択することで、失われた情報は何ですか？

それがユーザーにとって重要であるなら、それは確かにPHPバージョンでなければなりませんか？ それはあなたが宣伝しているものです。 appVersionに3つすべてを貼り付けることもできます。これは、結局のところフリーテキストフィールドです。

appVersion ==コンテナ画像タグを強制したい場合は、重要なチャート、つまり複数のコンテナがあるチャート、またはコンテナがないチャートでは難しいことがわかります。 それは実際にはそれのポイントではありません、さもなければそれはimageVersionでしょう。 単一のアップストリームアプリをパッケージ化する場合は、そのバージョンを使用します。 複数のアップストリームアプリのパッケージを作成する場合は、prometheus-operator's chartなどの1つを選択するか、appVersionを無視します。これはオプションのフィールドです。

チャートソースがアプリケーションの_一部_である場合（Agonesなど）、 appVersion空白のままにするか、それに依存するツールがある場合はversionからコピーします。

これらのことはどれもhelm install時間の決定である必要はありません。 前に述べたように、 helm packageは、「サードパーティのグラフのインストール時に別のアップストリームバージョンを切り替える」以外のすべてのワークフローに十分遅れており、 --valuesまたは--setある必要があります。

正直なところ、実際に欠落している機能はおそらく「 appVersionをtpl渡す」ことなので、 .Values.image.tagまたは自分に合ったものから読み取ることができます。

appVersion ==コンテナ画像タグを強制する場合

次に、おそらくhttps://github.com/helm/helm/issues/7517にいます。おそらくこれがすべての原因です。

私はこの議論をまったく理解していません。 自分に最適だと思う方法でアプリのバージョンを使用するオプションを人々に提供しないのは、非常に大きな問題です。

私にとって現在の形では、このAPP VERSIONをまったく持たないのが最善でしょう。 それは私たちのプロジェクトの人々に混乱をもたらすだけです。 同じヘルムチャートを使用している80を超えるサービスがあり、 helm upgrade -i ...このAPP VERSIONを簡単に変更することはできないため、すべてのアプリケーションが1.0ままであることがわかります。ここに

また、 helm listは役に立たないので、使用しないようにみんなに言う必要があることもわかりました。 アプリケーションのバージョンを確認するには、他のバージョンを使用する必要があります。

私はこの会話を読み始めたときは楽観的でしたが、最後までこれについて話し合う方法と、ユーザーに自分の考え方を強制するために戦う方法を見て、今は希望を失いました:(。

helm list 、 helm historyなどに2つの異なる出力「CHART（version）」と「APPVERSION」があると非常に便利で、コマンドラインオプションと出力解析を深く掘り下げる必要がありません。最も重要な事実。

「CHART（version）」と「APPVERSION」がビルド時に関連付けられている場合（「helmpackage」）、2つの異なる値を持つことの利点全体がいくらか失われます。 チャートを作成し、チャートバージョンをインクリメント/更新せずにアプリバージョンを更新すると、同じチャートバージョンでは非常に異なる結果が得られるため、大きな問題が発生します。 ：-<

そのため、今のところ、リリースごとにパッケージをビルドし、「CHART（version）」と「APPVERSION」を同期してインクリメントして、異常な/不明確な状況に陥らないようにする必要があります。

先ほど学習したように、「APP VERSION」はオプションであり、カスタム値を使用して、画像に{{Chart.appVersion}}の代わりに使用することができます。ただし、 helm listはあまり有益ではありません。 ：-<

ユーザー（開発者）の視点から：

• インストール時にバージョンのプロパティ/フラグ/値を設定する機能
• ラベル「XXバージョン」のヘルムリスト/履歴出力でそのバージョンのプロパティ/フラグ/値を確認する機能

私たちがそれを成し遂げることができるチャンスはありますか？

「CHART（version）」と「APPVERSION」がビルド時に関連付けられている場合（「helmpackage」）、2つの異なる値を持つことの利点全体がいくらか失われます。

これが混乱の核心だと思います。 私が使用しているアプリバージョンの利点は、現在の設定で意図されているように見えますが、チャートバージョンはチャート全体のバージョンであり、チャートバージョンではないため、ラップされたアプリケーションのバージョンを知っていることです。チャート内のテンプレートのバージョン。 「Helmチャートのバージョン〜XYが必要です」のようなすべてのステートメントに、「ああ、AppVersionを台無しにしないでください」を最後に追加する必要があります。

この利点は、アプリのバージョン（およびアプリの実際のバージョン）がインストール時に変更されることで失われます。これは、チャートバージョンでは使用しているアプリが表示されなくなり、SemVerを使用して次のことを確認できなくなるためです。たとえば、最新であるがAPI互換のリリースがあります。

ユースケース@pniederlagのために持っていることができること、記述されたappVersion可能値のエントリでポイントを作るだろうとテンプレートをhelm list求められているものを、限り、チャートの支持体が持つかのようにそのアプリケーションのバージョン（おそらくコンテナタグ）は、他のすべての「インストール時に変更」構成オプションと同様に、 --setまたは--valuesを介してインストール時に変更されます。

ここで、 AppVersion問題が発生しました。

リリースバージョンとAppVersionの両方を使用しています。

今すぐ設定するには-両方のバージョンが設定されたローカルtarアーカイブを作成するには、事前にhelm upgrade --installのhelm package明示的に呼び出す必要があります。

今、私はhelm-secretsサポートを追加しています、そして...
そして、そのラッパーはhelm packageでは機能しません！

ならどうしよう？
すべてのバージョンのサポートとフローを削除しますか？
シークレットを使用してドロップしますか？
何か案は？

実際には、 helm-secretsの方が問題ですが、ここで説明する--set app-version能力にも関連しています。これは、このように使用できれば、 helm packageを呼び出す必要がないためです。

UPDああ、待って...私はまだhelm secrets upgrade chart.tgz -f secrets.yamlを使うことができます...
わかった。
それでも、+ 1で--set app-versionを追加します。

ならどうしよう？
すべてのバージョンのサポートとフローを削除しますか？
シークレットを使用してドロップしますか？
何か案は？

2つのパッケージを作成します。チャートのみを含むhelmパッケージであり、env値とsecretsファイルはありません。 chart-versionは私たちにとって何の意味も持たず、chart-versionはapp-version構文をサポートしていないため、このパッケージの名前をchart-{app-version}.tgz変更します。 アプリの更新には、潜在的なグラフの更新が含まれます（gitタグ付けを使用した同じリポジトリ）。

次に、環境固有の2番目のtgz、チャートtgz、値yaml、および暗号化されたシークレットファイルを含むchart-{app-version}-{env}.tgzがあります。 このファイルには、 helm-secretsを使用してデプロイする自動スクリプトのタグ、アプリ、環境名などの値を含む「package.yaml」も含まれています。

私たちは、アプリケーションのバージョンまたはそのほとんどをセマンティックバージョン番号で識別するために使用されます。 次に、APPバージョンでこの番号を使用して、ロールバックまたはその他の操作のhelm historyリストで簡単に識別します。
システムはデプロイ時に自動的に注入することを許可しないため、デプロイコマンドの前にCI / CDパイプラインでこの単純なコマンドを自動的に実行します。

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

トリッキーですが、期待どおりに機能します。

@bvis
回避策の問題は、CI / CDパイプラインでチャートを編集する必要があることです。
一元化されたチャートリポジトリを使用する場合は、 helm pull repo/chart --untar強制されます

Chart.yaml / appVersionをプログラムで注入することでさらに進歩はありますか？ 回避策はありますか？ それはCI / CDヘルムに途方もない後押しを与えるでしょう。

@jakovistuk私が知る限り、appVersionを使用してコンテナのバージョンを表示するチャートは、たとえばnginx-ingress / Chart.yamlに見られるように、Chart.yamlを介してこれを直接

私はこの問題についてかなり長い間考えていなかったので、これは本当にばかげた質問かもしれませんが、Helm CLIを使用してappVersionをオーバーライドする方法はありますか？

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

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

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

この問題の時代、長さ、わずかに異なる機能ゲートの多種多様性、およびそれ以降のHelmプロジェクトの変更（Helm 3、OCIチャートなど）を考えると、この問題は良好な状態ではないと思います。現在の形式の機能要求として前進します。 私はこの問題を閉じるつもりですが、同様の機能要求を持っている他の人は、新しい問題を

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

これが解決されるまで（または解決されないまで）これが私のCI / CD（GitLab）でこれを解決する方法です：

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

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

image.tagをデフォルトで{{ .Chart.AppVersion }}に設定した場合、インストール中に--setを実行する必要はなく、すでに正しくなっています。 これは、DockerイメージがSHA1でタグ付けされているため、AppVersionがDockerイメージタグと一致し、バージョンが自動ビルドSemVerである場合、自動ビルドでもうまく機能します。

AppVersionがSemVerである場合、VersionがAppVersionと同じであることに問題はありません。

私のチームが作成したパッケージでは、AppVersionを検索するもの、たとえばimage.tagに移行しており、AppVersionが設定されていない場合はデフォルトでVersionになります。 これは大きな違いではなく、タグ付きリリースのhelm packageに対する引数が1つ少ないだけですが、チャートがパッケージ化したものと同じSCMから作成されている場合にのみ意味があります。

サブチャートを使用して画像タグを設定している場合は機能しない@TBBle

image.tagがサブチャートにあるが、親チャートのバージョンを使用しようとしているということですか？ もしそうなら、はい、それは非常に厄介であり、管理するのは簡単ではありません。 https://github.com/googleforgames/open-match/のヘルムチャートでこのレイアウトを正確にバウンスしました。 この場合、問題のサブチャートをメインチャートにロールバックすることをお勧めします。

チャートは、機能するために親チャートの動作に依存するのではなく、独立して分離された/使用可能な単位である必要があります。 サブチャートには独自のバージョンがあります。それは、その画像が使用する必要があるバージョンです。そうでない場合、なぜサブチャートなのですか？

Open Matchの場合、サブチャートはXXX.enableをvalues.yamlのショートカットとして使用して、一度にたくさんのものを無効にできるように使用されているように見えますが、その後、このような構造上の問題がたくさん発生します。 Open Matchのサブチャートはすべて、templatesという名前の親チャートを多用し、ローカルバージョンの0.0.0-devもあるため、何かがうまく構造化されていないというコードの臭いがすでに2つあります。

あるいは、あなたが行っている観察を誤解したのかもしれません。

@haimari残念ながら、機能していません（https://github.com/helm/helm/issues/6921に関連していますか？）：

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

しかし、これは機能します：

> 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

そしてこれでさえ（しかし汚いようです）：

> 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"}

@haimariのソリューションはこれは、CIパイプラインでsemver互換のタグを使用しているためです（つまり、これはタグ付きリリースのジョブ実行の例であり、every-commitでは実行されません）

@ a0s ：私は一般的に提案します：

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

次に、コンテナイメージタグの値を{{ Values.image.tag | default .Chart.AppVersion | default .Chart.Versionようにします。これにより、 @ haimariのようにオンザフライで変更する必要がなくなります。

あなたの例では、2つの異なるgitバージョンのように見えるものがありますよね？ 1つはコンテナ画像用で、もう1つはチャート用ですか？

SemVerでは、git commit SHAをsemverの意味のある部分に実際に配置することはできません。これは、semverが順序付けを意味し、git commitSHAを並べ替えることができないためです。

したがって、 0.0.1-alpha.<build-id>+g<gitcommitsha>ようなバージョンを使用する必要があります。ここで、 <build-id>はCIシステムのパイプラインやジョブIDのようなものであるため、プロジェクトにコミットすることは常に必要です。 そうすれば、要求したときに常に最新のビルドを取得できます。

SemVerでは、 -すると、そのバージョンのプレリリースであるため、 0.0.1-<anything>は0.0.0と0.0.1のリリースの間になります。 +後の部分はビルド情報であり、並べ替えでは無視されるため、git SHA、ブランチ名、またはその他の並べ替え不可能な追跡情報を配置するのに適した場所です。

したがって、ここで使用したものでは、SHAが2で始まる場合、たとえば0-2764e1場合、 0-3454e5は次のコミットよりも新しいように見えます。

あなたの例では、2つの異なるgitバージョンのように見えるものがありますよね？ 1つはコンテナ画像用で、もう1つはチャート用ですか？

はい、アプリとチャート-2つの独立したソフトウェアがあります。

そうすれば、要求したときに常に最新のビルドを取得できます。

最新のものを求めたくない（そして想像さえできない）場合はどうなりますか？

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

この文字列（補間後）は長すぎて、標準のhelm list出力の

インストールするアプリのバージョン（shaハッシュ）は常にわかっています（ --set引数で渡します）。 そして、私は常に自分が使用しているチャートのバージョンを知っています（ @haimariが説明したように、私は常にgit checkout chart && helm pack && helm upgrade .tar.gzを私のci / cdでローカルに使用します）

何がうまくいかない可能性がありますか？
1）通常のhelm upgrade中のエラー。 OK、エラーを修正して再試行します（アプリの別のshaコミットで-99％）（または代わりに--atomic使用します）
2）手動ロールバック： helm rollback <RELEASE_NAME>またはCI / CDを介した以前のshacommitの展開。

私は何が恋しいですか？

PS正直なところ、バージョンとアプリバージョンでは情報提供のみを目的として短いsha部分を使用したいと思います（ helm list ）

それは情報目的のためだけなら、それは後に行く+ 、SemVerではない- 。 リリースの順序やHelmチャートの配布を気にせず、チャートまたはアプリがまだSemVerされていない場合、 0+g<commitsha>は有効なSemVer（0.0.0に相当）です。

これは、たとえば、OpenMatchのHelm自動作成チャートが行うことです。 それらはすべて現在0.0.0-devであり、私たちはその0.0.0-dev+g<commitsha>作成を検討し