インストール

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

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

前提条件

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

クラスター

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

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

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

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

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

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

Ingressコントローラー

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

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

外部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 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にアクセスできます。

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

推奨される次のステップ

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

OpenShift

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

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

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

GitLab Operatorのアンインストール

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

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

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

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

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

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

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インスタンスに関連付けられたオブジェクトをdoes not。

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

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