インストール

GitLab Operatorには以下の外部インスタンスが必要です。

• PostgreSQL
• Redis
• オブジェクトストレージ

本番環境へのデプロイには、クラウドネイティブリファレンスアーキテクチャに従ってください。

このドキュメントでは、KubernetesまたはOpenShiftクラスターでマニフェストを使用してGitLab Operatorをデプロイする方法について説明します。

OpenShiftを使用する場合、インストールは通常Operator Lifecycle Manager（OLM）によって処理されます。 OLMを使用したインストールは実験的とみなされます。GitLabは、OLMを使用してデプロイされたインスタンスに関連する問題をサポートしません。 OLMの潜在的な問題の詳細については、イシュー241を参照してください。

前提条件

1. Kubernetesまたは既存のOpenShiftクラスターを作成または使用する
2. 前提条件となるサービスとソフトウェアをインストールする
   • Ingress/Gateway APIコントローラー
   • cert-manager
   • メトリクスサーバー
3. ドメイン名サービスを設定する

クラスター

Kubernetesの直近3つのマイナーバージョンと、OpenShiftの直近4つのマイナーリリースとの互換性を同時にターゲットとしています。新しいバージョンのサポートが追加されると、最も古いサポート対象バージョンのテストは終了します。KubernetesおよびOpenShiftの新しいマイナーリリースに対して、初回リリースから3か月以内にOperatorサポートを提供することを目標としています。

詳細については、Kubernetesサポートポリシーを参照してください。

上記に記載されているバージョンより新しいリリースとの互換性の問題は、イシュートラッカーでお知らせください。

一部のGitLab機能は、非推奨バージョンや上記に記載されているバージョンより古いバージョンでは動作しない場合があります。

OperatorはX86-64とARM64をサポートしています。ARM64ビルドは16.7から利用可能でしたが、完全なサポートとテストカバレッジは18.8から提供されています。

外部トラフィックルーティング

アプリケーションへのアクセスを提供するには、外部トラフィックルーティングが必要です。 Envoy Gatewayを使用したGateway APIは、新規デプロイに推奨されるアプローチです。設定の詳細と代替プロバイダーについては、Gateway APIドキュメントを参照してください。

バンドルされているNGINX IngressコントローラーはGitLabチャート19.0で非推奨となり、GitLab 20.0で削除される予定です。代替として外部NGINX Ingressコントローラーを使用できます。

TLS証明書

OperatorのKubernetes webhookの証明書を作成するために、cert-managerが使用されます。GitLabの証明書にもcert-managerを使用することをお勧めします。

OperatorはKubernetes webhookの証明書を必要とするため、GitLab Chartにバンドルされているcert-managerは使用できません。代わりに、Operatorをインストールする前にcert-managerをインストールしてください。

インストールドキュメントに従って、お使いのプラットフォームとツールに対応したサポート対象のcert-managerリリースをインストールしてください。

メトリクス

ドメイン名サービスの設定

DNSレコードを追加できる、インターネットからアクセス可能なドメインが必要です。

ドメインをGitLabコンポーネントに接続する方法の詳細については、ネットワークとDNSのドキュメントを参照してください。このセクションで説明する設定は、GitLabカスタムリソース（CR）を定義する際に使用します。

OpenShiftのIngressには追加の考慮事項があります。詳細については、OpenShift Ingressに関する注意事項を参照してください。

GitLab Operatorのインストール

まず、インストール方法を選択してください。

kubectl create namespace gitlab-system

kubectl apply -f gitlab-operator-<platform>.yaml

helm repo add gitlab https://charts.gitlab.io
helm repo update

helm install gitlab-operator gitlab/gitlab-operator \
  --create-namespace \
  --namespace gitlab-system

Operator Deploymentのステータスを確認してインストールを確認します。

kubectl -n gitlab-system get deployment gitlab-controller-manager

ネームスペース限定モードでのバンドルNGINX IngressとPrometheus

ネームスペース限定のマニフェストバリアント（およびwatchCluster=falseでのHelmインストール）では、チャートにバンドルされているNGINX IngressコントローラーとPrometheusサーバーのClusterRoleとClusterRoleBindingが省略されます。これら2つのコンポーネントはクラスター全体で動作するように設計されています。

• NGINX IngressはすべてのネームスペースにわたってIngressesを監視し、nodesやingressclassesなどのクラスタースコープのリソースを読み取ります。
• Prometheusサーバーはクラスター全体のターゲットを検出してスクレイプし、nodes、nodes/proxy、nodes/metrics、および/metrics非リソースURLへのアクセスが必要です。

ネームスペース限定モードでOperatorをインストールし、これらのバンドルコンポーネントを使用する場合は、クラスタースコープの権限を自分で提供する必要があります（通常、チャートのgitlab-nginx-ingress/gitlab-prometheus-server ServiceAccountを外部管理のClusterRoleにバインドし、NGINX Ingressの場合はコントローラーに--watch-namespaceを渡します）。

ネームスペース限定モードで推奨されるアプローチは、外部管理のモニタリングおよびIngress/Gateway APIソリューションを使用することです。

GitLabのインストール

1. GitLabカスタムリソース（CR）を作成します。

   mygitlab.yamlのような名前の新しいファイルを作成します。

   このファイルに記述する内容の例を以下に示します。

   apiVersion: apps.gitlab.com/v1beta1
   kind: GitLab
   metadata:
     name: gitlab
   spec:
     chart:
       version: "X.Y.Z" # https://gitlab.com/gitlab-org/cloud-native/gitlab-operator/-/blob/<OPERATOR_VERSION>/CHART_VERSIONS
       values:
         global:
           hosts:
             domain: example.com # use a real domain here
           ingress:
             configureCertmanager: true
         certmanager-issuer:
           email: youremail@example.com # use your real email address here

   spec.chart.values以下で使用する設定オプションの詳細については、GitLab Helmチャートドキュメントを参照してください。

2. 新しいGitLab CRを使用してGitLabインスタンスをデプロイします。

   kubectl -n gitlab-system apply -f mygitlab.yaml

   このコマンドにより、GitLab CRがクラスターに送信され、GitLab Operatorによって調整されます。コントローラーポッドのログをテールすることで進捗を確認できます。

   kubectl -n gitlab-system logs deployment/gitlab-controller-manager -c manager -f

   GitLabリソースを一覧表示してステータスを確認することもできます。

   $ kubectl -n gitlab-system get gitlab
   NAME     STATUS   VERSION
   gitlab   Ready    5.2.4

   CRが調整されると（GitLabリソースのステータスがRunningになると）、ブラウザでhttps://gitlab.example.comからGitLabにアクセスできます。

ログインするには、デプロイの初期rootパスワードを取得する必要があります。詳細な手順については、Helmチャートドキュメントを参照してください。

推奨される次のステップ

インストールが完了したら、認証オプションやサインアップ制限を含む推奨される次のステップを検討してください。

OpenShift

OpenShiftを実行している場合は、GitLab Operatorの承認ストラテジーを自動（デフォルト）から手動に変更してください。これにより、承認が与えられるまで、OpenShiftが新しいOperatorバージョンをインストールするのを防ぎます。

カスタムstartingCSVを設定して、Operatorのバージョンを固定したり、最新でないバージョンにアップグレードしたりすることもできます。

• 承認ストラテジーは、OpenShift Webコンソールから変更するか、Subscriptionを編集することで変更できます。
• 手動アップグレードを承認するには、InstallPlanの.spec.approvedをtrueに設定します。
• 各GitLab Operatorは定義されたGitLabチャートバージョンのサブセットをサポートしています。GitLab Operatorへのアップグレードには、GitLabカスタムリソースのチャートバージョンの更新も必要です。
• GitLab Operatorと指定されたGitLab HelmチャートバージョンにGitLab Helmチャートバージョンに関するエラーが発生して設定変更が失敗する場合は、GitLab Helmチャートバージョンに関するエラーを参照してください。

GitLab Operatorのアンインストール

GitLab Operatorとその関連リソースを削除するには、以下の手順に従ってください。

Operatorをアンインストールする前に注意すべき事項:

• Operatorは、GitLabインスタンスが削除されても、Persistent Volume ClaimsやSecretsを削除しません。
• Operatorを削除する際、インストールされているネームスペース（デフォルトではgitlab-system）は自動的に削除されません。これにより、永続ボリュームが意図せず失われることを防ぎます。

GitLabインスタンスのアンインストール

kubectl -n gitlab-system delete -f mygitlab.yaml

これにより、GitLabインスタンスと、上記で述べたPersistent Volume Claimsを除くすべての関連オブジェクトが削除されます。

GitLab Operatorのアンインストール

GL_OPERATOR_VERSION=<your_installed_version> # https://gitlab.com/gitlab-org/cloud-native/gitlab-operator/-/releases
PLATFORM=kubernetes # or "openshift"
kubectl delete -f https://gitlab.com/api/v4/projects/18899486/packages/generic/gitlab-operator/${GL_OPERATOR_VERSION}/gitlab-operator-${PLATFORM}-${GL_OPERATOR_VERSION}.yaml

これにより、Operatorの実行中のDeploymentを含むOperatorのリソースが削除されます。GitLabインスタンスに関連するオブジェクトは削除されません。

GitLab Operatorのトラブルシューティング

GitLab Operatorのトラブルシューティングについては、トラブルシューティングを参照してください。