2020-06-23 00:09:42 +05:30
---
2022-07-23 23:45:48 +05:30
stage: Systems
2020-06-23 00:09:42 +05:30
group: Geo
2022-11-25 23:54:43 +05:30
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
2020-06-23 00:09:42 +05:30
type: howto
---
2021-03-11 19:13:27 +05:30
# Location-aware Git remote URL with AWS Route53 **(PREMIUM SELF)**
2019-12-21 20:55:43 +05:30
2022-04-04 11:22:00 +05:30
NOTE:
Since GitLab 14.6,
[GitLab Geo supports a location-aware URL including web UI and API traffic. ](../secondary_proxy/location_aware_external_url.md )
This configuration is recommended over the location-aware Git remote URL
described in this document.
2019-12-21 20:55:43 +05:30
You can provide GitLab users with a single remote URL that automatically uses
2021-06-08 01:23:25 +05:30
the Geo site closest to them. This means users don't need to update their Git
configuration to take advantage of closer Geo sites as they move.
2019-12-21 20:55:43 +05:30
This is possible because, Git push requests can be automatically redirected
2021-06-08 01:23:25 +05:30
(HTTP) or proxied (SSH) from **secondary** sites to the **primary** site.
2019-12-21 20:55:43 +05:30
Though these instructions use [AWS Route53 ](https://aws.amazon.com/route53/ ),
other services such as [Cloudflare ](https://www.cloudflare.com/ ) could be used
as well.
## Prerequisites
In this example, we have already set up:
2021-06-08 01:23:25 +05:30
- `primary.example.com` as a Geo **primary** site.
- `secondary.example.com` as a Geo **secondary** site.
2019-12-21 20:55:43 +05:30
2023-01-13 00:05:48 +05:30
We create a `git.example.com` subdomain that automatically directs
2019-12-21 20:55:43 +05:30
requests:
2021-06-08 01:23:25 +05:30
- From Europe to the **secondary** site.
- From all other locations to the **primary** site.
2019-12-21 20:55:43 +05:30
In any case, you require:
2021-06-08 01:23:25 +05:30
- A working GitLab **primary** site that is accessible at its own address.
- A working GitLab **secondary** site.
2019-12-21 20:55:43 +05:30
- A Route53 Hosted Zone managing your domain.
2021-06-08 01:23:25 +05:30
If you haven't yet set up a Geo _primary_ site and _secondary_ site, see the
2021-01-29 00:20:46 +05:30
[Geo setup instructions ](../index.md#setup-instructions ).
2019-12-21 20:55:43 +05:30
## Create a traffic policy
In a Route53 Hosted Zone, traffic policies can be used to set up a variety of
routing configurations.
2021-04-17 20:07:23 +05:30
1. Go to the
[Route53 dashboard ](https://console.aws.amazon.com/route53/home ) and select
2019-12-21 20:55:43 +05:30
**Traffic policies**.
![Traffic policies ](img/single_git_traffic_policies.png )
2023-03-17 16:20:25 +05:30
1. Select **Create traffic policy** .
2019-12-21 20:55:43 +05:30
![Name policy ](img/single_git_name_policy.png )
2022-07-23 23:45:48 +05:30
1. Fill in the **Policy Name** field with `Single Git Host` and select **Next** .
2019-12-21 20:55:43 +05:30
![Policy diagram ](img/single_git_policy_diagram.png )
1. Leave **DNS type** as `A: IP Address in IPv4 format` .
2022-07-23 23:45:48 +05:30
1. Select **Connect to...** and select **Geolocation rule** .
2019-12-21 20:55:43 +05:30
![Add geolocation rule ](img/single_git_add_geolocation_rule.png )
1. For the first **Location** , leave it as `Default` .
2022-07-23 23:45:48 +05:30
1. Select **Connect to...** and select **New endpoint** .
2019-12-21 20:55:43 +05:30
1. Choose **Type** `value` and fill it in with `<your **primary** IP address>` .
1. For the second **Location** , choose `Europe` .
2022-07-23 23:45:48 +05:30
1. Select **Connect to...** and select **New endpoint** .
2019-12-21 20:55:43 +05:30
1. Choose **Type** `value` and fill it in with `<your **secondary** IP address>` .
![Add traffic policy endpoints ](img/single_git_add_traffic_policy_endpoints.png )
2022-07-23 23:45:48 +05:30
1. Select **Create traffic policy** .
2019-12-21 20:55:43 +05:30
![Create policy records with traffic policy ](img/single_git_create_policy_records_with_traffic_policy.png )
1. Fill in **Policy record DNS name** with `git` .
2022-07-23 23:45:48 +05:30
1. Select **Create policy records** .
2019-12-21 20:55:43 +05:30
![Created policy record ](img/single_git_created_policy_record.png )
2021-09-30 23:02:18 +05:30
You have successfully set up a single host, for example, `git.example.com` which
2021-06-08 01:23:25 +05:30
distributes traffic to your Geo sites by geolocation!
2019-12-21 20:55:43 +05:30
## Configure Git clone URLs to use the special Git URL
When a user clones a repository for the first time, they typically copy the Git
remote URL from the project page. By default, these SSH and HTTP URLs are based
on the external URL of the current host. For example:
- `git@secondary.example.com:group1/project1.git`
- `https://secondary.example.com/group1/project1.git`
![Clone panel ](img/single_git_clone_panel.png )
You can customize the:
2023-03-04 22:38:38 +05:30
- SSH remote URL to use the location-aware `git.example.com` . To do so, change the SSH remote URL
2019-12-21 20:55:43 +05:30
host by setting `gitlab_rails['gitlab_ssh_host']` in `gitlab.rb` of web nodes.
- HTTP remote URL as shown in
2021-10-27 15:23:28 +05:30
[Custom Git clone URL for HTTP(S) ](../../../user/admin_area/settings/visibility_and_access_controls.md#customize-git-clone-url-for-https ).
2019-12-21 20:55:43 +05:30
## Example Git request handling behavior
After following the configuration steps above, handling for Git requests is now location aware.
For requests:
2021-06-08 01:23:25 +05:30
- Outside Europe, all requests are directed to the **primary** site.
2019-12-21 20:55:43 +05:30
- Within Europe, over:
- HTTP:
2021-06-08 01:23:25 +05:30
- `git clone http://git.example.com/foo/bar.git` is directed to the **secondary** site.
2019-12-21 20:55:43 +05:30
- `git push` is initially directed to the **secondary** , which automatically
redirects to `primary.example.com` .
- SSH:
- `git clone git@git.example.com:foo/bar.git` is directed to the **secondary** .
- `git push` is initially directed to the **secondary** , which automatically
proxies the request to `primary.example.com` .