GitLab 11.0 Auto DevOps: от git push до Pod-а в Kubernetes за 8 минут без .gitlab-ci.yml

GitLab 11.0 вышел в конце июня. Главная фича - Auto DevOps перестала быть экспериментальной опцией и стала включена по умолчанию для новых проектов. Суть простая: GitLab смотрит на репозиторий, сам определяет язык, сам собирает образ, прогоняет тесты и деплоит в подключённый Kubernetes-кластер. Без единой строки .gitlab-ci.yml.

Мы скептически к этому отнеслись - примерно так же, как в 2017-м скептически смотрели на Review Apps в GitLab 9.0. Потом притёрлись. Решили и с этим проверить: взяли один из внутренних проектов и подключили кластер.

Что именно делает Auto DevOps

Когда Auto DevOps включена и к проекту привязан Kubernetes-кластер, GitLab разворачивает пайплайн из нескольких стадий:

• Auto Build - GitLab берёт Dockerfile из корня репозитория или, если его нет, использует Herokuish для детекции языка и сборки через buildpack. Образ пушится в встроенный GitLab Container Registry.
• Auto Test - запускает heroku-testrunner или тесты через docker run, если в образе есть скрипт. У нас Dockerfile был, тесты подхватились из него.
• Auto Deploy - деплоит образ в Kubernetes через Helm. GitLab сам устанавливает Tiller в кластер, создаёт namespace, рендерит Chart.
• Auto Review Apps - для feature-веток поднимает временное окружение с отдельным Ingress и URL вида <ветка>.<проект>.<базовый домен>.
• Auto DAST / SAST - сканирование безопасности. Мы его сразу отключили, смотрели только деплой.

Всё это живёт внутри встроенных .gitlab-ci.yml-шаблонов, которые GitLab подтягивает автоматически. Переопределить конкретную стадию можно, добавив в свой .gitlab-ci.yml только нужный кусок - остальное GitLab докидывает из Auto DevOps.

Как подключали кластер

Нативная интеграция Kubernetes в GitLab 11.0 - это отдельная вкладка в настройках проекта. Указываешь API URL кластера, CA-сертификат и токен сервисного аккаунта. GitLab сам проверяет доступность, устанавливает gitlab-managed-apps namespace и разворачивает туда Tiller, если его нет.

У нас кластер на managed-инфраструктуре, доступ к API уже был настроен. Создали отдельный ServiceAccount с ограниченными правами - не cluster-admin, а edit в нужных namespace. GitLab принял, хотя часть операций потом жаловалась на права при первоначальной инициализации Tiller. Пришлось дать чуть больше прав на этапе первого запуска, потом можно срезать.

После подключения кластера и включения Auto DevOps - пуш в master, и понеслось.

Что случилось за 8 минут

Таймлайн реального прогона:

00:00 - git push
00:12 - GitLab запустил пайплайн, стартовал Auto Build
02:40 - docker build завершился, образ в Container Registry
03:05 - Auto Test: тесты прошли (проект небольшой)
04:20 - Auto Deploy: Helm install в кластер
05:50 - Pod перешёл в Running
07:50 - Ingress поднят, URL доступен

Итого - чуть меньше 8 минут от коммита до работающего HTTP-эндпоинта в кластере. Без единой строки конфига, если не считать настройку кластера в GitLab UI.

Это... работает. По крайней мере для простого сервиса без особых требований к деплою.

Что понравилось и что нет

Хорошее. Скорость старта нулевая. Для нового проекта или прототипа - подключил кластер, включил Auto DevOps, получил рабочий CI/CD без написания пайплайна. Auto Review Apps для feature-веток - удобно: каждая ветка разворачивается в отдельный namespace с уникальным URL, можно смотреть как выглядит фича до мержа.

Неудобное. GitLab разворачивает Tiller в режиме cluster-wide, что в 2018-м остаётся проблемой безопасности Helm 2 - Tiller имеет права на весь кластер. Если в кластере несколько команд или проектов, это неприятно. Обойти можно, но тогда надо копаться в Helm-чарте Auto DevOps и переопределять его - часть магии ломается.

Ещё - Helm-чарт, который GitLab генерирует для Auto Deploy, очень generic. Там есть базовый Deployment, Service, Ingress, livenessProbe по HTTP. Если проекту нужны volumes, init-контейнеры, специфичные environment variables из секретов - всё это приходится пробрасывать через CI/CD variables или переопределять чарт. На третьем переопределении понимаешь, что проще написать свой .gitlab-ci.yml с нуля.

Вывод. Auto DevOps - это хорошая точка старта и рабочий инструмент для сервисов без специфики. Для продакшн-деплоя с нетривиальными требованиями он быстро упирается в ограничения generic-чарта. Но то, что пайплайн вообще заработал без .gitlab-ci.yml - это честный прогресс по сравнению с тем, что было в GitLab 9.0, когда мы писали пайплайн руками.

Посмотрим что будет с Helm 3, когда Tiller уберут - возможно тогда Auto DevOps для мультитенантных кластеров станет адекватнее.