Привет! Это Александр, DevOps инженер команд Страхования в Банки.ру.
Продолжаю серию статей про домашний сервер. В прошлых материалах я рассказал о выборе железа, сборке и настройке NAS и серверов для дома. В этой и последующих статьях опишу установку нужного софта в домашнюю серверную. Для этого вам, возможно, понадобится VPN на виртуальных машинах или на уровне всей домашней сети (у меня второй вариант).

Начать я бы хотел с установки GitLab. На данный момент у меня достаточно ресурсов, чтобы хостить GitLab и другие сервисы, которые использует DevOps-инженер. Но для чего мне нужен GitLab? Тут всё очень просто: в своей работе я использую подход Infrastructure as Code (IaC) — инфраструктура как код. При таком методе конфигурация инфраструктуры описана в файлах в репозитории, который хранит историю изменений.

В итоге из хранилища можно как развернуть нужный софт за считаные минуты, так и вспомнить,  что мы коммитили в репозиторий. GitLab требованиям этого подхода отвечает. К тому же у платформы широкий функционал, который понадобится мне в будущем (CI/CD, например, или хранение terrafrom state в самом GitLab).

Настраиваем DNS

Перед установкой GitLab мне предстояло решить вопрос с DNS и SSL-сертификатом на GitLab и другие мои сервисы. Да, я описывал вариант с Nginx Proxy Manager в прошлых статьях, но при тестировании некоторых сервисов, которые стоят за NPM, выявил ряд проблем и багов. Например, при переходе вроде как по внутренней ссылке в GitLab, домен автоматом менялся на localhost и, соответственно, страницу я так и не получал. Так что, NMP мне не подходил. 

В статье я не буду описывать покупку домена, но подойдёт любой регистратор. Я брал на reg.ru домен в зоне .ru (k8sl.ru) и остался доволен. Фокус заключается в том, чтобы купить любой недорогой домен в личное пользование, изменить NS-записи на NS-сервера Cloudflare и управлять DNS-записями домена через Cloudflare. Мне также пригодится API ключ от Cloudflare для получения SSL-сертификата через плагин cloudflare для certbot. 

Есть несколько вариантов получения сертификата и использования DNS провайдера. Для reg.ru есть плагин к certbot, но у самого reg.ru нет API, через который можно было бы пройти DNS-01 челлендж для получения бесплатного сертификата. Поэтому я и перевожу свои домены к Cloudflare, где мне привычнее ими управлять (надеюсь, что Cloudflare не забанят в России хотя бы к моменту выхода статьи).

Ещё один супербюджетный вариант – использование Duck DNS. Тут тоже всё более менее просто. Сервис выдаст вам личный API token сразу при регистрации, и у вас будет возможность взять до 5 доменов третьего уровня (по типу *.duckdns.org). Вот так, например, выглядит мой аккаунт и домены:

Из плюсов: домены будут бесплатными на постоянной основе. Если же будете покупать домен у регистратора, в первый год заплатите смешные 200-300 рублей, но с продлением на следующие периоды цены будут выше. Из минусов Duck DNS: вы получаете достаточно длинное имя домена, которое  придётся некоторое время вводить руками. 

При первых установках софта по типу GitLab лучше всего использовать SSL-сертификат. В противном случае придётся каждому подключившемуся к нему хосту объяснять, что с этими сервисами всё в порядке. Покупать дорогой Wildcard я не хочу, поэтому буду обходиться сертификатом от Let’s Encrypt, который получу на свой домен с помощью certbot. Бесплатные сертификаты выдаются на 90 дней, но certbot умеет отслеживать сроки выдачи и автоматически обновит сертификат и перезапустить приложение, которое его использует (когда останется меньше 30 дней до истечения срока действия). С такой настройкой мы получаем бесконечный и всегда актуальный SSL-сертификат. 

Так как я нахожусь в домашней сети с внешним серым IP, получать SSL от Let’s Encrypt приходится через челлендж DNS-01. То есть нужен поддерживаемый DNS провайдер (в моем случае Cloudflare), который и предоставляет API- ключ для подтверждения владения данным доменом. 

Работает это следующим образом: 

• При запуске certbot генерируется txt-запись для вашего домена. 

• Плагин certbot для Cloudflare создаёт новую временную txt-запись на аккаунте в Cloudflare и в дальнейшем подтверждает, что домен принадлежит именно вам.

Если вы выбрали вариант с  Duck DNS или подобными сервисами, большинство шагов из части с покупкой и сменой DNS нового домена можно пропустить. Вот пример из моего ЛК в reg.ru:

Быстро пройдусь по шагам: 

1. Создаем аккаунт у регистратора доменов и покупаем домен.

2. Создаем аккаунт в Cloudflare и после подтверждения почты и логина в аккаунт жмем кнопку add – Connect domain. Вписываем имя домена и выбираем вариант с ручным добавлением DNS-записей.

3. Полученные DNS-записи мы вписываем в настройках домена у регистратора.

4. Ждём некоторое время в панели управления Cloudflare (может быть почти сразу, а бывает придётся подождать час-другой). Как только DNS сервера обновятся, откроется панель управления доменом:

Здесь нас интересует секция с DNS setup и раздел get your api token в секции с API. Нажимаем на получение токена. Нам нужны вот такие параметры: 

(!) После создания токен будет показан всего один раз, так что лучше записать его сразу.

Подведу промежуточный результат: домен приобретён, DNS записи ведут на Cloudflare, API-токен для управления DNS-записями тоже получен. Переходим к развёртке GitLab.

Установка GitLab на ВМ в домашнем дата-центре

Для начала нам нужно определиться с параметрами ВМ. Почитав документацию и пообщавшись с несколькими ИИ, я принял решение создать под GitLab следующую ВМ:

• 4 ядра

• 8 ГБ оперативной памяти

• 128 ГБ дискового пространства

Этого вполне должно хватить для личного использования. При этом в документации GitLab есть пометка, что лучше не использовать сетевые диски, так как это может сильно замедлить производительность. Так что я создал диск на самом хосте, а потом уже настроил бекапы ВМ на NFS.

Первоначальная установка GitLab будет идти по вот этой инструкции, но с некоторыми изменениями. Так как мы находимся во внутренней сети, то установка как бы «сломается» где-то под конец, так как встроенный в пакет gitlab-а certbot не сможет получить сертификат. Хорошая новость в том, что это можно вылечить, установив certbot и плагин certbot-а для Cloudflare. 

Быстрый список команд следующий:

sudo apt-get update
sudo apt-get install -y curl openssh-server ca-certificates tzdata perl
sudo apt-get install -y postfix
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash
sudo EXTERNAL_URL="https://gitlab.k8sl.ru" apt-get install gitlab-ee #домен меняем на свой

Дождёмся, пока установка GitLab упадёт в ошибку, и продолжим. Теперь мы ставим certbot и плагин Cloudflare к нему:

sudo apt install certbot python3-pip
pip install certbot-dns-cloudflare --break-system-packages

После установки certbot создаём файл cloudflare.ini с токеном, полученным в панели Cloudflare:

echo "dns_cloudflare_api_token = XXXXXXXXXXXXX" > /etc/letsencrypt/cloudflare.ini
chmod 600 /etc/letsencrypt/cloudflare.ini

Для получения сертификата вводим следующую команду:

certbot certonly \
  --dns-cloudflare \
  --agree-tos \
  --email yourmail@example.com \
  --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
  --dns-cloudflare-propagation-seconds 60 \
  -d *.k8sl.ru

Вот так выглядит панель управления DNS-записями на момент выдачи SSL-сертификата. Как я писал ранее, добавляется временная txt-запись для подтверждения владения доменом.

В итоге в консоли получаем следующий ответ:

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/k8sl.ru/fullchain.pem
Key is saved at:     	/etc/letsencrypt/live/k8sl.ru/privkey.pem
This certificate expires on 2025-06-29.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

Итак, wildcard-сертификат у нас есть, теперь подправим конфиг gitlab. 

Редактируем файл /etc/gitlab/gitlab.rb и добавляем следующие строки (или находим и меняем путь к сертификатам, которые мы выписали, в соответствующих строках):

nginx['ssl_certificate'] = "/etc/letsencrypt/live/k8sl.ru/fullchain.pem"
nginx['ssl_certificate_key'] = "/etc/letsencrypt/live/k8sl.ru/privkey.pem"

После этого сохраняем файл и вводим в консоль команду:

sudo gitlab-ctl reconfigure

На этом этапе все должно пройти успешно. При посещении gitlab.k8sl.ru мы видим вот такую картину:

И рабочий SSL сертификат:

На этом базовая установка GitLab закончена. Забираем в консоли первичный пароль на root пользователя:

cat /etc/gitlab/initial_root_password | grep Password:

Через этот пароль мы и попадём в аккаунт админа Gitlab. Не забывайте сменить пароль, так как временный активен в течение 48 часов!

Также из документации certbot я узнал, что при обновлении сертификата можно автоматически перезапускать сервис, который этот сертификат использует. Поэтому используем следующие команды для создания скрипта перезагрузки встроенного в GitLab nginx сервера:

sudo sh -c 'printf "#!/bin/sh\nsudo gitlab-ctl restart nginx\n" > /etc/letsencrypt/renewal-hooks/post/gitlab.sh'
sudo chmod 755 /etc/letsencrypt/renewal-hooks/post/gitlab.sh

Дополнительно ещё хотелось бы описать настройку отправки почты с сервера GitLab. Это понадобится для удобного обновления/сброса пароля, получения уведомлений и возможности регистрации новых пользователей через письмо-приглашение. 

Изначально я планировал создать почту на ранее полученном мною домене k8sl.ru, но когда увидел ценники на внешний хостинг почты в российских и зарубежных сервисах с тарификацией поштучно за почтовый ящик, то решил создать новый бесплатный ящик на mail.ru и использовать его. Единственный момент, на котором я заострю внимание: у mail.ru нужно создавать пароль для внешних приложений. Тут описано, как это сделать. 

Я же просто предоставлю вам пример конфига для GitLab, который в ubuntu находится по пути /etc/gitlab/gitlab.rb (эти настройки подойдут и в другие ваши сервисы, где нужно только отправлять письма):

gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.mail.ru"
gitlab_rails['smtp_port'] = 465
gitlab_rails['smtp_user_name'] = "delta-prj@mail.ru" #вот тут ваш адрес почты
gitlab_rails['smtp_password'] = "введите ваш внешний пароль"
gitlab_rails['smtp_domain'] = "mail.ru"
gitlab_rails['smtp_authentication'] = "login"
gitlab_rails['smtp_enable_starttls_auto'] = false
gitlab_rails['smtp_tls'] = true
gitlab_rails['smtp_pool'] = false


gitlab_rails['smtp_openssl_verify_mode'] = 'peer'

gitlab_rails['gitlab_email_enabled'] = true

gitlab_rails['gitlab_email_from'] = 'delta-prj@mail.ru' #без этих настроек сервер mail.ru не давал отправлять почту, поэтому указываем откуда и от кого приходят письма
gitlab_rails['gitlab_email_display_name'] = 'gitlab.k8sl.ru'
gitlab_rails['gitlab_email_reply_to'] = 'alex.shcherbakov@inbox.ru' #указал куда отвечать на всякий случай

В заключении статьи подытожу, что у меня получилось:

• Приобрести домен, на который можно сделать неограниченное число субдоменов. 

• Перенаправить его на NS сервера Cloudflare, что в итоге позволяет мне использовать API Cloudflare. 

• Описать получение SSL-сертификатов от Let’s Encrypt во внутренней сети с использованием API Cloudflare.

• Установить и настроить GitLab с «вечным» SSL сертификатом и отправкой почты через внешний почтовый сервис. 

По факту, инструкция в статье универсальна, так как по ней можно настроить SSL и почту для большинства сервисов внутри домашней сети.

Для подготовки этой статьи были использованы следующие ресурсы:

• Документация Cloudflare

• Документация по Сertbot

• Статья, описывающая получение SSL через Сertbot и Сloudflare

• Документация по установке GitLab