正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

GitLab Operator

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

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

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

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

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

既知の問題

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

  • GitLab Operatorを使用した、既存のHelmチャートベースのインスタンスの管理。改善のサポートは、GitLab Operator issue 1567で提案されています。
  • OpenShiftルートを使用したSSH経由のGit。詳細については、OpenShiftルートに関するGitLab Operatorのドキュメントを参照してください。
  • 他のクラウドAPI（オブジェクトストレージなど）へのワークロードを認証するためのGKEワークロードIDおよびIAMサービスアカウント。詳細については、GitLab Operatorのイシュー1089を参照してください。

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

インストール

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

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

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

アップグレード

Operatorのアップグレードのドキュメントでは、GitLab Operatorをアップグレードする方法について説明しています。

GitLabのアップグレードのドキュメントでは、GitLabインスタンスをアップグレードする方法について説明しています（GitLab Operatorによって管理）。

バックアップと復元

バックアップとリストアのドキュメントでは、Operatorによって管理されているGitLabインスタンスをバックアップおよびリストアする方法について説明しています。

RedHat認定イメージ

RedHat認定イメージのドキュメントでは、RedHatによって認定されたイメージをデプロイするようにGitLab Operatorに指示する方法について説明します。

デベロッパーツール

  • 開発者ガイド: プロジェクトの構成とコントリビュートする方法の概要。
  • バージョニングとリリース情報: オペレーターのバージョニングとリリースに関する注意事項を記録します。
  • 設計上の判断: このプロジェクトでは、アーキテクチャの決定レコードを利用して、このオペレーターの構造、機能、および機能の実装について詳しく説明します。

マージリクエストのレビュー

マージリクエスト（MR）は通常、2人のレビュアーを必要とする標準的な方法に従います。まず、メンテナー以外の担当者がMRをレビューし、作成者にコメントを提供して、提案されている変更の改善/修正を支援します。作成者が必要な更新を行い、レビュアーがMRを承認すると、メンテナーの1人からのレビューをリクエストします。

このアプローチは、経験の浅いレビュアーに学習機会を提供するだけでなく、このアプローチは、経験の浅いレビュアーに学習機会を提供します。最初のレビューでは、最終的なレビューの前に、MRのほとんどの問題に対処します。大量のプロジェクトでは、メンテナーの負荷が原因でボトルネックが発生することがよくありますが、この最初のパスは負荷を軽減するのに役立ちます。

1つの承認のみの例外

特定の場合には、1つの承認のみでマージ（MR）をマージできるようにします。

Goモジュールのアップデート

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

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

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