Привет! Меня зовут Сергей — я руководитель DevOps-направления студии KTS.  Мы в компании периодически партнёримся с интересными ребятами и вместе организуем мероприятия: встреча предпринимателей, онлайн-квартирник, День продакт-менеджмента. Этот цикл из трёх статей — текстовая версия выступления со Дня Техдира. Выступление было подготовлено совместно с Southbridge и у него два автора: Руководитель DevOps-юнита в KTS Архитектор в Southbridge Доклад был посвящён истории развития деплоя приложений, основным моделям и их сравнению. Мы достаточно детально пройдёмся по Pull-модели и покажем, как с помощью «передовых» инструментов организовать управление инфраструктурой больших проектов и дать возможность разработчикам самостоятельно заказывать элементы в инфраструктуре под нужды своих приоложений. Всего на основе доклада мы подготовили три статьи, которые пойдут по порядку: Как было и развивалосьДля понимания контекста рассмотрим, как итеративно изменялся подход к развёртыванию приложений Что такое ArgoCD и зачем он нужен, с примерами использованияРассмотрим относительно новый виток в развитии деплоя приложений, посмотрим, какие вопросы можно закрыть с помощью этого инструмента Как управлять инфраструктурой в GitOps с помощью Crossplane  ← вы здесь 🚩Новый подход к IaC и как его можно объединить с ArgoCD Это финальная часть нашего доклада, в которой вы узнаете: какие инструменты использовали девопсы: от ручных изменений до полной автоматизации какие инструменты позволяют применить pull-модель для управления инфраструктурой, создания виртуалок и заказа новых серверов в дата-центрах два кейса, в которых мы объединяем Application Set и манифесты Crossplane Ручная схема работы Первые скрипты для старта Ansible-сценарий Автоматизация Ansible Terraform Полная автоматизация ArgoCD API и Push-модель Crossplane Как работать с Crossplane Инфраструктура Terrajet Как мы создали Crossplane-провайдер через Terrajet Первый кейс: бустрапинг окружений Второй кейс: динамические окружения Чем полезно объединить Crossplane и ArgoCD Итоги. Почему полезно автоматизировать Изначально DevOps-инженеры делали всё руками. Заходили через веб-интерфейс на панели хостинга, накликивали новую виртуалку и заходили в неё — или заказывали сервер. Делали apt install nginx, ставили сервер и всё работало так: Позже сделали автоматизацию. Команды записывают в Bash-скрипт и кладут в репозиторий. После этого заходят на сервер, руками делают git pull, получают скрипт и устанавливают на него необходимые сервисы и приложения: На этом шаге остановилось много организаций. Чтобы получить виртуалку, часто приходится ждать неделю-полторы: нужно написать служебную записку, отправить по инстанциям и только после этого получить доступ. Более продвинутые девопсы заменяют скрипт SH на Ansible-сценарий. Кладут всё в репозиторий, скачивают на сервер руками и запускают Ansible для настройки: Самые продвинутые девопсы автоматизируют запуск Ansible-сценария. Для этого его кладут в CI/CD. Появляется новый сервер, который заносят в inventory. После этого запускается CI/CD Job и всё автоматически настраивает: Единственное неудобство в том, что сервер приходится создавать руками. Существуют наработки, которые автоматизируют все эти процессы. Например, с Ansible можно получить виртуалки через API хостера. Но самый популярный инструмент для этого — Terraform. Программа для управления внешними ресурсами.  Для работы не нужно ничего создавать вручную. Достаточно описать конфигурацию для будущей инфраструктуры, и Terraform сделает всё сам: Иногда Terraform выполняет свою задачу хорошо, иногда могут возникать проблемы. Инструмент настолько популярный, что стал де-факто стандартом в подходе Infrastructure as a Code. Для полной автоматизации остается автоматизировать Terraform. Для этого запихиваем его в CI/CD, он запускается и сохраняет свой state в нужной системе, например в Gitlab: Вернемся к динамическим окружениям из второй части. В случае использования ArgoCD API и классической Push-модели мы можем вставить отдельную Job с названием build environment, в которой вызываем Terraform: Какую альтернативу может нам предложить Pull-модель? Это ещё один из инструментов Infrastructure as a Code. Его предназначение такое же, как у Terraform: создавать инфраструктуру в облаках, разворачивать базы и кластеры. Как и ArgoCD, он живёт в Kubernetes. В отличие от Terraform, Crossplane постоянно синхронизирует состояние. Terraform — консольная утилита: синхронизация и изменения происходят, только когда мы пишем terraform plan/apply. Crossplane же работает по агентной модели: всегда смотрит, что на самом деле есть в облаках, и что программист попросил развернуть через конфигурации. Если есть несовпадения, Crossplane будет пытаться применить изменения. Входит в фонд CNCF, который разрабатывает и продвигает облачные технологии. laC инструмент с аналогичными Terraform задачами живёт в Kubernetes управляет инфраструктурой постоянно синхронизирует состояние входит в CNCF Всю инфраструктуру можно представить как custom resources в Kubernetes: мы можем описать Postgres-кластер или Kubernetes-кластер через YAML-файл так же, как катили applications в ArgoCD. В итоге это попадёт в Crossplane. Он возьмёт спецификацию, пойдёт в облако и создаст Managed Postgres или Kubernetes кластер. Crossplane может создать любые инфраструктурные вещи, которые предоставляет облачный провайдер: Crossplane поддерживают: AWS Google Cloud Azure Yandex.Cloud Digital Ocean этот список постоянно пополняется Например, мы создаём манифест, описывающий MySQL-кластер. Указываем параметры, отправляем в Kubernetes. Crossplane берёт эту спецификацию, идёт по ней, например, в API Yandex.Cloud. Разворачивается база:  Выше — простой манифест для 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. В итоге всё работает автоматически: Terrafom — настолько популярный инструмент, что через него можно даже заказать пиццу, ведь он умеет дергать любые API. Поэтому разработчики Crossplane создали инструмент Terrajet — он может сгенерировать провайдер для Crossplane на базе Terraform. Terrajet будет полезен, если у вашего провайдера всё ещё нет поддержки Crossplane. Terrajet натравливается на Terraform-провайдер, и генерирует код провайдера. В итоге мы получаем проект с кодами на Go и сборкой в GitHub Actions: Мы увидели, что у наших друзей в Selectel нет Crossplane-провайдера, и сгенерировали его через Terrajet. Попробовали создать в Kubernetes спецификацию кластера, но не получилось. Для этого нужно поменять статус ответа при создании в API Selectel. Это связано с особенностями Terrajet. Когда в API Selectel поменяется статус, продвинемся дальше. Зато мы смогли импортировать текущие сущности. Для этого указали ID кластера в external name. Появился статус и дополнительные параметры. Теперь можем менять кластер как хотим. Теперь поговорим о кейсах, в которых мы объединяем Application Set и Crossplane-манифесты. DevOps-инженер создаёт values.yaml файл с описанием нужного окружения. Application Set натравлен на папку с окружениями, поэтому он после пуша в гит создает application, разворачивая все сущности внутри Kubernetes, в том числе манифесты для Crossplane. Он берёт эти манифесты и создаёт необходимые объекты в облаках для окружения: В динамических окружениях мы можем использовать тот самый второй чарт для создания отдельной БД и пользователя внутри общего кластера.  Например, когда разработчик отправляет ветку в Gitlab — в кластере автоматически создаётся новая база, и в секрет для приложения прокидываются настройки для подключения: Команда сама создаёт инфраструктуру для проектов. Для Crossplane можно писать свои провайдеры. Это полезно, когда у вас большая компания и есть платформенная команда. Программисты платформы могут писать свои провайдеры, которые, например, сетапят виртуалки внутри своей инфраструктуры и накатывают на них необходимые пакеты.  Kubernetes-кластер — единый центр взаимодействия с инфраструктурой. Всё, что связано с инфраструктурой, представлено в Kubernetes-кластере. Нет тридцати репозиториев: мол, тут Ansible, тут Terraform, тут ещё что-то. Программистам не нужно разбираться в hcl-языке и создавать отдельные мерж-реквесты в репозиториях с инфраструктурой. Все используют ресурсы Kubernetes. Не только для деплойментов, сервисов и ингрессов. Почти всё уже предоставляют custom-ресурсы — с помощью них можно управлять всем, что есть в платформе. Мы начинали с разработчика, который закачивает сайт на сервер по FTP: Но в этой простой схеме всё делается руками и находится в голове одного разработчика. Не будет разработчика — всё рухнет. Поэтому весь мир стремится максимально автоматизировать управление инфраструктурой и деплоем приложений. В результате, с одной стороны, мы приходим к подобным сложным системам. Но с другой, эти системы позволяют: работать большому количеству команд над проектом постоянно следить за инфраструктурой и синхронизировать ее состояние упрощать доставку обновлений на большое количество окружений В первой части: как развивался DevOps: от начала времен до ArgoCD и laC Во второй: как работает Argo CD и как устроен GitOps-подход В этой части мы рассказали, как управляют инфраструктурой. Другие статьи про DevOps для начинающих: Сравнение Kubernetes с другими оркестраторами: Docker Swarm, Nomad, Openshift Как изучать Kubernetes джуну — и зачем Как деплоить приложение на Django в Kubernetes с нуля Другие статьи про DevOps для продолжающих: Как построить эргономичный мониторинг Зачем мы сделали собственный контроллер для копирования секретов в Kubernetes Как экономить ресурсы, затрачиваемые Kubernetes За последние годы де-факто стандартом оркестрации и запуска приложений стал Kubernetes. Поэтому умение управлять Kubernetes-кластерами является особенно важным в работе любого современного DevOps-инженера.  Порог входа может казаться достаточно высоким из-за большого числа компонентов и связей между ними внутри системы. На курсе «Деплой приложений в Kubernetes» мы рассмотрим самые важные концепции, необходимые для управления кластерами любой сложности и научим применять эти знания на практике. 👉 Почитать про курс подробнее можно здесь: https://vk.cc/cn0ty6  Head of DevOps