Настраиваем GitLab Container Registry

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

В этой статье мы рассмотрим, как настроить реестр образов 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/

Источник: https://habr.com/ru/company/timeweb/blog/589675/


Интересные статьи

Интересные статьи

В основном идея использования CI/CD для iOS, да и для других платформ, — это автоматизация рутинной работы. Когда мы работаем над одним приложением, можем вручную собирать небольшой проект. Но команда...
В настоящее время существует множество систем CI/CD. У всех есть определенные достоинства и недостатки и каждый выбирает себе наиболее подходящую под проект. Цель данной статьи - познаком...
Привет, Хабр!TeamCity — пожалуй, один из самых популярных CI/CD-серверов, который используют разработчики по всему миру. В этой статье я расскажу про базовые концепции, н...
Привет, Хабр! Сегодня я хочу рассказать о нашем опыте автоматизации резервного копирования больших данных хранилищ Nextcloud в разных конфигурациях. Я работаю СТО в «Молния АК», где ...
Как быстро определить, что на отдельно взятый сайт забили, и им никто не занимается? Если в подвале главной страницы в копирайте стоит не текущий год, а старый, то именно в этом году опека над са...