Location-aware public URL (PREMIUM SELF)

With Geo proxying for secondary sites, you can provide GitLab users with a single URL that automatically uses the Geo site closest to them. Users don't need to use different URLs or worry about read-only operations to take advantage of closer Geo sites as they move.

With Geo proxying for secondary sites web and Git requests are proxied from secondary sites to the primary.

Prerequisites

This example creates a gitlab.example.com subdomain that automatically directs requests:

• From Europe to a secondary site.
• From all other locations to the primary site.

The URLs to access each node by itself are:

• primary.example.com as a Geo primary site.
• secondary.example.com as a Geo secondary site.

For this example, you need:

• A working GitLab primary site that is accessible at gitlab.example.com and primary.example.com.
• A working GitLab secondary site.
• A DNS zone managing your domain. Although the following instructions use AWS Route53 and GCP cloud DNS, other services such as Cloudflare can be used as well.

If you haven't yet set up a Geo primary site and secondary site, see the Geo setup instructions.

AWS Route53

In this example, you use a Route53 Hosted Zone managing your domain for the Route53 setup.

In a Route53 Hosted Zone, traffic policies can be used to set up a variety of routing configurations. To create a traffic policy:

1. Go to the Route53 dashboard and select Traffic policies.

2. Select Create traffic policy.

3. Fill in the Policy Name field with Single Git Host and select Next.

4. Leave DNS type as A: IP Address in IPv4 format.

5. Select Connect to..., then Geolocation rule.

6. For the first Location:

   1. Leave it as Default.
   2. Select Connect to..., then New endpoint.
   3. Choose Type value and fill it in with <your **primary** IP address>.

7. For the second Location:

   1. Choose Europe.
   2. Select Connect to... and select New endpoint.
   3. Choose Type value and fill it in with <your **secondary** IP address>.

   

8. Select Create traffic policy.

9. Fill in Policy record DNS name with gitlab.

   

10. Select Create policy records.

You have successfully set up a single host, like gitlab.example.com, which distributes traffic to your Geo sites by geolocation.

GCP

In this example, you create a GCP Cloud DNS zone managing your domain.

When creating Geo-Based record sets, GCP applies a nearest match for the source region when the source of the traffic doesn't match any policy items exactly. To create a Geo-Based record set:

1. Select Network Services > Cloud DNS.
2. Select the Zone configured for your domain.
3. Select Add Record Set.
4. Enter the DNS Name for your Location-aware public URL e.g. gitlab.example.com.
5. Select the Routing Policy: Geo-Based.
6. Select Add Managed RRData.
   1. Select Source Region: us-central1.
   2. Enter your <**primary** IP address>.
   3. Select Done.
7. Select Add Managed RRData.
   1. Select Source Region: europe-west1.
   2. Enter your <**secondary** IP address>.
   3. Select Done.
8. Select Create.

You have successfully set up a single host, like gitlab.example.com, which distributes traffic to your Geo sites using a location-aware URL.

Enable Geo proxying for secondary sites

After setting up a single URL to use for all Geo sites, continue with the steps to enable Geo proxying for secondary sites.