Как мы развернули GitLab CI/CD на Timeweb Cloud

CI/CD давно стало стандартом в разработке. Когда процессы автоматизированы, код быстрее проходит путь от коммита до продакшена, а вероятность ошибок снижается. GitLab удобен тем, что объединяет в себе репозитории, задачи и пайплайны в одном инструменте.

Чтобы внедрить GitLab CI/CD, нужна инфраструктура, которая выдержит нагрузку, позволит масштабироваться и не усложнит администрирование. Разберем деплой на примере Timeweb Cloud. 

В этой статье мы разберем:

• какую инфраструктуру выбрать под GitLab и раннеры;
• как установить и настроить GitLab;
• как подключить раннеры и запустить первые пайплайны;

Материал подойдет DevOps-инженерам и администраторам, которым интересен практический сценарий развертывания GitLab CI/CD в облаке.

cloud

Выбор инфраструктуры

Для стабильной работы GitLab и CI/CD-процессов лучше разделять сервисы по разным виртуальным машинам. GitLab сам по себе достаточно ресурсоемкий: он хранит репозитории, управляет интерфейсом и обрабатывает пайплайны. Если запускать на том же сервере и раннеры, нагрузка во время сборок может привести к падению или замедлению работы всей системы. Поэтому очень часто выделяют отдельный сервер под GitLab и отдельные инстансы под раннеры.

Далее мы рассмотрим пример — какую инфраструктуру мы выбрали для CI/CD в Timeweb Cloud.

Основной сервер с GitLab мы поставили на конфигурации с 8 vCPU, 12 GB RAM и SSD 100 GB. Этого достаточно для небольшой команды, где параллельно работает несколько проектов. В дальнейшем ресурсы можно увеличить — в облаке это делается без переноса системы. Для резервного копирования удобно подключить дополнительный диск или настроить выгрузку на отдельное хранилище.

Отдельные раннеры мы подняли на более легких инстансах: 2 vCPU, 4 GB RAM и 50 GB SSD. Такой конфигурации хватает для запуска типовых задач: линтинга, юнит-тестов, сборки контейнеров. Один раннер работает постоянно, еще один можно подключать при росте нагрузки. Timeweb Cloud позволяет быстро клонировать виртуальные машины, поэтому добавить новый раннер занимает считанные минуты.

Дополнительно можно развернуть окружения для staging и production прямо в облаке. В этом случае пайплайны будут доставлять приложение на выделенные инстансы, и деплой станет полностью автоматическим. Такой вариант подходит командам, у которых нет собственной инфраструктуры или есть потребность в быстром масштабировании.

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

Схема архитектуры GitLab CI/CD в облаке: отдельный сервер GitLab, раннеры для выполнения задач и опциональные окружения staging/production.

Установка и настройка GitLab

В Timeweb Cloud пользователи могут создавать облачные серверы, используя готовые образы из Маркетплейса. Один из таких образов — GitLab. Благодаря этому процесс установки не требует вмешательства инженера, всё происходит автоматически. 

Чтобы развернуть такой облачный сервер, в панели Timeweb Cloud перейдите на страницу создания нового облачного сервера, на шаге «Образ» выберите «Маркетплейс», нажмите на GitLab. Далее выберите необходимую конфигурацию и нажмите кнопку «Заказать». Через несколько минут сервер станет доступен, а пока можно привязать домен к серверу.  

Получение и привязка домена к серверу

GitLab можно запустить и по IP-адресу, но в реальной работе почти всегда используют домен. Во-первых, так удобнее: проще запомнить и передавать адрес вроде gitlab.company.ru, чем каждый раз вводить числовой IP. Во-вторых, домен необходим для выпуска SSL-сертификата и работы по HTTPS. Это критично для безопасности: GitLab хранит пароли, токены и ключи, и передавать их в открытом виде по HTTP небезопасно.

Кроме того, многие интеграции — вебхуки, авторизация через внешние сервисы, подключение IDE — требуют защищенного подключения по HTTPS. Без домена и сертификата часть функционала просто не будет работать.

Поэтому даже для небольшой команды лучше сразу привязать GitLab к домену и включить HTTPS. Это избавит от проблем с безопасностью и интеграциями в будущем.

Домен можно приобрести, в том числе, внутри Timeweb Cloud, и сразу привязать его к серверу. Все функции по управлению доменами находятся на вкладке «Домены и SSL» в панели управления. Для привязки домена к серверу создайте A-запись для поддомена gitlab.<ваш_домен>.<зона_домена> с IP-адресом сервера. Если работаете внутри Timeweb Cloud, то используйте инструкцию. 

Привязка домена к GitLab и настройка конфигурации

В Omnibus GitLab есть встроенный NGINX. Чтобы он корректно обслуживал домен по HTTPS, нужно изменить конфиг:

1. Откройте файл настроек:

sudo nano /etc/gitlab/gitlab.rb

2. Найдите параметр external_url и задайте значение со своим доменом.

external_url "https://gitlab.example.com"

Это ключевая строка: именно по external_url GitLab понимает, какой домен и протокол использовать.

3. Для SSL можно выбрать два варианта:

   • Автоматический сертификат Let’s Encrypt (проще всего):

letsencrypt['enable'] = true
letsencrypt['contact_emails'] = ['admin@example.com'] # почта для уведомлений
letsencrypt['auto_renew'] = true

• • Свой сертификат (если у вас есть .crt и .key):

nginx['ssl_certificate'] = "/etc/gitlab/ssl/gitlab.example.com.crt"
nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/gitlab.example.com.key"

Файлы нужно заранее скопировать в /etc/gitlab/ssl/ (директорию создать вручную через mkdir /etc/gitlab/ssl).

4. Примените изменения:

sudo gitlab-ctl reconfigure

Через несколько минут GitLab станет доступен по адресу указанному адресу. При переходе по ссылке вы увидите экран авторизации в GitLab:

Данные для входа находятся на странице сервера в панели управления Timeweb Cloud.

Подключение раннеров GitLab

Раннер — это агент, который выполняет задачи пайплайнов. GitLab сам по себе только управляет процессами, а запуск сборок и тестов происходит на разных раннерах. Чтобы система работала стабильно, их разворачивают на отдельных серверах. Это позволяет избежать ситуации, когда тяжелая сборка замедляет работу веб-интерфейса или репозиториев.

Мы установили раннер на отдельный инстанс в Timeweb Cloud с конфигурацией 2 vCPU, 4 ГБ RAM и диском на 50 ГБ. Такой сервер достаточно легкий, но хорошо справляется с линтингом, тестами и сборкой контейнеров. Если нагрузка возрастает, можно быстро запустить дополнительный Runner — в облаке это занимает несколько минут.

Установка раннера

Существует несколько способов установки GitLab Runner: через пакетный менеджер (apt, yum), бинарный файл или запуск в контейнере. В этой инструкции мы используем вариант с Docker и Docker Compose, так как он наиболее удобен для быстрого развёртывания и изоляции среды.

На сервер установите Docker и Docker Compose:

curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh

Дождитесь завершения выполнения команды. 

Чтобы Dockerhub, откуда скачиваются образы приложений, не блокировал ваш трафик, используйте прокси от Timeweb Cloud. Подробнее об этом пишем на странице по ссылке, а поставить его на сервер можно одной командой:

touch /etc/docker/daemon.json && echo "{ \"registry-mirrors\" : [ \"https://dockerhub.timeweb.cloud\" ] }" > $_ && systemctl reload docker

Далее создайте том для хранения конфигурации:

docker volume create runner1

Далее запускаем контейнер с Runner:

docker run -d --name gitlab-runner1 --restart always \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v runner1:/etc/gitlab-runner \
  gitlab/gitlab-runner:latest

После этого контейнер должен появиться в списке активных:

docker ps

Регистрация раннера

Чтобы раннер начал работать, зарегистрируйте его в GitLab. Сперва перейдите на страницу  https://<домен_gitlab>/admin/runners, нажмите на кнопку «Create instance runner», для тестирования поставьте галочку напротив пункта «Run untagged jobs» и нажмите на кнопку «Create runner». Не закрывайте страницу — на ней находится регистрационный токен, который понадобится дальше. 

Теперь введите команду на сервере раннера:

docker run --rm -it -v runner1:/etc/gitlab-runner gitlab/gitlab-runner:latest register

Во время регистрации укажите:

• URL GitLab — адрес вашего сервера, например https://gitlab.example.com;
• Token — регистрационный токен, который получили на странице регистрации чуть ранее;
• Name — нажмите Enter, чтобы оставить имя по умолчанию;
• Executor — среда выполнения задач. Мы выбрали docker;
• Docker-образ — базовый образ, в котором будут выполняться задачи, например python:3.10-slim.

После этого Runner появится в списке активных в настройках проекта.

CI/CD pipeline на практике

Когда GitLab и Runner настроены, следующий шаг — описать процесс сборки и доставки кода. Для этого в корне проекта создается файл .gitlab-ci.yml. В нем задаются стадии (stages) и шаги (jobs), которые Runner будет выполнять автоматически при каждом коммите.

Минимальный пример пайплайна включает три этапа: линтинг, тесты и сборку контейнера. Дополнительно можно добавить шаг деплоя на staging или production.

Создайте новый репозиторий, перейдя по ссылке вида:

https://<домен_gitlab>/projects/new#blank_project

Введите любое название проекта и нажмите на кнопку «Create project». Перейдите на страницу редактирования пайплайна — для этого перейдите на вкладке Build (1) выберите Pipeline editor (2). 

Далее нажмите на кнопку «Configure pipeline» — GitLab по умолчанию выдаст пример из трех стадий: сначала выполняется сборка проекта, затем параллельно запускаются юнит-тесты и линтер, а после их успешного завершения выполняется деплой. Все шаги имитируются командами echo и sleep, но структура отражает реальный процесс: задачи разбиты по стадиям, стадии выполняются последовательно, а внутри стадии джобы могут идти одновременно.

Для продолжения нажмите на кнопку «Commit changes» и нажмите на номер процесса пайплайна, чтобы посмотреть его прогресс. 

Через некоторое время на странице появится значок «Passed» — это значит, что пайплайн отработал верно. 

Пайплайн, в котором успешно выполнены стадии build, test и deploy

Теперь, когда базовая настройка завершена, вы можете строить собственные пайплайны под нужды проекта. В .gitlab-ci.yml легко описать любую последовательность шагов: от проверки кода и прогонки тестов до сборки Docker-образов, публикации артефактов и автоматического выката приложения в staging или production. GitLab поддерживает множество интеграций и готовых образов, поэтому ограничений практически нет — всё зависит только от требований команды и фантазии инженера.

Автоматизация и масштабирование

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

Самая распространенная задача — масштабирование раннеров. Когда разработчиков становится больше и пайплайны запускаются чаще, один сервер перестает справляться. В Timeweb Cloud можно быстро поднять новый инстанс и зарегистрировать его как раннер, а для больших команд — настроить авто-масштабирование. В этом случае дополнительные виртуальные машины запускаются только тогда, когда очередь заданий растет, и останавливаются после снижения нагрузки. Такой подход позволяет экономить ресурсы и платить только за используемые мощности.

Не менее важно предусмотреть резервное копирование. GitLab хранит код, настройки проектов и артефакты пайплайнов — потеря этих данных критична. В GitLab есть встроенные средства бэкапа, которые сохраняют данные в архив. В Timeweb Cloud удобно подключить отдельный диск или использовать объектное хранилище для регулярных резервных копий.

Еще один момент — обновления. GitLab активно развивается, и новые версии выходят регулярно. Чтобы получать исправления безопасности и новые функции, стоит обновлять систему по официальной инструкции. Обычно это не требует ручной перенастройки: достаточно выполнить команду обновления и перезапустить сервис.

Таким образом, автоматизация и масштабирование позволяют поддерживать GitLab CI/CD в рабочем состоянии без постоянного ручного вмешательства: при необходимости подключать новые раннеры, гарантировать сохранность данных и своевременно обновлять систему.

Разверните GitLab на собственном облачном сервере

Заключение

GitLab CI/CD в облаке — это удобный и гибкий инструмент, который позволяет командам автоматизировать весь цикл разработки: от проверки кода до выката в продакшен. Правильная архитектура — ключ к стабильной работе. Если GitLab работает отдельно, раннеры масштабируются под нагрузку, а резервные копии и обновления выполняются регулярно, система остается надежной и предсказуемой.

В результате разработчики получают прозрачный и безопасный процесс доставки кода, а администраторы — управляемую систему, которую можно масштабировать и развивать вместе с командой. Такой подход снимает рутину, снижает риски и позволяет сосредоточиться на главном — качестве продукта и скорости его выхода на рынок.