GitLab Operator

プラン: Free、Premium、Ultimate
提供形態: GitLab Self-Managed

GitLab Operatorは、Kubernetes Operatorパターンに従うインストールおよび管理方法です。

GitLab Operatorを使用して、OpenShiftまたは別のKubernetes互換プラットフォームでGitLabを実行します。

GitLab Operatorには既知の制限事項があり、本番環境での使用における特定のシナリオにのみ適しています。

GitLabカスタムリソースのデフォルト値は、not intended for production use。これらの値を使用すると、GitLab Operatorは、永続データを含むすべてのサービスがKubernetesクラスターにデプロイされるGitLabインスタンスを作成します。これは、not suitable for production workloads。本番環境へのデプロイでは、クラウドネイティブハイブリッドリファレンスアーキテクチャに従う必要があります。GitLabは、Kubernetesクラスター内にデプロイされたPostgreSQL、Redis、Gitaly、Praefect、またはMinIOに関連する問題はサポートしていません。

既知の問題

GitLab Operatorは、以下をサポートしていません:

GitLab Operatorを使用した、既存のHelmチャートベースのインスタンスの管理。改善のサポートは、GitLab Operatorイシュー1567で提案されています。
OpenShiftルートを使用したSSH経由のGit。詳細については、OpenShiftルートに関するGitLab Operatorドキュメントを参照してください。
他のクラウドAPI（オブジェクトストレージなど）へのワークロードを認証するためのGKEワークロードIDおよびIAMサービスアカウント。詳細については、GitLab Operatorイシュー1089を参照してください。
GitLab Operatorは、ゼロダウンタイム方式を使用してGitLabをアップグレードします。その結果、GitLabとGitLabチャートのバージョンは、一度に1つのマイナーリリースずつ更新する必要があります。一度に複数のバージョンをアップグレードするためのサポートは、GitLab Operatorイシュー1952で追跡されています。

GitLab Operatorには、GitLabチャートの他の制限事項があります。GitLab Operatorは、KubernetesリソースをプロビジョニングするためにGitLabチャートに依存しています。したがって、GitLabチャートの制限は、GitLab Operatorに影響を与えます。GitLab OperatorからのGitLabチャートの依存関係を削除することは、Cloud Nativeエピック64で提案されています。

インストール

GitLab Operatorをインストールする方法については、インストールドキュメントを参照してください。

セキュリティコンテキスト制約の使用方法の詳細は、それぞれのドキュメントに記載されています。

特にOpenShiftを使用する場合は、SSHアクセスからGitへの考慮事項も認識しておく必要があります。

アップグレード

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モジュールの更新

注: これは、このプロジェクトを所有するグループのGitLabチームメンバーのみに関連します。

このプロジェクトを所有するチームのチームメンバーである場合は、go.modファイルとgo.sumファイルに対するCODEOWNERSの承認権限が付与されています。MRがこれらのファイルのみを変更している場合、メンテナーでなくても、MRを承認してマージできるはずです。これは、Goモジュールの更新のリスクが非常に低いとチームが評価したため、メンテナーからのレビューの負荷を軽減し、依存関係の更新効率性を向上させるために実装されました。そのため、Goに慣れていて、変更が適切に見え、MRで完全にグリーンパイプラインが表示されている場合は、すぐに承認してマージしてください。

それでも、Goコードに慣れていない場合、またはその他の理由で別の意見が必要な場合は、2回目のレビューを実行するために、MRをメンテナーに渡すことをお勧めします。