GitLab/Test Instance

From Wikitech

A production-like test instance can be used to test changes, updates and prototype code. The WMCS/VPS instance uses mostly identical Puppet configuration and is accessible using wmcloud SSO for users with wmf/nda permissions. The instance can be reached at

The test instance does not share data (user, repos, groups) with the production instance. So if you need them for testing, you have to migrate this data or request certain groups.

Resetting test instance

Snapshot and restore is not supported in WMCS currently. If changes modify the test instance significantly, we advice to create an additional, temporary instance (see below). Minor changes can be tested by creating backups of certain config files, undo changes or disable puppet temporarily. However the test instance gitlab-prod-1002 must not differ from the actual puppet configuration.

Setup new test instances

If changes modify the test instance significantly, we advice to create an additional, temporary test instance in the WMCS/VPS project devtools. Follow steps below to create a additional instance:

  • Create VM in WMCS project devtools, flavor g3.cores2.ram4.disk20, image debian-11.0-bullseye
  • Create additional volume (~50gb) and assign it to VM (or re-map a existing volume from a old instance)
  • Edit /etc/fstab and mount the volume at /srv/gitlab-backup
  • Create floating IP (quota increase may needed)
  • Create DNS A record <service-name> for floating IP in zone
  • Request floating IP to be mapped to a second, private IP/port (assistance from WMCS is needed here)
  • Edit /etc/interfaces to make VM listen to both private addresses (similar to gitlab-prod-1001)
  • Set at least the following hieradata for the host:
    profile::gitlab::passive_host: '<service-name>'
    profile::gitlab::cert_path: '/etc/letsencrypt/live/<service-name>'
    profile::gitlab::key_path: '/etc/letsencrypt/live/<service-name>'
    profile::gitlab::service_ip_v4: '<second-private-ip>'
    profile::gitlab::service_name: '<service-name>'
  • Assign puppet role::gitlab to new instance
  • Wait for puppet run/force puppet run on new instance
  • Run initial cerbot command (see todo below, will be added to puppet):
    certbot certonly --standalone --preferred-challenges http -d <service-name>
  • Verify installation by login to the instance by using the new DNS entry. Login should be able using SSO (wmcloud idp has wildcard for
  • Optionally:

Open todos

  • move initial certbot command to puppet/verify if this is needed
  • simplify hiera data so that hostname has to be set only once
  • automate configuration for /etc/interfaces in puppet
  • verify steps above