Что такое GitOps? Краткий обзор методологии и знакомство с ArgoCD

В статье рассказываем, что такое методология GitOps и как она устроена — на примере ArgoCD.

---

Введение в CI/CD

Чтобы разобраться и понять идеи GitOps, нужно познакомиться с концепцией CI/CD, которая является неотъемлемой частью методологии. 

CI/CD — это комбинация современных принципов из DevOps- и Agile-практик в разработке ПО — непрерывной интеграции и поставки обновлений.

• Непрерывная интеграция (Continuous Integration, CI) — это подход в разработке, который заключается в постоянной проверке и слиянии изменений кода в общую ветку центрального репозитория.

Проще говоря, перед самим слиянием изменений в общую ветку код проекта проверяется на сервере вроде Jenkins, который знает, как его собрать и протестировать.

• Непрерывная поставка (Continuous Delivery, CD) — это подход, при котором программное обеспечение производится короткими итерациями, с высокой частотой обновления центрального репозитория.

Бенефит CD прост: чем чаще разработчики «пушат» изменения в центральный репозиторий, тем проще поддерживать проект. Так, если пользователи начнут отправлять репорты на последнее обновление, можно вернуться к предыдущему, не задев рабочие фичи.

С помощью CI/CD можно автоматизировать Git-процессы, развертывание приложений и сосредоточиться на безопасности и бизнес-логике.

Введение в философию GitOps

Что такое GitOps

GitOps — это методология, которая взяла лучшие практики из разработки и перенесла их на инфраструктуру. Так, последнюю можно рассматривать как код (по модели IaC, Infrastructure as Code) и декларативно описывать с помощью JSON- или YAML-файлов. На основе них специальное ПО будет автоматически разворачивать инфраструктуру — в том числе по процессам CI/CD. 

GitOps и Git

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

GitOps и DevOps

Разработчики из Atlassian считают, что сама идея Infrastructure as Code пришла из DevOps. Методология GitOps же просто внедряет DevOps-методы, тем самым закрывает «пропасть» между системным администрированием и разработкой распределенных облачных приложений.

Принципы и преимущества GitOps

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

• Декларативная система. По GitOps вся инфраструктура описана в YAML- или JSON-файлах декларативно. Хотя по умолчанию IaC можно описать и процедурным подходом. Главное, чтобы это было однозначно и исчерпывающе.

IaC — это не только серверы, но и настройка политик доступа, сети и всего того, что может предложить облачный провайдер.

• Система контроля версий. Это буквально «фундамент» и главное преимущество GitOps. И так как Git — самая популярная DVCS-система, методология называется именно GitOps, а не, например, SVNOps. 

Каждое обновление инфраструктуры проходит через Git-репозиторий и проверяется после запроса на слияние с главной веткой (pull-requests). Группа специалистов тестирует обновление и либо принимает его, либо отклоняет. Это важное преимущество системы Git. 

Кроме того, с помощью системы прав в Git можно разграничивать доступы к разным частям вашего проекта. Так, например, простые участники не могут принять запрос на слияние или незаметно изменить конфигурацию инфраструктуры. 

• Автоматизация изменений. После того, как специалисты утверждают слияние, изменения автоматически развертываются в приложении. 

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

Большой пласт работ выполняет специальный программный агент — оператор. Он проверяет, есть ли обновления в репозитории.

Теперь давайте рассмотрим один из примеров работы с GitOps.

GitOps на примере Kubernetes

Обычно GitOps применяют в разработке облачных приложений на базе оркестраторов вроде Kubernetes. Поэтому GitOps-инструменты — о них мы поговорим ниже — содержат методы, объединяющие развертывание, мониторинг, управление кластерами и приложениями. С помощью них можно автоматически обновлять контейнеры — в соответствии с последней версией главной ветки. 

Оператор здесь выполняет роль посредника между системной оркестрации и конвейером, который проверяет и автоматически синхронизирует состояние репозитория с облачным приложением. Вот, как это работает: 

1. Разработчик изменил конфигурацию контейнера и делает pull request, чтобы выпустить изменение в прод. 

2. Специалисты проверяют код и отклоняют/утверждают слияние. 

3. Слияние активирует конвейер CI/CD, который автоматически тестирует и добавляет код в реестр (registry). 

4. Оператор регистрирует и скачивает обновление, а после — отправляет подключенному локальному репозиторию.

Готово — обновление вышло в продакшен. Но все ли так просто на практике?

Популярные инструменты

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

ArgoCD

Это мощный декларативный GitOps-инструмент для непрерывной доставки (Continuous Delivery, CD) и развертывания приложений K8s. Важная особенность — «мультиплексное» управление: оператор ArgoCD может работать сразу с несколькими кластерами. Кроме того, инструмент предоставляет не только эффективный CD, но и удобный UI/UX. Посмотрите сами: интерфейс интуитивно понятен «даже ребенку». 

Решение хорошо подходит тем, кто хочет попрактиковаться и продолжить в GitOps: ArgoCD просто развернуть, настроить и поддерживать. 

Начать работу с ArgoCD →

Flux

Не путайте этот инструмент с React-архитектурой Flux. Это второе по популярности решение после ArgoCD. Инструмент GitOps Flux также предназначен для CD приложений Kubernetes, но может управлять только одним кластером и репозиторием. В остальном — функционал идентичен. 

Flux может работать только с одним кластером, а ArgoCD — с несколькими.

Узнать больше о Flux →

Helm operator

Это open source-оператор (GitOps-расширение) Kubernetes для декларативного управления HelmRelease, диаграммами Хелма. Его можно использовать в качестве расширения для Flux, чтобы автоматизировать релизы Helm-чартов. 

---

Мы рассмотрели лишь малую часть инструментов GitOps. Вы также можете использовать Jenkins X, Quay, Gitkube, WKSctl и другие решения — выбор зависит от задачи. 

Знакомство и начало работы с ArgoCD 

Теперь посмотрим, как организовать свою IaC-среду с помощью ArgoCD.

Подготовка окружения

1. Для начала нужно подготовить пространство нашего проекта — установить kubectl, VirtualBox (или KVM) и minikube. Это можно сделать прямо внутри виртуального окружения. 

2. Далее нужно установить в директиву своего проекта ArgoCD, извлечь initial password и подключиться к ArgoCD WebUI по localhost.

Супер — теперь можно задеплоить приложение через WebUI. Но давайте разберем IaC-подход и опишем свой K8s-проект через YAML-файл. 

Деплой проекта Kubernetes

ArgoCD оперирует специальными пользовательскими ресурсами (Custom Resource Definition) для Kubernetes — Application, ApplicationSet и AppProject. Разберемся с каждым на практике. 

AppProject: знакомство с файлами манифеста

После установки ArgoCD в директории проекта должен появиться каталог argocd. Внутри него — манифест-файлы для вашей инфраструктуры, в том числе базовый YAML-файл projects/dev.yaml, который полностью описывает проект. 

    # https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/#projects
apiVersion: argoproj.io/v1alpha1

# название проекта
kind: AppProject 
metadata:
  name: development 
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  # описание проекта
  description: Project containing development environment services 

  # ссылка на репозиторий, откуда оператор может делать манифесты, 
  # значение * — любые
  sourceRepos: 
    - '*'

  # набор из пространств имен, в которые можно деплоить 
  # манифесты 
  destinations:
    - namespace: '*'
      server: '*'
  clusterResourceWhitelist:
    - group: '*'
      kind: '*'

Базовый dev.yaml обладает всеми правами доступа и может работать с любыми репозиториями, объектами и кластерами. На его основе можно создавать свои манифест-файлы с другими политиками. 

Чтобы подгрузить рабочий проект, нужно сделать деплой манифест-файлов: 

    kubectl apply -f argocd/projects/dev.yaml

Проект создан, его можно увидеть в ArgoCD WebUI. Кроме того, автоматически «подтягивается» кластер, внутрь которого был установлен ArgoCD. Внутри него можно создавать приложения Kubernetes.

Application

Чтобы настроить деплой приложения ArgoCD, нужно создать и настроить для него конфиг applications/kuber.yaml. 

    apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  # название приложения
  name: kuber 
  namespace: argocd
    - resources-finalizer.argocd.argoproj.io
spec:
  # то же название проекта, что в dev.yaml
  project: development 

  # репозиторий, из которого ArgoCD будет брать код 
  source:
    repoURL: ... 
    targetRevision: master 
    # путь до приложения Kubernetes, деплой которого также описан
    # YAML-файлом (см. пример в репозитории)
    path: your_project/dev/kuber  

    server: https://kubernetes.default.svc
    namespace: kuber

  # параметры для автоматического мониторинга и внесения изменений
  # в Git-репозитория 
  syncPolicy:
    # каждые 3 минуты Ar—goCD проверяет Git-репозиторий
    automated: 
      prune: true 
      # чтобы запретить автоматический деплой, поставьте false
      selfHeal: true 
    syncOptions:         
 - CreateNamespace=true 

Последний этап: осталось сделать деплой Kubernetes-приложения.

    kubectl apply -f argocd/applications/kuber.yaml

После выполнения команды во вкладке Application появится приложение. Также теперь оператор будет автоматически деплоить все изменения из репозитория, на который вы ссылаетесь через repoURL.