インストール

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

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

前提要件

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

クラスタ:

当社は、Kubernetesの3つの最新のマイナーバージョンと、OpenShiftの4つの最新のマイナーリリースとの互換性を同時に目指しています。新しいバージョンのサポートが追加されると、最も古いサポート対象バージョンのテストは中止されます。私たちの目標は、KubernetesとOpenShiftの新しいマイナーリリースの最初の提供から3か月以内に、オペレーターのサポートを提供することです。

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

ノート: 一部のコンポーネント（Kubernetes用のエージェントやGitLab Chartsなど）では、GitLabが異なるクラスターのバージョンをサポートする場合があります。

上記のリストよりも新しいリリースとの互換性に関するイシューは、イシュートラッカーでお知らせください。

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

16.7以降、オペレーターはx86-64およびarm64用に構築されています。arm64イメージは継続的インテグレーションでテストされておらず、本番環境での使用は推奨されません。

マルチアーキテクチャクラスターを使用している場合は、ノードセレクターをkubernetes.io/archラベルをオペレーターデプロイに追加することをお勧めします。

デプロイにパッチを適用して、x86-64/amd64ノードでのみスケジュールされるようにします:

kubectl patch deployments gitlab-controller-manager \
  -p '{"spec": {"template": {"spec": {"nodeSelector": {"kubernetes.io/arch": "amd64"}}}}}'

オペレーターHelmチャートを使用している場合は、values.yamlにノードセレクターを追加できます:

nodeSelector:
  kubernetes.io/arch: amd64

これにより、テストするプラットフォームを使用して、オペレーターがamd64ノードで実行されるようになります。

CNGイメージのarm64サポートの詳細については、エピック10928を参照してください。

Ingressコントローラー

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

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

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

TLS証明書

オペレーターのKubernetes Webhookの証明書を作成するには、cert-managerを使用します。GitLab証明書にもcert-managerを使用する必要があります。

オペレーターにはKubernetes Webhookの証明書が必要なため、GitLabチャートにバンドルされているcert-managerは使用できません。代わりに、オペレーターをインストールする前に、cert-managerをインストールします。

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

メトリクス

ドメインネームシステムの設定

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

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

OpenShiftのIngressには、特別な考慮事項が必要です。詳細については、OpenShift Ingressに関する注意事項を参照してください。

GitLabオペレーターのインストール

まず、インストール方法を選択します。

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

オペレーターデプロイのステータスを確認して、インストールを確認します:

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

   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オペレーターの承認戦略を自動（デフォルト）から手動に変更します。これにより、承認が得られるまで、OpenShiftが新しいオペレーターバージョンをインストールするのを防ぐことができます。

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

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

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

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

オペレーターをアンインストールする前に注意すべき点:

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

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

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

これにより、GitLabインスタンスと、上記のように永続ボリュームクレームを除くすべての関連オブジェクトが削除されます）。

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

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

これにより、オペレーターの実行中のデプロイを含む、オペレーターのリソースが削除されます。これは、GitLabインスタンスに関連付けられたオブジェクトを削除しません。

GitLabオペレーターのトラブルシューティング

オペレーターのトラブルシューティングは、トラブルシューティング.mdにあります。