You are browsing a read-only backup copy of Wikitech. The live site can be found at wikitech.wikimedia.org

Difference between revisions of "GitLab/Replica"

From Wikitech-static
Jump to navigation Jump to search
imported>Jelto
 
imported>Jelto
(add information about automated restore)
 
(3 intermediate revisions by the same user not shown)
Line 11: Line 11:


=== Manual sync of replica ===
=== Manual sync of replica ===
to manually sync of production GitLab with the replica the latest backups have to be moved from production GitLab to the replica:<syntaxhighlight lang="bash">
To manually sync of production GitLab with the replica the latest backups have to be moved from production GitLab to the replica. You can either use the existing <code>rsync</code> configuration or cumin. In most cases the most recent backup should bre present under <code>/etc/gitlab/config_backup/latest</code> and <code>/srv/gitlab-backup/latest</code> and you can skip this step.
 
==== Transfer of backup to replica ====
 
 
For rsync, run the following commands on gitlab1001 to sync the latest backup to gitlab2001:<syntaxhighlight lang="bash">
gitlab1001:~# /usr/bin/rsync -avp --delete /etc/gitlab/config_backup/latest/ rsync://gitlab2001.wikimedia.org/config-backup
gitlab1001:~# /usr/bin/rsync -avp --delete /srv/gitlab-backup/latest/ rsync://gitlab2001.wikimedia.org/data-backup
</syntaxhighlight><code>/config-backup</code> and <code>/data-backup</code> are just module names of the <code>rsyncd</code> config. The backups are copied to <code>/etc/gitlab/config_backup/latest</code> and <code>/srv/gitlab-backup/latest</code>.
 
Or use cumin:<syntaxhighlight lang="bash">
cumin1001:~$ sudo SSH_AUTH_SOCK=/run/keyholder/proxy.sock scp -3 gitlab1001.wikimedia.org:/etc/gitlab/config_backup/gitlab_config_1628121602_2021_08_05.tar gitlab2001.wikimedia.org:/etc/gitlab/config_backup/
cumin1001:~$ sudo SSH_AUTH_SOCK=/run/keyholder/proxy.sock scp -3 gitlab1001.wikimedia.org:/etc/gitlab/config_backup/gitlab_config_1628121602_2021_08_05.tar gitlab2001.wikimedia.org:/etc/gitlab/config_backup/
cumin1001:~$ sudo SSH_AUTH_SOCK=/run/keyholder/proxy.sock scp -3 gitlab1001.wikimedia.org:/srv/gitlab-backup/1628121868_2021_08_05_13.12.9_gitlab_backup.tar gitlab2001.wikimedia.org:/srv/gitlab-backup/
cumin1001:~$ sudo SSH_AUTH_SOCK=/run/keyholder/proxy.sock scp -3 gitlab1001.wikimedia.org:/srv/gitlab-backup/1628121868_2021_08_05_13.12.9_gitlab_backup.tar gitlab2001.wikimedia.org:/srv/gitlab-backup/
</syntaxhighlight>When the backup archives are transferred to the replica the [[GitLab/Backup and Restore#Restore|GitLab restore guide]] should be used. The exception here is that we have to keep the <code>gitlab.rb</code> from the replica when restoring the config backup. So make sure to copy the old <code>gitlab.rb</code> before following the guide.<syntaxhighlight lang="bash">
</syntaxhighlight>
 
==== Restore of backup on replica ====
All restore logic for the replica is handled by a [[gerrit:plugins/gitiles/operations/puppet/+/refs/heads/production/modules/gitlab/files/gitlab-restore.sh|custom shell script]] which is present on the replica. So the easiest option to restore is to run the script on the replica: <syntaxhighlight lang="bash">
/srv/gitlab-backup/gitlab-restore.sh
</syntaxhighlight>It is also possible to do the restore manually if needed. The [[GitLab/Backup and Restore#Restore|GitLab restore guide]] should be used. The exception here is that we have to keep the <code>gitlab.rb</code> from the replica when restoring the config backup. '''Before restore,''' make sure to copy the old <code>gitlab.rb</code> before following the guide.<syntaxhighlight lang="bash">
sudo cp /etc/gitlab/gitlab.rb /etc/gitlab/gitlab.rb.bak
sudo cp /etc/gitlab/gitlab.rb /etc/gitlab/gitlab.rb.bak
</syntaxhighlight>When the restore is finished, the settings have to be reapplied to the replica using [https://gitlab.wikimedia.org/releng/gitlab-settings gitlab-settings]:<syntaxhighlight lang="bash">
</syntaxhighlight>'''Before restore,''' make sure the backup can be found by GitLab. So we have to move and rename the backups:<syntaxhighlight lang="bash">
./settings --instance https://gitlab-replica.wikimedia.org update
cp /srv/gitlab-backup/latest/latest.tar /srv/gitlab-backup/latest_gitlab_backup.tar
</syntaxhighlight>'''After the restore''' is finished, the settings have to be reapplied to the replica using [https://gitlab.wikimedia.org/releng/gitlab-settings gitlab-settings]:<syntaxhighlight lang="bash">
./settings --instance https://gitlab-replica.wikimedia.org --settings-file settings-replica.yaml update
</syntaxhighlight>
</syntaxhighlight>


=== Automated sync of replica ===
=== Automated sync of replica ===
Automated sync is not implemented currently. The plan is to restore backups of production GitLab every 24 hours.
Automated sync and restore between the replica and production GitLab is active. For automated sync of the backups a systemd timer with <code>rsync</code> is configured on production GitLab and <code>rsyncd</code> is running on the replica. The job runs every 24h and transfers the most recent data and config backup to the replica.<ref>https://gerrit.wikimedia.org/r/c/operations/puppet/+/710948</ref> The actual restore of the backup on the replica is handled by [[gerrit:plugins/gitiles/operations/puppet/+/refs/heads/production/modules/gitlab/files/gitlab-restore.sh|custom shell script]] and a [[gerrit:plugins/gitiles/operations/puppet/+/refs/heads/production/modules/gitlab/manifests/restore.pp|systemd timer running this script]]. The restore runs every 24 hours.
 
The most recent backup can be found in: <code>/etc/gitlab/config_backup/latest</code> and <code>/srv/gitlab-backup/latest</code>.
 
So make sure to use the timestamp latest when using the <code>gitlab-backup restore BACKUP=latest</code> command and follow the [[GitLab/Backup and Restore#Restore|GitLab restore guide]].


=== Usage ===
=== Usage ===
The usage of gitlab-replica should be mostly internal for testing, troubleshooting and in case of an emergency. Thus login with SSO needs the groups <code>ops</code>, <code>wmf</code> or <code>nda</code>.
The usage of gitlab-replica should be mostly internal for testing, troubleshooting and in case of an emergency. Thus login with SSO needs the groups <code>ops</code>, <code>wmf</code> or <code>nda</code>.

Latest revision as of 09:29, 29 October 2021

gitlab-replica.wikimedia.org is a copy of production GitLab. Currently gitlab2001 is the replica of gitlab1001.

The purpose of the GitLab replica is:

  • to have a almost identical machine with production Gitlab to test changes
  • to verify the installation path developed by S&F for gitlab1001
  • to have a host for failover in case production GitLab breaks (WIP)
  • to have parity with gerrit-replica

The purpose is not to share the load between both GitLab instances.

Manual sync of replica

To manually sync of production GitLab with the replica the latest backups have to be moved from production GitLab to the replica. You can either use the existing rsync configuration or cumin. In most cases the most recent backup should bre present under /etc/gitlab/config_backup/latest and /srv/gitlab-backup/latest and you can skip this step.

Transfer of backup to replica

For rsync, run the following commands on gitlab1001 to sync the latest backup to gitlab2001:

gitlab1001:~# /usr/bin/rsync -avp --delete /etc/gitlab/config_backup/latest/ rsync://gitlab2001.wikimedia.org/config-backup
gitlab1001:~# /usr/bin/rsync -avp --delete /srv/gitlab-backup/latest/ rsync://gitlab2001.wikimedia.org/data-backup

/config-backup and /data-backup are just module names of the rsyncd config. The backups are copied to /etc/gitlab/config_backup/latest and /srv/gitlab-backup/latest. Or use cumin:

cumin1001:~$ sudo SSH_AUTH_SOCK=/run/keyholder/proxy.sock scp -3 gitlab1001.wikimedia.org:/etc/gitlab/config_backup/gitlab_config_1628121602_2021_08_05.tar gitlab2001.wikimedia.org:/etc/gitlab/config_backup/
cumin1001:~$ sudo SSH_AUTH_SOCK=/run/keyholder/proxy.sock scp -3 gitlab1001.wikimedia.org:/srv/gitlab-backup/1628121868_2021_08_05_13.12.9_gitlab_backup.tar gitlab2001.wikimedia.org:/srv/gitlab-backup/

Restore of backup on replica

All restore logic for the replica is handled by a custom shell script which is present on the replica. So the easiest option to restore is to run the script on the replica:

/srv/gitlab-backup/gitlab-restore.sh

It is also possible to do the restore manually if needed. The GitLab restore guide should be used. The exception here is that we have to keep the gitlab.rb from the replica when restoring the config backup. Before restore, make sure to copy the old gitlab.rb before following the guide.

sudo cp /etc/gitlab/gitlab.rb /etc/gitlab/gitlab.rb.bak

Before restore, make sure the backup can be found by GitLab. So we have to move and rename the backups:

cp /srv/gitlab-backup/latest/latest.tar /srv/gitlab-backup/latest_gitlab_backup.tar

After the restore is finished, the settings have to be reapplied to the replica using gitlab-settings:

./settings --instance https://gitlab-replica.wikimedia.org --settings-file settings-replica.yaml update

Automated sync of replica

Automated sync and restore between the replica and production GitLab is active. For automated sync of the backups a systemd timer with rsync is configured on production GitLab and rsyncd is running on the replica. The job runs every 24h and transfers the most recent data and config backup to the replica.[1] The actual restore of the backup on the replica is handled by custom shell script and a systemd timer running this script. The restore runs every 24 hours.

The most recent backup can be found in: /etc/gitlab/config_backup/latest and /srv/gitlab-backup/latest.

So make sure to use the timestamp latest when using the gitlab-backup restore BACKUP=latest command and follow the GitLab restore guide.

Usage

The usage of gitlab-replica should be mostly internal for testing, troubleshooting and in case of an emergency. Thus login with SSO needs the groups ops, wmf or nda.