GitLab — основы, возможности и CI/CD

Что такое GitLab?

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

История GitLab началась в 2011 году как внутренний проект украинских разработчиков. Первая публичная версия вышла в сентябре 2011 года, а в 2015 году GitLab стал первым проектом на GitLab.com, запустив облачный хостинг. В 2017 году GitLab совершил болезненный, но показательный миграционный процесс — перенос всей инфраструктуры из Azure в Google Cloud, который был проведён в прямом эфире и задокументирован в серии постов.

Архитектура GitLab состоит из трёх основных компонентов: GitLab Rails (веб-приложение на Ruby on Rails), GitLab Shell (обработка Git-операций через SSH) и Gitaly (gRPC-сервер для доступа к Git-данным). CI/CD обеспечивается через GitLab Runner — отдельное приложение, которое устанавливается на серверах сборки и выполняет jobs в изолированных окружениях (Docker, Kubernetes, VirtualBox).

GitLab CI/CD: пайплайны и раннеры

GitLab CI/CD — это встроенная система непрерывной интеграции и доставки, которая является ключевым преимуществом платформы. В отличие от GitHub Actions, GitLab CI/CD был заложен в архитектуру с самого начала и не требует отдельной настройки: каждый проект автоматически получает CI/CD после добавления файла .gitlab-ci.yml в корень репозитория.

Пайплайн (pipeline) состоит из стадий (stages), которые выполняются последовательно или параллельно: build → test → deploy. Каждая стадия содержит один или несколько job, которые выполняются на раннерах. Если один job в стадии завершился ошибкой, вся стадия помечается как failed, и последующие стадии не запускаются по умолчанию. Ниже приведён пример пайплайна для мобильного проекта:

# .gitlab-ci.yml
stages:
  - build
  - test
  - deploy

build-android:
  stage: build
  image: openjdk:17-jdk
  script:
    - ./gradlew assembleDebug
  artifacts:
    paths:
      - app/build/outputs/

unit-tests:
  stage: test
  script:
    - ./gradlew testDebugUnitTest

deploy-firebase:
  stage: deploy
  script:
    - firebase appdistribution:distribute app.apk

GitLab Runner поддерживает несколько executor (исполнителей): Docker (рекомендуется), Kubernetes, SSH, VirtualBox и Parallels. Самый популярный вариант — Docker-исполнитель, который запускает каждый job в отдельном контейнере. Runner можно зарегистрировать как специфичный для одного проекта или как общий (shared) для всей группы. GitLab.com предоставляет бесплатные shared раннеры с ограничением в 2000 минут в месяц.

Продвинутые возможности CI/CD

GitLab CI/CD поддерживает ручной запуск (when: manual), отложенный запуск (when: delayed), параллельное выполнение (parallel: 5), матрицу (matrix), динамические пайплайны (child pipelines) и многоуровневые пайплайны (parent-child). Это позволяет строить сложные сценарии: например, динамически генерировать пайплайн для каждого модуля в монорепозитории или запускать параллельные сборки для разных архитектур Android (arm64, x86_64).

GitLab против GitHub: ключевые отличия

GitLab и GitHub — два главных конкурента на рынке Git-платформ, но их философия и архитектура принципиально различаются. GitHub делает ставку на открытое сообщество, экосистему интеграций и социальные функции (форки, звёзды). GitLab фокусируется на комплексном DevOps-цикле и предоставляет все инструменты из коробки: от планирования до мониторинга.

Основное архитектурное различие: GitLab — это единое монолитное приложение, которое разработчик устанавливает целиком. Все функции (CI/CD, Container Registry, Security Scanning, Pages) встроены и работают сразу после установки. GitHub — это платформа с API, где большинство функций реализуется через интеграцию со сторонними сервисами: Travis CI, CircleCI, Jenkins, SonarQube. Таблица ниже сравнит ключевые характеристики:

Выбор между GitLab и GitHub зависит от потребностей команды. Если приоритет — быстрое развёртывание с нулевой конфигурацией и открытое сообщество — выбирайте GitHub. Если необходимо полное управление инфраструктурой, самописный хостинг и встроенная безопасность — GitLab предпочтительнее. По данным опроса Stack Overflow (2024), GitHub используют 90% разработчиков, GitLab — 33% (часто обе платформы одновременно).

Self-Managed GitLab: установка на свой сервер

Self-Managed GitLab (ранее On-Premises) позволяет установить платформу на собственный сервер и получить полный контроль над данными, инфраструктурой и аптаймом. Это особенно важно для организаций с требованиями комплаенса: финансовый сектор, государственные учреждения, медицинские организации, где данные не могут храниться на сторонних серверах.

Установка GitLab поддерживается на Ubuntu, Debian, CentOS и через Docker. Официальный Omnibus-пакет включает все компоненты: веб-сервер (NGINX), базу данных (PostgreSQL), кэш (Redis), обработчик Git (Gitaly) и фоновые процессы. Минимальные требования: 4 ГБ RAM и 2 CPU для команды до 100 человек. Для крупных инсталляций с высокой нагрузкой рекомендуется разделение компонентов на отдельные серверы.

# Установка GitLab CE на Ubuntu через Omnibus
curl -LO https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh
sudo bash script.deb.sh

# Установка пакета
sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ce

# Просмотр статуса
sudo gitlab-ctl status
sudo gitlab-ctl tail

Self-Managed GitLab не имеет ограничений по минутам CI/CD — все раннеры принадлежат организации, и их мощность ограничена только собственным железом. Также доступны Geo-репликация для регионов, аудит-логи, блокировка по IP и интеграция с корпоративными LDAP/SAML-провайдерами. GitLab выпускает обновления каждый месяц (22-го числа) с новыми функциями и исправлениями безопасности.

Встроенные инструменты безопасности GitLab

Безопасность в GitLab встроена на уровне платформы и включает несколько сканеров, работающих на каждом этапе пайплайна. SAST (Static Application Security Testing) анализирует исходный код на наличие уязвимостей без выполнения приложения, поддерживая более 15 языков, включая Java, Kotlin, Swift, Python и JavaScript. DAST (Dynamic Application Security Testing) тестирует запущенное веб-приложение на уязвимости изнутри.

Дополнительные инструменты: Container Scanning проверяет Docker-образы на уязвимости в базовых слоях; Dependency Scanning анализирует зависимости проекта и предупреждает об известных CVE; Secret Detection находит случайно закоммиченные ключи API, пароли и токены; Fuzz Testing выполняет автоматическое тестирование с некорректными данными для поиска неочевидных багов. Все результаты сканирования отображаются в едином Security Dashboard.

GitLab также предоставляет Compliance — инструменты для соблюдения регуляторных требований. Compliance Dashboard показывает статус соответствия всех проектов, Audit Events логирует каждое действие администратора и разработчика, а Compliance Frameworks позволяют принудительно применять политики конфигурации для определённых групп проектов. Это делает GitLab популярным выбором в корпоративных средах с жёсткими требованиями безопасности.

Container Registry и Dependency Proxy

GitLab Container Registry — это встроенный Docker-реестр, интегрированный с CI/CD. После сборки Docker-образа в пайплайне его можно сразу опубликовать в Registry, используя переменные окружения CI_REGISTRY и CI_REGISTRY_USER. Registry поддерживает pull-through кэширование, тегирование, политики очистки и scanning на уязвимости прямо в реестре.

Dependency Proxy — механизм кэширования контейнеров и образов из внешних регистров (Docker Hub, Quay, GCR). Когда пайплайн запрашивает образ ubuntu:latest, GitLab сначала проверяет свой кэш — если образ уже загружен, он не скачивается повторно. Это снижает нагрузку на внешние реестры, ускоряет пайплайны и защищает от rate-лимитов Docker Hub.

Для мобильных разработчиков GitLab предоставляет GitLab Pages для хостинга документации и отчётов тестирования. После прогона тестов артефакты (HTML-отчёты, скриншоты, логи) можно опубликовать как Pages и получить ссылку для отправки QA-команде. Это удобнее, чем загружать отчёты в облачное хранилище, так как всё размещается в рамках того же GitLab-проекта.

GitLab API и Webhooks

GitLab API (REST и GraphQL) предоставляет доступ ко всем ресурсам платформы: проекты, пользователи, пайплайны, Merge Request, реестр. API используется для автоматизации: создать проект по шаблону, назначить ревьюера, получить статус пайплайна. Webhooks позволяют отправлять HTTP-уведомления во внешние системы при событиях: push, merge, создание Issue. Webhooks интегрируются с Mattermost, Slack, Telegram и внутренними мониторинговыми системами.

GitLab Pages для мобильной документации

GitLab Pages автоматически публикует статические сайты из репозитория. Для мобильных проектов Pages удобен для размещения документации к API, отчётов о покрытии тестами и результатов lint-анализа. Публикация происходит автоматически после успешного пайплайна — достаточно указать в .gitlab-ci.yml шаг deploy с публикацией в Pages. Результат доступен по адресу https://namespace.gitlab.io/project-name.