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

このテンプレートの目的は、既知の問題のある設定のために、ユーザが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 を適切に使用することを強く推奨します。 1つのキーが存在する可能性は、プロパティマップ全体がそのキーの前にいくつかのブランチが存在しない可能性と同じです。 マップ構造内に存在しないプロパティにアクセスしようとすると、一般的に曖昧な表現で Helm_は_文句を言います。 時間を節約するために、明示的である必要があります。

メッセージ形式

すべてのメッセージは以下のフォーマットでお送りください： 


chart:
    message
  • メッセージの前にあるif ステートメントでは、その後にある改行をトリミングしては_いけません_。 (}} not-}}) これにより、ユーザーにとってのフォーマットと読みやすさが保証されます。
  • このメッセージは、グローバル・チャートに対して、どのチャートが影響を受けるかを宣言する必要があります。 これにより、ユーザは、そのプロパティがチャートのどこから来たのか、また、構成プロパティを理解することができます。 例:gitlab.unicorn,minio,registry.
  • このメッセージは、障害の原因となったプロパティと、どのような処置を取るべきかをユーザーに知らせるものでなければなりません。 影響を受けるチャートとの関連でプロパティに名前を付けてください。例えば、gitlab.unicorn.minio.enabled は、gitlab.unicornであるため、minio.enabled と参照されます。複数のチャートが影響を受ける場合は、完全なプロパティ名を使用してください。
  • メッセージは段落を折り返すような改行をしては_いけません_。 これは、メッセージがコンフィギュレーション値を補間する可能性があり、そうすると改行が崩れるからです。

メッセージの例 


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にあります。