В этой статье мы рассмотрим, как настроить реестр образов 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://medium.com/@s.petrushin/%D0%BD%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0-gitlab-container-registry-c9ae3fb8a35

https://serveradmin.ru/gitlab-container-registry-za-nginx-reverse-proxy/

Комментарии (3)


  1. alexesDev
    17.11.2021 10:50

    Там в gitlab.rb есть letsencrypt['enable'] = false, который чуть намекает... https://docs.gitlab.com/omnibus/settings/ssl.html#lets-encrypt-integration


  1. angelsaint
    17.11.2021 21:53

    Было бы хорошо добавить в статью немаловажный момент - как очищать реестр. При активных ci/cd процессах реест начинает очень быстро пухнуть, диски забиваются, на размер резервных копий без слёз не взглянешь. В гитлаб есть встроенная очистка, но её нужно не забыть активировать и её возможностей не всегда хватает и приходится браться за api.


    1. alexesDev
      17.11.2021 23:27

      Давно уже появились "Tag expiration policy".

      Вообще лучше не хранить images в gitlab для прода, тк в случае проблем с gitlab у вас может прилечь прод. Я копирую в отдельный продовый registry перед деплом. И раз в пол года по очереди чищу registry.