Владислав Ефименко, Автор в Академия Selectel

В статье рассказываем, что такое методология 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-инструменты — о них мы поговорим ниже — содержат методы, объединяющие развертывание, мониторинг, управление кластерами и приложениями. С помощью них можно автоматически обновлять контейнеры — в соответствии с последней версией главной ветки. Оператор здесь выполняет роль посредника между системной оркестрации и конвейером, который проверяет и автоматически синхронизирует состояние репозитория с облачным приложением. Вот, как это работает: Разработчик изменил конфигурацию контейнера и делает pull request, чтобы выпустить изменение в прод. Специалисты проверяют код и отклоняют/утверждают слияние. Слияние активирует конвейер CI/CD, который автоматически тестирует и добавляет код в реестр (registry). Оператор регистрирует и скачивает обновление, а после — отправляет подключенному локальному репозиторию. Готово — обновление вышло в продакшен. Но все ли так просто на практике? Популярные инструменты Давайте рассмотрим популярные инструменты, которые можно использовать для управления контейнерными приложениями по 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. Подготовка окружения Для начала нужно подготовить пространство нашего проекта — установить kubectl, VirtualBox (или KVM) и minikube. Это можно сделать прямо внутри виртуального окружения. Далее нужно установить в директиву своего проекта ArgoCD, извлечь initial password и подключиться к ArgoCD WebUI по localhost. В качестве username укажите admin. Супер — теперь можно задеплоить приложение через WebUI. Но давайте разберем IaC-подход и опишем свой K8s-проект через YAML-файл. Деплой проекта Kubernetes ArgoCD оперирует специальными пользовательскими ресурсами (Custom Resource Definition) для Kubernetes — Application, ApplicationSet и AppProject. Разберемся с каждым на практике. AppProject: знакомство с файлами манифеста После установки ArgoCD в директории проекта должен появиться каталог argocd. Внутри него — манифест-файлы для вашей инфраструктуры, в том числе базовый YAML-файл projects/dev.yaml, который полностью описывает проект. Базовый dev.yaml обладает всеми правами доступа и может работать с любыми репозиториями, объектами и кластерами. На его основе можно создавать свои манифест-файлы с другими политиками. Чтобы подгрузить рабочий проект, нужно сделать деплой манифест-файлов: Проект создан, его можно увидеть в ArgoCD WebUI. Кроме того, автоматически «подтягивается» кластер, внутрь которого был установлен ArgoCD. Внутри него можно создавать приложения Kubernetes. Список проектов. Список доступных Kubernetes-кластеров. Application Чтобы настроить деплой приложения ArgoCD, нужно создать и настроить для него конфиг applications/kuber.yaml. Последний этап: осталось сделать деплой Kubernetes-приложения. После выполнения команды во вкладке Application появится приложение. Также теперь оператор будет автоматически деплоить все изменения из репозитория, на который вы ссылаетесь через repoURL.