GitLab Operator
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab Self-Managed
GitLab Operatorは、Kubernetes Operatorパターンに従うインストールおよび管理方法です。
OpenShiftまたは別のKubernetes互換プラットフォームでGitLabを実行するには、GitLab Operatorを使用してください。
既知の問題
GitLab Operatorは、以下をサポートしていません:
- GitLab Operatorで既存のHelmチャートベースのインスタンスを管理すること。この改善に関するサポートは、GitLab Operatorのイシュー1567で提案されています。
- OpenShift Routesを使用したSSH経由のGit。詳細については、OpenShift Routesに関するGitLab Operatorドキュメントを参照してください。
- ワークロードを他のクラウドAPI（オブジェクトストレージなど）に対して認証するためのGKEワークロードIDおよびIAMサービスアカウント。詳細については、GitLab Operatorのイシュー1089を参照してください。
- Operatorはゼロダウンタイム方式でGitLabをアップグレードします。そのため、GitLabとGitLabチャートのバージョンは、マイナーリリースを1つずつ順に更新する必要があります。一度に複数のバージョンをアップグレードする機能のサポートは、GitLab Operatorのイシュー1952で追跡されています。
GitLab Operatorには、GitLabチャートのその他の制限事項が適用されます。GitLab Operatorは、KubernetesリソースをプロビジョニングするためにGitLabチャートに依存しています。したがって、GitLabチャートにおける制限はGitLab Operatorに影響を与えます。GitLab OperatorからGitLabチャートへの依存を解消することは、クラウドネイティブのエピック64で提案されています。
インストール
GitLab Operatorのインストール方法については、インストールドキュメントを参照してください。
セキュリティコンテキストの制約をどのように使用しているかの詳細については、それぞれのドキュメントに記載しています。
特にOpenShiftを使用する場合は、GitへのSSHアクセスに関する考慮事項にも注意してください。
アップグレード
GitLab Operator、またはGitLab Operatorによって管理されるGitLabインスタンスをアップグレードする方法については、GitLab OperatorでGitLabインスタンスをアップグレードするを参照してください。
バックアップと復元
バックアップと復元のドキュメントでは、Operatorで管理されるGitLabインスタンスをバックアップおよび復元する方法について説明しています。
RedHat認定イメージを使用する
RedHat認定イメージのドキュメントでは、RedHatによって認定されたイメージをGitLab Operatorにデプロイさせる方法を説明しています。
デベロッパーツール
- デベロッパーガイド: プロジェクトの構造とコントリビュートの方法の概要を説明しています。
- バージョニングとリリースの情報: Operatorのバージョニングとリリースに関する注意事項を記録しています。
- 設計上の判断: このプロジェクトではアーキテクチャ決定レコードを使用しており、このOperatorの構造、機能、および機能の実装の詳細を記述しています。
マージリクエストのレビュー
マージリクエスト（MR）は通常、2人のレビュアーを必要とする標準的な運用に従います。まずメンテナー以外のメンバーがMRをレビューし、提案されている変更の改善/修正を支援するために作成者にコメントを提供します。作成者が必要な更新を行い、レビュアーがMRを承認した後、メンテナーの1人にレビューをリクエストします。
このアプローチは、経験の浅いレビュアーに学習の機会を提供するだけではありません。最終的なレビューの前に、最初のレビューでMRに関するほとんどの問題を解決します。変更の多いプロジェクトでは、メンテナーの負荷によりボトルネックが発生しがちですが、この最初のパスはそれらの負荷を軽減するのに役立ちます。
1回の承認のみの例外
特定のケースでは、1回の承認のみでMRをマージすることを許可しています。
Goモジュールの更新
このプロジェクトを所有するチームのメンバーである場合、go.modファイルとgo.sumファイルに対するCODEOWNERS承認権限が付与されています。MRがこれらのファイルのみを変更している場合、メンテナーでなくてもMRを承認してマージできるはずです。これは、Goモジュールの更新は非常にリスクが低いとチームが評価したことを踏まえ、メンテナーによるレビューの負荷を軽減し、依存関係更新の効率性を向上させる目的で実装されました。そのため、Goに精通しており変更内容に問題がなく、MRのパイプラインがすべてグリーンであれば、すぐにそのまま承認してマージしてください。
ただし、Goコードにまだ精通していない、などの理由によりセカンドオピニオンを必要とする場合は、MRをメンテナーに回して2回目のレビューを実施することをおすすめします。