- 問題のあるコンフィギュレーションをキャッチする試み
- 非推奨による変更
- 環境よりもinitContainerの秘密を優先
- グローバルチャートからサブチャートがデプロイされます。
gitlab/*
のテンプレート・パーシャルは、可能な限りグローバルであるべきです。- フォークチャート
- Chart全体で使用されているKubernetesのバージョン
デザインの決定
このドキュメントは、このリポジトリにあるHelmチャートの設計に関して決定された理由とドキュメントを集めたものです。
問題のあるコンフィギュレーションをキャッチする試み
これらのチャートは複雑で柔軟性が高いため、予測不可能な、またはまったく機能しないデプロイにつながる設定を作成することが可能な重複がいくつかあります。 既知の問題のある設定の組み合わせを防ぐために、私たちは、その設定が機能しないことを検出し、ユーザーに警告するように設計されたテンプレートロジックを実装しています。
これは、非推奨の動作を再現しますが、機能的なコンフィギュレーションを確保するためのものです。
757で導入checkConfig: 既知のエラーをテストするメソッドを追加。
非推奨による変更
これらのデプロイの開発中に、既存のデプロイのプロパティの変更を必要とする改良を行うことがあります。 2つの例として、MinIOの使用設定の一元化と、外部オブジェクトストレージの設定のプロパティからシークレットへの移行(私たちの好みに従った)があります。
ユーザが誤って、機能しないコンフィギュレーションへの変更を含むこれらのチャートの更新版をデプロイすることを防ぐ手段として、私たちは非推奨通知を実装することにしました。 これらは、プロパティが再配置、変更、置換、または完全に削除されたことを検出し、コンフィギュレーションにどのような変更を加える必要があるかをユーザに通知するように設計されています。 これには、あるプロパティをシークレットに置き換える方法に関するドキュメントを参照するようユーザに通知することも含まれます。 これらの通知により、Helminstall
またはupgrade
コマンドはパースエラーで停止し、対処が必要な項目の完全なリストを出力します。 ユーザがエラー、修正、繰り返しのループに陥らないように配慮しています。
デプロイを成功させるためには、すべての非推奨事項が対処されなければなりません。 私たちは、デバッグを必要とする予期せぬ動作や完全な失敗を経験するよりも、壊れるような変更を知らされることをユーザーは好むと考えています。
396で導入Deprecations: 非推奨事項のバッファリストを実装。
環境よりもinitContainerの秘密を優先
コンテナエコシステムの多くは、環境変数を通じて構成される機能を備えているか、あるいはそれを期待しています。 この構成方法は、「12ファクターアプリ(The Twelve-Factor App)」の概念に由来します。 これにより、複数のデプロイ環境にまたがる構成が大幅に簡素化されますが、コンテナの環境を通じてパスワードや秘密鍵などの接続秘密を渡すことには、セキュリティ上の懸念が残ります。
ほとんどのコンテナエコシステムは、実行中のコンテナの状態を検査する簡単な方法を提供しています。Dockerを例にとると、デーモンと通信できるプロセスであれば、実行中のすべてのコンテナの状態を照会できます。 つまり、dindのような特権コンテナがあれば、そのコンテナは指定されたノード上の_任意の_コンテナの環境を検査し、その中に含まれる_すべての_秘密を公開することができます。完全なDevOpsライフサイクルの一部として、dindはレジストリにプッシュされ、その後デプロイされるコンテナを構築するために定期的に使用されます。
このような懸念があるため、私たちはinitContainersを使用して機密情報を保管することにしました。
関連イシュー
グローバルチャートからサブチャートがデプロイされます。
このリポジトリのすべてのサブチャートは、グローバルチャートを介してデプロイされるように設計されています。 各コンポーネントは個別にデプロイすることができますが、グローバルチャートによって促進されるプロパティの共通セットを使用します。
この決定により、リポジトリ全体の使用とメンテナンスの両方が簡素化されます。
関連イシュー
gitlab/*
のテンプレート・パーシャルは、可能な限りグローバルであるべきです。
gitlab/*
サブチャートのすべてのテンプレート・パーシャルは、可能な限りグローバルまたは GitLab サブチャートtemplates/_helpers.tpl
の一部であるべきです。フォークされたチャートのテンプレートは、それらのチャートの一部として残ります。これにより、これらのフォークによるメンテナンスの影響を減らすことができます。
そのメリットは単純明快です:
- DRY な動作が増え、メンテナンスが容易になりました。 1 つのエントリで十分なのに、複数のサブチャートで同じ関数が重複する必要はありません。
- テンプレート名の衝突の減少:Chart全体のすべてのパーシャルが一緒にコンパイルされるので、それらをグローバルな振る舞いのように扱うことができます。
関連イシュー
フォークチャート
以下のChartは、フォークに関するガイドラインに従って、このリポジトリでフォークまたは再作成されました。
Redis
GitLab Helm chartの3.0
リリースでは、アップストリームのRedis chartをフォークしなくなり、代わりに依存関係として含めるようになりました。
Redis HA
Redis-HAは、3.0
以前のリリースに含まれていたチャートです。現在は削除され、オプションのHAサポートが追加されたアップストリームのRedisチャートに置き換えられています。
ミニオ
私たちのMinIOチャートは、上流のMinIOから変更したものです。
- プロパティから新しいものを作成する代わりに、既存のKubernetesシークレットを利用します。
- 環境経由で機密キーを提供することを削除します。
-
defaultBucket.*
プロパティの代わりにdefaultBuckets
を使って複数のバケットを自動作成。
レジストリ
私たちのレジストリチャートは、上流docker-registry
から変更されました。
- Chart内のMinIOサービスを自動的に使用できるようにします。
- 自動的にGitLabサービスに認証をフックします。
NGINX Ingress
当社のNginxIngressチャートは、アップストリームのNGINX Ingressから変更されています。
- tcpコンフィグマップをChartの外部にできる機能を追加。
- リリース名に基づいてIngressクラスをテンプレート化できる機能を追加
Chart全体で使用されているKubernetesのバージョン
異なるKubernetesバージョンのサポートを最大化するために、kubectl
Kubernetesの現在の安定リリースより1つ低いマイナー kubectl
バージョンを使用kubectl
します。 これにより、少なくとも3つ、そしておそらくそれ以上のKubernetesマイナーバージョンのサポートが可能になるはずです。 バージョンに関するさらなる議論については kubectl
、イシュー1509を参照してください。
関連イシュー
関連マージリクエスト: