Девтрон спонсировал этот пост. Insight Partners является инвестором в Devtron и TNS.
Gitops навсегда произвел революцию в управлении инфраструктурой и процессом доставки программного обеспечения. С GIT в качестве единственного источника истины, Gitops заменил традиционные, ручные и подверженные ошибкам процесса развертывания более быстрым, автоматизированным подходом. Такие инструменты, как CD Argo CD и Flux CD, доминировали в разговорах, используя Gitops в качестве основного принципа в развертываниях Kubernetes.
Однако по мере того, как нативный ландшафт облака развивается, и развертывание становится все более сложным, эти ведущие инструменты сталкиваются с новыми проблемами в поддержании безопасности, масштабируемости и передовой практики. Итак, как Gitops нужно выглядеть сегодня, чтобы удовлетворить требования Cloud Native Organizations для развертывания более умных и безопасных развертываний Kubernetes?
Восстание Gitops Tools: Flux и Argo CD
WeaveWorks придумал термин «глитопс» в 2017 году. Основная идея Gitops состоит в том, чтобы использовать GIT в качестве единственного источника истины для декларативной инфраструктуры и развертывания приложений.
Перед Gitops команды в значительной степени полагались на пользовательские сценарии (Python, Bash и т. Д.) Или ручные команды (Kubectl) для развертывания приложений. Эти ручные подходы внесли несколько проблем, например, затрудняя отслеживание изменений или повторных развертываний, и отсутствие стандартизации означало, что процессы часто подвергались ошибкам.
Гитопс появился для решения этих проблем, и поток был первым инструментом, который принял эту модель. Поток облегчил развертывание, непосредственно избавив изменения из репозитория GIT вместо того, чтобы продвигать изменения в кластере. Затем появился CD Argo, который учитывал ограничения Flux, предоставив визуальную панель панели и улучшая удобство использования, что привело к более широкому внедрению предприятия.
Вместе Flux и Argo CD проложили путь для современной, надежной и масштабируемой доставки программного обеспечения, работающих на Gitops.
Затянутые пробелы в инструментах Gitops
В то время как Gitops улучшили доставку программного обеспечения, эти инструменты Gitops представили свой собственный набор проблем. Команды начали сталкиваться с проблемами с откатами, процессами одобрения и управлением слишком большим количеством инструментов.
Вот несколько общих пробелов в современных инструментах Gitops.
Многокрасные препятствия управления
Управление несколькими кластерами Kubernetes с этими инструментами Gitops часто вносит значительную сложность. Организации должны выбирать между развертыванием отдельных экземпляров CD Argo на кластер, что приводит к высоким операционным накладным расходам или с использованием одного централизованного экземпляра CD ARGO для всех кластеров Kubernetes, которые могут стать единственной точкой отказа. Такие архитектурные проблемы затрудняют поддержание видимости, контроля и устойчивости в разных средах, а многокрасные глинопсы становятся реальной проблемой.
Отсутствие политических развертываний
Инструменты Gitops, такие как Flux и Argo CD, действуют только в качестве инструментов синхронизации Git-Kubernetes. В то время как они преуспевают в том, чтобы поддерживать синхронизацию Cluster с тем, что определено в GIT, им не хватает местной поддержки для политических развертываний, которые регулируют, как и когда должны происходить развертывание.
Например, организации могут захотеть обеспечить соблюдение ручных разрешений, применять проверки безопасности или соответствия требованиям или ограничить развертывание в определенных временных окнах. Такая политика необходима для предотвращения неверных или непреднамеренных изменений в добыче добычи.
Нет местных откатов на основе SLO
В текущих инструментах Gitops не хватает собственной поддержки откатов, управляемых целями уровня обслуживания (SLO). Откалы на основе SLO позволяют командам быстро вернуться к предыдущей стабильной версии, когда развертывания влияют на ключевые показатели пользователя. Без этой возможности команды вынуждены писать пользовательские сценарии или полагаться на внешний инструмент, который увеличивает сложность и разрастание инструментов.
Отсутствие возможностей для продвижения в Гитоп
В Gitops «продвижение» — это процесс перемещения приложения из одной среды в другую, например, от разработки к тестированию, а затем к производству, путем внесения декларативных изменений в GIT. Текущие инструменты Gitops не имеют нативной поддержки для продвижения по службе. Командам часто приходится полагаться на ручные шаги, управление филиалами или пользовательские трубопроводы для продвижения приложений по окружающей среде, что противоречит основным принципам автоматизации и последовательности.
Необходимость в гитопсах с приложением
Чтобы преодолеть ограничения текущих инструментов Gitops, платформы следующего поколения должны выходить за рамки базового синхронизации Git-Kubernetes. Они должны быть с учетом приложения, защищены по проектированию и достаточно гибким, чтобы поддерживать сложную доставку в масштабе. Вот что должна предоставить современная платформа Gitops:
Гибкие возможности отката
Откат должен быть больше, чем просто вернуть GIT Commit. Платформы Gitops должны поддерживать интеллектуальные, автоматизированные откаты на основе показателей в реальном времени, таких как нарушения SLO, частота ошибок или задержки. Это сводит к минимуму влияние пользователя без необходимости полагаться на ручное вмешательство или пользовательские сценарии.
Поддержка передовых стратегий развертывания
Стратегии развертывания, такие как Canary, сине-зеленый и прогрессивные развертывания, не должны требовать дополнительных настройков или сторонних инструментов. Вместо интеграции сторонних инструментов, таких как Flagger, команды должны иметь возможность настраивать и выполнять расширенные шаблоны развертывания непосредственно в платформе Gitops.
Упрощенные многократные развертывания
Обработка развертываний по нескольким кластерам не должна быть сложной или хрупкой. Современная платформа Gitops должна облегчить управление приложениями в разных кластерах с помощью единого единого представления, в то же время предоставляя командам гибкость для самостоятельного управления каждым кластером.
Продвижение приложений с мощностью GITOPS
Содействие приложениям от разработки до постановки до производства не должно быть ручным или сложным процессом. Хорошая платформа Gitops должна позволить командам определять четкие рабочие процессы по продвижению в GIT, поэтому приложения проходят через каждую среду автоматически и безопасно без дополнительных шагов или сценариев.
Встроенная политика одобрения
Политика утверждения должна быть частью процесса Gitops с самого начала. Будь то быстрое подпись от товарища по команде или автоматическая проверка проблем, платформа должна убедиться, что ворота одобрения встроены прямо в рабочий процесс Gitops, чтобы развернулись только безопасные, пересмотренные изменения.
Усовершенствованный контроль доступа на основе ролей
Контроль доступа на основе ролей (RBAC) должен быть встроен непосредственно в платформу и не зависеть от кластеров Kubernetes, которые могут добавить ненужную сложность. Команды должны иметь возможность устанавливать подробные разрешения на платформе по окружающей среде, приложениям и рабочим процессам, обеспечивая безопасность и соответствие без ненужных дополнительных накладных расходов.
Встроенная наблюдение
Очень важна четкая видимость в развертывании, статусе синхронизации, здоровья приложений и исторических изменений. В 2025 году платформы Gitops должны обеспечить встроенную наблюдением, что позволяет командам легко устранять проблемы, отслеживать откаты и контролировать весь процесс развертывания с унифицированной панели панели.
Модернизация управления жизненным циклом приложений
Источник: Devtron.
Devtron создан для упрощения Gitops для современных команд. Он поддерживает гибкие откаты, передовые стратегии развертывания и легкое управление многоклельными. С встроенными воротами утверждения, мелкозернистыми RBAC и надежными функциями наблюдения, Devtron сохраняет безопасность, соблюдение и прозрачность на протяжении всего процесса развертывания. Его унифицированная платформа дает командам полный контроль, позволяя им развернуть умнее и безопаснее, ускоряющую доставку программного обеспечения без ущерба для качества.
Devtron глубоко интегрируется с продуктами на протяжении жизненного цикла микросервисов, IE, CI/CD, безопасности, стоимости, отладки и наблюдаемости через интуитивно понятный веб -интерфейс. Devtron помогает вам развернуть, наблюдать, управлять и отлаживать существующие приложения Helm во всех ваших кластерах. Insight Partners является инвестором в Devtron и TNS. Узнайте больше последних из Devtron Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Айаан — писатель технического контента в Devtron. Он увлечен Kubernetes, Gitops, Cloud Contination Tech и любит делиться своими мыслями через блоги, чтобы упростить сложные темы. Узнайте больше от Ayaan Bordoloi
