Привет! Меня зовут Сергей — я руководитель DevOps-направления в KTS.
Мы в компании периодически партнёримся с интересными ребятами и вместе организуем мероприятия: встреча предпринимателей, онлайн-квартирник, День продакт-менеджмента. Этот цикл из трёх статей — текстовая версия выступления со Дня Техдира. Выступление было подготовлено совместно с Southbridge и у него два автора:
Сергей Маленко
Руководитель DevOps-юнита в KTS
Сергей Бондарев
Архитектор в Southbridge
Доклад был посвящён истории развития деплоя приложений, основным моделям и их сравнению. Мы достаточно детально пройдёмся по Pull-модели и покажем, как с помощью «передовых» инструментов организовать управление инфраструктурой больших проектов и дать возможность разработчикам самостоятельно заказывать элементы в инфраструктуре под нужды своих приоложений.
Всего на основе доклада мы подготовили три статьи, которые пойдут по порядку:
Как было и развивалось
Для понимания контекста рассмотрим, как итеративно изменялся подход к развёртыванию приложенийЧто такое ArgoCD и зачем он нужен, с примерами использования
Рассмотрим относительно новый виток в развитии деплоя приложений, посмотрим, какие вопросы можно закрыть с помощью этого инструментаКак управлять инфраструктурой в GitOps с помощью Crossplane ← вы здесь ?
Новый подход к IaC и как его можно объединить с ArgoCD
Это финальная часть нашего доклада, в которой вы узнаете:
какие инструменты использовали девопсы: от ручных изменений до полной автоматизации
какие инструменты позволяют применить pull-модель для управления инфраструктурой, создания виртуалок и заказа новых серверов в дата-центрах
два кейса, в которых мы объединяем Application Set и манифесты Crossplane
Содержание
Ручная схема работы
Изначально DevOps-инженеры делали всё руками. Заходили через веб-интерфейс на панели хостинга, накликивали новую виртуалку и заходили в неё — или заказывали сервер. Делали apt install nginx
, ставили сервер и всё работало так:
Первые скрипты для старта
Позже сделали автоматизацию. Команды записывают в Bash-скрипт и кладут в репозиторий. После этого заходят на сервер, руками делают git pull, получают скрипт и устанавливают на него необходимые сервисы и приложения:
На этом шаге остановилось много организаций. Чтобы получить виртуалку, часто приходится ждать неделю-полторы: нужно написать служебную записку, отправить по инстанциям и только после этого получить доступ.
Ansible-сценарий
Более продвинутые девопсы заменяют скрипт SH на Ansible-сценарий. Кладут всё в репозиторий, скачивают на сервер руками и запускают Ansible для настройки:
Автоматизация Ansible
Самые продвинутые девопсы автоматизируют запуск Ansible-сценария. Для этого его кладут в CI/CD. Появляется новый сервер, который заносят в inventory. После этого запускается CI/CD Job и всё автоматически настраивает:
Единственное неудобство в том, что сервер приходится создавать руками.
Существуют наработки, которые автоматизируют все эти процессы. Например, с Ansible можно получить виртуалки через API хостера. Но самый популярный инструмент для этого — Terraform.
Terraform
Программа для управления внешними ресурсами.
Для работы не нужно ничего создавать вручную. Достаточно описать конфигурацию для будущей инфраструктуры, и Terraform сделает всё сам:
Иногда Terraform выполняет свою задачу хорошо, иногда могут возникать проблемы. Инструмент настолько популярный, что стал де-факто стандартом в подходе Infrastructure as a Code.
Полная автоматизация
Для полной автоматизации остается автоматизировать Terraform. Для этого запихиваем его в CI/CD, он запускается и сохраняет свой state в нужной системе, например в Gitlab:
ArgoCD API и Push-модель
Вернемся к динамическим окружениям из второй части.
В случае использования ArgoCD API и классической Push-модели мы можем вставить отдельную Job с названием build environment, в которой вызываем Terraform:
Какую альтернативу может нам предложить Pull-модель?
Crossplane
Это ещё один из инструментов Infrastructure as a Code. Его предназначение такое же, как у Terraform: создавать инфраструктуру в облаках, разворачивать базы и кластеры. Как и ArgoCD, он живёт в Kubernetes.
В отличие от Terraform, Crossplane постоянно синхронизирует состояние. Terraform — консольная утилита: синхронизация и изменения происходят, только когда мы пишем terraform plan/apply. Crossplane же работает по агентной модели: всегда смотрит, что на самом деле есть в облаках, и что программист попросил развернуть через конфигурации. Если есть несовпадения, Crossplane будет пытаться применить изменения.
Входит в фонд CNCF, который разрабатывает и продвигает облачные технологии.
Инфраструктура
Всю инфраструктуру можно представить как custom resources
в Kubernetes: мы можем описать Postgres-кластер или Kubernetes-кластер через YAML-файл так же, как катили applications
в ArgoCD. В итоге это попадёт в Crossplane. Он возьмёт спецификацию, пойдёт в облако и создаст Managed Postgres или Kubernetes кластер. Crossplane может создать любые инфраструктурные вещи, которые предоставляет облачный провайдер:
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
:
Дальше описываем PostgreSQL-кластер. Для экономии ресурсов удобнее создавать внутри одного кластера разные БД. Для этого создаём два чарта:
первый чарт, в котором создаём сам БД-кластер
второй чарт: создаётся конкретная база данных внутри кластера и пользователь к ней. Именно этот чарт мы можем использовать как зависимость для чартов самих приложений
Таким образом, команда через чарт своего приложения может сама попросить базу в кластере, dns-запись или любую другую сущность облака, используя зависимости в виде инфраструктурных чартов.
Например, рассмотрим деплой backend-приложения. Для него обычно нам требуется БД и пользователь к ней. Разработчики подключают к чарту своего приложения зависимость в виде второго чарта, описанного выше. В итоге, ArgoCD разворачивает и само приложение, и манифесты для Crossplane. Crossplane по этим манифестам создаёт пользователя и базу внутри кластера, затем создает секрет с данными для подключения. Этот секрет уже заранее мы примонтировали к подам приложения через deployment
. В итоге всё работает автоматически:
Terrajet
Terrafom — настолько популярный инструмент, что через него можно даже заказать пиццу, ведь он умеет дергать любые API. Поэтому разработчики Crossplane создали инструмент Terrajet — он может сгенерировать провайдер для Crossplane на базе Terraform. Terrajet будет полезен, если у вашего провайдера всё ещё нет поддержки Crossplane.
Terrajet натравливается на Terraform-провайдер, и генерирует код провайдера. В итоге мы получаем проект с кодами на Go и сборкой в GitHub Actions:
Как мы создали 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
status:
atProvider:
id: a58b105d-***-f8d63d83fd85
kubeApiIp: 45.***.***.***
maintenanceWindowEnd: "03:00:00"
status: ACTIVE
Первый кейс: бустрапинг окружений
Теперь поговорим о кейсах, в которых мы объединяем Application Set и Crossplane-манифесты.
DevOps-инженер создаёт values.yaml
файл с описанием нужного окружения. Application Set натравлен на папку с окружениями, поэтому он после пуша в гит создает application, разворачивая все сущности внутри Kubernetes, в том числе манифесты для Crossplane. Он берёт эти манифесты и создаёт необходимые объекты в облаках для окружения:
Второй кейс: динамические окружения
В динамических окружениях мы можем использовать тот самый второй чарт для создания отдельной БД и пользователя внутри общего кластера.
Например, когда разработчик отправляет ветку в Gitlab — в кластере автоматически создаётся новая база, и в секрет для приложения прокидываются настройки для подключения:
Чем полезно объединить Crossplane и ArgoCD
Команда сама создаёт инфраструктуру для проектов. Для Crossplane можно писать свои провайдеры. Это полезно, когда у вас большая компания и есть платформенная команда. Программисты платформы могут писать свои провайдеры, которые, например, сетапят виртуалки внутри своей инфраструктуры и накатывают на них необходимые пакеты.
Kubernetes-кластер — единый центр взаимодействия с инфраструктурой. Всё, что связано с инфраструктурой, представлено в Kubernetes-кластере. Нет тридцати репозиториев: мол, тут Ansible, тут Terraform, тут ещё что-то. Программистам не нужно разбираться в hcl-языке и создавать отдельные мерж-реквесты в репозиториях с инфраструктурой.
Все используют ресурсы Kubernetes. Не только для деплойментов, сервисов и ингрессов. Почти всё уже предоставляют custom-ресурсы — с помощью них можно управлять всем, что есть в платформе.
Итоги. Почему полезно автоматизировать
Мы начинали с разработчика, который закачивает сайт на сервер по FTP:
Но в этой простой схеме всё делается руками и находится в голове одного разработчика. Не будет разработчика — всё рухнет.
Поэтому весь мир стремится максимально автоматизировать управление инфраструктурой и деплоем приложений. В результате, с одной стороны, мы приходим к подобным сложным системам. Но с другой, эти системы позволяют:
работать большому количеству команд над проектом
постоянно следить за инфраструктурой и синхронизировать ее состояние
упрощать доставку обновлений на большое количество окружений
Статьи из трека:
В первой части: как развивался DevOps: от начала времен до ArgoCD и laC
Во второй: как работает Argo CD и как устроен GitOps-подход
В этой части мы рассказали, как управляют инфраструктурой.
Другие статьи про DevOps для начинающих:
Другие статьи про DevOps для продолжающих:
За последние годы де-факто стандартом оркестрации и запуска приложений стал Kubernetes. Поэтому умение управлять Kubernetes-кластерами является особенно важным в работе любого современного DevOps-инженера.
Порог входа может казаться достаточно высоким из-за большого числа компонентов и связей между ними внутри системы. На курсе «Деплой приложений в Kubernetes» мы рассмотрим самые важные концепции, необходимые для управления кластерами любой сложности и научим применять эти знания на практике.
? Почитать про курс подробнее можно здесь: https://vk.cc/cn0ty6