GitLab является одним из самых популярных инструментов для создания полноценного конвейера Ci/CD. Про GitLab написано множество статей и книг, однако большинство из них посвящены использованию этого решения в облачной среде на базе gitlab.com или других облачных провайдеров.
Но очень часто разработчикам хочется иметь собственный конвейер CI/CD, не связанный ни с какими внешними сервисами. Это может быть обусловлено различными требованиями, например мы очень боимся что наш код и артефакты могут быть скомпрометированы злоумышленниками или мы хотим полностью локальную среду разработки и тестирования по другим причинам. Так или иначе нам необходим свой локальный GitLab. Здесь конечно лучше развернуть решение на виртуальных машинах или в аппаратной конфигурации, но как правило, подобные действия требуются определенных затрат времени.
Однако, бывают ситуации, когда конвейер нужно развернуть быстро, например когда есть проблемы с работой основного конвейера и нужно что‑то срочно собрать. Или нужно что‑то проверить в конфигурации, но не хочется трогать основной конвейер. В моем случае необходимо было развернуть GitLab для демонстрации возможностей CI/CD.
Здесь нам на помощь приходят контейнеры. На просторах сети можно найти несколько вариантов развертывания GitLab из образов Docker, но удобнее всего воспользоваться Docker Compose.
Просто загрузим YAML файл:
wget https://raw.githubusercontent.com/sameersbn/docker-gitlab/master/docker-compose.yml
А вот набирать docker‑compose up пока не будем, так как если это сделать, то потом мы столкнемся с разными странностями в работе нашего GitLab. Вместо этого откроем в редакторе docker‑compose.yml блок параметров:
…
gitlab:
restart: always
image: sameersbn/gitlab:17.11.0
depends_on:
- redis
- postgresql
ports:
- "10080:80"
- "10022:22"
volumes:
- gitlab-data:/home/git/data:Z
healthcheck:
test: ["CMD", "/usr/local/sbin/healthcheck"]
interval: 5m
timeout: 10s
retries: 3
start_period: 5m
environment:
- DEBUG=false
…Заменим в разделе ports порт 10 080:80 на любой другой, например 10 088:80. Дело в том, что все современные браузеры очень не любят порт 10 080 после того, как в 2021 году хакеры использовали его для атаки NAT Slipstreaming. Также далее в файле найдем параметр — GITLAB_PORT=10 080 и также заменим номер порта на 10 088.
Следующим шагом нам нужно заменить значение GITLAB_HOST на IP адрес или DNS имя узла, на котором будут разворачиваться контейнеры. Если оставить localhost то при обращении к нашему GitLab из сети у нас периодически будут возникать сложности при выполнении различных задач, так как он будет в некоторые запросы подсовывать значение localhost.
Сохраним изменения и выполним:
$ docker-compose up
Первый запуск займет несколько минут, так как контейнеры довольно тяжелые. В итоге мы должны увидеть следующее:
Далее мы будем настраивать GitLab в браузере. Откройте HTTP страницу по адресу вашего узла Docker и порту 10 088.
Дальше все в целом должно быть знакомо всем тем, кто уже работал с GitLab. Ну а для новичков расскажем, что делать при первом запуске.
В открывшемся окне вам предлагается указать пароль для учетной записи root в GitLab. Эта основной административный аккаунт и с ним надо быть аккуратнее.
Разворачиваем runner
В рамках данной статьи я не буду глубоко уходить в вопросы администрирования GitLab, так как наша задача сейчас не в этом. Вместо этого мы подключим еще один узел на котором наш конвейер будет выполнять сборки.
Сейчас мы развернули только саму систему GitLab, но у нас нет узлов, на которых мы можем выполнять задачи из нашего пайплайна.
Для того, чтобы развернуть runner нам нужно сначала создать проект. Не очень хорошая идея выполнять какие‑либо задачи кроме административных из под учетки root, поэтому сначала создадим еще одного пользователя user1.
Для этого нажимаем кнопочку Admin.
Дальше выбираем Users → New user и заполняем необходимые поля. После этого перелогиниваемся под данным пользователем.
Теперь нам необходимо создать новый проект, для этого нажимаем New Project в правом верхнем углу. Далее нам предлагается выбрать какой проект нужно создать. Выбираем blank project.
Далее указываем имя и область видимости. После создания проекта переходим в него. Далее нам нужно создать runner. Для этого выбираем в левом нижнем углу Settings и далее CI/CD.
В открывшемся списке выбираем Runners и New Project Runner.
После этого нам нужно определиться с теми настройками, которые будут использоваться нашим runner. В зависимости от тех задач, которые вы собираетесь выполнять, вы можете указать теги для задач и другие параметры.
После нажатия Create Runner нам будет предложено выбрать операционную систему, на которой будет работать наш runner. Выбираем Linux и копируем ту команду с параметрами, которую он нам предлагает.
Останемся верны идеям контейнеризации и запустим runner тоже из контейнера. На этот раз у нас контейнер всего один и docker compose нам не потребуется. Запустим его:
docker run -d gitlab/gitlab-runner
В моем примере мы будем использовать контейнер в качестве runner поэтому после того, как он успешно запустился зайдем в него:
docker exec -it ID_контейнера /usr/bin/bash
Далее в этом контейнере выполним скопированную ранее из веб интерфейса GitLab команду. Затем последовательно отвечаем на вопросы. В своем примере я выбрал самый простой вариант исполнителя — shell, но возможно для ваших задач потребуется другой тип исполнителя.
После завершения регистрации выполним:
$ gitlab-runner run
Далее возвращаемся в веб интерфейс GitLab. Наш новый runner Должен быть зеленым.
Мы выполнили базовые настройки вашего конвейера, далее вы можете настраивать пайплайн, работать с версиями кода и делать многое другое. Согласитесь, наш процесс базового развертывания занял не очень много времени.
Заключение
В этой небольшой статье мы рассмотрели развертывание GitLab и GitLab runner из образов Docker. Мы специально не погружались в вопросы администрирования, ограничившись лишь набором базовых действий, которые необходимо выполнить для создания проекта и регистрации runner.
Таким образом, вы можете без лишних затрат, достаточно быстро развернуть готовый к использованию конвейер CI/CD.
Если хотите углубиться в современные подходы к развёртыванию и управлению инфраструктурой — присоединяйтесь к практическим занятиям в Otus. Никакой воды: только разбор ключевых инструментов и реальных задач.
GitOps практики. Развертываем сервис через ArgoCD — Разберёмся, как работает ArgoCD и научимся шаг за шагом запускать сервисы. 7 мая в 20:00
Роль и задачи DevOps в современном IT — Поговорим о трендах, инструментах и разнице между DevOps, SRE и Platform Engineering. 22 мая в 20:00