Введение
Здравствуйте, дорогие друзья! Сегодня хочу поделиться опытом, который был получен за 2 часа изучения того, как развернуть Gitlab и подключить к нему Gitlab Runner из‑под Docker, и всё это на домашней Fedora 44.
Всё то, что было сделано, вызвано желанием немного потыкать и узнать, что из себя представляет Gitlab как для DevOps, так и для QA. При этом я не ограничивал себя в возможностях бесплатной удалённой версии от самого Gitlab.
Хочу заранее извиниться за возможные ошибки: Docker я знаю на уровне написания базовых конфигов в Docker Compose. При этом по всей статье будут присутствовать исключительно команды Docker для поднятия контейнеров и взаимодействия между ними.
Также в статье не расписываю, как установить Docker: если вы это читаете, подразумевается, что у вас он уже есть.
Установка Gitlab
Сама по себе установка Gitlab не имела каких‑либо проблем. Всё прошло по самому стандартному сценарию, за исключением того, что для контейнеров и отдельных проектов я стараюсь создавать пользователя, у которого будут храниться конфигурационные файлы.
sudo useradd gitlab -m -Usudo usermod -aG wheel,docker gitlabsudo su gitlabcd ~
Можно также задать пароль для пользователя, если есть на то необходимость: sudo passwd gitlab
Для хранения конфигураций, логов и данных Gitlab создаю отдельные директории:
mkdir -p /home/gitlab/gitlab_env/configmkdir -p /home/gitlab/gitlab_env/logsmkdir -p /home/gitlab/gitlab_env/data
Также, прежде чем создавать контейнер, следует создать отдельную общую сеть для них:
docker network create gitlab-net
После чего можно спокойно запускать контейнер через:
docker run --detach \ --hostname gitlab.local \ --network gitlab-net \ --publish 7443:443 \ --publish 7080:80 \ --publish 7022:22 \ --name gitlab \ --restart always \ --volume /home/gitlab/gitlab_env/config:/etc/gitlab:Z \ --volume /home/gitlab/gitlab_env/logs:/var/log/gitlab:Z \ --volume /home/gitlab/gitlab_env/data:/var/opt/gitlab:Z \ gitlab/gitlab-ee:latest
Обратите внимание на --hostname gitlab.local — на адрес gitlab.local нас будет периодически перенаправлять. Данную проблему мы решим через Nginx‑проксирование и указание хоста для локального доступа. Учтите также, что внутри другого контейнера в той же сети обращение к этому контейнеру будет по доменному имени gitlab.
gitlab.local, Nginx и хост
Давайте заранее закроем проблему перенаправления на адрес gitlab.local. Первое, что мы сделаем, — это добавим запись в hosts для локальной сети:
sudo /etc/hosts/
В файле находим 127.0.0.1 и ::1 — в конец добавляем gitlab.local.
Файл может иметь следующий вид:
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 gitlab.local::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 gitlab.local
Зачем мы это сделали: чтобы все запросы по адресу gitlab.local шли через локальную сеть.
Теперь нам необходимо сделать проксирование запросов внутрь контейнера. Чисто технически это не обязательно, но, как показала практика, лучше сделать, чем мучиться.
Для начала установим Nginx:
sudo dnf install nginx
После создаём конфигурационный файл для проксирования запросов. Для меня стало удивлением, что структура nginx отличается от обычной и выглядит следующим образом:
drwxr-xr-x. 1 root root 444 июн 19 19:18 .drwxr-xr-x. 1 root root 5434 июл 5 22:40 ..drwxr-xr-x. 1 root root 0 июл 5 19:46 conf.ddrwxr-xr-x. 1 root root 0 мая 22 03:00 default.d-rw-r--r--. 1 root root 1077 мая 22 03:00 fastcgi.conf-rw-r--r--. 1 root root 1077 мая 22 03:00 fastcgi.conf.default-rw-r--r--. 1 root root 1007 мая 22 03:00 fastcgi_params-rw-r--r--. 1 root root 1007 мая 22 03:00 fastcgi_params.default-rw-r--r--. 1 root root 2837 мая 22 03:00 koi-utf-rw-r--r--. 1 root root 2223 мая 22 03:00 koi-win-rw-r--r--. 1 root root 38661 янв 16 03:00 mime.types-rw-r--r--. 1 root root 5349 мая 22 03:00 mime.types.default-rw-r--r--. 1 root root 1990 июн 19 19:18 nginx.conf-rw-r--r--. 1 root root 2630 мая 22 03:00 nginx.conf.default-rw-r--r--. 1 root root 636 мая 22 03:00 scgi_params-rw-r--r--. 1 root root 636 мая 22 03:00 scgi_params.default-rw-r--r--. 1 root root 664 мая 22 03:00 uwsgi_params-rw-r--r--. 1 root root 664 мая 22 03:00 uwsgi_params.default-rw-r--r--. 1 root root 3611 мая 22 03:00 win-utf
Нам для проксирования нужно создать конфигурационный файл внутри директории /etc/nginx/conf.d:
sudo nano /etc/nginx/conf.d/docker_gitlab.conf
И заполняем его:
upstream backend { server 127.0.0.1:7080;}server { listen 80; server_name gitlab.local; location / { proxy_pass http://backend; proxy_set_header Host $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-Proto $scheme; }}
После чего перезапустим nginx:
sudo systemctl restart nginx
Результатом всех этих действий мы обеспечиваем гарантию, что при запросе в браузере на http://gitlab.local/ мы попадём на веб‑интерфейс Gitlab на страницу входа или увидим:
Подготовка к Runners
После всех этих действий следует зайти на Gitlab. Для этого нужно получить пароль от root‑пользователя, который мы будем временно использовать:
docker exec gitlab cat /etc/gitlab/initial_root_password
После чего мы можем увидеть наш пароль и зайти в систему под пользователем root; нас попросят внести данные и создать первый проект.
Когда мы находимся непосредственно в веб‑интерфейсе, переходим в наш проект, который мы создали:
После того как мы перешли к самому проекту, открываем боковое меню, настройки и CICD. Создаём Runner:
Нажимаем «Create projet runner» для создания и настраиваем. Для упрощения задачи демонстрации поставлю галочку напротив Run untagged jobs (Запускать задачи без тегов) и создам runner, нажав кнопку внизу страницы.
После чего мы попадаем на страницу с мануалом, в котором следует запомнить исключительно токен. На этом первый этап настройки нашего Gitlab + Gitlab Runner закончился.
Gitlab Runner в Docker
Сразу скажу: из‑за специфики дистрибутива Fedora и активного использования SELinux внутри него мы сталкиваемся с проблемами, которые я не смог решить, не отключив защиту в целом. Если у вас есть идеи, как можно улучшить ситуацию и не отключать SELinux, то прошу дайте знать, как именно это сделать.
Поначалу у нас всё будет достаточно просто: нам просто следует создать директорию для конфигураций и запустить контейнер для gitlab‑runner:
mkdir -p /home/gitlab/gitlab-runner/configdocker run -d \ --name gitlab-runner \ --restart always \ --network gitlab-net \ -v /home/gitlab/gitlab-runner/config:/etc/gitlab-runner:Z \ -v /var/run/docker.sock:/var/run/docker.sock:z \ gitlab/gitlab-runner
После чего начинаем регистрацию нашего бегунка:
docker exec -it gitlab-runner gitlab-runner register
В URL вводим: http://gitlab/ — так как обращение будет происходить через Docker‑сеть, далее токен и остальные настройки по желанию.
Далее мы рассмотрим, какие изменения нужно внести в конфигурации. Переходим в сам файл:
sudo nano /home/gitlab/gitlab-runner/config/config.toml
В секцию [[runners]] следует добавить clone_url = "http://gitlab/" — это необходимо для того, чтобы runner не использовал адрес который ему отдает сам Gitlab и обращался по адресам, определённым внутри сети Docker.
Если у вас есть секция [runners.docker], в ней следует добавить network_mode = "host", чтобы создаваемые контейнеры использовали сеть контейнера gitlab‑runner и могли обращаться к репозиториям, и extra_hosts = ["gitlab:host-gateway"] для подстановки IP‑адреса через ключевое слово host-gateway. В конечном итоге файл будет выглядеть примерно следующим образом:
concurrent = 1check_interval = 0shutdown_timeout = 0[session_server] session_timeout = 1800[[runners]] name = "684cccc2538a" url = "http://gitlab/" clone_url = "http://gitlab/" id = 3 token = "your-token-here" token_obtained_at = 2026-07-05T21:25:19Z token_expires_at = 0001-01-01T00:00:00Z executor = "docker" [runners.cache] MaxUploadedArchiveSize = 0 [runners.cache.s3] AssumeRoleMaxConcurrency = 0 [runners.cache.gcs] [runners.cache.azure] [runners.docker] tls_verify = false image = "some-image:lastes" network_mode = "host" extra_hosts = ["gitlab:host-gateway"] privileged = false disable_entrypoint_overwrite = false oom_kill_disable = false disable_cache = false volumes = ["/cache"] volume_keep = false shm_size = 0 network_mtu = 0
После всего этого в репозиторий проекта добавьте файлик .gitlab-ci.yml:
# .gitlab-ci.yml# Простая проверка работоспособности Runner# ==================== Проверка Runner ====================runner-health-check: stage: .pre tags: - your-runner-tag # ← укажите тег вашего раннера (или уберите, если untagged) script: - echo "Runner work!" - echo "CI_COMMIT_SHA $CI_COMMIT_SHA" - echo "CI_PIPELINE_ID $CI_PIPELINE_ID" - echo "Runner hostname $(hostname)" - uname -a - cat /etc/os-release || echo "OS info not available" - echo "Docker allowed?" && (docker --version && echo "Docker work" || echo "Docker not found") - echo "Check success complete!" artifacts: paths: - runner-check.log when: always after_script: - echo "Runner health check finished at $(date)" > runner-check.log
Это нужно для базовой проверки, жив ли у нас runner в контейнере. Если он прошёл, значит, базовых проблем не будет. Если появились проблемы, чаще всего они связаны с SELinux. Чтобы проверить, так ли это, в терминале введите sudo setenforce 0 и повторно запустите тестирование.
В конечном итоге у нас должен появиться артефакт: runner-check.log говорящий, что тест пройден успешно.
Результат и вывод
В результате всех этих действий у нас есть Gitlab и также работающие Runners для запуска pipeline на локальной машине. Что очень удобно для дальнейшего изучения DevOps или QA‑направлений, связанных с работой через Gitlab.
Основные проблемы доставляет SELinux, используемый в Fedora. К примеру, я не нашёл решения проблемы с доступом к docker.sock, и без отключения SELinux постоянно получал ошибку:
ERROR: Failed to remove network for buildERROR: Preparation failed: getting docker info: permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.51/info": dial unix /var/run/docker.sock: connect: permission denied (docker.go:1287:0s)
Буду рад попробовать решения, которые предложите вы со своей стороны, чтобы не отключать SELinux.
ссылка на оригинал статьи https://habr.com/ru/articles/1058480/