GitLab Webserviceチャートの使用

webserviceサブチャートは、GitLab Railsウェブサーバーにポッドごとに2つのWebserviceワーカーを提供します。これは、1つのポッドがGitLabであらゆるWebリクエストを処理するために必要な最小限の数です。

このチャートのポッドは、gitlab-workhorseとwebserviceの2つのコンテナを使用します。GitLab Workhorseはポート8181でリッスンし、ポッドへの受信トラフィックの宛先は_常に_そうでなければなりません。webserviceはGitLabのRailsコードベースを格納し、8080でリッスンし、メトリクス収集の目的でアクセスできます。webserviceは、通常のトラフィックを直接受信してはなりません。

要件

このチャートは、Redis、PostgreSQL、Gitaly、およびRegistryサービスに依存します。これらは、完全なGitLabチャートの一部として、またはこのチャートがデプロイされるKubernetesクラスタリングから到達可能な外部サービスとして提供されます。

設定

webserviceチャートは、次のように構成されています: グローバル設定 、デプロイメント設定 、Ingress設定 、外部サービス 、およびチャートの設定。

インストールコマンドラインオプション

以下の表には、helm installコマンドに--setフラグを使用して指定できる、チャートの構成がすべて記載されています。

チャート設定の例

extraEnv

extraEnvを使用すると、ポッド内のすべてのコンテナで追加の環境変数を公開できます。

extraEnvの使用例を以下に示します:

extraEnv:
  SOME_KEY: some_value
  SOME_OTHER_KEY: some_other_value

コンテナの起動時に、環境変数が公開されていることを確認できます:

env | grep SOME
SOME_KEY=some_value
SOME_OTHER_KEY=some_other_value

extraEnvFrom

extraEnvFromを使用すると、ポッド内のすべてのコンテナで、他のデータソースからの追加の環境変数を公開できます。後続の変数は、デプロイごとにオーバーライドできます。

extraEnvFromの使用例を以下に示します:

extraEnvFrom:
  MY_NODE_NAME:
    fieldRef:
      fieldPath: spec.nodeName
  MY_CPU_REQUEST:
    resourceFieldRef:
      containerName: test-container
      resource: requests.cpu
  SECRET_THING:
    secretKeyRef:
      name: special-secret
      key: special_token
      # optional: boolean
deployments:
  default:
    extraEnvFrom:
      CONFIG_STRING:
        configMapKeyRef:
          name: useful-config
          key: some-string
          # optional: boolean

image.pullSecrets

pullSecretsを使用すると、プライベートレジストリに対して認証を行い、ポッドのイメージをプルできます。

プライベートレジストリとその認証方法の詳細については、Kubernetesドキュメントを参照してください。

pullSecretsの使用例を以下に示します:

image:
  repository: my.webservice.repository
  pullPolicy: Always
  pullSecrets:
  - name: my-secret-name
  - name: my-secondary-secret-name

serviceAccount

このセクションでは、サービスアカウントを作成するかどうか、およびポッドにデフォルトのアクセストークンをマウントするかどうかを制御します。

tolerations

tolerationsを使用すると、taintされたワーカーノードでポッドをスケジュールできます

tolerationsの使用例を以下に示します:

tolerations:
- key: "node_label"
  operator: "Equal"
  value: "true"
  effect: "NoSchedule"
- key: "node_label"
  operator: "Equal"
  value: "true"
  effect: "NoExecute"

annotations

annotationsを使用すると、Webserviceポッドに注釈を追加できます。例:

annotations:
  kubernetes.io/example-annotation: annotation-value

strategy

deployment.strategyを使用すると、デプロイの更新仕様を変更できます。更新時にデプロイのポッドがどのように再作成されるかを定義します。指定されていない場合は、クラスタリングのデフォルトが使用されます。たとえば、ローリング更新の開始時に追加のポッドを作成せず、使用できないポッドの最大数を50%に変更する場合は、次のようにします:

deployment:
  strategy:
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 50%

更新仕様のタイプをRecreateに変更することもできますが、新しいポッドのスケジュール前にすべてのポッドが強制終了され、新しいポッドが起動するまでWeb UIが使用できなくなるため、注意してください。この場合、rollingUpdateを定義する必要はなく、typeのみを定義する必要があります:

deployment:
  strategy:
    type: Recreate

詳細については、Kubernetesドキュメントを参照してください。

TLS

Webserviceポッドは2つのコンテナを実行します:

• gitlab-workhorse
• webservice

gitlab-workhorse

Workhorseは、WebおよびメトリクスのエンドポイントでTLSをサポートしています。これにより、Workhorseと他のコンポーネント（特にnginx-ingress、gitlab-shell、およびgitaly）間の通信が保護されます。TLS証明書には、共通名（CN）またはサブジェクト代替名（SAN）にWorkhorseサービスホスト名（例: RELEASE-webservice-default.default.svc）が含まれている必要があります。

Webserviceの複数のデプロイが存在する可能性があることに注意してください。そのため、異なるサービス名に対してTLS証明書を準備する必要があります。これは、複数のSANまたはワイルドカード証明書のいずれかによって実現できます。

TLS証明書が生成されたら、その証明書のKubernetes TLSシークレットを作成します。ca.crtキーを持つTLS証明書のCA証明書のみを含む別のシークレットも作成する必要があります。

global.workhorse.tls.enabledをtrueに設定することで、gitlab-workhorseコンテナのTLSを有効にできます。カスタムシークレット名をgitlab.webservice.workhorse.tls.secretNameおよびglobal.certificates.customCAsにそれぞれ渡すことができます。

gitlab.webservice.workhorse.tls.verifyがtrue（デフォルト）の場合、CA証明書シークレット名もgitlab.webservice.workhorse.tls.caSecretNameに渡す必要があります。これは、自己署名証明書とカスタムCAに必要です。このシークレットは、NGINXがWorkhorseのTLS証明書を検証するために使用します。

global:
  workhorse:
    tls:
      enabled: true
  certificates:
    customCAs:
      - secret: gitlab-workhorse-ca
gitlab:
  webservice:
    workhorse:
      tls:
        verify: true
        # secretName: gitlab-workhorse-tls
        caSecretName: gitlab-workhorse-ca
      monitoring:
        exporter:
          enabled: true
          tls:
            enabled: true

gitlab-workhorseコンテナのメトリクスエンドポイントのTLSは、global.workhorse.tls.enabledから継承されます。メトリクスエンドポイントのTLSは、WorkhorseでTLSが有効になっている場合にのみ使用できます。メトリクスリスナーは、gitlab.webservice.workhorse.tls.secretNameで指定されたものと同じTLS証明書を使用します。

メトリクスエンドポイントに使用されるTLS証明書では、特に含まれているPrometheus Helmチャートを使用している場合は、含まれているサブジェクトの代替名（SAN）について追加の考慮事項が必要になる場合があります。詳細については、TLS対応エンドポイントをスクレイプするようにPrometheusを構成するを参照してください。

webservice

TLSを有効にする主なユースケースは、PrometheusメトリクスのスクレイプのためにHTTPS経由で暗号化を提供することです。

PrometheusがHTTPSを使用して/metrics/エンドポイントをスクレイプするには、証明書のCommonName属性またはSubjectAlternativeNameエントリの追加構成が必要です。これらの要件については、TLS対応エンドポイントをスクレイプするようにPrometheusを構成するを参照してください。

設定gitlab.webservice.tls.enabledにより、webserviceコンテナでTLSを有効にできます:

gitlab:
  webservice:
    tls:
      enabled: true
      # secretName: gitlab-webservice-tls

secretNameは、Kubernetes TLSシークレットを指している必要があります。たとえば、ローカル証明書とキーを使用してTLSシークレットを作成するには、次のようにします:

kubectl create secret tls <secret name> --cert=path/to/puma.crt --key=path/to/puma.key

このチャートのCommunity Editionを使用する

デフォルトの場合、HelmチャートではGitLabのEnterprise Editionを使用します。必要に応じて、Community Editionを代わりに使用できます。2つのエディションの違いについて詳しくは、こちらをご覧ください。

Community Editionを使用するには、image.repositoryをregistry.gitlab.com/gitlab-org/build/cng/gitlab-webservice-ceに、workhorse.imageをregistry.gitlab.com/gitlab-org/build/cng/gitlab-workhorse-ceに設定します。

グローバル設定

いくつかの一般的なグローバル設定をチャート間で共有します。GitLabやレジストリホスト名など、一般的な構成オプションについては、グローバルドキュメントを参照してください。

デプロイ設定

このチャートには、複数のデプロイオブジェクトとそれらに関連するリソースを作成する機能があります。この機能を使用すると、パスベースのルーティングを使用して、GitLabアプリケーションへのリクエストをポッドの複数のセット間で分散させることができます。

このマップのキー（この例ではdefault）は、それぞれの「名前」です。defaultには、RELEASE-webservice-defaultで作成された、デプロイ、サービス、HorizontalPodAutoscaler、PodDisruptionBudget、およびオプションのIngressがあります。

指定されていないプロパティは、gitlab-webserviceチャートのデフォルトから継承されます。

deployments:
  default:
    ingress:
      path: # Does not inherit or default. Leave blank to disable Ingress.
      pathType: Prefix
      provider: nginx
      annotations:
        # inherits `ingress.anntoations`
      proxyConnectTimeout: # inherits `ingress.proxyConnectTimeout`
      proxyReadTimeout:    # inherits `ingress.proxyReadTimeout`
      proxyBodySize:       # inherits `ingress.proxyBodySize`
    deployment:
      annotations: # map
      labels: # map
      # inherits `deployment`
    pod:
      labels: # additional labels to .podLabels
      annotations: # map
        # inherit from .Values.annotations
    service:
      labels: # additional labels to .serviceLabels
      annotations: # additional annotations to .service.annotations
        # inherits `service.annotations`
    hpa:
      minReplicas: # defaults to .minReplicas
      maxReplicas: # defaults to .maxReplicas
      metrics: # optional replacement of HPA metrics definition
      # inherits `hpa`
    pdb:
      maxUnavailable: # inherits `maxUnavailable`
    resources: # `resources` for `webservice` container
      # inherits `resources`
    workhorse: # map
      # inherits `workhorse`
    extraEnv: #
      # inherits `extraEnv`
    extraEnvFrom: #
      # inherits `extraEnvFrom`
    puma: # map
      # inherits `puma`
    workerProcesses: # inherits `workerProcesses`
    shutdown:
      # inherits `shutdown`
    nodeSelector: # map
      # inherits `nodeSelector`
    tolerations: # array
      # inherits `tolerations`
    priorityClassName: # inherits `priorityClassName`

デプロイIngress

各deploymentsエントリは、チャート全体のIngress設定から継承されます。ここに表示される値は、そこで提供される値をオーバーライドします。pathを除き、すべての設定はこれらと同一です。

webservice:
  deployments:
    default:
      ingress:
        path: /
   api:
     ingress:
       path: /api

pathプロパティは、Ingressのpathプロパティに直接入力され、各サービスに送信されるURIパスを制御できます。上記の例では、defaultはキャッチオールパスとして機能し、apiは/apiですべてのトラフィックを受信しました

pathを空に設定すると、特定のデプロイが関連付けられたIngressリソースの作成を無効にできます。以下を参照してください。 internal-apiは外部トラフィックを受信しません。

webservice:
  deployments:
    default:
      ingress:
        path: /
   api:
     ingress:
       path: /api
   internal-api:
     ingress:
       path:

Ingress設定

注釈

annotationsは、Webservice Ingressに注釈を設定するために使用されます。

serviceUpstream

これにより、NGINXにアップストリームとしてサービス自体に直接連絡するように指示することで、Webserviceポッドへのトラフィックのバランスがより均等になります。詳細については、NGINXドキュメントを参照してください。

これをオーバーライドするには、次のように設定します:

gitlab:
  webservice:
    ingress:
      serviceUpstream: "false"

proxyBodySize

proxyBodySizeは、NGINXプロキシの最大ブロックサイズを設定するために使用されます。これは通常、デフォルトよりも大きいDockerイメージを許可するために必要です。これは、Linuxパッケージインストールのnginx['client_max_body_size']構成と同等です。代替オプションとして、次の2つのパラメータのいずれかを使用してブロックサイズを設定することもできます:

• gitlab.webservice.ingress.annotations."nginx\.ingress\.kubernetes\.io/proxy-body-size"
• global.ingress.annotations."nginx\.ingress\.kubernetes\.io/proxy-body-size"

追加のIngress

extraIngress.enabled=trueを設定すると、追加のIngressをデプロイできます。Ingressには、-extraサフィックスが付いたデフォルトIngressという名前が付けられ、デフォルトIngressと同じ設定がサポートされます。

リソース

メモリリクエスト/制限

各ポッドは、workerProcessesと等しい数のワーカーを起動します。各ワーカーは、ベースライン量のメモリをいくらか使用します。推奨事項:

• ワーカーあたり最小1.25GB（requests.memory）
• ワーカーあたり最大1.5GB、さらにプライマリに1GB（limits.memory）

必要なリソースはユーザーが生成したワークロードに依存し、GitLabアプリケーションの変更またはアップグレードに基づいて将来変更される可能性があることに注意してください。

デフォルトは、:

workerProcesses: 2
resources:
  requests:
    memory: 2.5G # = 2 * 1.25G
# limits:
#   memory: 4G   # = (2 * 1.5G) + 950M

4つのワーカーが構成されている場合:

workerProcesses: 4
resources:
  requests:
    memory: 5G   # = 4 * 1.25G
# limits:
#   memory: 7G   # = (4 * 1.5G) + 950M

外部サービス

Redis

Redisドキュメントは、グローバルページに統合されました。最新のRedis構成オプションについては、このページを参照してください。

PostgreSQL

PostgreSQLドキュメントは、グローバルページに統合されました。最新のPostgreSQL構成オプションについては、このページを参照してください。

Webserviceデプロイのdependencies initContainerは、次のことを確認するスクリプトを実行します:

• GitLabの依存関係が利用可能かどうか。
• PostgreSQLのデータベース移行が実行されたかどうか。

これらのスクリプトの動作を制御するには、WebserviceチャートのextraEnv構成キーを使用できます。2つの環境変数がサポートされています:

• BYPASS_POST_DEPLOYMENT=true: すべての通常の移行が実行され、デプロイ後の移行のみが保留されている場合、依存関係チェックは合格します
• BYPASS_SCHEMA_VERSION=true（推奨されません）: 通常の移行が実行されていない場合でも、依存関係チェックは合格します。この環境変数を使用すると、データベーススキーマがアプリケーションコードの期待値と一致しないため、起動後にRailsデプロイがエラーになる可能性があります。

Gitaly

Gitalyは、グローバル設定によって構成されます。Gitaly構成ドキュメントを参照してください。

MinIO

minio:
  serviceName: 'minio-svc'
  port: 9000

レジストリ

registry:
  host: registry.example.com
  port: 443
  api:
    protocol: http
    host: registry.example.com
    serviceName: registry
    port: 5000
  tokenIssuer: gitlab-issuer
  certificate:
    secret: gitlab-registry
    key: registry-auth.key

チャート設定

次の値は、Webserviceポッドの構成に使用されます。

メトリクス

metrics.enabledの値でメトリクスを有効にし、GitLabモニタリングエクスポーターを使用してメトリクスポートを公開できます。ポッドにはPrometheus注釈が付与されるか、metrics.serviceMonitor.enabledがtrueの場合、Prometheus Operator ServiceMonitorが作成されます。メトリクスは/-/metricsエンドポイントからスクレイプできますが、これにはGitLab Prometheusメトリクスが管理者エリアで有効になっている必要があります。また、GitLab Workhorseのメトリクスはworkhorse.metrics.enabledを介して公開することもできますが、Prometheusの注釈を使用して収集することはできないため、workhorse.metrics.serviceMonitor.enabledがtrueであるか、外部のPrometheus設定が必要です。

GitLab Shell

GitLab Shellは、Webserviceとの通信で認証トークンを使用します。共有シークレットを使用して、トークンをGitLab ShellおよびWebserviceと共有します。

shell:
  authToken:
    secret: gitlab-shell-secret
    key: secret
  port:

WebServerオプション

現在のチャートのバージョンは、Puma Webサーバーをサポートしています。

Puma固有のオプション:

networkpolicyの設定

このセクションでは、NetworkPolicyを制御します。この設定はオプションであり、特定のエンドポイントへのポッドのエグレスおよびイングレスを制限するために使用されます。

ネットワークポリシーの例

webserviceサービスには、Prometheusエクスポーターが有効になっている場合、イングレス接続、NGINXイングレスからのトラフィック、およびいくつかのGitLabポッドが必要です。通常、さまざまな場所へのエグレス接続が必要です。この例では、次のネットワークポリシーを追加します:

• イングレスリクエストを許可:
  • ポッドgitaly、gitlab-pages、gitlab-shell、kas、mailroom、およびnginx-ingressからポート8181へ
  • Prometheusポッドからポート8080、8083、および9229へ
• エグレスリクエストを許可:
  • gitalyポッドからポート8075へ
  • kasポッドからポート8153へ
  • kube-dnsからポート53へ
  • registryポッドからポート5000へ
  • 外部データベース172.16.0.10/32からポート5432へ
  • 外部Redis 172.16.0.11/32からポート6379へ
  • インターネット0.0.0.0/0からポート443へ
  • S3またはSTSのAWS VPCエンドポイントのようなエンドポイントからポート443 172.16.1.0/24へ

提供されている例は単なる例であり、完全ではない可能性があります

ウェブサービスには、オブジェクトストレージ上のイメージへの送信接続が必要であることに注意してください

この例は、kube-dnsがネームスペースkube-systemに、prometheusがネームスペースmonitoringに、nginx-ingressがネームスペースnginx-ingressにデプロイされたという前提に基づいています。

networkpolicy:
  enabled: true
  ingress:
    enabled: true
    rules:
      - from:
          - podSelector:
              matchLabels:
                app: gitaly
        ports:
          - port: 8181
      - from:
          - podSelector:
              matchLabels:
                app: gitlab-pages
        ports:
          - port: 8181
      - from:
          - podSelector:
              matchLabels:
                app: gitlab-shell
        ports:
          - port: 8181
      - from:
          - podSelector:
              matchLabels:
                app: kas
        ports:
          - port: 8181
      - from:
          - podSelector:
              matchLabels:
                app: mailroom
        ports:
          - port: 8181
      - from:
          - namespaceSelector:
              matchLabels:
                kubernetes.io/metadata.name: nginx-ingress
            podSelector:
              matchLabels:
                app: nginx-ingress
                component: controller
        ports:
          - port: 8181
      - from:
          - namespaceSelector:
              matchLabels:
                kubernetes.io/metadata.name: monitoring
            podSelector:
              matchLabels:
                app: prometheus
                component: server
                release: gitlab
        ports:
          - port: 9229
          - port: 8080
          - port: 8083
  egress:
    enabled: true
    rules:
      - to:
          - podSelector:
              matchLabels:
                app: gitaly
        ports:
          - port: 8075
      - to:
          - podSelector:
              matchLabels:
                app: kas
        ports:
          - port: 8153
      - to:
          - ipBlock:
              cidr: 0.0.0.0/0
              except:
                - 10.0.0.0/8
        ports:
          - port: 443
      - to:
          - ipBlock:
              cidr: 172.16.0.10/32
        ports:
          - port: 5432
      - to:
          - ipBlock:
              cidr: 172.16.0.11/32
        ports:
          - port: 6379
      - to:
          - namespaceSelector:
              matchLabels:
                kubernetes.io/metadata.name: kube-system
            podSelector:
              matchLabels:
                k8s-app: kube-dns
        ports:
          - port: 53
            protocol: UDP

LoadBalancerLoadBalancerサービス

service.typeがLoadBalancerに設定されている場合、オプションでservice.loadBalancerIPを指定して、ユーザー指定のIPでLoadBalancerを作成できます（クラウドプロバイダーがサポートしている場合）。

service.typeがLoadBalancerに設定されている場合は、service.loadBalancerSourceRangesを設定して、LoadBalancerにアクセスできるCIDR範囲を制限する必要があります（クラウドプロバイダーがサポートしている場合）。現在、メトリクスポートが公開されている問題により、これは必須です。

LoadBalancerサービスタイプの詳細については、Kubernetesドキュメントを参照してください

service:
  type: LoadBalancer
  loadBalancerIP: 1.2.3.4
  loadBalancerSourceRanges:
  - 10.0.0.0/8

KEDAの設定

このkedaセクションでは、通常のHorizontalPodAutoscalersではなく、KEDA ScaledObjectsのインストールを有効にします。この設定はオプションであり、カスタムまたは外部メトリクスに基づいてオートスケーリングが必要な場合に使用できます。

ほとんどの設定は、該当する場合、hpaセクションで設定された値にデフォルト設定されます。

以下が当てはまる場合、hpaセクションで設定されたCPUとメモリのしきい値に基づいて、CPUとメモリのトリガーが自動的に追加されます:

• triggersが設定されていません。
• 対応するrequest.cpu.requestまたはrequest.memory.request設定も、ゼロ以外の値に設定されています。

トリガーが設定されていない場合、ScaledObjectは作成されません。

これらの設定の詳細については、KEDAドキュメントを参照してください。