Установка и настройка Gitlab на Ubuntu 18.04

Выполним установку и настройку Gitlab Community Edition через установку Omnibus-пакета

1. Установка зависимостей для Gitlab-пакета с предварительным обновлением локального кеша пакетов

 

2. Добавление Gitlab репозитария, из которого будет установлен пакет Gitlab Community Edition

 

3. Установка Gitlab

 

4. Настройка домен/урл по которому будет доступен Gitlab снаружи
Если не используется SSL, тогда указываем протокол http в параметре
external_url в файле /etc/gitlab/gitlab.rb

Для фактического применения сделанных настроек необходимо выполнить команду:

 

5. Настройка Gitlab на работу с SSL

Получение бесплатного Let’sEncrypt-сертификата

Gitlab поддерживает два способа работы с SSL:

1.Автоматическое генерирование самим Gitlab-ом сертификатов Let’sEncrypt(c их поселедующим ручным (с помощью команды gitlab-ctl renew-le-certs) или автоматическим обновлением)
https://docs.gitlab.com/omnibus/settings/ssl.html#lets-encrypt-integration

2.Ручная настройка HTTPS со своими собственными сертификатами
https://docs.gitlab.com/omnibus/settings/nginx.html#manually-configuring-https

Будем использовать второй способ, в котором получим бесплатный Let’sEncrypt-сертификат и установим автообновление этого сертификата

Сгенерируем Диффи-Хелмана ключ

Настройка Gitlab на поддержку SSL

https://docs.gitlab.com/omnibus/settings/ssl.html
https://docs.gitlab.com/omnibus/settings/nginx.html#manually-configuring-https

Протокол изменяем с http на https

Включаем принудительный редирект http->https

Указываем пути к сертификату, приватному ключу и к ключу Дифи-Хелмана

Обязательно отключаем поддержку letsencrypt, встроенную в Gitlab
Чтобы при выполнении команды gitlab-ctl reconfigure
Gitlab не пытался самостоятельно обновить сертификаты Let’sEncrypt и тем самым перезаписать уже действующие сертификаты

Перенастраиваем/переконфигурируем Gitlab после внесений изменений в файл /etc/gitlab/gitlab.rb

 

Настройка автообновления Let’sEncrypt-сертификата с последующим перечитыванием nginx-ом своей конфигурации и нового сертификата/ключа
https://docs.gitlab.com/omnibus/settings/nginx.html#update-the-ssl-certificates

Для получение сертификата добавляем в cron-скрипт для запуска каждые 2 месяца, который

 

6. Базовая настройка Gitlab после его установки

 

Установка пароля:
Логинимся в Gitlab (предварительно в WEB-интерфейсе устанавливаем пароль)

 

Отключение авторегистрации:

 

Указание корректного Email-адреса:

 

Изменение дефолтного имени пользователя с админискими правми с root на свое имя:

 

Настройка Gitlab Shell на нестандартный порт SSH(если SSH-сервер запущен не на стандартном порту)

 

Настройка SMTP-сервера
В качестве SMTP-сервера используем локально запущеннный postfix без поддержки SSL, слушающий запросы на localhost

Перенастраиваем/переконфигурируем Gitlab после внесений изменений в файл /etc/gitlab/gitlab.rb

Тестирование SMTP-кнфигурации путем отправки тестового сообщения из консоли Gitlab
https://docs.gitlab.com/omnibus/settings/smtp.html#testing-the-smtp-configuration

Заходим в Gitlab консоль

Выполняем команду по отправке тестового сообщения

Если необходимо отключить отправку всех типов сообщений
https://docs.gitlab.com/omnibus/settings/smtp.html#disable-all-outgoing-email

 

Отключение неиспользуемых сервисов
Отключение Prometheus (который включен по умолчанию)

Отключение Grafana

При отключении сервиса Prometheus fвтоматически также будут отключены такие сервисы,которые использует prometheus

Применяем настройки

Проверяем отсутствие запущенных Prometheus и Grafana-сервисов


Настройка Nginx статусной страницы

Конфигурация, которая создается после изменений в файле /etc/gitlab/gitlab.rb
и выполнению команды для применения изменений (gitlab-ctl reconfigure)

Error-логи Nginx

Все конфигурационные файлы/файлы виртуальных хостов/статусной страницы и т.д. для Nginx распологаются в каталоге /var/opt/gitlab/nginx/conf:

 

Настройка ротации логов

https://docs.gitlab.com/omnibus/settings/logs.html

GitLab включает расширенную систему журналов, в которой все службы и компоненты GitLab будут записывать в системные логи

Дефолтное месторасположение логов всех сервисов/компонентов доступно по команде:

Runit-управляемые сервисы генерируют логи испольхуя svlogd
Ротацию логов таких сервисов настраиваем через параметры

Например, настроим ротацию с такой логикой
Ротировать только по времени(раз в сутки), ротация по размеру отключена
Хранить 7 ротированных файлов, при ротации сжимать старый лог-файл

Logrotate-сервис,который встроен в Gitlab управляет всеми логами кроме логов для Runit-управляемых сервисов
Аналогично, как и для логов runit-сервисов, настроим ротацию всех остальных
логов средствами встроенного в Gitlab logrotate-сервиса, а именно:
Ежесуточная ротация по времени(не по рамзмеру), с хранением 7 посоледних ротированных копий/лог-файлов, с сжатием ротированных файлов

Применяем сделанные настройки

При необходимости можно выполнить ручной запуск ротации(по дефолту ротация выполняется по расписанию)

Несколько команд для просмотра логов средствами утилиты gitlab-ctl

Просмотр логов всех сервисов в online-режиме

Просмотр всех логов в конкретном подкаталоге(например, в подкаталоге gitlab-rails)

Просмотр лога конкретного файла(например, access-лога Gitlab-сервиса)


Настройка лимитов на подключение к Gitlab

Enabling/Disabling Rack Attack and setting up basic auth throttling
https://docs.gitlab.com/omnibus/settings/configuration.html#enablingdisabling-rack-attack-and-setting-up-basic-auth-throttling
https://docs.gitlab.com/ee/security/rack_attack.html

3 неуспешные попытки за 10 минут — блокировка на 3 часа

Rate Limit/Throttling
Более 5 запросов незарегистрированным пользователем — троттлинг на 120 секунд
с кодом ответа 429 и ответом Too Many Requests

https://docs.gitlab.com/ee/security/rate_limits.html

6-й запрос

Проверка наличия IP-адрса в заблокаированных:

Дефолтное место хранения репозитариев
https://docs.gitlab.com/omnibus/settings/configuration.html#configuring-the-external-url-for-gitlab

Storage-директории

 

Полезные команды для работы с Gitlab-сервисами через утилиту gitlab-ctl

Послать команду на nginx-сервис для перечитывания им своей конфигурации при обновлении

 

Включение Container Registry в Gitlab

Получение Let’sEncrypt-сертификата для домена registry.mydomain.com

Для автоматического продления сертификата добавим в ранее созданный скрипт /usr/local/bin/ssl-renew.sh после строки с командой по запуску certbot
команду для обновления сертификата для домена registry.mydomain.com

И в конеце скрипта последней строкой добавляем перезапуск сервиса registry

Итого скрипт по обновлению сертификатов(как для gitlab, так и для registry) имеет вид:

По умолчанию registry запускается на порту 5000

Взаимодействие Gitlab и Registry
https://docs.gitlab.com/omnibus/architecture/registry/README.html

 

Процес аутентификации в Container Registry в Gitlab(docker login…)
1.Docker client->Docker daemon->registry.mydomain.com->
2.Реджистри возвращает код ответа 401 т.к. не был предоставлен валидный токен
Вместе с кодом ответа 401 реджистри отправляет клиенту(который попытался залогиниться в реджистри с помощью команды docker login https://registry.mydomain.com)
token_realm (который указан в конфигурации реджистри в файле /var/opt/gitlab/registry/config.yml)

Этот token_realm как раз и указывает клиенту, где он может получить токен т.е.
обратиться за токеном на Gitlab (https://gitlab.mydomain.com) по указанному роуту

3.Docker клиент подключается к Gitlab API и получает токен
Этот токен Gitlab подписывает приватным ключем РЕДЖИСТРИ, а сертификат РЕДЖИСТРИ, которым будет
проверяться подписанный Gitlab-ом приватным ключем токен, прописан в конфиг.файла registry

Эта пара приватный ключ и сертификат для Реджистри является самоподписными и автоматически
выпускается Gitlab-ом при включении/настройке Registry
И эта пара никакого не имеет отношения к сертификату/ключу, который использует клиент при подключении к Registry снаружи(который мы выпускали средствами Let’sEncrypt)

4.Docker клиент подключается снова к Registry, но уже с валидным токеном, который он получил от Gitlab API и
успешно аутентифицируется в Docker-реджистри

Увеличение времени жизни токена(по дефолту 5 минут)
https://docs.gitlab.com/13.6/ee/administration/packages/container_registry.html#container-registry-domain-configuration
Полезно,если в хранилище загружается большой по размеру образ, который не успевает загрузиться за 5 минут

 

Тегирование, загрузка, скачивание образов с Container Registry
https://docs.gitlab.com/ee/user/packages/container_registry/
Залогиниться пользователем,который создан в Gitlab, в Registry( например, my-gitlab-user-name)

Перетегировать образ в формат, поддерживаемый Gitlab-ом

Загрузить образ в Registry

Удалить локальный образ

Загрузить образ с Registry

 

Troubleshooting Registry
https://docs.gitlab.com/13.6/ee/administration/packages/container_registry.html#troubleshooting

Лог файл Registry

Лог файл Gitlab

 

Источник:

Установка
https://docs.gitlab.com/13.6/omnibus/installation

Настройка
https://docs.gitlab.com/omnibus/settings/configuration.html
https://docs.gitlab.com/13.6/omnibus/README.html#configuring

Nginx
https://docs.gitlab.com/13.6/omnibus/settings/nginx.html

Комментирование и размещение ссылок запрещено.

Комментарии закрыты.

Яндекс.Метрика