GitLab 9.0: Review Apps и Prometheus из коробки - заканчиваем переезд с Jenkins

Две недели назад мы описали переезд первых pipeline-ов с Jenkins на GitLab CI. Вчера вышел GitLab 9.0, и мы потратили день на то чтобы понять что из обещанного действительно работает, а что пока числится в changelog только формально.

Спойлер: Review Apps работают. Prometheus-интеграция - приятный сюрприз. Subgroups - спасение для больших команд. Auto DevOps - пока скорее демо, чем инструмент.

Что изменилось в 9.0 по существу

GitLab давно умеет и SCM, и CI/CD, но это чувствовалось как два разных продукта в одном корпусе. 9.0 ощущается как шаг к тому чтобы они стали одним целым.

Review Apps в стабильном виде. Это главное что мы ждали. Идея проста: для каждого merge request автоматически поднимается временная среда со своим URL, разработчик и ревьюер могут кликать руками, а не читать диффы и гадать как это выглядит. После мерджа окружение удаляется. Раньше это работало, но нестабильно - окружения не удалялись, URL не проставлялись, GitLab периодически терял связь между MR и деплоем. В 9.0 судя по первому дню - починили.

Встроенная интеграция с Prometheus. Теперь GitLab умеет показывать метрики прямо в интерфейсе деплоя - CPU и память окружения, куда задеплоились. Подключается через Settings -> Integrations -> Prometheus, указываешь адрес сервера. Мы уже ставили Prometheus на managed-проекты, так что у нас это заработало без дополнительных усилий. Красиво ли - да. Нужно ли как замена Grafana - нет, это скорее быстрый взгляд «что случилось после деплоя».

Subgroups. Наконец-то. Возможность группировать проекты в иерархию: company/team/project вместо плоского company/project-team-suffix. Для больших организаций с десятками репозиториев это не косметика, а реальное упрощение навигации и управления доступами.

Как настраиваем Review Apps

Конфиг не сложный, но требует понимания что за окружение будет подниматься. Мы деплоим в Kubernetes, поэтому Review App - это отдельный namespace с именем MR:

stages:
  - build
  - test
  - review
  - deploy
  - cleanup

review:
  stage: review
  script:
    - kubectl create namespace review-$CI_ENVIRONMENT_SLUG || true
    - helm upgrade --install
        review-$CI_ENVIRONMENT_SLUG ./chart
        --namespace review-$CI_ENVIRONMENT_SLUG
        --set image.tag=$CI_COMMIT_SHA
        --set ingress.host=review-$CI_ENVIRONMENT_SLUG.example.com
  environment:
    name: review/$CI_COMMIT_REF_NAME
    url: https://review-$CI_ENVIRONMENT_SLUG.example.com
    on_stop: stop_review
  only:
    - branches
  except:
    - master

stop_review:
  stage: cleanup
  script:
    - helm delete --purge review-$CI_ENVIRONMENT_SLUG
    - kubectl delete namespace review-$CI_ENVIRONMENT_SLUG
  environment:
    name: review/$CI_COMMIT_REF_NAME
    action: stop
  when: manual
  only:
    - branches
  except:
    - master

on_stop - ключевой момент. Это джоб который GitLab вызовет при закрытии MR. Без него окружения накапливались бы бесконечно. В 8.x это работало ненадёжно, в 9.0 пока ни одного протечённого namespace.

Wildcard DNS на *.example.com надо настроить заранее - это единственная внешняя зависимость. Ingress в Kubernetes делает остальное.

Что с переездом с Jenkins

До этой недели у нас оставался один проект на Jenkins - монолитное Java-приложение с Groovy-пайплайном на 400 строк. Переносить его руками было бы больно, и мы откладывали.

GitLab 9.0 не сделал это проще магически, но несколько вещей помогли:

Pipeline editor в интерфейсе стал чуть умнее - подсвечивает синтаксические ошибки в .gitlab-ci.yml до коммита. Мелочь, но сокращает цикл «закоммитил - посмотрел что упало - поправил».

Переменные окружения теперь можно группировать по окружениям прямо в UI. Раньше всё в одну кучу, теперь можно сказать «эта переменная только для production». Не rocket science, но когда переносишь большой Jenkinsfile с кучей секретов по окружениям - экономит время.

Сам перенос занял два дня. Groovy-пайплайн на 400 строк превратился в .gitlab-ci.yml на 120. Часть логики ушла в Makefile который вызывается из CI, часть - в переменные GitLab. Jenkins-агент отключили.

Prometheus-интеграция: чего ждать и чего не ждать

Встроенный дашборд в GitLab показывает две метрики: CPU и память деплоя. Это данные из Kubernetes через kube-state-metrics или напрямую из cAdvisor - зависит от того как настроен Prometheus. Временной диапазон фиксирован на «последние 8 часов». Изменить нельзя.

Для быстрой проверки «что случилось сразу после деплоя» - удобно. Для нормального мониторинга и алертинга - Grafana и Alertmanager никуда не уходят. Это не конкурирующие вещи, это разные уровни детализации.

Auto DevOps

GitLab 9.0 анонсировал Auto DevOps - автоматический пайплайн на основе Herokuish, который пытается сам разобраться что за проект и как его собирать. На проекте с Dockerfile это просто запускает docker build. На проекте без него пытается угадать язык через buildpack.

Мы попробовали на чистом Rails-проекте. Собралось. Задеплоилось в миникуб. Но это демо, не продакшн: пайплайн непрозрачный, кастомизация ограничена, и непонятно как это поведёт себя на проекте с нестандартными зависимостями. Для команд которые хотят CI/CD «из коробки без погружения» - может и пригодится. Для нашей работы с клиентами - пишем .gitlab-ci.yml руками, это предсказуемее.

Итог

GitLab 9.0 - это не революция, но заметный шаг. Review Apps наконец работают так как должны. Subgroups решают реальную проблему организации репозиториев. Prometheus-интеграция - приятный бонус для тех кто уже использует этот стек. Jenkins у нас теперь не осталось ни на одном managed-проекте - последний уехал на этой неделе.

Что хочется в 9.x: нормальный dependency management между пайплайнами разных репозиториев (сейчас через triggers API, но это костыль), и более гибкий UI для Prometheus - хотя бы выбор временного диапазона.