Setting up Geo
Prerequisites
- Two (or more) independently working GitLab sites:
- One GitLab site serves as the Geo primary site. Use the GitLab reference architectures documentation to set this up. You can use different reference architecture sizes for each Geo site. If you already have a working GitLab instance that is in-use, it can be used as a primary site.
- The second GitLab site serves as the Geo secondary site. Use the GitLab reference architectures documentation to set this up. It’s a good idea to sign in and test it. However, be aware that all of the data on the secondary are lost as part of the process of replicating from the primary site.
Geo supports multiple secondaries. You can follow the same steps and make any changes accordingly. - Ensure the primary site has a GitLab Premium or Ultimate subscription to unlock Geo. You only need one license for all the sites.
- Confirm the requirements for running Geo are met by all sites. For example, sites must use the same GitLab version, and sites must be able to communicate with each other over certain ports.
Using Omnibus GitLab
If you installed GitLab using the Omnibus packages (highly recommended):
-
Set up the database replication (
primary (read-write) <-> secondary (read-only)
topology). - Configure GitLab to set the primary and secondary sites.
- Optional: Configure Object storage
- Optional: Configure a secondary LDAP server for the secondary sites. See notes on LDAP.
- Optional: Configure Geo secondary proxying to use a single, unified URL for all Geo sites. This step is recommended to accelerate most read requests while transparently proxying writes to the primary Geo site.
- Follow the Using a Geo Site guide.
Using GitLab Charts
Configure the GitLab chart with GitLab Geo.
Post-installation documentation
After installing GitLab on the secondary sites and performing the initial configuration, see the following documentation for post-installation information.