Интеграция с GitLab

Задача

GitLab остаётся источником правды для кода и CI, а Kubernetes - местом, где должен оказаться готовый образ. Между ними часто выстраивается хрупкая цепочка webhook’ов и кастомных скриптов.

Командам нужно, чтобы связка была предсказуемой: кто имеет право на деплой из какого проекта и как это доказывается при аудите.

Риски «склейки на коленке»

Разъезжающиеся версии образов, неочевидные права на registry, ручной ввод тегов при выкладке.

Сложно объяснить безопаснику и заказчику единый сценарий, если половина шагов живёт в личных репозиториях скриптов.

Что даёт связка Opsy и GitLab

Единый управляемый слой поверх Kubernetes с опорой на привычный контур GitLab: проекты, образы и сценарии выкладки согласованы между инструментами.

Меньше сюрпризов при смене людей: меньше магии в cron и больше прозрачных шагов.

Документация и API

HTTP API, примеры и детали интеграции - на странице «API & Integrations».

Типовой контур «код → образ → кластер»

В зрелой схеме GitLab отвечает за то, чтобы в registry оказался проверенный образ с понятным тегом или digest. Дальше начинается слой, который решает, в какой кластер и с какими параметрами этот образ попадёт.

Если этот слой собран на webhook’ах без единой модели прав, почти неизбежны ситуации, когда деплой инициировал не тот токен или не тот проект.

Для комплаенса важно показать цепочку: какой merge request, какой pipeline, какой образ и какое действие в Kubernetes ему соответствует.

Когда интеграция особенно критична

• Несколько продуктовых команд используют общие GitLab-группы и общие кластера.
• Образы собираются в одном registry, а выкатываются в разные окружения с разными политиками.
• Нужно согласовать доступы между разработчиками, DevOps и информационной безопасностью.
• Планируется масштабирование числа микросервисов без линейного роста «скриптов на коленке».

Иллюстрации ниже - фрагменты интерфейса Opsy из связанной темы продукта. Нажмите на снимок, чтобы открыть его на весь экран.

Тема продукта →   Все сценарии   Открыть Demo