• Requirements
• Configuration
• Installation command line options
• Chart configuration examples
  • extraEnv
  • image.pullSecrets
  • tolerations
  • annotations
  • strategy
• Using the Community Edition of this chart
• Global Settings
• Ingress Settings
  • proxyBodySize
• Resources
  • Unicorn Worker Killer memory settings
  • Memory requests/limits
• External Services
  • Redis
  • PostgreSQL
  • Gitaly
  • MinIO
  • Registry
• Chart Settings
  • metrics.enabled
  • GitLab Shell
  • WebServer options

Using the GitLab Webservice Chart

The webservice sub-chart provides the GitLab Rails webserver with two Webservice workers per pod. (The minimum necessary for a single pod to be able to serve any web request in GitLab)

Currently the container used in the chart also includes a copy of GitLab Workhorse, which we haven’t split out yet.

Requirements

This chart depends on Redis, PostgreSQL, Gitaly, and Registry services, either as part of the complete GitLab chart or provided as external services reachable from the Kubernetes cluster this chart is deployed onto.

Configuration

The webservice chart is configured as follows: Global Settings, Ingress Settings, External Services, and Chart Settings.

Installation command line options

The table below contains all the possible chart configurations that can be supplied to the helm install command using the --set flags.

Chart configuration examples

extraEnv

extraEnv allows you to expose additional environment variables in all containers in the pods.

Below is an example use of extraEnv:

extraEnv:
  SOME_KEY: some_value
  SOME_OTHER_KEY: some_other_value

When the container is started, you can confirm that the enviornment variables are exposed:

env | grep SOME
SOME_KEY=some_value
SOME_OTHER_KEY=some_other_value

image.pullSecrets

pullSecrets allows you to authenticate to a private registry to pull images for a pod.

Additional details about private registries and their authentication methods can be found in the Kubernetes documentation.

Below is an example use of pullSecrets:

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

tolerations

tolerations allow you schedule pods on tainted worker nodes

Below is an example use of tolerations:

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

annotations

annotations allows you to add annotations to the Webservice pods. For example:

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

strategy

deployment.strategy allows you to change the deployment update strategy. It defines how the pods will be recreated when deployment is updated. When not provided, the cluster default is used. For example, if you don’t want to create extra pods when the rolling update starts and change max unavailable pods to 50%:

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

You can also change the type of update strategy to Recreate, but be careful as it will kill all pods before scheduling new ones, and the web UI will be unavailable until the new pods are started. In this case, you don’t need to define rollingUpdate, only type:

deployment:
  strategy:
    type: Recreate

For more details, see the Kubernetes documentation.

Using the Community Edition of this chart

By default, the Helm charts use the Enterprise Edition of GitLab. If desired, you can use the Community Edition instead. Learn more about the differences between the two.

In order to use the Community Edition, set image.repository to registry.gitlab.com/gitlab-org/build/cng/gitlab-webservice-ce and workhorse.image to registry.gitlab.com/gitlab-org/build/cng/gitlab-workhorse-ce.

Global Settings

We share some common global settings among our charts. See the Globals Documentation for common configuration options, such as GitLab and Registry hostnames.

Ingress Settings

proxyBodySize

proxyBodySize is used to set the NGINX proxy maximum body size. This is commonly required to allow a larger Docker image than the default. As an alternative option, you can set the body size with either of the following two parameters too:

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

Resources

Unicorn Worker Killer memory settings

Memory thresholds for the unicorn-worker-killer can be customized using the unicorn.memory.min and unicorn.memory.max chart values. While the default values are sane, you can increase (or lower) these values to fine-tune them for your environment or troubleshoot performance issues.

Memory requests/limits

Each pod spawns an amount of workers equal to workerProcesses, who each use some baseline amount of memory. The default memory requests and limits are based on two workers at the measured usage of 750MB /worker, and a maximum usage of about 1G /worker. Thus, if you update workerProcesses, you should update requests.memory and limits.memory (if configured) accordingly. Note though, that as GitLab and usage changes, the required resources will change as well.

Default:

workerProcesses: 2
resources:
  requests:
    memory: 1.5G # = 2 * 750M
# limits:
#   memory: 2G   # = 2 * 1G

With 4 workers configured:

workerProcesses: 4
resources:
  requests:
    memory: 3G   # = 4 * 750M
# limits:
#   memory: 4G   # = 4 * 1G

External Services

Redis

The Redis documentation has been consolidated in the globals page. Please consult this page for the latest Redis configuration options.

PostgreSQL

The PostgreSQL documentation has been consolidated in the globals page. Please consult this page for the latest PostgreSQL configuration options.

Gitaly

Gitaly is configured by global settings. Please see the Gitaly configuration documentation.

MinIO

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

Registry

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

Chart Settings

The following values are used to configure the Webservice Pods.

metrics.enabled

By default, each pod exposes a metrics endpoint at /-/metrics. Metrics are only available when GitLab Prometheus metrics are enabled in the Admin area. When metrics are enabled, annotations are added to each pod allowing a Prometheus server to discover and scrape the exposed metrics.

GitLab Shell

GitLab Shell uses an Auth Token in its communication with Webservice. Share the token with GitLab Shell and Webservice using a shared Secret.

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

WebServer options

Current version of chart supports both Unicorn and Puma web servers. Puma is the default, however you can switch to the Unicorn server by setting webServer: unicorn

Puma unique options: