Как управлять инфраструктурой в GitOps с помощью Crossplane

Это заключительная часть нашего доклада, из которого вы узнаете:

• Какие инструменты использовали DevOps: от ручных изменений до полной автоматизации
• Какие инструменты позволяют применять модель вытягивания для управления инфраструктурой, создания виртуальных машин (ВМ) и заказа новых серверов в дата-центрах
• Два случая, когда мы объединяем манифесты ApplicationSet и Crossplane

Содержание

• Схема ручного управления
• Первые скрипты для начала
• Ansible-скрипт
• Ansible автоматизация
• Терраформ
• Полная автоматизация
• ArgoCD API и push-модель
• Кроссплан
• Как работать с кросспланом
• Инфраструктура
• Терраджет
• Как мы создали провайдера Crossplane с Terrajet
• Первый случай: начальная загрузка сред
• Второй случай: динамические среды
• Почему полезно совмещать Crossplane и ArgoCD
• Подведение итогов. Почему хорошо автоматизировать

Схема ручного управления

Изначально инженеры DevOps все делали вручную. Они заходили в систему через веб-интерфейс на панели хостинга, делали новую виртуальную машину и заходили в нее. Или они заказывали сервер. Они занимались установкой nginx и настройкой сервера. Все работало так:

Первые скрипты для начала

Позже появилась автоматика. Команды написаны в сценарии Bash и помещены в репозиторий. После этого разработчики идут на сервер, вручную делают «git pull», получают скрипт и устанавливают на него необходимые сервисы и приложения:

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

Ansible-скрипт

Более продвинутые DevOps заменяют сценарий SH сценарием Ansible. Они помещают все в репозиторий, загружают на сервер вручную и запускают Ansible для настройки:

Ansible автоматизация

Самые продвинутые DevOps автоматизируют запуск скрипта Ansible. Для этого они помещают его в CI/CD. Появляется новый сервер, который заносится в «инвентарь». После этого запускается задание CI/CD. Он устанавливает все автоматически:

Единственное неудобство в том, что вам придется создавать сервер вручную. Есть решения, которые автоматизируют все эти процессы. Например, с помощью Ansible вы можете получить виртуальные машины через API хостера. Но самым популярным инструментом для автоматизации является Terraform.

Терраформ

Программа для управления внешними ресурсами.

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

Иногда Terraform хорошо справляется со своей задачей, иногда возникают проблемы. Этот инструмент настолько популярен, что стал стандартом де-факто в подходе «инфраструктура как код» (IaC).

Полная автоматизация

Чтобы получить полную автоматизацию, сам Terraform должен быть автоматизирован. Для этого помещаем его в CI/CD, он запускается и сохраняет свое «состояние» в нужной системе, например GitLab:

ArgoCD API и push-модель

Вернемся к динамическим средам из второй части.

В случае использования API ArgoCD и классической модели push мы можем вставить отдельное задание с именем «среда сборки», в котором мы вызываем Terraform:

Какова альтернатива вытягивающей модели?

Кроссплан

Это еще один из инструментов IaC. Его цель та же, что и у Terraform: создавать инфраструктуру в облаках, развертывать базы данных и кластеры. Как и ArgoCD, он живет в Kubernetes.

В отличие от Terraform, Crossplane постоянно синхронизирует состояние. Terraform — это консольная утилита: синхронизация и изменения происходят только тогда, когда мы пишем terraform plan/apply. С другой стороны, Crossplane использует модель на основе агентов: она всегда отслеживает, что на самом деле находится в облаках и что кодер попросил развернуть в конфигурациях. Если есть несоответствия, Crossplane попытается применить изменения.

Он является частью фонда CNCF, занимающегося разработкой и продвижением облачных технологий.

• Инструмент laC с задачами, аналогичными Terraform
• Живет в Кубернете
• Управляет инфраструктурой
• Постоянно синхронизирует состояние
• Входит в состав CNCF

Инфраструктура

Всю инфраструктуру можно представить в виде кастомных ресурсов в Kubernetes: мы можем описать кластер Postgres или кластер Kubernetes через YAML-файл, точно так же, как мы накатывали приложения в ArgoCD. В конечном итоге это перейдет к Crossplane. Он возьмет спецификацию, отправится в облако и создаст управляемый кластер Postgres или Kubernetes. Crossplane может создать любую инфраструктуру, которая есть у облачного провайдера:

Кроссплан поддерживается:

• АМС
• Облако Google
• Лазурный
• Яндекс.Облако
• Цифровой океан
• Этот список постоянно пополняется

Как работать с кросспланом

Например, мы создаем манифест, описывающий кластер MySQL. Указываем параметры и отправляем в Kubernetes. Crossplane берет эту спецификацию и следует ей, например, чтобы добраться до API Яндекс.Облака. База разворачивается:

apiVersion: mdb.yandex-cloud.jet.crossplane.io/v1alpha1
kind: MySQLCluster
metadata:
 name: mysql-auth
spec:
 forProvider:
   environment: PRODUCTION
   host:
     - zone: ru-central1-b
   name: mysql-auth
   resources:
     - diskSize: 10
       diskTypeId: network-hdd
       resourcePresetId: b2.nano
   networkIdRef:
     name: default
   folderIdRef:
     name: default
   version: "8.0"

Выше мы видим простой манифест для Crossplane, который создает кластер MySQL в Яндекс.Облаке.

Какие возможности мы получаем? Мы можем описать всю инфраструктуру в диаграммах Helm! Не только элементы в Kubernetes, но и любые облачные объекты для настройки среды. Например, записи DNS, группы безопасности, сети и т. д.

Допустим, мы хотим создать кластер Kubernetes в Яндекс.Облаке. Нам нужна группа безопасности, описание кластера и группа узлов. Для этого мы создаем отдельную диаграмму, в которой описываем все эти сущности. Мы используем «значения» для параметризации групп узлов, конфигурации самого кластера, security-группы:

Далее мы опишем кластер PostgreSQL. Для экономии ресурсов удобнее создавать разные базы данных в рамках одного кластера. Для этого создадим две диаграммы:

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

Таким образом, команда может запросить базу в кластере, запись DNS или любую другую облачную сущность через свою диаграмму приложений. Они будут использовать зависимости в виде диаграмм инфраструктуры.

Например, давайте рассмотрим развертывание серверного приложения. Для этого нам обычно нужна база данных и пользователь. Разработчики подключают зависимость в виде второй диаграммы, описанной выше, к диаграмме своего приложения. В результате ArgoCD развертывает как само приложение, так и манифесты для Crossplane. Crossplane использует эти манифесты для создания пользователя и базы внутри кластера. Затем он создает секрет с данными подключения. Этот секрет уже предварительно подключен к модулям приложений посредством развертывания. В итоге все работает автоматически:

Терраджет

Terrafom — настолько популярный инструмент, что с его помощью можно даже заказать пиццу, потому что он умеет тянуть любой API. Вот почему разработчики Crossplane создали инструмент Terrajet. Он может генерировать провайдера на основе Terraform для Crossplane. Terrajet полезен, если ваш провайдер до сих пор не поддерживает Crossplane.

Terrajet сопоставляется с провайдером Terraform и генерирует код провайдера. В итоге имеем проект с кодом Go и сборкой в ​​GitHub Actions:

Как мы создали провайдера Crossplane с Terrajet

Мы заметили, что у наших друзей в компании Selectel не было провайдера Crossplane, поэтому сгенерировали его с Terrajet.

Мы пытались создать спецификацию кластера в Kubernetes, но это не сработало. Для этого нужно изменить статус ответа при создании в API Selectel. Это связано с особенностями Terrajet. Когда Selectel API изменит статус, мы сможем двигаться дальше.

Тем не менее, мы смогли импортировать текущие объекты. Для этого мы указали ID кластера во внешнем имени. Появился статус и дополнительные параметры. Теперь мы можем менять кластер по своему усмотрению.

apiVersion: mks.selectel.jet.crossplane.io/v1alpha1
kind: ClusterV1
metadata:
  name: devopsdemo
  annotations:
    crossplane.io/external-name: "a58b105d-***-f8d63d83fd85"
spec:
  forProvider:
    zonal: true
    projectId: eccc*****f32f
    region: ru-2
    kubeVersion: 1.22.9
  providerConfigRef:
    name: default

status:
  atProvider:
    id: a58b105d-***-f8d63d83fd85
    kubeApiIp: 45.***.***.***
    maintenanceWindowEnd: "03:00:00"
    status: ACTIVE

Первый случай: начальная загрузка сред

Теперь поговорим о случаях, когда мы объединяем манифесты ApplicationSet и Crossplane.

Инженер DevOps создает файл values.yaml с описанием нужной среды. ApplicationSet сопоставляется с папкой среды, поэтому после отправки в Git создается «приложение», развертывающее все объекты внутри Kubernetes (включая манифесты для Crossplane). Он берет эти манифесты и создает необходимые облачные объекты для среды:

Второй случай: динамические среды

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

Например, когда разработчик отправляет ветку в GitLab, в кластере автоматически создается новая база данных, а в секрет приложения кидаются настройки подключения:

Почему полезно совмещать Crossplane и ArgoCD

Команда сама создает инфраструктуру для проектов. Вы можете написать собственных поставщиков для Crossplane. Это полезно, когда у вас большая компания и команда платформы. Разработчики платформ могут писать собственных провайдеров, которые, например, настраивают виртуальные машины внутри своей инфраструктуры и применяют к ним необходимые пакеты.

Кластер Kubernetes — это единая точка взаимодействия с инфраструктурой. Все, что связано с инфраструктурой, представлено в кластере Kubernetes. Вам не нужно множество репозиториев: скажем, для Ansible, для Terraform и еще для чего-то. Кодировщикам не нужно понимать язык HCL и создавать отдельные запросы на слияние в репозиториях с инфраструктурой.

Все используют ресурсы Kubernetes. Не только для развертываний, служб и входов. Почти все уже предоставлено пользовательскими ресурсами: вы можете использовать их для управления всем на платформе.

Подведение итогов. Почему хорошо автоматизировать

Мы начали с разработчика, который загружает веб-сайт на сервер через FTP:

Но в этой простой схеме все делается вручную и находится в голове у одного разработчика. Если не будет разработчика, все рухнет.

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

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

Отслеживать статьи:

Часть 1: История DevOps: от начала времен до ArgoCD и IaC

Часть 2: Как работает Argo CD и как работает подход GitOps

В этой части мы говорили о том, как осуществляется управление инфраструктурой.