Add latest changes from gitlab-org/gitlab@master
After Width: | Height: | Size: 74 KiB |
After Width: | Height: | Size: 87 KiB |
After Width: | Height: | Size: 20 KiB |
After Width: | Height: | Size: 100 KiB |
After Width: | Height: | Size: 138 KiB |
After Width: | Height: | Size: 37 KiB |
After Width: | Height: | Size: 55 KiB |
After Width: | Height: | Size: 210 KiB |
|
@ -229,6 +229,10 @@ For more information on Geo security, see [Geo security review](security_review.
|
|||
|
||||
For more information on tuning Geo, see [Tuning Geo](tuning.md).
|
||||
|
||||
### Set up a location-aware Git URL
|
||||
|
||||
For an example of how to set up a location-aware Git remote URL with AWS Route53, see [Location-aware Git remote URL with AWS Route53](location_aware_git_url.md).
|
||||
|
||||
## Remove Geo node
|
||||
|
||||
For more information on removing a Geo node, see [Removing **secondary** Geo nodes](remove_geo_node.md).
|
||||
|
|
|
@ -0,0 +1,120 @@
|
|||
# Location-aware Git remote URL with AWS Route53 **(PREMIUM ONLY)**
|
||||
|
||||
You can provide GitLab users with a single remote URL that automatically uses
|
||||
the Geo node closest to them. This means users don't need to update their Git
|
||||
configuration to take advantage of closer Geo nodes as they move.
|
||||
|
||||
This is possible because, Git push requests can be automatically redirected
|
||||
(HTTP) or proxied (SSH) from **secondary** nodes to the **primary** node.
|
||||
|
||||
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.
|
||||
|
||||
NOTE: **Note**
|
||||
You can also use a load balancer to distribute web UI or API traffic to
|
||||
[multiple Geo **secondary** nodes](../../../user/admin_area/geo_nodes.md#multiple-secondary-nodes-behind-a-load-balancer).
|
||||
Importantly, the **primary** node cannot yet be included. See the feature request
|
||||
[Support putting the **primary** behind a Geo node load balancer](https://gitlab.com/gitlab-org/gitlab/issues/10888).
|
||||
|
||||
## Prerequisites
|
||||
|
||||
In this example, we have already set up:
|
||||
|
||||
- `primary.example.com` as a Geo **primary** node.
|
||||
- `secondary.example.com` as a Geo **secondary** node.
|
||||
|
||||
We will create a `git.example.com` subdomain that will automatically direct
|
||||
requests:
|
||||
|
||||
- From Europe to the **secondary** node.
|
||||
- From all other locations to the **primary** node.
|
||||
|
||||
In any case, you require:
|
||||
|
||||
- A working GitLab **primary** node that is accessible at its own address.
|
||||
- A working GitLab **secondary** node.
|
||||
- A Route53 Hosted Zone managing your domain.
|
||||
|
||||
If you have not yet setup a Geo **primary** node and **secondary** node, please consult
|
||||
[the Geo setup instructions](https://docs.gitlab.com/ee/administration/geo/replication/#setup-instructions).
|
||||
|
||||
## Create a traffic policy
|
||||
|
||||
In a Route53 Hosted Zone, traffic policies can be used to set up a variety of
|
||||
routing configurations.
|
||||
|
||||
1. Navigate to the
|
||||
[Route53 dashboard](https://console.aws.amazon.com/route53/home) and click
|
||||
**Traffic policies**.
|
||||
|
||||
![Traffic policies](img/single_git_traffic_policies.png)
|
||||
|
||||
1. Click the **Create traffic policy** button.
|
||||
|
||||
![Name policy](img/single_git_name_policy.png)
|
||||
|
||||
1. Fill in the **Policy Name** field with `Single Git Host` and click **Next**.
|
||||
|
||||
![Policy diagram](img/single_git_policy_diagram.png)
|
||||
|
||||
1. Leave **DNS type** as `A: IP Address in IPv4 format`.
|
||||
1. Click **Connect to...** and select **Geolocation rule**.
|
||||
|
||||
![Add geolocation rule](img/single_git_add_geolocation_rule.png)
|
||||
|
||||
1. For the first **Location**, leave it as `Default`.
|
||||
1. Click **Connect to...** and select **New endpoint**.
|
||||
1. Choose **Type** `value` and fill it in with `<your **primary** IP address>`.
|
||||
1. For the second **Location**, choose `Europe`.
|
||||
1. Click **Connect to...** and select **New endpoint**.
|
||||
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)
|
||||
|
||||
1. Click **Create traffic policy**.
|
||||
|
||||
![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`.
|
||||
1. Click **Create policy records**.
|
||||
|
||||
![Created policy record](img/single_git_created_policy_record.png)
|
||||
|
||||
You have successfully set up a single host, e.g. `git.example.com` which
|
||||
distributes traffic to your Geo nodes by geolocation!
|
||||
|
||||
## 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)
|
||||
|
||||
However, you can customize the SSH remote URL to use the location-aware
|
||||
`git.example.com`. To do so, change the SSH remote URL's host by setting
|
||||
`gitlab_rails['gitlab_ssh_host']` in `gitlab.rb` of web nodes.
|
||||
|
||||
Unfortunately the means to specify a custom HTTP clone URL is not yet
|
||||
implemented. The feature request can be found at
|
||||
[Customizable Git HTTP clone root URL](https://gitlab.com/gitlab-org/gitlab/issues/31949).
|
||||
|
||||
## Example Git request handling behavior
|
||||
|
||||
After following the configuration steps above, handling for Git requests is now location aware.
|
||||
For requests:
|
||||
|
||||
- Outside Europe, all requests are directed to the **primary** node.
|
||||
- Within Europe, over:
|
||||
- HTTP:
|
||||
- `git clone http://git.example.com/foo/bar.git` is directed to the **secondary** node.
|
||||
- `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`.
|