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 в корінь репозиторію.

Пайплайн складається зі стадій, які виконуються послідовно або паралельно: 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 кешування, тегування, політики очищення та сканування на вразливості прямо в реєстрі.

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.