В современном ИТ ландшафте множество методологий имеют в своем названии упоминание Ops: DevOps, ChatOps, MLOps и другие. По сути, все они так или иначе являются порождением философии DevOps и сегодня мы поговорим о GitOps — подходе к управлению инфраструктурой и развёртыванием приложений, который использует репозиторий Git в качестве центрального механизма.

GitOps позволяет командам декларативно определять конфигурацию инфраструктуры и приложений, а затем автоматически развёртывать их. Основная идея GitOps заключается в использовании Git как единого источника данных для декларативной инфраструктуры и приложений.

В этой статье мы рассмотрим, те преимущества, которые дает использование GitOps, а также развеем некоторые мифы вокруг GitOps..

Основная идея GitOps

Общий принцип использования GitOps основан на том, что вы определяете желаемые конфигурации инфраструктуры вашего решения в Git, а инструмент или программное обеспечение облачного провайдера, на котором построена ваша инфраструктура, отслеживает любые изменения в вашем репозитории и если что‑либо изменилось, то инфраструктура приводится в желаемое состояние. Этот процесс, известный как согласование, является ключевым компонентом GitOps.

Также, важно, что если инфраструктура отклоняется от желаемого состояния (например, из‑за ручного изменения), программное обеспечение оператора обеспечивает её возвращение в данное состояние.

Например, в конфигурации инфраструктуры Git указано, что для автоматического масштабирования минимальное количество экземпляров подов Kubernetes равно 3, а максимальное — 9. Программное обеспечение оператора развёртывает группу автоматического масштабирования со значениями из Git.

Предположим, кто‑то вносит изменения вручную, и теперь минимальное и максимальное значения для автомасштабирования равны 4 и 12. Поскольку программное обеспечение оператора постоянно отслеживает инфраструктуру, оно выявляет отклонение конфигурации по сравнению с сохраненной в git. Таким образом, он откатывает ручные изменения, чтобы привести их в соответствие с желаемым состоянием в Git.

Таким образом, на высоком уровне GitOps стремится к обеспечению выполнения следующих задач:

• Git должен быть единственным источником истины;

• Рабочие процессы инфраструктуры, должны быть ориентированы на разработчика;

• Должна обеспечиваться хорошая прослеживаемость изменений инфраструктуры;

• Git обеспечивает единообразие и стандартизацию;

• Обеспечение повышенного уровня безопасности.

Далее давайте на примере разберем ключевые принципы работы GitOps.

Единый источник достоверной информации

В GitOps желаемое состояние всей инфраструктуры определяется и версионируется в репозитории Git. Это означает, что Git служит единым источником достоверной информации как для кода приложения, так и для конфигураций инфраструктуры.

Все конфигурации и код, связанные с микросервисами, включая манифесты Kubernetes и чарты Helm, хранятся в репозитории Git. Его можно назвать репозиторием развертывания или инфраструктуры. Этот репозиторий служит единым источником достоверной информации для всего процесса развертывания.

Посмотрим пример структуры репозитория инфраструктуры, содержащий чарты Helm, организованные для различных сред в Git. Изначально ArgoCD разворачивает эти чарты в зависимости от сред. Первый коммит добавляет чарты Helm для новых микросервисов. А последующие коммиты отслеживают обновления и изменения, обеспечивая контроль версий.

Рабочие процессы инфраструктуры, ориентированные на разработчика

GitOps стремится управлять инфраструктурой с помощью привычных рабочих процессов Git. Изменения инфраструктуры вносятся посредством запросов на извлечение, проверок кода и слияний, что обеспечивает совместную работу и согласованность.

В нашем примере для любых изменений в развернутых микросервисах требуется запрос на извлечение от разработчика/DevOps‑инженера. Инженер вносит необходимые изменения в файл app1-values.yaml в репозитории инфраструктуры, обеспечивая включение всех требуемых конфигураций.

Затем создается запрос pull request (PR) для слияния этих изменений с основной веткой. Этот PR включает в себя подробное описание изменений, причин и любой соответствующий контекст.

PR проходит серию тестов перед слиянием с целевой веткой (проверка конфигурации инфраструктуры, проверка соответствия, lint‑тестирование и т. д.). Эти тесты зависят от политик безопасности соответствующей организации.

PR назначается назначенным ревьюерам из команды DevOps. Эти ревьюеры тщательно проверяют изменения на корректность, наличие потенциальных проблем и соответствие лучшим практикам.

Рецензенты предоставляют обратную связь, запрашивают изменения при необходимости и утверждают PR после устранения всех замечаний. Перед объединением PR проходит серию автоматизированных тестов.

Валидация конфигурации инфраструктуры: гарантирует, что изменения не нарушают существующие конфигурации и соответствуют требуемой схеме.

Проверка соответствия: мы проверяем, соответствуют ли конфигурации политикам безопасности и соответствия требованиям организации.

Линт‑тестирование: проверяем соответствие стандартам кодирования и лучшим практикам.

Интеграционные тесты: запускаются тесты для обеспечения корректного взаимодействия нового микросервиса с другими сервисами.

Эти тесты автоматизированы с использованием инструментов CI/CD, интегрированных с репозиторием Git (например, GitHub Actions, Jenkins или GitLab CI).

После того, как PR пройдёт все проверки и автоматизированные тесты, он будет объединён с основной веткой. Это действие активирует ArgoCD, который обнаруживает изменения и начинает процесс развёртывания.

Прослеживаемость изменений и аудит

Благодаря GitOps все изменения инфраструктуры отслеживаются и версионируются в Git. Это обеспечивает чёткое ведение контрольного журнала, позволяющее легко понять, какие изменения были внесены, кем и когда.

Например, каждое сообщение о коммите содержит подробную информацию: «Добавить начальную конфигурацию для app-1». История Git позволяет отслеживать изменения с течением времени. Обсуждения и утверждения запросов на извлечение также регистрируются, предоставляя контекст и обоснование изменений.

Единообразие и стандартизация

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

Например, чарт Helm для app1 включает шаблоны и файлы параметризованных значений. Разработчикам нужно только изменить values.yaml для разных сред.

Таким образом, GitOps препятствует ручным изменениям инфраструктуры. Все изменения вносятся через Git, и инструмент GitOps автоматически синхронизирует фактическое состояние инфраструктуры с желаемым состоянием, заданным в репозитории.

Возвращаясь к нашему примеру, ArgoCD постоянно отслеживает состояние репозитория Git. Любое изменение в репозитории автоматически применяется к кластеру Kubernetes. Если в кластер вносится ручное изменение, ArgoCD обнаруживает отклонение и корректирует его, применяя желаемое состояние из репозитория Git.

Команда DevOps уведомляется об отклонении и предпринятых корректирующих действиях, что обеспечивает прозрачность и подотчётность.

Повышенная безопасность

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

Так, автоматизированные инструменты безопасности (например, Trivy) сканируют конфигурации Helm на наличие уязвимостей. Проверка кода обеспечивает соответствие политикам безопасности.

Распространённые заблуждения о GitOps

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

GitOps — это просто инфраструктура как код с дополнительными этапами. Нет, хотя GitOps использует IaC, это полноценная операционная модель. Представьте себе IaC как рецепт, а GitOps — как целую систему ресторанной кухни, включая рабочий процесс, проверку качества и предоставление услуг.

«Это работает только в Kubernetes». Хотя Kubernetes сделал GitOps знаменитым, его принципы работают везде. Многие команды успешно применяли GitOps к традиционной инфраструктуре, базам данных и даже сетевым конфигурациям.

«Для работы GitOps нужно, чтобы всё было автоматизировано». Необязательно, начните с малого! Вам не нужна 100% автоматизация с первого дня. Многие успешные внедрения GitOps начинаются с частичной автоматизации и постепенно расширяются. Используйте ручные этапы утверждения там, где это целесообразно.

«Он заменяет конвейеры CI/CD». GitOps дополняет вашу CI/CD, а не заменяет её. Представьте CI/CD как сборочную линию, а GitOps — как систему инвентаризации и контроля качества. — они работают вместе.

«Git слишком сложен для команд операционного управления». Современные инструменты Git значительно упростили эту задачу. К тому же, большинству членов команды достаточно знать лишь базовые операции и уметь пользоваться графическим интерфейсом. Кривая обучения не такая крутая, как может показаться.

Ключевой принцип внедрения GitOps — начать с малого, сосредоточиться на ценности и постепенно развивать практику GitOps. Не поддавайтесь давлению, которое заставляет вас менять всё в одночасье.

Заключение

В этой статье мы рассмотрели основы GitOps и его преобразующее влияние на управление инфраструктурой. Используя Git как единый источник информации, GitOps обеспечивает надежность, согласованность и прослеживаемость рабочих процессов DevOps.

Независимо от того, начинаете ли вы с малого или планируете масштабное внедрение, GitOps предлагает мощную платформу для поддержки современной разработки программного обеспечения. Используйте GitOps, чтобы создать согласованную, безопасную и гибкую культуру DevOps, соответствующую современным быстро меняющимся требованиям разработки.

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

• 26 августа в 20:00 — Интеграция инструмента ArgoCD: разберёмся, как реализовать принцип согласования состояний на практике.

• 2 сентября в 20:00 — CI/CD best practices: обсудим, как GitOps дополняет конвейеры поставки и помогает повысить их надёжность.

• 18 сентября в 20:00 — Введение в Crossplane: управление облачной инфраструктурой через Kubernetes: посмотрим, как расширить подход GitOps за пределы кластеров.

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