GitLab Geo configuration
Note: This is the documentation for installations from source. For installations using the Omnibus GitLab packages, follow the Omnibus GitLab Geo nodes configuration guide.
Configuring a new secondary node
Note: This is the final step in setting up a secondary Geo node. Stages of the setup process must be completed in the documented order. Before attempting the steps in this stage, complete all prior stages.
The basic steps of configuring a secondary node are to replicate required configurations between the primary and the secondaries; to configure a tracking database on each secondary; and to start GitLab on the secondary node.
You are encouraged to first read through all the steps before executing them in your testing/production environment.
- Do not setup any custom authentication in the secondary nodes, this will be handled by the primary node.
- Do not add anything in the secondaries Geo nodes admin area (Admin Area ➔ Geo Nodes). This is handled solely by the primary node.
Step 1. Copying the database encryption key
GitLab stores a unique encryption key on disk that is used to encrypt
sensitive data stored in the database. All secondary nodes must have the
exact same value for
db_key_base as defined on the primary node.
SSH into the primary node, and execute the command below to display the current encryption key:
sudo -u git -H bundle exec rake geo:db:show_encryption_key RAILS_ENV=production
Copy the encryption key to bring it to the secondary node in the following steps.
SSH into the secondary, and execute the command below to open the
sudo -u git -H editor config/secrets.yml
Change the value of
db_key_baseto the output from the primary node. Then save and close the file.
Restart GitLab for the changes to take effect:
service gitlab restart
The secondary will start automatically replicating missing data from the primary in a process known as backfill. Meanwhile, the primary node will start to notify changes to the secondary, which will act on those notifications immediately. Make sure the secondary instance is running and accessible.
Step 2. (Optional) Enabling hashed storage
Once restarted, the secondary will automatically start replicating missing data from the primary in a process known as backfill. Meanwhile, the primary node will start to notify the secondary of any changes, so that the secondary can act on those notifications immediately.
Make sure the secondary instance is running and accessible. You can login to the secondary node with the same credentials as used in the primary.
Step 2. (Optional) Enabling hashed storage (from GitLab 10.0)
Step 3. (Optional) Configuring the secondary to trust the primary
You can safely skip this step if your primary uses a CA-issued HTTPS certificate.
If your primary is using a self-signed certificate for HTTPS support, you will
need to add that certificate to the secondary's trust store. Retrieve the
certificate from the primary and follow your distribution's instructions for
adding it to the secondary's trust store. In Debian/Ubuntu, for example, with a
certificate file of
primary.geo.example.com.crt, you would follow these steps:
cp primary.geo.example.com.crt /usr/local/share/ca-certificates
Step 4. Enable Git access over HTTP/HTTPS
GitLab Geo synchronizes repositories over HTTP/HTTPS, and therefore requires this clone
method to be enabled. Navigate to Admin Area ➔ Settings
/admin/application_settings) on the primary node, and set
Enabled Git access protocols to
Both SSH and HTTP(S) or
Step 5. Verify proper functioning of the secondary node
Read Selective replication.
Read the troubleshooting document.