debian-mirror-gitlab/doc/administration/geo/replication/docker_registry.md

131 lines
4.6 KiB
Markdown
Raw Normal View History

2020-06-23 00:09:42 +05:30
---
stage: Enablement
group: Geo
2021-02-22 17:27:13 +05:30
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
2020-06-23 00:09:42 +05:30
type: howto
---
2021-04-29 21:17:54 +05:30
# Docker Registry for a secondary site **(PREMIUM SELF)**
2019-07-31 22:56:46 +05:30
2019-12-04 20:38:33 +05:30
You can set up a [Docker Registry](https://docs.docker.com/registry/) on your
2021-04-29 21:17:54 +05:30
**secondary** Geo site that mirrors the one on the **primary** Geo site.
2019-07-31 22:56:46 +05:30
## Storage support
2020-06-23 00:09:42 +05:30
Docker Registry currently supports a few types of storage. If you choose a
2019-07-31 22:56:46 +05:30
distributed storage (`azure`, `gcs`, `s3`, `swift`, or `oss`) for your Docker
2021-04-29 21:17:54 +05:30
Registry on the **primary** site, you can use the same storage for a **secondary**
2019-07-31 22:56:46 +05:30
Docker Registry as well. For more information, read the
2019-12-04 20:38:33 +05:30
[Load balancing considerations](https://docs.docker.com/registry/deploying/#load-balancing-considerations)
2021-02-22 17:27:13 +05:30
when deploying the Registry, and how to set up the storage driver for the GitLab
2020-07-28 23:09:34 +05:30
integrated [Container Registry](../../packages/container_registry.md#use-object-storage).
2019-12-04 20:38:33 +05:30
## Replicating Docker Registry
You can enable a storage-agnostic replication so it
2020-06-23 00:09:42 +05:30
can be used for cloud or local storage. Whenever a new image is pushed to the
2021-04-29 21:17:54 +05:30
**primary** site, each **secondary** site will pull it to its own container
2019-12-04 20:38:33 +05:30
repository.
To configure Docker Registry replication:
2021-04-29 21:17:54 +05:30
1. Configure the [**primary** site](#configure-primary-site).
1. Configure the [**secondary** site](#configure-secondary-site).
2019-12-04 20:38:33 +05:30
1. Verify Docker Registry [replication](#verify-replication).
2021-04-29 21:17:54 +05:30
### Configure **primary** site
2019-12-04 20:38:33 +05:30
Make sure that you have Container Registry set up and working on
2021-04-29 21:17:54 +05:30
the **primary** site before following the next steps.
2019-12-04 20:38:33 +05:30
We need to make Docker Registry send notification events to the
2021-04-29 21:17:54 +05:30
**primary** site.
2019-12-04 20:38:33 +05:30
1. SSH into your GitLab **primary** server and login as root:
2020-03-13 15:44:24 +05:30
```shell
2019-12-04 20:38:33 +05:30
sudo -i
```
1. Edit `/etc/gitlab/gitlab.rb`:
```ruby
registry['notifications'] = [
{
'name' => 'geo_event',
'url' => 'https://example.com/api/v4/container_registry_event/events',
'timeout' => '500ms',
'threshold' => 5,
'backoff' => '1s',
'headers' => {
2020-04-22 19:07:51 +05:30
'Authorization' => ['<replace_with_a_secret_token>']
2019-12-04 20:38:33 +05:30
}
}
]
```
2021-02-22 17:27:13 +05:30
NOTE:
2020-04-22 19:07:51 +05:30
Replace `<replace_with_a_secret_token>` with a case sensitive alphanumeric string
that starts with a letter. You can generate one with `< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c 32 | sed "s/^[0-9]*//"; echo`
2021-02-22 17:27:13 +05:30
NOTE:
2019-12-04 20:38:33 +05:30
If you use an external Registry (not the one integrated with GitLab), you must add
2020-01-01 13:55:28 +05:30
these settings to its configuration yourself. In this case, you will also have to specify
2019-12-04 20:38:33 +05:30
notification secret in `registry.notification_secret` section of
`/etc/gitlab/gitlab.rb` file.
2021-02-22 17:27:13 +05:30
NOTE:
2019-12-04 20:38:33 +05:30
If you use GitLab HA, you will also have to specify
the notification secret in `registry.notification_secret` section of
`/etc/gitlab/gitlab.rb` file for every web node.
1. Reconfigure the **primary** node for the change to take effect:
2020-03-13 15:44:24 +05:30
```shell
2019-12-04 20:38:33 +05:30
gitlab-ctl reconfigure
```
2021-04-29 21:17:54 +05:30
### Configure **secondary** site
2019-12-04 20:38:33 +05:30
Make sure you have Container Registry set up and working on
2021-04-29 21:17:54 +05:30
the **secondary** site before following the next steps.
2019-12-04 20:38:33 +05:30
2021-04-29 21:17:54 +05:30
The following steps should be done on each **secondary** site you're
2019-12-04 20:38:33 +05:30
expecting to see the Docker images replicated.
2021-04-29 21:17:54 +05:30
Because we need to allow the **secondary** site to communicate securely with
the **primary** site Container Registry, we need to have a single key
pair for all the sites. The **secondary** site will use this key to
2019-12-04 20:38:33 +05:30
generate a short-lived JWT that is pull-only-capable to access the
2021-04-29 21:17:54 +05:30
**primary** site Container Registry.
2019-12-04 20:38:33 +05:30
2021-04-29 21:17:54 +05:30
For each application and Sidekiq node on the **secondary** site:
1. SSH into the node and login as the `root` user:
2019-12-04 20:38:33 +05:30
2020-03-13 15:44:24 +05:30
```shell
2019-12-04 20:38:33 +05:30
sudo -i
```
2021-04-29 21:17:54 +05:30
1. Copy `/var/opt/gitlab/gitlab-rails/etc/gitlab-registry.key` from the **primary** to the node.
2019-12-04 20:38:33 +05:30
1. Edit `/etc/gitlab/gitlab.rb`:
```ruby
gitlab_rails['geo_registry_replication_enabled'] = true
2020-06-23 00:09:42 +05:30
gitlab_rails['geo_registry_replication_primary_api_url'] = 'https://primary.example.com:5050/' # Primary registry address, it will be used by the secondary node to directly communicate to primary registry
2019-12-04 20:38:33 +05:30
```
2021-04-29 21:17:54 +05:30
1. Reconfigure the node for the change to take effect:
2019-12-04 20:38:33 +05:30
2020-03-13 15:44:24 +05:30
```shell
2019-12-04 20:38:33 +05:30
gitlab-ctl reconfigure
```
### Verify replication
2019-07-31 22:56:46 +05:30
2020-10-24 23:57:45 +05:30
To verify Container Registry replication is working, go to **Admin Area > Geo**
2021-04-29 21:17:54 +05:30
(`/admin/geo/nodes`) on the **secondary** site.
2019-12-04 20:38:33 +05:30
The initial replication, or "backfill", will probably still be in progress.
2021-04-29 21:17:54 +05:30
You can monitor the synchronization process on each Geo site from the **primary** site's **Geo Nodes** dashboard in your browser.