Skip to content

Updating your solution

This section describes all the possible ways you may need to update your solution.

General best-practice for updating

For a consistent and healthy deployment, we strongly discourage combining GitLab version updates with GET updates, unless strictly required.

For a GitLab version bump, we have seperate playbooks to speed up the Ansible runs and prevent any other possible bugs being introduced. This way, any issues can be traced back to the GitLab update more easily.

Zero downtime

We have 'zero downtime' variants of our update playbooks. These playbooks are 'zero downtime' because they attempt to de-register the node that is being updated from the loadbalancers before performing the update. This ensures end-users are not attempting to connect to a node that is being updated. The node will be re-registered with the loadbalancer afterwards.

Running zero downtime variants of playbooks is significantly slower than the normal variants, not because the zero downtime playbooks are slow as such, but because the normal variants update all nodes at once, causing a total systems outage for a few minutes.

If you are using Zero Downtime, do not update multiple minor GitLab versions! This is not supported by upstream because there are no database migrations for this usecase.

The rate of updates can be controlled with the Ansible variable called serial. This value is passed to the Ansible option with the same name, which you can read more about from upstream.

Renovatebot

For supported usecases, our Renovatebot can submit Merge Requests to your project in GitLab to automatically propose a version update when upstream versions have changed. This bot will make the file edits that are explained below. You will still need to run the Terraform and Ansible commands to actually perform the updates.

GitLab updates

Updating GitLab will be a regular occurence. Therefore, the steps required to update GitLab are small:

First, set the new version of GitLab in ansible/inventory/vars.yml:

all:
  vars:
    gitlab_version: "17.5.2"  # No need to append -ee.0

Next, simply run one of the GitLab update playbooks:

source .venv/bin/activate
cd ansible
eval $(op signin)  # Unlock 1Password if not done already

# Choose one:

# Zero downtime
aws-sso ansible-playbook -i inventory glh.environment_toolkit.zero_downtime_gitlab_update

# Quick updates with downtime
aws-sso ansible-playbook -i inventory glh.environment_toolkit.gitlab_update

GET updates

From time to time, you will need to upgrade the entire stack instead of just GitLab itself. This also requires you to update the Terraform stack.

Start by reading the relevant section of our Changelog, and following the upgrade instructions.

Then, bump the Terraform module version:

module "gitlab_cluster" {
  source = "git.glhd.nl/glh/gitlab-environment-toolkit/aws"
  version = "2.1.7"

  # ...
}

To perform Terraform actions to propagate the changes, run the following commands:

cd terraform
aws-sso terraform init -upgrade
aws-sso terraform apply

Next, you must update the Ansible stack as well. In ansible/galaxy-requirements.yml and ansible/requirements.txt, bump the version selectors to the new version of GET. Then update the Ansible dependencies:

source .venv/bin/activate
cd ansible
pip install -U -r requirements.txt
ansible-galaxy install -r galaxy-requirements.yml

Then choose from either update playbook below:

# Zero downtime
aws-sso ansible-playbook -i inventory glh.environment_toolkit.zero_downtime_all

# Faster update with significant downtime
aws-sso ansible-playbook -i inventory glh.environment_toolkit.all