Установка GitLab CE на свой сервер: внедрение CI/CD под ключ

Каждый раз, когда очередной разработчик увольняется, а его логин от корпоративного GitHub остаётся привязан к личной почте, я вижу, как владелец бизнеса теряет контроль над собственным продуктом. Код компании годами живёт в чужом облаке — GitHub, GitLab.com, Bitbucket, — и однажды это облако может заблокировать аккаунт, поднять цену в валюте или просто оказаться недоступным. Я, Евгений Семёнов, руководитель «АйТи-Фреш», делаю установку GitLab CE на сервере клиента так, чтобы код, история коммитов и пайплайны сборки принадлежали бизнесу, а не сервису за океаном.

Почему код в чужом облаке — это риск, а не удобство

У одного клиента — цифровое агентство на 18 человек — весь код жил в приватных репозиториях на Bitbucket, а деплой на прод шёл руками через FTP по вечерам, потому что «так исторически сложилось». Однажды система безопасности заблокировала аккаунт компании на пять дней: вход зафиксировали из другой страны, где как раз был в командировке технический директор. Все репозитории оказались недоступны, хотфикс для крупного заказчика встал, а разработчики полдня писали в поддержку на английском, объясняя, что они не хакеры. В этот момент бизнес понял: код компании ему не принадлежит — он живёт по правилам чужого сервиса.

Похожая история повторяется в разных вариантах: организация в GitHub зарегистрирована на личную почту уволившегося тимлида, бесплатный тариф режет минуты CI, а после ухода ключевого разработчика никто не может понять, кто из оставшихся имеет права владельца репозитория. Добавьте вопрос юрисдикции: если сервис недоступен из РФ или меняет условия, разработка встаёт. А если в репозитории по недосмотру осели конфиги с чувствительными данными, физически они лежат на серверах в США или Ирландии — и это уже вопрос к 152-ФЗ при проверке или тендере (хранить реальные персональные данные прямо в коде нельзя в любом случае, но собственный сервер хотя бы снимает вопрос о том, где физически находятся репозитории). Внедрение GitLab CE закрывает эти риски одним решением: и Git, и CI/CD переезжают на сервер, который принадлежит вам.

Что это даёт бизнесу

• Код и вся история коммитов остаются на вашей инфраструктуре — блокировка иностранного сервиса или смена его политики больше не может остановить разработку.
• Автоматическая сборка и деплой через CI/CD сокращают релиз с часов ручной работы до 10–15 минут по кнопке, а ошибки «забыл файл на проде» практически исчезают.
• Резервные копии репозиториев и базы GitLab настроены под ваш RPO — вы сами решаете, раз в час или раз в сутки, и сами храните бэкапы, а не полагаетесь на политику стороннего облака.
• Увольнение разработчика больше не создаёт дыру в доступах: права выдаёт и отзывает администратор компании через понятный интерфейс, без писем в зарубежную поддержку.
• Исходный код лежит на сервере в РФ — это упрощает прохождение аудитов и проверок службы безопасности при заключении контрактов с крупными заказчиками.
• При росте команды не нужно докупать платные места в GitHub Enterprise или на GitLab.com Premium — GitLab CE бесплатен независимо от числа пользователей, вы платите только за железо.

Как проходит внедрение

Что нужно от вас

• Доступ к серверу или VPS с правами root (или согласие арендовать новый — подберём конфигурацию под вашу команду).
• Список репозиториев для переноса и перечень пользователей с их ролями — кто должен видеть какие проекты.
• Поддомен для GitLab (например, git.вашакомпания.ру) и почтовый ящик или SMTP для уведомлений системы.
• Если уже есть пайплайны сборки — доступ к ним для анализа и переноса логики в GitLab CI/CD.

Как это устроено

Разработчик пушит код в GitLab на вашем сервере, раннер автоматически собирает и тестирует его в Docker-контейнере, а при успехе разворачивает на продакшене — без единого байта данных на серверах за пределами вашей инфраструктуры.

GitLab CE против облачных GitHub и GitLab.com: что вы теряете, оставаясь в облаке

На старте GitHub или GitLab.com кажутся бесплатными и удобными — регистрация за пять минут, знакомый интерфейс, ничего настраивать не нужно. Но бесплатный тариф ограничивает минуты CI, число участников в закрытых организациях и объём хранилища для артефактов. Команда из 15–20 разработчиков с активной CI/CD упирается в эти лимиты за первый же месяц и либо переходит на платный тариф в валюте, либо режет автоматизацию вручную.

Установка GitLab CE на свой сервер снимает эти лимиты: ни минуты сборки, ни число пользователей, ни объём хранилища не ограничены — упор идёт только в железо вашего сервера. Для команды в 30 человек GitLab.com Premium стоит около 29 $ за пользователя в месяц — это порядка 900 тысяч рублей в год по одной только подписке; свой сервер с арендой VPS обходится в разы дешевле. Плюс к экономии — сам факт, что код физически не покидает вашу инфраструктуру, что снимает вопросы у служб безопасности крупных заказчиков при заключении контрактов.

Сколько стоит внедрение GitLab CE

Частые вопросы

Чем GitLab CE отличается от платного GitLab.com или GitHub Enterprise?
CE — это бесплатная Community Edition с открытым кодом: полноценный Git, мерж-реквесты, CI/CD, Container Registry. В платных редакциях остаются продвинутые вещи вроде обязательных многоуровневых approval в мерж-реквестах, расширенного аудита и глубокого сканирования безопасности (Security Dashboard) — но команде до 50 человек этого почти всегда не требуется.

Это законно и правда бесплатно, без скрытых лицензий?
Да, GitLab CE распространяется под открытой лицензией MIT, и использовать его можно без платежей вендору. Вы платите только за наши работы по внедрению и за сервер, на котором он работает.

Какой сервер нужен под GitLab CE?
Официальный минимум — 4 CPU и 4 ГБ RAM, но на 4 ГБ система работает впритык, особенно с активной CI. Для команды до 15 разработчиков рекомендую 4 CPU и 8 ГБ RAM с SSD. Для 20–50 человек с активными пайплайнами — от 8–16 ГБ RAM и отдельный сервер под GitLab Runner, чтобы сборки не мешали основной работе GitLab.

Можно перенести существующие репозитории без потери истории коммитов?
Да. Перенос из GitHub, Bitbucket или GitLab.com делается через git push --mirror и сохраняет всю историю коммитов, ветки и теги; issues и мерж-реквесты при необходимости переносим отдельно через импорт. Разработчики не заметят разницы, кроме нового адреса git remote.