Advanced configuration

The Deckhouse Code chart is built on the GitLab Helm chart. Values that this page does not list keep the names and the meaning of the upstream chart. The tables below list the values the chart adds under global.codeHelm, the additions under global.psql and global.appConfig, and the upstream defaults the chart changes. The Default column shows the value the chart ships with; — means the value is empty until you set it.

Components the cluster provides

The chart deploys the application and, when registry.enabled is true, the container registry. The cluster provides the components below before the release is installed; the chart does not deploy them:

• an ingress controller, addressed by global.ingress.class and, when the load balancer is enabled, by global.codeHelm.loadbalancer.ingressService;
• cert-manager with a ClusterIssuer, used by global.codeHelm.ingress.tls and global.codeHelm.tls.internal;
• PostgreSQL, Redis and an S3-compatible object storage, addressed by global.psql, global.redis and global.appConfig.object_store;
• Prometheus Operator and Grafana, when the objects from Monitoring are used;
• GitLab Runner.

The upstream subcharts gitlab-runner, prometheus, certmanager, nginx-ingress, nginx-ingress-geo, haproxy, traefik, kubernetes-ingress, gitlab-zoekt and redis-ha are not part of the chart. Setting their install or enabled key to true, or installCertmanager to true, fails the install.

Secrets created from values

global.codeHelm.externalSecrets creates the Secrets with the credentials of the external services from the values file, in place of Secrets created by hand before the install. Each Secret is named after the release, so several releases can share a namespace.

When registry.enabled is true, the container registry needs a storage Secret from either the registry.storage.s3 block below or registry.storage.secret; when both are absent, the install fails.

Backup storage

global.codeHelm.backup holds the address of the storage that receives backup archives. It is used together with the credentials from global.codeHelm.externalSecrets.backup to build the Secret <release>-s3cfg.

Ingress TLS

global.codeHelm.ingress.tls selects where the certificates of the Ingress objects come from.

In the manual mode, create the Secrets yourself, or add cert-manager.io/cluster-issuer: <ISSUER> to global.ingress.annotations, where <ISSUER> is the name of a cert-manager ClusterIssuer. Every Ingress of the chart carries these annotations, and cert-manager issues each certificate into the Secret its Ingress names.

Load balancer

global.codeHelm.loadbalancer deploys an HAProxy Deployment with a Service of type LoadBalancer, named <release>-code-loadbalancer. The Service accepts ports 80, 443 and 22: HTTP and HTTPS are forwarded to the ingress controller, SSH to the Git shell Service inside the cluster. This gives the instance one external address for Git over HTTPS and SSH.

Internal TLS

global.codeHelm.tls.internal encrypts the traffic between the components of the release with certificates from cert-manager: the chart creates a self-signed Issuer, an internal CA and a Certificate for the web service, Workhorse, Praefect and each Gitaly virtual storage. The Secrets are named <release>-webservice-tls, <release>-workhorse-tls, <release>-praefect-tls and the Gitaly Secret of each virtual storage.

Istio

global.codeHelm.istio puts the release into an Istio service mesh: the pods receive the sidecar injection label, and a PeerAuthentication object sets the mTLS mode of the namespace. The mesh replaces the internal TLS, so global.codeHelm.tls.internal.enabled, global.gitaly.tls.enabled, global.praefect.tls.enabled, global.workhorse.tls.enabled, gitlab.webservice.tls.enabled and, when the registry is enabled, registry.tls.enabled must be false; otherwise the install fails.

Metrics through kube-rbac-proxy

global.codeHelm.kubeRbacProxy adds a kube-rbac-proxy sidecar to the web service, Sidekiq, Gitaly, Git shell, Pages, Praefect, exporter, registry and load balancer pods. The sidecar serves the metrics of its pod on the port https-metrics and lets a request through only after a TokenReview and a SubjectAccessReview of its bearer token. The chart creates a Service <release>-<component>-metrics and a ServiceMonitor <release>-<component> per component, the Secret <release>-prometheus-token the ServiceMonitors take the token from, and the RBAC objects the sidecars need for the reviews.

Audit events

global.codeHelm.audit adds an audit sidecar to the web service and Sidekiq pods. The sidecar reads the audit log of its pod and writes each event to its standard output in the CEF format, so the logging stack of the cluster collects the events from the container logs. To read them directly:

d8 k -n code logs <POD_NAME> -c audit

Audit events describes the events themselves.

Monitoring

global.codeHelm.monitoring creates the objects that Prometheus Operator and Grafana pick up.

Advanced search

global.codeHelm.search connects the instance to an OpenSearch cluster for code and content search. Advanced search describes indexing and the search itself.

To run the indexing jobs in pods of their own, add a Sidekiq pod for the queue:

gitlab:
  sidekiq:
    pods:
      - name: all-in-1
      - name: global-search
        queues: global-search-indexing

Container images

Every workload image is pinned in the chart at build time. global.codeHelm.images replaces the pinned image of a component, for example when the images are mirrored to a registry inside the network.

PostgreSQL connection encryption

global.psql.sslMode and global.psql.ssl set how the application connects to PostgreSQL. global.praefect.psql.sslMode does the same for the Praefect database and also defaults to prefer.

Authentication providers

The chart accepts the upstream fields of an entry in global.appConfig.omniauth.providers (name, label, icon, secret, key, args) and the group fields below. When an entry names a secret, the provider is read from that Secret and the group fields go into its YAML. SAML shows the complete provider entries.

An LDAP server in global.appConfig.ldap.servers.<name> accepts the upstream fields (host, port, uid, base, bind_dn, password, active_directory and the others) and a group_sync block that maps LDAP groups to groups of the instance. LDAP describes the synchronization.

Changed upstream defaults

The chart ships the upstream values below with other defaults. Each row names what the change requires from the cluster or the values file.

Additional resources

• Quick start
• Configuration