Продвижение между окружениями

Задача

Компании держат несколько кластеров и окружений: регионы, стадии пайплайна, изоляция для заказчиков. Промоушн артефакта из dev в prod легко превращается в цепочку ручных действий и личных kubeconfig.

Без единой модели доступа сложно ответить на вопрос: кто имеет право продвинуть релиз на прод и кто это подтвердил.

Типичные боли

Разные версии образов в соседних средах, «плавающие» теги, ручное копирование манифестов.

Онбординг нового инженера растягивается из-за количества контекстов и исключений.

Как Opsy упорядочивает сценарий

Единая учётная запись и политики доступа над несколькими кластерами снижают зависимость от локальных kubeconfig и разрозненных правил.

Продвижение релиза между стадиями становится прослеживаемым: меньше сюрпризов при передаче между командами и при аудите.

Углубление

Архитектура мультикластера и сценарии для крупных установок - на странице «Мультикластер».

Промоушн - это не только «другой кластер»

Между dev и prod часто скрываются различия в секретах, лимитах ресурсов, версиях CRD и сетевых политиках. Даже при одинаковом образе поведение сервиса может различаться.

Когда учётные записи и kubeconfig размазаны по людям, почти неизбежны «ручные» промоушны в обход согласованного процесса - особенно в пожарных ситуациях.

Для регулируемых отраслей важно доказать, что в прод попал именно тот артефакт, который прошёл согласование на предыдущей стадии.

Организации, которым это ближе всего

• Несколько географических регионов или изолированных контуров с общей политикой релизов.
• Строгие требования к разделению доступа между разработкой и эксплуатацией.
• Команды, уставшие от ручного копирования манифестов между средами.
• Компании, масштабирующие число кластеров быстрее, чем растёт штат DevOps.

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

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