GitLabチャートへの依存

GitLab Operator（単に “Operator “とも呼ばれます）は、ADR 0004に記載されているように、GitLab Helm Charts（単に “Chart “とも呼ばれます）に依存しています。

GitLab Chartへの変更による影響の理解

OperatorがChartの新しいバージョンを取り込むとき、Chart内の変更も取り込みます。Chartの変更をサポートするために、Operatorに調整を加えなければならないことがあります。

たとえば、Chartマージリクエスト3278は、変更をサポートするためにNGINX RBACオブジェクトの更新とともに、NGINX Ingress Controllerイメージタグのバージョンを更新しました。これにより、master のパイプラインが壊れるという Operator のイシュー 1324が発生しました。この問題は Operatorマージリクエスト 655によって解決されました。

Chart マージ・リクエストが送信されたとき、理想的には、Operator の付随するマージ・リクエストが開かれ、Chart マージ・リクエストに依存するものとしてマークされる必要がありました。このアプローチにより、Chartへの変更がOperatorのコンテキストで考慮されるようになり、チームが2つのコンポーネントを可能な限りシームレスに連携させることができます。

GitLab Chart への変更による影響の評価

Chartに変更を提出する際には、オペレーションへの影響を考慮する必要があります。これは、Chartマージリクエストテンプレートの承認チェックリストに項目として含まれています。

Chartへの変更がOperatorに与える影響を評価するには、その変更がOperatorに自動的に取り込まれるかどうかを検討します。これを確実に達成する唯一の方法は、Operatorコードベースを手動で検査し、Chartからソースとなっているリソースへの関連参照を検索し、調整が必要な方法でOperatorが関連変更と相互作用するかどうかを確認することです。これをテストする自動メカニズムを提供することは、Chartイシュー4900で調査中です。

それまでの間、以下の例は、考えられる影響を特定するのに役立ちます：

  • .metadata.name などのリソースの名称やラベリングスキームの変更、および/または.metadata.labels
  • リソースグループやバージョンの変更。.apiVersion
  • サービスアカウント名またはRBACポリシーの変更
  • RedisやPostgreSQLのバージョンなど、Chartの依存関係のアップグレード
  • メジャーリリースや停止バージョンで導入された、チャートを破壊するような変更

自動的に取り込まれる変更の例は、Chartマージリクエスト3247です。これは、Operatorが直接操作しないリソースの内部に新しいフィールドを追加し、レンダリングされたHelmテンプレートからそれらを取得し、クラスターでそれらを調整するだけです。