Свой GitLab: когда облака мало

Картина первая: служба безопасности запретила выкладывать код в публичные облака — в репозитории лежат интеграции с банком и персональные данные клиентов. Картина вторая: GitLab.com лёг ровно в момент пятничного релиза, и команда час сидит, гипнотизируя статус-страницу. Картина третья: посчитали GitHub Enterprise на 30 разработчиков и присвистнули. У всех трёх — общее решение: свой GitLab.

Когда облака мало

Есть три честных причины поднимать self-hosted:

• Compliance и тайна. ПДн, банковский сектор, госконтракты, NDA с заказчиком — код просто не имеет права уезжать наружу.
• Контроль и независимость. Падение чужого SaaS не должно ронять ваши релизы. Свой инстанс лежит, только если вы его уронили.
• Деньги на масштабе. Когда разработчиков становится много, цена на seat в облаке начинает кусаться.

Если ничего из этого не про вас — оставайтесь на GitLab.com или GitHub. Свой инстанс — это сервер, который надо обновлять, бэкапить и чинить. Не бесплатно.

CE или EE

GitLab CE (Community Edition) — бесплатный, с открытым кодом. Покрывает всё, что нужно 90% команд: репозитории, MR, CI/CD, registry, issues, wiki, базовый code review.

GitLab EE (Enterprise Edition) — платный, и оправдан он только если вам реально нужны его фичи: продвинутые роли и approval-rules, security-сканеры из коробки, audit-логи под compliance, multi-region, портфельное планирование. Платить за EE «на вырост» — деньги на ветер. Начните с CE; апгрейд до EE — это смена лицензии, переезд не нужен.

Сколько железа

Минимум для команды до 20 человек:

• 4 vCPU, 8–16 ГБ RAM, SSD от 100 ГБ под данные;
• отдельный диск/том под /var/opt/gitlab — он растёт;
• бэкап-хранилище на другом хосте: бэкап на том же диске — это не бэкап.

Под CI отдельные машины — runner'ы. Сам GitLab задачи не выполняет.

Runner'ы: shared или dedicated

• Shared runner'ы — общие на весь инстанс. Удобно для маленькой команды, но один тяжёлый pipeline блокирует всех.
• Dedicated/group runner'ы — привязаны к проекту или группе. Нужны, когда у команд разные требования (память, GPU, доступы во внутренние сети).
• Docker executor — стандарт. Каждый job в чистом контейнере, никакой грязи между сборками.
• Shell executor — только для очень специфичных кейсов (нативные сборки под конкретное железо). Опасен: засоряет систему и плохо изолирован.

Простейший gitlab-ci, с которого можно начать:

stages: [test, build, deploy]

test:
  stage: test
  image: php:8.4-cli
  script:
    - composer install --no-interaction
    - vendor/bin/pest

deploy:
  stage: deploy
  image: alpine:3
  script:
    - apk add --no-cache openssh-client rsync
    - rsync -az --delete ./ deploy@prod:/var/www/app/
  only: [main]

Дальше уже наслаиваются артефакты, кэш composer/npm, registry, environments, manual approval перед prod.

Бэкапы и обновления

Самое скучное и самое важное.

• Бэкапы. Встроенный gitlab-backup create плюс отдельно копия /etc/gitlab (там ключи и конфиг). Важно: gitlab-backup create не включает /etc/gitlab/gitlab-secrets.json и /etc/gitlab/gitlab.rb — без них восстановление на чистом хосте невозможно (зашифрованные данные останутся нечитаемыми). Хранить минимум в двух местах, проверять восстановлением хотя бы раз в квартал.
• Обновления. GitLab требует строгой последовательности версий при апгрейдах между мажорами. Прыгать через релизы нельзя — сломаются миграции БД. Перед апгрейдом — снапшот VM плюс бэкап. После — проверить runner'ы (их версия должна быть ≤ версии сервера).
• PostgreSQL. Внутри bundle он удобен, но в продакшене лучше вынести во внешний managed-Postgres — проще обновлять и бэкапить.

Развернуть инстанс по официальной инструкции — в среднем полдня; с runner'ами, registry, SSO и резервным копированием — пара дней. Помогу с разворачиванием и сопровождением, если внутри команды нет devops, — особенно полезно на этапе апгрейдов между мажорами, где легко получить нерабочий инстанс.

Что часто забывают

• SSO/LDAP. Подключите сразу — иначе через год будет 80 локальных аккаунтов и непонятно, кто из них уволенный.
• Registry. Включайте сразу — потом мигрировать образы больно.
• Pages. Нужен валидный wildcard-сертификат на отдельный домен.
• Мониторинг. Prometheus-endpoint встроен, подключите к Grafana и поставьте алерты на queue size и время ответа.

Запомнить

• Свой GitLab оправдан compliance'ом, независимостью или экономикой на масштабе. Не «потому что круто».
• CE покрывает большинство задач. EE — только под конкретные фичи.
• Runner'ы вынесены на отдельные машины, docker executor по умолчанию.
• Бэкапы и строгая последовательность мажорных апгрейдов — must.

Если думаете о собственном GitLab или уже есть, но «как-то само живёт» — напишите. Установлю CE/EE с нуля, подниму runner'ы под ваш стек, напишу базовые pipeline'ы и возьму инстанс на сопровождение: бэкапы, обновления, мониторинг.