デプロイガイド

helm installを実行する前に、GitLab をどのように実行するかについていくつか決めておく必要があります。 オプションは Helm の--set option.name=value コマンドラインオプションを使って指定します。 コマンドラインオプションの完全なリストはこちらを参照してください。 このガイドでは、必要な値と一般的なオプションについて説明します。

設定オプションの選択

各セクションでは、helm installと組み合わせて使用するオプションを収集します。

秘密

デフォルトでは自動的に生成されますが、指定したい場合はsecrets ガイドに従ってください。

ネットワークとDNS

デフォルトでは、Ingressオブジェクトで設定された名前ベースの仮想サーバーを使用して GitLab サービスを公開するために、type: LoadBalancerの KubernetesService オブジェクトに依存しています。gitlab、registry、minio (有効な場合) をチャートに適切な IP に解決するレコードを含むドメインを指定する必要があります。

Helmのインストールコマンドにこれらのオプションを含めます： 

--set global.hosts.domain=example.com

外部DNSによる動的IP

external-dnsのような自動DNS登録サービスを使うつもりなら、GitLabに追加の設定は必要ありませんが、クラスターにデプロイする必要があります。 external-dnsを選ぶなら、プロジェクトページにサポートされているプロバイダーごとの包括的なガイドがあります。

このリポジトリのスクリプトを使用して GKE クラスターをプロビジョニングした場合、external-dnsはすでにクラスターにインストールされています。

静的IP

DNSレコードを手動で設定する場合は、すべて静的IPを指す必要があります。たとえば、example.com を選択し、静的IPが10.10.10.10の場合、gitlab.example.com、registry.example.com 、minio.example.com (MinIO を使用している場合) はすべて10.10.10.10に解決する必要があります。

GKEを使用している場合、静的IPとDNSを設定するためのドキュメントがここにあります。 このプロセスの詳細については、クラウドおよび/またはDNSプロバイダのドキュメントを参照してください。

Helmのインストールコマンドにこれらのオプションを含めます： 

--set global.hosts.externalIP=10.10.10.10

永続性

デフォルトでは、ダイナミック・プロビジョナーが基礎となる永続ボリュームを作成することを想定して、Chartはボリューム・クレームを作成します。 storageClassをカスタマイズしたり、ボリュームを手動で作成して割り当てたりする場合は、ストレージのドキュメントを参照してください。

重要：初期インストール後、ストレージの設定を変更するにはKubernetesオブジェクトを手動で編集する必要があるため、本番インスタンスにGitLabをインストールする前に、余分なストレージの移行作業を避けるために事前に計画を立てておくとよいでしょう。

TLS証明書

GitLabをhttpsで動かすにはTLS証明書が必要です。 デフォルトでは、Chartは無料のTLS証明書を取得するためにcert-managerをインストールし、設定します。 もし独自のワイルドカード証明書を持っていたり、すでにcert-managerをインストールしていたり、TLS証明書を取得する他の方法がある場合は、TLSオプションについてこちらをお読みください。

デフォルトの設定では、TLS証明書を登録するための電子メールアドレスを指定する必要があります。

Helmのインストールコマンドにこれらのオプションを含めます： 

--set certmanager-issuer.email=me@example.com

PostgreSQL

デフォルトでは、このChartはクラスタ内のPostgreSQLデータベースを提供します。

注：この構成は本番環境での使用は推奨されません。

  • bitnami/PostgreSQLでは、デフォルトで1つのStatefulSetが提供されます。
  • これらのChartの4.0.0の時点で、レプリケーションは内部で利用可能ですが、_デフォルトでは有効になって_いません。 そのような機能はGitLabによって負荷テストされていません。

本番環境に対応したデータベースのセットアップについては、高度なデータベースのドキュメントを参照してください。

外部のPostgreSQLデータベースを準備している場合、Chartは以下のようにそれを使用するように設定することができます。

Helmのインストールコマンドにこれらのオプションを含めます： 

--set postgresql.install=false
--set global.psql.host=production.postgress.hostname.local
--set global.psql.password.secret=kubernetes_secret_name
--set global.psql.password.key=key_that_contains_postgres_password

Redis

すべてのRedisコンフィギュレーション設定が移動され、charts/globals.mdページに統合されました。

注：この構成は本番環境での使用は推奨されません。

  • bitnami/Redisがデフォルトで提供するStatefulSetは1つです。
  • これらのChartの4.0.0の時点で、レプリケーションは内部で利用可能ですが、_デフォルトでは有効になって_いません。 そのような機能はGitLabによって負荷テストされていません。

本番環境でのRedisインスタンスのセットアップについては、Redisの詳細なドキュメントを参照してください。

ミニオ

デフォルトでは、このChartはオブジェクトストレージAPIを提供するためにクラスタ内のMinIOデプロイを提供します。

注：この構成は本番環境での使用は推奨されません。

本番環境で使用可能なオブジェクトストレージのセットアップについては、外部オブジェクトストレージの

Prometheus

私たちはアップストリームのPrometheusチャートを使用しており、独自のデフォルトから値を上書きすることはありません。 しかし、デフォルトではalertmanager、nodeExporter、pushgatewayを無効にしています。

設定オプションの詳細なリストについては、Prometheusのチャートのドキュメントを参照し、prometheusのサブキーであることを確認してください。

インスタンスンスでは、永続的なストレージの要求を制御することができます： 

prometheus:
  alertmanager:
    enabled: false
    persistentVolume:
      enabled: false
      size: 2Gi
  pushgateway:
    enabled: false
    persistentVolume:
      enabled: false
      size: 2Gi
  server:
    persistentVolume:
      enabled: true
      size: 8Gi

送信メール

デフォルトでは、送信メールは無効になっています。 有効にするには、global.smtp およびglobal.email 設定を使用して SMTP サーバーの詳細を指定します。これらの設定の詳細は、コマンドラインオプションに記載されています。

SMTP サーバーに認証が必要な場合は、secrets ドキュメントのパスワードの提供に関するセクションを必ずお読みください。認証設定は--set global.smtp.authentication=""で無効にできます。

KubernetesクラスタがGKE上にある場合、SMTPポート25がブロックされていることに注意してください。

受信メール

デフォルトでは、受信メールは無効になっています。 有効にするには、global.appConfig.incomingEmail設定を使用して、IMAP サーバーの詳細とアクセス認証情報を提供します。これらの設定の詳細は、コマンドラインオプションに記載されています。 また、secrets ガイドに記載されているように、IMAP パスワードを含む Kubernetes シークレットを作成する必要があります。

ユーザが通知メールに返信してイシューやMRにコメントできる、メール返信機能を使用するには、送信メールと受信メールの両方の設定を行う必要があります。

サービスデスクEメール

デフォルトでは、サービスデスクのメールは無効になっています。 有効にするには、global.appConfig.serviceDeskEmail設定を使用して、IMAP サーバーの詳細とアクセス認証情報を提供します。これらの設定の詳細は、コマンドラインオプションに記載されています。 また、secrets ガイドに記載されているように、IMAP パスワードを含む Kubernetes シークレットを作成する必要があります。

注意サービスデスクの電子メールは、受信電子メールが設定されている_必要があります_。

コミュニティ版のデプロイ

デフォルトでは、HelmチャートはGitLabのEnterprise Editionを使用します。 必要であれば、代わりにCommunity Editionを使用することもできます。両者の違いについてはこちらをご覧ください。

Community Editionをデプロイするには、Helmインストールコマンドにこのオプションを含めます： 

--set global.edition=ce

リレーショナルアクセス制御

このChartのデフォルトはRBACの作成と使用です。 クラスターでRBACが有効になっていない場合は、これらの設定を無効にする必要があります： 

--set certmanager.rbac.create=false
--set nginx-ingress.rbac.createRole=false
--set prometheus.rbac.create=false
--set gitlab-runner.rbac.create=false

CPUとRAMのリソース要件

このChartのGitLabコンポーネント（PostgreSQL、Redis、MinIOではありません）のリソース要求とレプリカの数は、デフォルトでは小規模な本番環境でのデプロイに十分なように設定されています。 これは、少なくとも8vCPUと30gbのRAMを持つクラスターに適合するように意図されています。 非本番インスタンスをデプロイしようとしている場合は、より小規模なクラスターに適合するようにデフォルトを減らすことができます。

最小GKEサンプル値ファイルは、3vCPU 12gbクラスターに適合するようにリソースをチューニングする例を提供します。

最小Minikubeサンプル値ファイルには、2vCPU、4GBのMinikubeインスタンス内に収まるようにリソースをチューニングする例が記載されています。

Helmを使ったデプロイ

すべての設定オプションを収集したら、依存関係を取得してHelmを実行します。 この例では、Helmリリースにgitlab. 

helm repo add gitlab https://charts.gitlab.io/
helm repo update
helm upgrade --install gitlab gitlab/gitlab \
  --timeout 600s \
  --set global.hosts.domain=example.com \
  --set global.hosts.externalIP=10.10.10.10 \
  --set certmanager-issuer.email=me@example.com
注意: すべてのHelmコマンドはHelm v3の構文で指定されています。 Helm v2の構文と異なる場合は、その違いを詳しく説明するように努めています。
注意:helm install を使用する場合、Helm v2 と Helm v3 のオペレーションに若干の違いがあります。Helm v2 を使用する場合、--name オプションでリリース名を指定しないと、ランダムにリリース名が生成されます。Helm v3 では、--generate-nameオプションを使用しない限り、コマンドラインの位置引数でリリース名を指定する必要があります。
注: 上記のタイムアウトオプションは、Helm v2とHelm v3では扱いが異なります。 Helm v3では、値に単位を付加した期間を指定することができます (例:120s =2m,210s =3m30s)。--timeout オプションは、単位を指定_せずに_秒数として扱われます。
注意:--timeout オプションの使用は、Helm のインストールまたはアップグレード中にデプロイされる複数のコンポーネントがあり、このオプションが--timeout 適用さ --timeoutれるという点で、欺瞞的です--timeout 。この --timeout値は、各コンポーネントのインストールに個別に適用され、すべてのコンポーネントのインストールに適用されるわけではありません。そのため、--timeout を使用して 3 分後に Helm のインストールを中止するつもりが、インストールされたコンポーネントのどれもがインストールに 3 分以上かかったため、5 分後にインストールが完了する可能性があります。

特定のバージョンのGitLabをインストールしたい場合は、--version <installation version> オプションを使うこともできます。

ChartのバージョンとGitLabのバージョンのマッピングはこちら。

タグ付きリリースではなく開発ブランチをインストールする手順は、開発者デプロイのドキュメントにあります。

GitLab オペレータ（実験的）

GitLab Operatorを使用してダウンタイムゼロのアップグレードを実現したい場合は、オペレーターを使用するためのドキュメントに従ってください。

デプロイの監視

デプロイが終了すると、インストールされたリソースのリストが出力されます（5～10分かかる場合があります）。

デプロイのステータスは、helm status gitlab を実行することで確認できます。別のターミナルでコマンドを実行すれば、デプロイが行われている最中でも確認できます。

初期ログイン

インストール時に指定したドメインにアクセスすることで、GitLabインスタンスにアクセスすることができます。 rootの初期パスワード用のシークレットを手動で作成した場合は、それを使ってroot ユーザーとして rootサインインすることができますroot 。 そうでない場合は、GitLabが自動的に rootユーザーroot 用のランダムなパスワードを root作成しています。これは、以下のコマンドで抽出することができます（<name> をリリース名に置き換えます - 上記のコマンドを使った場合はgitlabになります）。 

kubectl get secret <name>-gitlab-initial-root-password -ojsonpath='{.data.password}' | base64 --decode ; echo