В этой статье мы рассмотрим, как настроить реестр образов GitLab Container Registry, находящийся за обратным прокси сервером NGINX. Предполагается, что у вас уже установлен GitLab с помощью пакета Omnibus. Согласно документации, Container Registry можно настроить на том же домене, на котором работает сам GitLab, но в случае работы GitLab за прокси сервером, необходимо завести отдельный домен для реестра образов, чтобы избежать конфликта доменных имен при настройке виртуальных хостов в GitLab Nginx.
Реестр образов будет доступен по адресу: registry.example.com. Добавляем А запись для домена реестра в DNS. Приводим конфиг виртуального хоста на сервере обратного прокси к следующему виду:
server {
listen 80;
server_name registry.example.com;
#return 301 https://$host$request_uri;
root /usr/share/nginx/html;
location / {
deny all;
}
location ^~ /.well-known {
default_type 'text/plain';
allow all;
}
error_log /var/log/nginx/registry_example_com_error.log error;
access_log /var/log/nginx/registry_example_com_access.log;
}
Получаем валидный сертификат от Let’s Encrypt с помощью плагина webroot:
certbot certonly -a webroot -w /usr/share/nginx/html -d registry.example.com
Дополняем конфигурацию домена реестра. Указываем путь к сертификату и приватному ключу, который мы получили ранее. Также проксируем запросы на порт "registry_nginx" и не забываем включить постоянный редирект на https:
server {
listen 443 ssl;
server_name registry.example.com;
ssl_certificate /etc/letsencrypt/live/registry.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/registry.example.com/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSL:10m;
client_max_body_size 2000M;
chunked_transfer_encoding on;
root /usr/share/nginx/html;
location / {
proxy_pass http://192.168.0.10:8090;
proxy_read_timeout 300;
proxy_connect_timeout 300;
proxy_redirect off;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Ssl on;
}
location ^~ /.well-known {
default_type 'text/plain';
allow all;
}
error_log /var/log/nginx/registry_example_com_ssl_error.log error;
access_log /var/log/nginx/registry_example_com_ssl_access.log;
}
Проверяем и перечитываем конфиг nginx:
nginx -t
nginx -s reload
Теперь вносим изменения в конфигурацию сервера GitLab. По умолчанию подсистема "GitLab Container Registry" отключена. Она активируется, полностью автоматически настраиваясь оркестратором "Omnibus", при обнаружении в конфигурационном файле параметра "registry_external_url".
# cat /etc/gitlab/gitlab.rb
registry_external_url 'https://registry.example.com'
gitlab_rails['registry_enabled'] = true
registry['enable'] = true
registry_nginx['enable'] = true
registry_nginx['proxy_set_headers'] = {
"Host" => "$http_host",
"X-Real-IP" => "$remote_addr",
"X-Forwarded-For" => "$proxy_add_x_forwarded_for",
"X-Forwarded-Proto" => "https",
"X-Forwarded-Ssl" => "on"
}
registry_nginx['listen_port'] = 8090
registry_nginx['listen_https'] = false
Запускаем перенастройку GitLab:
gitlab-ctl reconfigure
Проверяем на клиенте аутентификацию и заливку образа:
docker login registry.example.com
docker build -t registry.example.com/test/test-1 .
docker push registry.example.com/test/test-1
Источники:
https://serveradmin.ru/gitlab-container-registry-za-nginx-reverse-proxy/
Комментарии (3)
angelsaint
17.11.2021 21:53Было бы хорошо добавить в статью немаловажный момент - как очищать реестр. При активных ci/cd процессах реест начинает очень быстро пухнуть, диски забиваются, на размер резервных копий без слёз не взглянешь. В гитлаб есть встроенная очистка, но её нужно не забыть активировать и её возможностей не всегда хватает и приходится браться за api.
alexesDev
17.11.2021 23:27Давно уже появились "Tag expiration policy".
Вообще лучше не хранить images в gitlab для прода, тк в случае проблем с gitlab у вас может прилечь прод. Я копирую в отдельный продовый registry перед деплом. И раз в пол года по очереди чищу registry.
alexesDev
Там в gitlab.rb есть
letsencrypt['enable'] = false
, который чуть намекает... https://docs.gitlab.com/omnibus/settings/ssl.html#lets-encrypt-integration