インストール

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

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

前提条件

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

クラスター

GitLabでは、Kubernetesの直近3つのマイナーバージョンと、OpenShiftの直近4つのマイナーリリースのすべてに対して同時に互換性を維持することを目標としています。新しいバージョンのサポートが追加されると、最も古いサポート対象バージョンのテストは中止されます。当社の目標は、KubernetesとOpenShiftの新しいマイナーリリースが提供開始されてから3か月以内に、Operatorによるサポートを提供することです。

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

上記のリリースよりも新しいリリースに関する互換性の問題については、イシュートラッカーでご報告ください。

一部のGitLab機能は、非推奨のバージョンや、上記のバージョンよりも古いバージョンでは機能しない場合があります。

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

Ingressコントローラー

Ingressコントローラーは、アプリケーションへの外部アクセスを提供し、コンポーネント間のセキュアな通信を確保するために必要です。

GitLab Operatorは、デフォルトでGitLab HelmチャートからフォークしたNGINXチャートをデプロイします。

外部Ingressコントローラーを使用する場合は、KubernetesコミュニティのNGINX Ingressを使用してIngressコントローラーをデプロイします。お使いのプラットフォームとお好みのツールに応じて、リンク先の関連手順に従ってください。後で使用するために、Ingressクラスの値を書き留めておいてください（通常、デフォルトはnginxです）。GitLab CRを設定する際は、GitLab HelmチャートからのNGINXオブジェクトを無効にするために、必ずnginx-ingress.enabled=falseを設定してください。

TLS証明書

OperatorのKubernetes Webhook用の証明書を作成するには、cert-managerを使用します。GitLabの証明書にもcert-managerを使用してください。

OperatorにはKubernetes Webhook用の証明書が必要なため、GitLabチャートにバンドルされている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デプロイのステータスをチェックして、インストールを確認します:

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

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 Operatorが調整できるように、GitLab CRをクラスターに送信します。コントローラーポッドからのログを追跡して進捗状況を監視できます:

   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を利用できます。

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

推奨される次のステップ

インストールが完了したら、推奨される次のステップ（認証オプションやサインアップ制限など）を実行することを検討してください。

OpenShift

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

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

• 承認戦略は、OpenShift Webコンソールから変更するか、サブスクリプションを編集することで変更できます。
• 手動アップグレードを承認するには、InstallPlanの.spec.approvedをtrueに設定します。
• 各GitLab Operatorは、特定のGitLabチャートバージョンのサブセットのみをサポートしています。そのため、GitLab Operatorをアップグレードする場合は、GitLabカスタムリソース内のチャートバージョンの更新も併せて行う必要があります。
• GitLab Operatorと指定されたGitLab Helmチャートバージョンに互換性がない場合、GitLab Helmチャートバージョンに関するエラーによりチャートの設定変更が失敗することがあります。

GitLab Operatorをアンインストールする

GitLab Operatorとその関連リソースを削除するには、次の手順に従います。

Operatorをアンインストールする前に、次の点に注意してください:

• GitLabインスタンスを削除しても、OperatorはPersistentVolumeClaimやシークレットを削除しません。
• Operatorを削除しても、インストール先のネームスペース（デフォルトではgitlab-system）は自動的には削除されません。これは、永続ボリュームが誤って失われることを防ぐためです。

GitLabインスタンスをアンインストールする

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

これにより、GitLabインスタンスとすべての関連オブジェクトが削除されます（前述のとおり、PersistentVolumeClaimを除きます）。

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のデプロイを含む、Operatorのリソースが削除されます。GitLabインスタンスに関連付けられたオブジェクトは削除されません。

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

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