デザインの決定

この文書では、このリポジトリにあるHelmチャートの設計に関する理由と決定を収集します。どのように決定を適用するかについてはDecision Makingをご覧ください。

問題のある設定を捕捉する試み

これらのChartは複雑で柔軟性が高いため、予測できない、あるいはまったく機能しないデプロイにつながる設定を作成することが可能な重複がいくつかあります。既知の問題のある設定の組み合わせを防ぐために、私たちは、その設定が機能しないことを検出し、ユーザーに警告するように設計されたテンプレートロジックを実装しています。

これはdeprecationsの動作を再現していますが、機能的な設定を保証するためのものです。

757で導入checkConfig: 既知のエラーをテストするメソッドを追加。

非推奨化による変更

このChartの開発者の間では、既存のデプロイのプロパティの変更を必要とする改良を行うことがあります。2つの例として、MinIOの使用を一元的に設定することと、外部オブジェクトストレージの設定をプロパティからシークレットにマイグレーションすることです（私たちの好みに従いました）。

ユーザーが誤って、機能しない設定に対する変更を含むこれらのChartの更新版をデプロイするのを防ぐ手段として、私たちは非推奨通知を実装することにしました。これは、プロパティが再配置されたり、変更されたり、置き換えられたり、完全に削除されたりしたことを検出し、設定にどのような変更を加える必要があるかをユーザーに通知するように設計されています。これには、プロパティをシークレットに置き換える方法のドキュメントを見るようにユーザーに通知することも含まれます。これらの通知により、Helminstall またはupgrade コマンドはパースエラーで停止し、アドレスが必要な項目の完全なリストを出力します。ユーザーがエラー、修正、繰り返しのループに陥らないように配慮しています。

デプロイを成功させるためには、すべての非推奨事項にアドレスしなければなりません。ユーザーは、デバッグが必要な予期せぬ動作や完全な失敗を経験するよりも、変更があったことを知らされることを好むと私たちは信じています。

396で導入された非推奨事項: 非推奨事項のバッファされたリストを実装します。

環境よりもinitContainerのシークレットを優先

コンテナエコシステムの多くは、環境変数で設定できるようになっています。この設定方法は、12ファクターアプリ（The Twelve-Factor App）のコンセプトに由来しています。これにより、複数のデプロイ環境にまたがる設定が大幅に簡素化されますが、コンテナの環境を介してパスワードや秘密鍵などの接続シークレットを渡すことにはセキュリティ上の懸念が残ります。

ほとんどのコンテナエコシステムは、実行中のコンテナの状態を検査する簡単な方法を提供しています。Dockerを例にとると、デーモンと通信できるプロセスであれば、実行中のすべてのコンテナの状態をクエリできます。つまり、dind](https://hub.docker.com/r/gitlab/dind/)のような特権コンテナがある場合、そのコンテナは指定されたノード上の_すべての_コンテナの環境を検査し、その中に含まれる_すべての_シークレットを公開することができます。[完全なDevOpsライフサイクルの一部として、dind、レジストリにプッシュされ、その後デプロイされるコンテナを構築するために定期的に使用されます。

このような懸念があるため、私たちはinitContainersを使用した機密情報の配布を推奨することにしました。

関連するイシュー

グローバルチャートからサブチャートがデプロイされます。

このリポジトリのすべてのサブチャートは、グローバルチャートからデプロイされるように設計されています。各コンポーネントは個別にデプロイすることができますが、グローバルチャートによって促進される共通のプロパティセットを利用します。

この決定により、リポジトリ全体の使用と保守の両方が簡単になります。

関連イシュー

gitlab/* のテンプレートパーシャルは、可能な限り内部で使用すべきです。

gitlab/* サブチャートのすべてのテンプレートパーシャルは、可能な限りグローバルまたは GitLab サブチャートtemplates/_helpers.tpl の一部であるべきです。フォークされたチャートのテンプレートは、そのチャートの一部として残ります。これにより、フォークによるメンテナンスの影響を減らすことができます。

この利点は単純明快です：

  • DRYな動作が増え、メンテナンスが容易になります。1つのエントリで十分なのに、複数のサブチャートで同じ関数が重複する理由はないはずです。
  • テンプレート名の衝突の減少。Chart全体のすべてのパーシャルが一緒にコンパイルされるので、それらをグローバルな振る舞いのように扱うことができます。

関連イシュー

フォークされたチャート

以下のChartは、フォークに関するガイドラインに従って、このリポジトリでフォークまたは再作成されました。

Redis

GitLab Helm チャートの3.0 リリースでは、アップストリームの Redis チャートをフォークしなくなり、代わりに依存関係として含めるようになりました。

Redis HA

Redis-HAは、3.0以前のリリースに含まれていたチャートです。現在は削除され、オプションのHAサポートが追加されたアップストリームのRedisチャートに置き換えられています。

MinIO

私たちのMinIOチャートは、アップストリームMinIOから変更されました。

  • プロパティから新しいシークレットを作成する代わりに、既存のKubernetesシークレットを利用します。
  • 環境経由で機密キーを提供することを削除します。
  • defaultBucket.* プロパティの代わりにdefaultBuckets を使って複数のバケットを自動作成できるようにしました。

レジストリ

我々のレジストリチャートは、アップストリームdocker-registryから変更されたものです。

  • Chart内のMinIOサービスを自動的に使用できるようにします。
  • GitLabサービスに自動的に認証をフックします。

NGINX Ingress

NGINX Ingressのチャートは、アップストリームのNGINX Ingressから変更されています。

  • TCP ConfigMap をチャートの外部にできるようにする機能を追加しました。
  • リリース名に基づいてIngressクラスをテンプレート化できる機能を追加

Chart全体でKubernetesのバージョンを使用

異なるKubernetesバージョンを最大限にサポートするには、kubectl Kubernetesの現在の安定リリースより1つ低いマイナー kubectlバージョンを使用します。kubectl これにより、少なくとも3つ、そしておそらくそれ以上のKubernetesマイナーバージョンをサポートできるはずです。バージョンに関するさらなる議論については kubectl、イシュー1509を参照してください。

関連イシュー

関連マージリクエスト：

CNG と一緒に出荷された画像バリアント

日付: 2022-02-10

CNG プロジェクトはDebian と UBI の両方をベースにしたイメージを出荷しています。両方のディストリビューションの設定をメンテナーとすることを決定した理由は以下の通りです：

  • Debian ベースのイメージを出荷する理由：
    • 実績、前例
    • ディストリビューションに精通
    • コミュニティ対 “企業”
    • ベンダーロックインの欠如
  • UBIベースのイメージを出荷する理由
    • お客様の環境によっては必要です。
    • RHEL 認定および OpenShift Marketplace / RedHat カタログへの登録に必要です。

このトピックに関するさらなる議論はイシュー#3095 にあります。