• 前提条件
  • クラスター
    • Kubernetes
    • OpenShift
  • イングレスコントローラ
  • TLS証明書
  • メトリクス
    • Kubernetes
    • OpenShift
  • ドメインネームサービスの設定
• GitLab オペレータのインストール
• 推奨される次のステップ
• GitLab オペレータをアンインストールします。
  • GitLab のインスタンスをアンインストールします。
  • GitLab オペレータをアンインストールします。
• GitLab Operator のトラブルシューティング

インストール

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

OpenShiftを使用している場合、これらの手順は通常、オペレータがバンドル公開されると、OLM（オペレータライフサイクルマネージャ）によって処理されます。しかし、最新のオペレータイメージをテストするために、ユーザーは、オペレータリポジトリで利用可能なデプロイマニフェストを使用してオペレータをインストールする必要があるかもしれません。

前提条件

1. 既存のKubernetesまたはOpenShiftクラスターを作成または使用します。
2. 前提条件となるサービスとソフトウェアのインストール
   • イングレスコントローラー
   • 証明書マネージャー
   • メトリクス・サーバー
3. ドメインネームサービスの設定

クラスター

Kubernetes

従来のKubernetesクラスターを作成するには、公式ツールまたはお好みのインストール方法を使用してください。

GitLab OperatorはKubernetes 1.19から1.22をサポートしており、CIでは1.21と1.22に対してテストされています。エピック7599では、1.25のサポートに向けた進捗を追跡しています。コンポーネントやその他のインストール方法によっては、GitLabは異なるクラスターのバージョンをサポートする場合があります。

OpenShift

OpenShiftクラスターを作成するには、OpenShiftクラスター設定ドキュメントで _開発環境の_作成例を参照してください。

GitLab OperatorはOpenShift 4.10から4.12をサポートしています。

イングレスコントローラ

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

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

外部のIngressコントローラを使用したい場合は、KubernetesコミュニティによるNGINX Ingressを推奨してIngressコントローラをデプロイします。あなたのプラットフォームと好みのツールに基づいて、リンク先の関連する指示に従ってください。後々のためにIngressクラスの値を控えておいてください（通常デフォルトはnginx）。GitLab CRを設定するときは、nginx-ingress.enabled=false 、GitLab Helm ChartからNGINXオブジェクトを無効にするように設定してください。

TLS証明書

OperatorのKubernetes Webhook用の証明書を作成するには、Cert Managerを使用します。GitLab証明書にもCert Managerを使用することをお勧めします。

プラットフォームと推奨ツールに基づき、関連するインストール手順に従ってください。

当社のコードベースは現在、Cert Manager 1.6.1 を対象としています。

メトリクス

Kubernetes

HorizontalPodAutoscalersがポッドのメトリクスを取得できるように、メトリクスサーバをインストールします。

OpenShift

OpenShiftにはデフォルトでPrometheus Adapterが同梱されているので、手動でアクションを起こす必要はありません。

ドメインネームサービスの設定

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

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

OpenShiftにおけるIngressは、特別な考慮が必要です。詳しくはOpenShift Ingressに関するノートをご覧ください。

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

1. GitLab Operatorをデプロイします。

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

   このコマンドは、まずオペレータが使用するサービスアカウント、ロール、ロールバインディングをデプロイし、次にオペレータ自身をデプロイします。

   デフォルトでは、Operator はデプロイされたネームスペースのみを監視します。クラスタ・スコープで監視するようにするには、マニフェスト内のデプロイからWATCH_NAMESPACE 環境変数をspec.template.spec.containers[0].env の下で削除し、上記のkubectl apply コマンドを再実行してください。

   クラスター・スコープでオペレーションを実行することは実験的と見なされます。詳細はイシュー#100を参照してください。

   実験的です：別の方法として、Helm経由でGitLab Operatorをデプロイします。

   helm repo add gitlab-operator https://gitlab.com/api/v4/projects/18899486/packages/helm/stable
   helm repo update
   helm install gitlab-operator gitlab-operator/gitlab-operator --create-namespace --namespace gitlab-system
   

2. 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/0.8.1/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 Chart ドキュメントを参照してください。

3. 新しい 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 ）、ブラウザでGitLabにアクセスすることができますhttps://gitlab.example.com。

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

推奨される次のステップ

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

GitLab オペレータをアンインストールします。

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

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

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

GitLab のインスタンスをアンインストールします。

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

GitLabインスタンスと、（上記のPVC）以外の関連オブジェクトを削除します。

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

実行中のOperatorのデプロイを含む、Operatorのリソースを削除します。GitLabインスタンスに関連付けられているオブジェクトは削除されません。

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

Operator のトラブルシューティングはtroubleshooting.md にあります。