GitLab CE 8.0 на внутреннем сервере: весь инфраструктурный код теперь в Git

GitLab CE 8.0 вышел в конце сентября с интегрированным CI и переработанным merge request workflow. Мы ждали этого повода чтобы наконец сделать то, о чём говорили несколько месяцев: развернуть собственный GitLab и перенести туда весь инфраструктурный код.

До этого жили в странном состоянии: Ansible playbooks были на каком-то shared-диске, Dockerfile лежали у разных людей в разных папках, конфиги правились руками прямо на серверах. Всё это называлось «у нас всё под контролем», но «под контролем» значило в основном «Игорь помнит как это устроено».

Что изменилось в 8.0

Ключевое для нас - два момента.

Встроенный CI. До версии 8.0 GitLab CI существовал как отдельный продукт, который надо было ставить рядом и связывать с GitLab через токены. В 8.0 это стало единым целым: репозиторий, pipelines, результаты - всё в одном интерфейсе. Для инфраструктурного кода это принципиально: можно автоматически проверять синтаксис playbooks при каждом push без отдельного сервиса.

Merge requests стали удобнее. Раньше создать MR в GitLab было немного неловко. В 8.0 переработали интерфейс code review - комментарии к строкам, inline diff, обсуждения. Это важно именно когда ты хочешь ревьюить инфраструктурные изменения, а не просто хранить код.

Как разворачивали

GitLab CE мы поставили на отдельную виртуалку. Официальный omnibus-пакет - это большой .deb или .rpm который тащит внутри nginx, PostgreSQL, Redis и Sidekiq. Звучит тяжело, но на практике поставить проще чем настраивать каждый компонент отдельно.

Несколько наблюдений по установке:

• Память. GitLab официально требует 2 ГБ. На практике с реальной нагрузкой команды из нескольких человек и без CI-runner'ов хватает 1.5 ГБ, но не меньше - иначе Sidekiq начинает тормозить.
• PostgreSQL внутри omnibus работает на том же хосте. Это удобно для старта, но надо сразу думать о бэкапах: gitlab-rake gitlab:backup:create делает дамп всего включая репозитории. Включили в cron на ночь, дамп идёт на отдельный том.
• LDAP-интеграция настраивается в /etc/gitlab/gitlab.rb и работает нормально с Active Directory. Это прямо закрывало вопрос с доступами - не плодить ещё одни пароли для команды.
• HTTPS с внутренним CA. GitLab умеет читать собственный сертификат, если положить его в нужное место и перезапустить gitlab-ctl reconfigure. Заняло время, но без HTTPS внутри корпоративной сети работать некомфортно.

Самая неочевидная проблема: по умолчанию GitLab разрешает любому залогиненному пользователю создавать группы и проекты. Для корпоративного использования это надо сразу ограничить в настройках admin area, иначе начнётся зоопарк.

Что переехало в репозитории

Первым делом перенесли Ansible playbooks. До GitLab они жили в одном bare-репозитории на файловом сервере - push работал, но никакого ревью не было. Теперь у нас отдельный проект infra/ansible, с двумя ветками: main для production-окружения, dev для экспериментов.

Правило которое ввели сразу: изменения в playbooks, которые трогают production-окружение, идут через MR с ревью хотя бы одного другого человека. Это немного замедляет «а давай быстро поправлю таску» - но именно это и нужно, потому что быстрые правки в playbooks без ревью - источник большей части наших инцидентов последних месяцев.

Про работу с Ansible playbooks и ролями писали раньше - сейчас всё это живёт в GitLab.

Dockerfile и docker-compose файлы переехали в отдельный проект infra/containers. Частный Docker registry уже был, теперь появился и источник истины для Dockerfile которые в него пушатся.

Конфиги nginx, конфиги мониторинга, скрипты бэкапов - всё это тоже завели в репозитории. Не автоматизировали с первого дня - просто переложили в Git чтобы история изменений появилась.

Что это изменило в работе

Честно: не сразу и не для всех.

Первую неделю несколько человек продолжали по привычке делать изменения руками на сервере и потом «ах да, надо закоммитить». Пришлось явно договориться: если изменение не в репозитории - его не существует. Звучит строго, но без этого правила смысл от Git теряется.

Конкретный случай который показал ценность системы: при настройке нового сервера клиента обнаружили что в nginx-конфиге была опция которую добавили три месяца назад «на время» и забыли убрать. В Git это видно через git log - когда добавили, кто, зачем. Без версионирования такие штуки просто живут в конфиге навечно.

MR с code review для инфраструктурных изменений - это непривычно для команды которая привыкла «зайти и поправить». Но код ревью ловит вещи которые ты не замечаешь сам: опечатку в пути, переменную которая неправильно называется, задачу которая делает что-то лишнее. В appdev это давно норма, в инфраструктурном коде - пока нет, но движемся в эту сторону.

Встроенный CI пока используем осторожно: запускаем ansible-playbook --syntax-check и yamllint при каждом push в ветку. Не деплоим автоматически - для этого нужно больше уверенности в тестовом окружении, которого пока нет.

Итого

GitLab CE 8.0 работает, и мы довольны что наконец переехали. Omnibus-установка занимает полдня включая LDAP и HTTPS. Всё managed-сопровождение теперь имеет единую точку где живёт инфраструктурный код.

Главная ценность пока не в CI и не в merge request workflow - а в том что появилась история изменений. «Кто и когда поменял этот конфиг» раньше был вопросом к памяти конкретного инженера. Теперь это git log.