GitLabチャートの必須コンポーネント

KubernetesクラスタにGitLabをデプロイする前に、次の必須コンポーネントをインストールし、インストール時に使用するオプションを決定します。

前提要件

kubectl

Kubernetesのドキュメントに従って、kubectlkubectlをインストールします。インストールするバージョンは、クラスタで実行されているバージョンのマイナーリリースの範囲内である必要があります。

Helm

Helmのドキュメントに従って、Helm v3.17.3以降をインストールします。

PostgreSQL

デフォルトでは、GitLabチャートには、bitnami/PostgreSQLによって提供される、クラスタ内PostgreSQLデプロイメントが含まれています。このデプロイはトライアル目的のみであり、本番環境での使用は推奨されません。

外部の、本番環境対応のPostgreSQLインスタンスをセットアップする必要があります。

サポートされているPostgreSQLのバージョンについては、GitLabの要件を確認してください。

GitLabチャート4.0.0の時点で、レプリケーションは内部的に利用可能ですが、デフォルトでは有効になっていません。このような機能は、GitLabではロードテストされていません。

Redis

デフォルトでは、GitLabチャートには、bitnami/Redisによって提供される、クラスタ内Redisデプロイメントが含まれています。このデプロイはトライアル目的のみであり、本番環境での使用は推奨されません。

外部の、本番環境対応のRedisインスタンスをセットアップする必要があります。利用可能なすべての設定については、Redisグローバルドキュメントを参照してください。

GitLabチャート4.0.0の時点で、レプリケーションは内部的に利用可能ですが、デフォルトでは有効になっていません。このような機能は、GitLabではロードテストされていません。

Gitaly

デフォルトでは、GitLabチャートには、クラスタ内Gitalyデプロイメントが含まれています。本番環境では、KubernetesでのGitalyの実行はサポートされていません。Gitalyは、従来の仮想マシンでのみサポートされています。

外部の、本番環境対応のGitalyインスタンスをセットアップする必要があります。利用可能なすべての設定については、Gitalyグローバルドキュメントを参照してください。

その他のオプションの決定

GitLabをデプロイするときは、helm installで次のオプションを使用します。

シークレット

SSHキーのようなシークレットをいくつか作成する必要があります。デフォルトでは、これらのシークレットはデプロイメント中に自動的に生成されますが、指定する場合は、シークレットに関するドキュメントに従ってください。

ネットワーキングとドメインネームシステム

デフォルトでは、サービスを公開するために、GitLabはIngressオブジェクトで設定された名前ベースの仮想サーバーを使用します。これらのオブジェクトは、type: LoadBalancerのKubernetes Serviceオブジェクトです。

gitlab、registry、およびminio（有効な場合）をチャートの適切なIPアドレスに解決するレコードを含むドメインを指定する必要があります。

たとえば、helm installで次のように使用します:

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

カスタムドメインサポートが有効になっている場合、デフォルトでは<pages domain>である*.<pages domain>サブドメインは、pages.<global.hosts.domain>になります。このドメインは、--set global.pages.externalHttpまたは--set global.pages.externalHttpsによってPagesに割り当てられた外部IPに解決されます。

カスタムドメインを使用するには、GitLab Pagesは、カスタムドメインを対応する<namespace>.<pages domain>ドメインにポイントするCNAMEレコードを使用できます。

external-dnsを使用した動的IPアドレス

external-dnsのような自動ドメインネームシステム登録サービスを使用する予定がある場合は、GitLabの追加のドメインネームシステム設定は必要ありません。ただし、external-dnsをクラスタにデプロイする必要があります。プロジェクトページには、サポートされている各クラウドプロバイダーの包括的なガイドがあります。

提供されたスクリプトを使用してGKEクラスタをプロビジョニングする場合、external-dnsはクラスタに自動的にインストールされます。

静的IPアドレス

ドメインネームシステムレコードを手動で設定する場合は、すべて静的IPアドレスを指している必要があります。たとえば、example.comを選択し、10.10.10.10の静的IPアドレスがある場合、gitlab.example.com、registry.example.com、およびminio.example.com（MinIOを使用している場合）はすべて10.10.10.10に解決される必要があります。

GKEを使用している場合は、外部IPとドメインネームシステムエントリの作成について詳細をお読みください。このプロセスの詳細については、クラウドプロバイダーまたはドメインネームシステムプロバイダーのドキュメントを参照してください。

たとえば、helm installで次のように使用します:

--set global.hosts.externalIP=10.10.10.10

Istioプロトコル選択との互換性

サービスポート名は、Istioの明示的なポート選択と互換性のある規則に従います。たとえば、tls-gitalyやhttps-metricsのように、<protocol>-<suffix>のように表示されます。

GitalyとKASはgRPCを使用しますが、イシュー #3822とイシュー #4908の調査結果により、代わりにtcpプレフィックスを使用することに注意してください。

永続

デフォルトでは、GitLabチャートは、動的プロビジョニングツールが基盤となる永続ボリュームを作成することを期待して、ボリュームクレームを作成します。storageClassをカスタマイズしたり、手動でボリュームを作成して割り当てたりする場合は、ストレージドキュメントを確認してください。

TLS certificates

TLS証明書を必要とするHTTPSでGitLabを実行する必要があります。デフォルトでは、GitLabチャートは無料のTLS証明書を取得するためにcert-managerをインストールして設定します。

独自のワイルドカード証明書を持っている場合、またはcert-managerがすでにインストールされている場合、またはTLS証明書を取得する他の方法がある場合は、TLSオプションの詳細をお読みください。

デフォルトの設定では、TLS証明書を登録するためにメールアドレスを指定する必要があります。たとえば、helm installで次のように使用します:

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

Prometheus

ここでは、アップストリームPrometheusチャートを使用し、メトリックの収集をKubernetes APIとGitLabチャートによって作成されたオブジェクトに制限するために、カスタマイズされたprometheus.ymlファイル以外の独自のデフォルトからの値をオーバーライドしません。ただし、デフォルトでは、alertmanager、node-exporter、pushgateway、およびkube-stat-metricsを無効にします。

prometheus.ymlファイルは、gitlab.com/prometheus_scrape注釈を持つリソースからメトリクスを収集するようにPrometheusに指示します。さらに、gitlab.com/prometheus_pathおよびgitlab.com/prometheus_port注釈を使用して、メトリクスの検出方法を設定できます。これらの各注釈は、prometheus.io/{scrape,path,port}注釈に匹敵します。

PrometheusのインストールでGitLabアプリケーションをモニタリングしている場合、またはモニタリングする場合は、元のprometheus.io/*注釈が適切なポッドとサービスに追加されます。これにより、既存のユーザーのメトリクス収集の継続性が確保され、デフォルトのPrometheus設定を使用して、Kubernetesクラスタで実行されているGitLabアプリケーションメトリクスと他のアプリケーションの両方をキャプチャできます。

網羅的な設定オプションのリストについては、アップストリームPrometheusチャートのドキュメントを参照し、prometheusへのサブキーであることを確認してください。これは要件チャートとして使用するためです。

たとえば、永続ストレージのリクエストは、次のように制御できます:

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

TLS対応エンドポイントをスクレイプするようにPrometheusを設定する

特定のexporterでTLSが許可され、チャートの設定でexporterのエンドポイントのTLS設定が公開されている場合、PrometheusはTLS対応エンドポイントからメトリクスをスクレイプするように設定できます。

TLSとKubernetesサービスディスカバリをPrometheusのスクレイプ設定に使用する場合には、いくつかの注意点があります:

• ポッドとサービスエンドポイントの検出ロールの場合、Prometheusはポッドの内部IPアドレスを使用して、スクレイプターゲットのアドレスを設定します。TLS証明書を確認するには、メトリクスエンドポイント用に作成された証明書に設定された共通名（CN）、またはサブジェクト代替名（SAN）拡張機能に含まれる名前でPrometheusを設定する必要があります。名前は解決する必要はなく、有効なドメインネームシステム名である任意の文字列にすることができます。
• exporterのエンドポイントに使用される証明書が自己署名されている場合、またはPrometheusベースイメージに存在しない場合、Prometheusポッドは、exporterのエンドポイントに使用される証明書に署名した認証局（CA）の証明書をマウントする必要があります。Prometheusは、ベースイメージのDebianからca-bundleを使用します。
• Prometheusは、各スクレイプ設定に適用されるtls_configを使用して、これらの項目の両方を設定することをサポートしています。Prometheusには、ポッドの注釈やその他の検出された属性に基づいてPrometheusターゲットラベルを設定するための堅牢なrelabel_configメカニズムがありますが、tls_config.server_nameとtls_config.ca_fileの設定はrelabel_configを使用して行うことはできません。詳細については、Prometheusプロジェクトイシューをご覧ください。

これらの注意点を考慮すると、最も簡単な設定は、exporterのエンドポイントに使用されるすべての証明書間で「名前」とCAを共有することです:

1. tls_config.server_name（たとえば、metrics.gitlab）に使用する単一の任意の名前を選択します。
2. exporterのエンドポイントをTLSで暗号化されたするために使用される各証明書のSANリストにその名前を追加します。
3. 同じCAからすべての証明書を発行します:
   • CA証明書をクラスタシークレットとして追加します。
   • Prometheusチャートの extraSecretMounts:設定を使用して、そのシークレットをPrometheusサーバーコンテナにマウントします。
   • それをPrometheusのscrape_configのtls_config.ca_fileとして設定します。

Prometheus TLS値の例では、次の方法でこの共有設定の例を示します:

1. ポッド/エンドポイントscrape_configロールのtls_config.server_nameをmetrics.gitlabに設定します。
2. exporterのエンドポイントに使用されるすべての証明書のSANリストにmetrics.gitlabが追加されていることを前提としています。
3. CA証明書がmetrics.gitlab.tls-caという名前のシークレットに追加され、Prometheusチャートがデプロイされているのと同じネームスペースに作成されたシークレットキーもmetrics.gitlab.tls-caという名前であることを前提としています（たとえば、kubectl create secret generic --namespace=gitlab metrics.gitlab.tls-ca --from-file=metrics.gitlab.tls-ca=./ca.pem）。
4. そのmetrics.gitlab.tls-caシークレットを/etc/ssl/certs/metrics.gitlab.tls-caに、extraSecretMounts:エントリを使用してマウントします。
5. tls_config.ca_fileを/etc/ssl/certs/metrics.gitlab.tls-caに設定します。

Exporterエンドポイント

GitLabチャートに含まれるすべてのメトリクスエンドポイントがTLSをサポートしているわけではありません。エンドポイントがTLS対応にできる場合は、gitlab.com/prometheus_scheme: "https"注釈とprometheus.io/scheme: "https"注釈も設定され、どちらもrelabel_configで使用してPrometheus __scheme__ターゲットラベルを設定できます。Prometheus TLS値の例には、gitlab.com/prometheus_scheme: "https"注釈を使用して__scheme__をターゲットとするrelabel_configが含まれています。

次の表に、デプロイメント（またはGitalyとPraefectの両方を使用している場合は、次の場合）を示します: gitlab.com/prometheus_scrape: true注釈が適用されたStatefulSetとサービスエンドポイント。

以下のドキュメントリンクで、コンポーネントがSANエントリの追加について言及している場合は、Prometheusのtls_config.server_nameに使用することにしたSANも必ず追加してください。

webserviceポッドの場合、公開されるポートは、webserviceコンテナ内のスタンドアロンのwebrickエクスポーターです。workhorseコンテナポートはスクレイプされません。詳細については、Webservice Metricsドキュメントを参照してください。

送信メール

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

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

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

受信メール

受信メールの設定は、mailroomチャートに記載されています。

サービスデスクメール

受信メールの設定は、mailroomチャートに記載されています。

RBAC

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

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

次の手順

クラウドプロバイダーを設定し、クラスターを作成します。