DevOps-GitLab

Configure the GitLab chart with an external database | GitLab

Configure the GitLab chart with an external database

For a production-ready GitLab chart deployment, use an external database.

Prerequisites:

A deployment of PostgreSQL 12 or later. If you do not have one, consider
a cloud provided solution like AWS RDS PostgreSQL
or GCP Cloud SQL. For a self-managed solution,
consider the Omnibus GitLab package.
An empty database named gitlabhq_production by default.
A user with full database access. See the
external database documentation for details.
A Kubernetes Secret with the password for the database user.
The pg_trgm and btree_gist extensions. If you don’t provide an account with
the Superuser flag to GitLab, ensure these extensions are loaded prior to
proceeding with the database installation.

Networking prerequisites:

Ensure that the database is reachable from the cluster. Be sure that your firewall policies allow traffic.
If you plan to use PostgreSQL as a load balancing cluster and Kubernetes
DNS for service discovery, when you install the bitnami/postgresql chart,
use --set slave.service.clusterIP=None .
This setting configures the PostgreSQL secondary service as a headless service to
allow DNS A records to be created for each secondary instance.

For an example of how to use Kubernetes DNS for service discovery,
see examples/database/values-loadbalancing-discover.yaml .

To configure the GitLab chart to use an external database:

Set the following parameters:
- postgresql.install : Set to false to disable the embedded database.
- global.psql.host : Set to the hostname of the external database, can be a domain or an IP address.
- global.psql.password.secret : The name of the secret that contains the database password for the gitlab user.
- global.psql.password.key : Within the secret, the key that contains the password.
Optional. The following items can be further customized if you are not using the defaults:
- global.psql.port : The port the database is available on. Defaults to 5432 .
- global.psql.database : The name of the database.
- global.psql.username : The user with access to the database.
Optional. If you use a mutual TLS connection to the database, set the following:
- global.psql.ssl.secret : A secret that contains the client certificate, key, and certificate authority.
- global.psql.ssl.serverCA : In the secret, the key that refers to the certificate authority (CA).
- global.psql.ssl.clientCertificate : In the secret, the key that refers to the client certificate.
- global.psql.ssl.clientKey : In the secret, the client.

When you deploy the GitLab chart, add the values by using the --set flag. For example:

        helm install gitlab gitlab/gitlab
  --set postgresql.install=false
  --set global.psql.host=psql.example
  --set global.psql.password.secret=gitlab-postgresql-password
  --set global.psql.password.key=postgres-password

       

Configure MinIO with the GitLab chart | GitLab

Configure MinIO with the GitLab chart

MinIO is an object storage server that exposes S3-compatible APIs.

MinIO can be deployed to several different platforms. To launch a new MinIO instance,
follow their Quickstart Guide.
Be sure to secure access to the MinIO server with TLS.

To connect GitLab to an external MinIO instance,
first create MinIO buckets for the GitLab application, using the bucket names
in this example configuration file.

Using the MinIO client, create the necessary buckets before use:

      mc mb gitlab-registry-storage
mc mb gitlab-lfs-storage
mc mb gitlab-artifacts-storage
mc mb gitlab-uploads-storage
mc mb gitlab-packages-storage
mc mb gitlab-backup-storage

     

Once the buckets have been created, GitLab can be configured to use the MinIO instance.
See example configuration in rails.minio.yaml and
registry.minio.yaml
in the examples folder.

Read article

Setup standalone Gitaly | GitLab

Create VM with Omnibus GitLab
Configure Omnibus GitLab

Setup standalone Gitaly

The instructions here make use of the Omnibus GitLab package for Ubuntu.
This package provides versions of the services that are guaranteed to be compatible with the charts’ services.

Create VM with Omnibus GitLab

Create a VM on your provider of choice, or locally. This was tested with VirtualBox, KVM, and Bhyve.
Ensure that the instance is reachable from the cluster.

Install Ubuntu Server onto the VM that you have created. Ensure that openssh-server is installed, and that all packages are up to date.
Configure networking and a hostname. Make note of the hostname/IP, and ensure it is both resolvable and reachable from your Kubernetes cluster.
Be sure firewall policies are in place to allow traffic.

Follow the installation instructions for Omnibus GitLab. When you perform the package installation, do not provide the EXTERNAL_URL= value. We do not want automatic configuration to occur, as we’ll provide a very specific configuration in the next step.

Configure Omnibus GitLab

Create a minimal gitlab.rb file to be placed at /etc/gitlab/gitlab.rb . Be
very explicit about what’s enabled on this node, using the following contents
based on the documentation for
running Gitaly on its own server.

NOTE : The values below should be replaced

AUTH_TOKEN should be replaced with the value in the gitaly-secret secret
GITLAB_URL should be replaced with the URL of the GitLab instance
SHELL_TOKEN should be replaced with the value in the gitlab-shell-secret secret

      # Avoid running unnecessary services on the Gitaly server
postgresql['enable'] = false
redis['enable'] = false
nginx['enable'] = false
puma['enable'] = false
sidekiq['enable'] = false
gitlab_workhorse['enable'] = false
grafana['enable'] = false
gitlab_exporter['enable'] = false
gitlab_kas['enable'] = false

# If you run a seperate monitoring node you can disable these services
prometheus['enable'] = false
alertmanager['enable'] = false

# If you don't run a seperate monitoring node you can
# Enable Prometheus access & disable these extra services
# This makes Prometheus listen on all interfaces. You must use firewalls to restrict access to this address/port.
# prometheus['listen_address'] = '0.0.0.0:9090'
# prometheus['monitor_kubernetes'] = false

# If you don't want to run monitoring services uncomment the following (not recommended)
# node_exporter['enable'] = false

# Prevent database connections during 'gitlab-ctl reconfigure'
gitlab_rails['auto_migrate'] = false

# Configure the gitlab-shell API callback URL. Without this, `git push` will
# fail. This can be your 'front door' GitLab URL or an internal load
# balancer.
gitlab_rails['internal_api_url'] = 'GITLAB_URL'
gitlab_shell['secret_token'] = 'SHELL_TOKEN'

# Make Gitaly accept connections on all network interfaces. You must use
# firewalls to restrict access to this address/port.
# Comment out following line if you only want to support TLS connections
gitaly['listen_addr'] = "0.0.0.0:8075"

# Authentication token to ensure only authorized servers can communicate with
# Gitaly server
gitaly['auth_token'] = 'AUTH_TOKEN'

git_data_dirs({
 'default' => {
   'path' => '/var/opt/gitlab/git-data'
 },
 'storage1' => {
   'path' => '/mnt/gitlab/git-data'
 },
})

# To use TLS for Gitaly you need to add
gitaly['tls_listen_addr'] = "0.0.0.0:8076"
gitaly['certificate_path'] = "path/to/cert.pem"
gitaly['key_path'] = "path/to/key.pem"

     

After creating gitlab.rb , reconfigure the package with gitlab-ctl reconfigure .
Once the task has completed, check the running processes with gitlab-ctl status .
The output should appear as such:

      # gitlab-ctl status
run: gitaly: (pid 30562) 77637s; run: log: (pid 30561) 77637s
run: logrotate: (pid 4856) 1859s; run: log: (pid 31262) 77460s

     

Read article

Configure the GitLab chart with an external Gitaly | GitLab

Configure the chart
Multiple external Gitaly
- Connecting to external Gitaly over TLS

Configure the GitLab chart with an external Gitaly

This document intends to provide documentation on how to configure this Helm chart with an external Gitaly service.

If you don’t have Gitaly configured, for on-premise or deployment to VM,
consider using our Omnibus GitLab package.

External Gitaly services can be provided by Gitaly nodes, or
Praefect clusters.

Configure the chart

Disable the gitaly chart and the Gitaly service it provides, and point the other services to the external service.

You need to set the following properties:

global.gitaly.enabled : Set to false to disable the included Gitaly chart.
global.gitaly.external : This is an array of external Gitaly service(s).
global.gitaly.authToken.secret : The name of the secret which contains the token for authentication.
global.gitaly.authToken.key : The key within the secret, which contains the token content.

The external Gitaly services will make use of their own instances of GitLab Shell.
Depending your implementation, you can configure those with the secrets from this
chart, or you can configure this chart’s secrets with the content from a predefined
source.

You may need to set the following properties:

global.shell.authToken.secret : The name of the secret which contains secret for GitLab Shell.
global.shell.authToken.key : The key within the secret, which contains the secret content.

A complete example configuration, with two external services ( external-gitaly.yml ):

      global:
  gitaly:
    enabled: false
    external:
      - name: default                   # required
        hostname: node1.git.example.com # required
        port: 8075                      # optional, default shown
      - name: praefect                  # required
        hostname: ha.git.example.com    # required
        port: 2305                      # Praefect uses port 2305
        tlsEnabled: false               # optional, overrides gitaly.tls.enabled
    authToken:
      secret: external-gitaly-token     # required
      key: token                        # optional, default shown
    tls:
      enabled: false                    # optional, default shown

     

Example installation using the above configuration file in conjunction other
configuration via gitlab.yml :

      helm upgrade --install gitlab gitlab/gitlab  \
  -f gitlab.yml \
  -f external-gitaly.yml

     

Multiple external Gitaly

If your implementation uses multiple Gitaly nodes external to these charts,
you can define multiple hosts as well. The syntax is slightly different, as
to allow the complexity required.

An example values file is provided, which shows the
appropriate set of configuration. The content of this values file is not
interpreted correctly via --set arguments, so should be passed to Helm
with the -f / --values flag.

Connecting to external Gitaly over TLS

If your external Gitaly server listens over TLS port,
you can make your GitLab instance communicate with it over TLS. To do this, you
have to

Create a Kubernetes secret containing the certificate of the Gitaly
server

        kubectl create secret generic gitlab-gitaly-tls-certificate --from-file=gitaly-tls.crt=<path to certificate>

       

Add the certificate of external Gitaly server to the list of
custom Certificate Authorities
In the values file, specify the following
```
global:
  certificates:
    customCAs:
      - secret: gitlab-gitaly-tls-certificate
```
or pass it to the helm upgrade command using --set
```
--set global.certificates.customCAs[0].secret=gitlab-gitaly-tls-certificate
```

To enable TLS for all Gitaly instances, set global.gitaly.tls.enabled: true .

        global:
  gitaly:
    tls:
      enabled: true

       

To enable for instances individually, set tlsEnabled: true for that entry.

        global:
  gitaly:
    external:
      - name: default
        hostname: node1.git.example.com
        tlsEnabled: true

       

You can choose any valid secret name and key for this, but make
sure the key is unique across all the secrets specified in


          customCAs

to avoid
collision since all keys within the secrets will be mounted. You do not
need to provide the key for the certificate, as this is the client side .

Read article

Configure the GitLab chart with external GitLab Pages | GitLab

Requirements
Known limitations
Configure external GitLab Pages instance
Configure the chart

Configure the GitLab chart with external GitLab Pages

This document intends to provide documentation on how to configure this Helm
chart with a GitLab Pages instance, configured outside of the cluster, using an
Omnibus GitLab package.

Requirements

GitLab 13.7 or later.
External Object Storage, as
recommended for production instances, should be used.
Base64 encoded form of a 32-bytes-long API secret key for Pages to interact
with GitLab Pages.

Known limitations

GitLab Pages Access Control
is not supported out of the box.

Configure external GitLab Pages instance

Install GitLab using the Omnibus GitLab
package.

Edit /etc/gitlab/gitlab.rb file and replace its contents with the
following snippet. Update the values below to match your configuration:

        roles ['pages_role']

# Root domain where Pages will be served.
pages_external_url '<Pages root domain>'  # Example: 'http://pages.example.io'

# Information regarding GitLab instance
gitlab_pages['gitlab_server'] = '<GitLab URL>'  # Example: 'https://gitlab.example.com'
gitlab_pages['api_secret_key'] = '<Base64 encoded form of API secret key>'

       

Apply the changes by running sudo gitlab-ctl reconfigure .

Configure the chart

Create a bucket named gitlab-pages in the object storage for storing Pages
deployments.

Create a secret gitlab-pages-api-key with the Base64 encoded form of API
secret key as value.

        kubectl create secret generic gitlab-pages-api-key --from-literal="shared_secret=<Base 64 encoded API Secret Key>"

       

Refer the following configuration snippet and add necessary entries to your
values file.

        global:
  pages:
    path: '/srv/gitlab/shared/pages'
    host: <Pages root domain>
    port: '80'  # Set to 443 if Pages is served over HTTPS
    https: false  # Set to true if Pages is served over HTTPS
    artifactsServer: true
    objectStore:
      enabled: true
      bucket: 'gitlab-pages'
    apiSecret:
      secret: gitlab-pages-api-key
      key: shared_secret
  extraEnv:
    PAGES_UPDATE_LEGACY_STORAGE: true  # Bypass automatic disabling of disk storage

       

By setting


            PAGES_UPDATE_LEGACY_STORAGE

environment variable to true,
the feature flag


            pages_update_legacy_storage

is enabled which deploys Pages
to local disk. When you migrate to object storage, do remember to remove this
variable.

Deploy the chart
using this configuration.

Read article

Configure the GitLab chart with Mattermost Team Edition | GitLab

Prerequisites
Deploy the Mattermost Team Edition Helm chart
Deploy GitLab Helm chart
Create an OAuth application with GitLab
Troubleshooting

Configure the GitLab chart with Mattermost Team Edition

This document describes how to install Mattermost Team Edition Helm chart in proximity with an existing GitLab Helm chart deployment.

As the Mattermost Helm chart is installed in a separate namespace, it is recommended that
cert-manager and nginx-ingress be configured to manage cluster-wide Ingress and certificate resources. For additional configuration information,
refer to the Mattermost Helm configuration guide.

Prerequisites

A running Kubernetes cluster.
Helm v3

For the Team Edition you can have just one replica running.

Deploy the Mattermost Team Edition Helm chart

Once you have installed the Mattermost Team Edition Helm chart, you can deploy it using the following command:

      helm repo add mattermost https://helm.mattermost.com
helm repo update
helm upgrade --install mattermost -f values.yaml mattermost/mattermost-team-edition

     

Wait for the pods to run. Then, using the Ingress host you specified in the configuration, access your Mattermost server.

For additional configuration information, refer to the Mattermost Helm configuration guide.
you experience any issues with this, please view the Mattermost Helm chart issue repository or
the Mattermost Forum.

Deploy GitLab Helm chart

To deploy the GitLab Helm chart, follow the instructions described here.

Here’s a light way to install it:

      helm repo add gitlab https://charts.gitlab.io/
helm repo update
helm upgrade --install gitlab gitlab/gitlab \
  --timeout 600s \
  --set global.hosts.domain=<your-domain> \
  --set global.hosts.externalIP=<external-ip> \
  --set certmanager-issuer.email=<email>

     

<your-domain> : your desired domain, such as gitlab.example.com .
<external-ip> : the external IP pointing to your Kubernetes cluster.
<email> : email to register in Let’s Encrypt to retrieve TLS certificates.

Once you’ve deployed the GitLab instance, follow the instructions for the initial login.

Create an OAuth application with GitLab

The next part of the process is setting up the GitLab SSO integration.
To do so, you need to create the OAuth application to allow Mattermost to use GitLab as the authentication provider.

Only the default GitLab SSO is officially supported. “Double SSO”, where GitLab SSO is chained to other SSO solutions, is not supported. It may be possible to connect
GitLab SSO with AD, LDAP, SAML, or MFA add-ons in some cases, but because of the special logic required they’re not officially
supported and are known not to work on some experiences.

Troubleshooting

If you are following a process other than the one provided and experience authentication and/or deployment issues,
let us know in the Mattermost troubleshooting forum.

Read article

Welcome to Knowledge Base!

KB at your finger tips

DevOps-GitLab