• 前提条件
  • kubectl
  • Helm
  • PostgreSQL
  • Redis
• 他のオプションの決定
  • シークレット
  • ネットワークとDNS
    • 動的IPアドレスにexternal-dns
    • 静的 IP アドレス
    • Istioプロトコル選択との互換性
  • 永続性
  • TLS証明書
  • Prometheus
    • PrometheusがTLS対応エンドポイントをスクレイピングする設定
    • エクスポート・エンドポイント
  • 送信メール
  • 受信メール
  • サービスデスクのメール
  • RBAC
• 次のステップ

GitLabチャートの前提条件

KubernetesクラスターにGitLabをデプロイする前に、以下の前提条件をインストールし、インストール時に使用するオプションを決めてください。

前提条件

kubectl

Kubernetesのドキュメントに従って kubectl 。インストールするバージョンは、クラスターで動作しているバージョンの1マイナーリリース以内である必要があります。

Helm

Helmドキュメントに従って Helm v3.5.2 以降をインストールしてください。

PostgreSQL

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

外部で本番環境用のPostgreSQLインスタンスをセットアップする必要があります。PostgreSQL 13は、GitLab Chart 6.0以降の推奨デフォルトバージョンです。

GitLab chart 4.0.0では、内部でレプリケーションが利用できますが、デフォルトでは有効になっていません。このような機能はGitLabによって負荷テストされていません。

Redis

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

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

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

他のオプションの決定

GitLabをデプロイするとき、helm install 、以下のオプションを使います。

シークレット

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

ネットワークとDNS

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

gitlab,registry,minio (有効な場合) をChartに適切な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レコードを使うことができます。

動的IPアドレスにexternal-dns

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

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

静的 IP アドレス

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

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

例えば、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 Chartはダイナミックプロビジョナが基盤となる永続ボリュームを作成することを想定してボリュームクレームを作成します。storageClass をカスタマイズしたり、手動でボリュームを作成して割り当てたい場合は、ストレージのドキュメントをレビューしてください。

TLS証明書

GitLabをHTTPSで実行するにはTLS証明書が必要です。デフォルトでは、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 、nodeExporter 、pushgateway を無効にしています。

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設定を使用してGitLabアプリケーションのメトリクスとKubernetesクラスタで実行されている他のアプリケーションの両方をキャプチャする機能が提供されます。

設定オプションの詳細なリストについては、アップストリームの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

PrometheusがTLS対応エンドポイントをスクレイピングする設定

指定されたExporterがTLSを許可し、Chart設定がExporterのエンドポイントのTLS設定を公開している場合、PrometheusはTLS対応エンドポイントからメトリクスをスクレイピングするように設定できます。

Prometheusのスクレイプ設定にTLSとKubernetes Service Discoveryを使用する場合、いくつかの注意点があります：

• ポッドと サービスエンドポイントディスカバリのロールでは、Prometheusはスクレイプターゲットのアドレスを設定するためにポッドの内部IPアドレスを使用します。TLS証明書を検証するために、Prometheusはメトリクスエンドポイント用に作成された証明書に設定されたCommon Name(CN) 、またはSubject Alternative Name(SAN) 拡張に含まれる名前で設定されている必要があります。この名前は解決する必要はなく、有効な DNS 名であれば任意の文字列を使用できます。
• Exporter のエンドポイントに使用される証明書が自己署名されているか、または Prometheus ベースイメージに存在しない場合、Prometheus ポッドは、Exporter のエンドポイントに使用される証明書に署名した認証局(CA) の証明書をマウントする必要があります。Prometheus はベースイメージにDebian のca-bundle を使用しています。
• Prometheusは、各スクレイプ設定に適用されるtls_configを使用して、これらの項目の両方の設定をサポートしています。PrometheusにはPodアノテーションやその他の発見された属性に基づいてPrometheusターゲットラベルを設定するための堅牢なrelabel_configメカニズムがありますが、relabel_config を使用してtls_config.server_name とtls_config.ca_file を設定することはできません。 詳細についてはこのPrometheusプロジェクトのイシューを参照してください。

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

1. tls_config.server_name に使用する任意の名前を1つ選びます（例えば、metrics.gitlab ）。
2. Exporter エンドポイントの TLS 暗号化に使用する各証明書の SAN リストにその名前を追加します。
3. 同じCAからすべての証明書をイシューします：
   • クラスター秘密としてCA証明書を追加します。
   • そのシークレットを Prometheusチャートの extraSecretMounts: 設定を使用して Prometheus サーバーコンテナにマウントします。
   • これを Prometheusscrape_config のtls_config.ca_file に設定します。

Prometheus TLS values exampleでは、この共有設定の例を示しています：

1. ポッド/エンドポイントscrape_config のロールに対してtls_config.server_name をmetrics.gitlab に設定します。
2. Exporter エンドポイントに使用されるすべての証明書の SAN リストにmetrics.gitlab が追加されていると仮定します。
3. CA証明書が、デプロイされたPrometheus Chartと同じ名前空間（例えば、kubectl create secret generic --namespace=gitlab metrics.gitlab.tls-ca --from-file=metrics.gitlab.tls-ca=./ca.pem ）で作成された、metrics.gitlab.tls-ca 同じく名前付きのシークレットキーを持つ metrics.gitlab.tls-caシークレットに追加されていると仮定します。
4. そのmetrics.gitlab.tls-ca シークレットをextraSecretMounts: エントリを使用して/etc/ssl/certs/metrics.gitlab.tls-ca にマウントします。
5. tls_config.ca_file を/etc/ssl/certs/metrics.gitlab.tls-ca に設定します。

エクスポート・エンドポイント

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

次の表は、gitlab.com/prometheus_scrape: true アノテーションが適用されているデプロイメント（または Gitaly と Praefect のいずれかまたは両方を使用する場合：StatefulSets）とサービスエンドポイントの一覧です。

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

Web サービス・ポッドの場合、公開されるポートは Web サービス・コンテナ内のスタンドアロン Webrick Exporter です。Workhorse コンテナ・ポートはスクレイピングされません。詳細については、「Webservice Metrics」のドキュメントを参照してください。

送信メール

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

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

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

受信メール

受信メールの設定はメールルームChartに記載されています。

サービスデスクのメール

受信メールの設定はメールルームChartに記載されています。

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

次のステップ

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