![](https://habrastorage.org/getpro/habr/upload_files/cd1/89e/a31/cd189ea314aeb232dfb8a251592ad980.jpg)
Привет! Меня зовут Сергей — я руководитель DevOps-направления студии KTS.
Мы в компании периодически партнёримся с интересными ребятами и вместе организуем мероприятия: встреча предпринимателей, онлайн-квартирник, День продакт-менеджмента. Этот цикл из трёх статей — текстовая версия выступления со Дня Техдира. Выступление было подготовлено совместно с Southbridge и у него два автора:
![](https://habrastorage.org/getpro/habr/upload_files/59d/bfb/828/59dbfb82834303b31ad9a06d445d9dd4.png)
Сергей Маленко
Руководитель DevOps-юнита в KTS
![](https://habrastorage.org/getpro/habr/upload_files/394/170/e7b/394170e7bbda0984ce70cc74d6a8a5b1.png)
Сергей Бондарев
Архитектор в Southbridge
Доклад был посвящён истории развития деплоя приложений, основным моделям и их сравнению. Мы достаточно детально пройдёмся по Pull-модели и покажем, как с помощью «передовых» инструментов организовать управление инфраструктурой больших проектов и дать возможность разработчикам самостоятельно заказывать элементы в инфраструктуре под нужды своих приоложений.
Всего на основе доклада мы подготовили три статьи, которые пойдут по порядку:
Как было и развивалось
Для понимания контекста рассмотрим, как итеративно изменялся подход к развёртыванию приложенийЧто такое ArgoCD и зачем он нужен, с примерами использования
Рассмотрим относительно новый виток в развитии деплоя приложений, посмотрим, какие вопросы можно закрыть с помощью этого инструментаКак управлять инфраструктурой в GitOps с помощью Crossplane ← вы здесь ????
Новый подход к IaC и как его можно объединить с ArgoCD
Это финальная часть нашего доклада, в которой вы узнаете:
какие инструменты использовали девопсы: от ручных изменений до полной автоматизации
какие инструменты позволяют применить pull-модель для управления инфраструктурой, создания виртуалок и заказа новых серверов в дата-центрах
два кейса, в которых мы объединяем Application Set и манифесты Crossplane
Содержание
Ручная схема работы
Изначально DevOps-инженеры делали всё руками. Заходили через веб-интерфейс на панели хостинга, накликивали новую виртуалку и заходили в неё — или заказывали сервер. Делали apt install nginx
, ставили сервер и всё работало так:
![](https://habrastorage.org/getpro/habr/upload_files/192/8e1/2db/1928e12db95e3825685a4aa86bf94938.png)
Первые скрипты для старта
Позже сделали автоматизацию. Команды записывают в Bash-скрипт и кладут в репозиторий. После этого заходят на сервер, руками делают git pull, получают скрипт и устанавливают на него необходимые сервисы и приложения:
![](https://habrastorage.org/getpro/habr/upload_files/9f6/799/d40/9f6799d4071c7b50aec44308cfe0d60c.png)
На этом шаге остановилось много организаций. Чтобы получить виртуалку, часто приходится ждать неделю-полторы: нужно написать служебную записку, отправить по инстанциям и только после этого получить доступ.
Ansible-сценарий
Более продвинутые девопсы заменяют скрипт SH на Ansible-сценарий. Кладут всё в репозиторий, скачивают на сервер руками и запускают Ansible для настройки:
![](https://habrastorage.org/getpro/habr/upload_files/10b/dfe/7e8/10bdfe7e82c0618d72d6b7d8f1f4b9ab.png)
Автоматизация Ansible
Самые продвинутые девопсы автоматизируют запуск Ansible-сценария. Для этого его кладут в CI/CD. Появляется новый сервер, который заносят в inventory. После этого запускается CI/CD Job и всё автоматически настраивает:
![](https://habrastorage.org/getpro/habr/upload_files/795/28f/63a/79528f63adf8c980d9cac4d96e480357.png)
Единственное неудобство в том, что сервер приходится создавать руками.
Существуют наработки, которые автоматизируют все эти процессы. Например, с Ansible можно получить виртуалки через API хостера. Но самый популярный инструмент для этого — Terraform.
Terraform
Программа для управления внешними ресурсами.
Для работы не нужно ничего создавать вручную. Достаточно описать конфигурацию для будущей инфраструктуры, и Terraform сделает всё сам:
![](https://habrastorage.org/getpro/habr/upload_files/4ba/688/195/4ba6881952cb3a9b9822ebfb16cd14f5.png)
Иногда Terraform выполняет свою задачу хорошо, иногда могут возникать проблемы. Инструмент настолько популярный, что стал де-факто стандартом в подходе Infrastructure as a Code.
Полная автоматизация
Для полной автоматизации остается автоматизировать Terraform. Для этого запихиваем его в CI/CD, он запускается и сохраняет свой state в нужной системе, например в Gitlab:
![](https://habrastorage.org/getpro/habr/upload_files/c72/a53/d00/c72a53d0014956940469d6121cd38b39.png)
ArgoCD API и Push-модель
Вернемся к динамическим окружениям из второй части.
В случае использования ArgoCD API и классической Push-модели мы можем вставить отдельную Job с названием build environment, в которой вызываем Terraform:
![](https://habrastorage.org/getpro/habr/upload_files/838/d92/68d/838d9268d90d894fbe22e70d985facb0.png)
Какую альтернативу может нам предложить Pull-модель?
Crossplane
Это ещё один из инструментов Infrastructure as a Code. Его предназначение такое же, как у Terraform: создавать инфраструктуру в облаках, разворачивать базы и кластеры. Как и ArgoCD, он живёт в Kubernetes.
В отличие от Terraform, Crossplane постоянно синхронизирует состояние. Terraform — консольная утилита: синхронизация и изменения происходят, только когда мы пишем terraform plan/apply. Crossplane же работает по агентной модели: всегда смотрит, что на самом деле есть в облаках, и что программист попросил развернуть через конфигурации. Если есть несовпадения, Crossplane будет пытаться применить изменения.
Входит в фонд CNCF, который разрабатывает и продвигает облачные технологии.
![](https://habrastorage.org/getpro/habr/upload_files/d44/58d/eaa/d4458deaa9e2e565392bfe4803f23595.png)
laC инструмент с аналогичными Terraform задачами
живёт в Kubernetes
управляет инфраструктурой
постоянно синхронизирует состояние
входит в CNCF
Инфраструктура
Всю инфраструктуру можно представить как custom resources
в Kubernetes: мы можем описать Postgres-кластер или Kubernetes-кластер через YAML-файл так же, как катили applications
в ArgoCD. В итоге это попадёт в Crossplane. Он возьмёт спецификацию, пойдёт в облако и создаст Managed Postgres или Kubernetes кластер. Crossplane может создать любые инфраструктурные вещи, которые предоставляет облачный провайдер:
![](https://habrastorage.org/getpro/habr/upload_files/31a/13d/6fc/31a13d6fc9ddb67d28a49e27f15ae16c.png)
Crossplane поддерживают:
AWS
Google Cloud
Azure
Yandex.Cloud
Digital Ocean
этот список постоянно пополняется
Как работать с Crossplane
Например, мы создаём манифест, описывающий MySQL-кластер. Указываем параметры, отправляем в Kubernetes. Crossplane берёт эту спецификацию, идёт по ней, например, в API Yandex.Cloud. Разворачивается база:
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 cluster в Yandex.Cloud.
Какие возможности нам открываются? Мы можем описывать всю инфраструктуру в helm-чартах! Не только элементы внутри Kubernetes, а любые облачные объекты для настройки окружения. Например, DNS-записи, группы безопасности, сети и так далее.
Допустим, мы хотим создать Kubernetes-кластер в Yandex.Cloud. Нам потребуется security-group
, описание кластерa, node-group
. Для этого создаём отдельный чарт, в котором описываем все эти сущности. Через values параметризируем нод-группы, конфигурацию самого кластера, security-group
:
![](https://habrastorage.org/getpro/habr/upload_files/596/5c7/ba8/5965c7ba827a6cf6c79c4a7765025d5b.png)
Дальше описываем PostgreSQL-кластер. Для экономии ресурсов удобнее создавать внутри одного кластера разные БД. Для этого создаём два чарта:
первый чарт, в котором создаём сам БД-кластер
второй чарт: создаётся конкретная база данных внутри кластера и пользователь к ней. Именно этот чарт мы можем использовать как зависимость для чартов самих приложений
Таким образом, команда через чарт своего приложения может сама попросить базу в кластере, dns-запись или любую другую сущность облака, используя зависимости в виде инфраструктурных чартов.
Например, рассмотрим деплой backend-приложения. Для него обычно нам требуется БД и пользователь к ней. Разработчики подключают к чарту своего приложения зависимость в виде второго чарта, описанного выше. В итоге, ArgoCD разворачивает и само приложение, и манифесты для Crossplane. Crossplane по этим манифестам создаёт пользователя и базу внутри кластера, затем создает секрет с данными для подключения. Этот секрет уже заранее мы примонтировали к подам приложения через deployment
. В итоге всё работает автоматически:
![](https://habrastorage.org/getpro/habr/upload_files/e8f/83d/b2b/e8f83db2ba7e6cda7632858f3f04ea53.png)
Terrajet
Terrafom — настолько популярный инструмент, что через него можно даже заказать пиццу, ведь он умеет дергать любые API. Поэтому разработчики Crossplane создали инструмент Terrajet — он может сгенерировать провайдер для Crossplane на базе Terraform. Terrajet будет полезен, если у вашего провайдера всё ещё нет поддержки Crossplane.
Terrajet натравливается на Terraform-провайдер, и генерирует код провайдера. В итоге мы получаем проект с кодами на Go и сборкой в GitHub Actions:
![](https://habrastorage.org/getpro/habr/upload_files/d41/de6/cf7/d41de6cf716f1c47b9fddfcce4a12199.png)
Как мы создали Crossplane-провайдер через Terrajet
Мы увидели, что у наших друзей в Selectel нет Crossplane-провайдера, и сгенерировали его через Terrajet.
Попробовали создать в Kubernetes спецификацию кластера, но не получилось. Для этого нужно поменять статус ответа при создании в API Selectel. Это связано с особенностями Terrajet. Когда в API Selectel поменяется статус, продвинемся дальше.
Зато мы смогли импортировать текущие сущности. Для этого указали ID кластера в external name.
Появился статус и дополнительные параметры. Теперь можем менять кластер как хотим.
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
![https://github.com/ktsstudio/provider-jet-selectel https://github.com/ktsstudio/provider-jet-selectel](https://habrastorage.org/getpro/habr/upload_files/5f5/25b/cf9/5f525bcf9427fc6042f79df29afd4adc.png)
status:
atProvider:
id: a58b105d-***-f8d63d83fd85
kubeApiIp: 45.***.***.***
maintenanceWindowEnd: "03:00:00"
status: ACTIVE
Первый кейс: бустрапинг окружений
Теперь поговорим о кейсах, в которых мы объединяем Application Set и Crossplane-манифесты.
DevOps-инженер создаёт values.yaml
файл с описанием нужного окружения. Application Set натравлен на папку с окружениями, поэтому он после пуша в гит создает application, разворачивая все сущности внутри Kubernetes, в том числе манифесты для Crossplane. Он берёт эти манифесты и создаёт необходимые объекты в облаках для окружения:
![](https://habrastorage.org/getpro/habr/upload_files/1a4/8d0/7bc/1a48d07bc03e020dce1ec1e1519a1a9f.png)
Второй кейс: динамические окружения
В динамических окружениях мы можем использовать тот самый второй чарт для создания отдельной БД и пользователя внутри общего кластера.
Например, когда разработчик отправляет ветку в Gitlab — в кластере автоматически создаётся новая база, и в секрет для приложения прокидываются настройки для подключения:
![](https://habrastorage.org/getpro/habr/upload_files/447/54e/0a4/44754e0a4c387277d6dd1477b4402277.png)
Чем полезно объединить Crossplane и ArgoCD
Команда сама создаёт инфраструктуру для проектов. Для Crossplane можно писать свои провайдеры. Это полезно, когда у вас большая компания и есть платформенная команда. Программисты платформы могут писать свои провайдеры, которые, например, сетапят виртуалки внутри своей инфраструктуры и накатывают на них необходимые пакеты.
Kubernetes-кластер — единый центр взаимодействия с инфраструктурой. Всё, что связано с инфраструктурой, представлено в Kubernetes-кластере. Нет тридцати репозиториев: мол, тут Ansible, тут Terraform, тут ещё что-то. Программистам не нужно разбираться в hcl-языке и создавать отдельные мерж-реквесты в репозиториях с инфраструктурой.
Все используют ресурсы Kubernetes. Не только для деплойментов, сервисов и ингрессов. Почти всё уже предоставляют custom-ресурсы — с помощью них можно управлять всем, что есть в платформе.
Итоги. Почему полезно автоматизировать
Мы начинали с разработчика, который закачивает сайт на сервер по FTP:
![](https://habrastorage.org/getpro/habr/upload_files/b57/108/a7b/b57108a7b1fdbee6d63b9ff4b0611d76.png)
Но в этой простой схеме всё делается руками и находится в голове одного разработчика. Не будет разработчика — всё рухнет.
Поэтому весь мир стремится максимально автоматизировать управление инфраструктурой и деплоем приложений. В результате, с одной стороны, мы приходим к подобным сложным системам. Но с другой, эти системы позволяют:
работать большому количеству команд над проектом
постоянно следить за инфраструктурой и синхронизировать ее состояние
упрощать доставку обновлений на большое количество окружений
![](https://habrastorage.org/getpro/habr/upload_files/9e6/f3e/72e/9e6f3e72e06dab7b6ace999f12ba87ae.png)
Статьи из трека:
В первой части: как развивался DevOps: от начала времен до ArgoCD и laC
Во второй: как работает Argo CD и как устроен GitOps-подход
В этой части мы рассказали, как управляют инфраструктурой.
Другие статьи про DevOps для начинающих:
Другие статьи про DevOps для продолжающих:
За последние годы де-факто стандартом оркестрации и запуска приложений стал Kubernetes. Поэтому умение управлять Kubernetes-кластерами является особенно важным в работе любого современного DevOps-инженера.
Порог входа может казаться достаточно высоким из-за большого числа компонентов и связей между ними внутри системы. На курсе «Деплой приложений в Kubernetes» мы рассмотрим самые важные концепции, необходимые для управления кластерами любой сложности и научим применять эти знания на практике.
???? Почитать про курс подробнее можно здесь: https://vk.cc/cn0ty6
BATAZOR
Собственно в плане Crossplane не очень понятно чем он дополняет Argo CD. Разве что создавать с нуля кластер, а дальше - управление БД - операторы для rabbitmq, kafka и так дают описать все что нужно в Helm-чарте и не понятно зачем использовать кастомный для конкретного кластера mysqlcluster если можно взять оператор, который не будет завесить от вендора
Sermalenk Автор
Не совсем верно понят смысл Crossplane. Он создает объекты в облаке, а не в кластере Kubernetes. То есть это такая замена Terraform, где мы описываем инфраструктуру не в отдельном репе с применением языка HCL, а используем те же инструменты Kubernetes (Custom resources).
То есть в случае установки кластера БД "своими силами" внутри купленного кластера Kubernetes следует использовать операторы. В случае использования managed кластера БД в облаках – Crossplane (или Terraform в не GitOps подходе).