GitOps: или как мы перестали волноваться и полюбили этот процесс

GitOps — это обновления инфраструктуры через pull request. И точка. Или нет? В третьем эпизоде ​​missionCTRL архитекторы решений Spacelift Эмин Алемдар и Джои Стаут беседуют с Тимом Дэвисом, техническим менеджером по маркетингу продуктов Spacelift, чтобы разобраться, что на самом деле означает GitOps и кто имеет право его определять. Они разбираются в происхождении термина, споре пуристов Kubernetes и разрыве между командами, которые считают, что они используют GitOps, и командами, которые действительно его используют. Они также обсуждают, как выглядит эффективное управление (прозрачность плана, утверждения, обнаружение отклонений), должен ли ИИ участвовать в цикле проверки и когда команда готова внедрить этот процесс. Попутно Джои рассказывает историю об административном слиянии, удаленной группе узлов и последовавшем за этим позоре. missionCTRL представлен вам компанией Spacelift, платформой оркестрации инфраструктуры. Узнайте больше на https://spacelift.io/. Можете ли вы указать на pull request, который санкционировал изменение? Поделитесь своим мнением о GitOps в комментариях и оставьте идеи для следующего эпизода. Подпишитесь на канал missionCTRL на YouTube, чтобы не пропустить следующий выпуск. Также доступно на Apple Podcasts, Spotify и везде, где вы слушаете подкасты. 00:27 - Вступление 01:37 - Что такое GitOps? 06:36 - Распространенные пробелы и масштабирование инфраструктуры как кода 08:21 - Инструментарий против процессной методологии 12:11 - Обнаружение отклонений и автоматическое исправление 13:50 - История Джои 14:58 - Роль ИИ в обзорах GitOps 17:01 - Борьба с «усталостью от зеленого флага» и «звонком позора» 19:51 - Корни и эволюция GitOps в Kubernetes 23:11 - Видимость запросов на слияние и список желаемых функций 26:04 - Есть ли варианты использования, когда GitOps НЕ нужен? 28:28 — Когда команда готова к GitOps? 34:08 — Заключительные мысли