チェックコンフィグテンプレート

このテンプレートの目的は、既知の問題のある設定のために、ユーザーがHelmチャート、またはそのアップデートを壊れた状態でデプロイするのを防ぐ手段を提供することです。

設計は複数のテンプレートを利用し、チェックを宣言・管理するモジュール方式を提供します。これは開発とメンテナンスの簡素化を支援するためです。

一般的なコンセプト

  1. templates/NOTES.txt includeの最後の項目はtemplates/_checkConfig.tpl のgitlab.checkConfig テンプレートです。
  2. gitlab.checkConfig テンプレートincludeは、同じファイル内のさらなるテンプレートで、その出力（文字列）をlist に集めています。
  3. 個々のテンプレートは、誤った設定の検出を処理し、ユーザーに問題のアドレスを知らせるメッセージを出力するか、何も出力しません。
  4. gitlab.checkConfig テンプレートはメッセージが収集されたかどうかをチェックします。メッセージがあれば、fail 関数を使用して、CONFIGURATION: のヘッダで出力します。
  5. fail 関数はデプロイプロセスを終了させ、ユーザーが壊れた設定でデプロイすることを防ぎます。

テンプレートの命名

このパターンの内部で定義され、このパターンで使われるテンプレートは、gitlab.checkConfig.* の命名規則に従うべきです。ここで* をredis.both のような情報的な名前に置き換えて、この設定が何に関連しているかを示します。

検出における考慮点

開発者は、キーや親キーが存在すると仮定しないように注意すべきです。if 、hasKey 、empty を適切に適用することを強く推奨します。一つのキーが存在する可能性は、プロパティマップ全体がそのキーの前のいくつかのブランチが存在しない可能性と同じです。_Helmは_マップ構造内に存在しないプロパティにアクセスしようとすると、一般的に曖昧な表現で文句を言います。時間を節約するために、明示的にしてください。

メッセージ形式

すべてのメッセージは、以下の形式でなければなりません：


chart:
    message
  • メッセージの前にあるif ステートメントでは、メッセージの後にある改行 を_トリミングしてはいけません_。(-}} ではなく}} ) こうすることで、ユーザーにとって読みやすい書式になります。
  • メッセージは、グローバル・チャートに対してどの Chart が影響を受けるかを宣言する必要があります。これにより、ユーザーは、そのプロパティが Chart や設定プロパティのどこから来たのかを理解しやすくなります。例gitlab.puma minio,registry.
  • こ の メ ッ セージは、 障害の原因 と な っ たプ ロ パテ ィ と 、 どの よ う なア ク シ ョ ンが必要であ る か をユーザーに知らせ る 必要があ り ます。そのプ ロ パテ ィ に、 影響を受ける Chart （複数可） に対す る 相対的な名前を付け ます。た と えば、gitlab.puma.minio.enabled は、非推奨の影響を受ける Chart がgitlab.puma であるため、minio.enabled として参照されます。複数の Chart が影響を受ける場合は、完全なプロパティ名を使用してください。
  • メッセージには、段落を折り返すような_改行を入れては_いけません。なぜなら、メッセージは設定値を補間する可能性があり、そうするとハード・ラッピングが壊れてしまうからです。

メッセージの例


redis: both providers
    It appears that `redis.enabled` and `redis-ha.enabled` are both true. This will lead to undefined behavior. Please enable only one.

新しいチェックのアクティビティ

テンプレートが定義され、その中に影響を受けるプロパティを検出するロジックが配置されれば、この新しいテンプレートのアクティ ビティは簡単です。gitlab.checkConfig テンプレートのadd templates here の下に行を追加するだけです。

対応するテストはspec/integration/check_config_spec.rb にあります。