Привет! Меня зовут Сергей — я руководитель DevOps-направления студии KTS. 

Мы в компании периодически партнёримся с интересными ребятами и вместе организуем мероприятия: встреча предпринимателей, онлайн-квартирник, День продакт-менеджмента. Этот цикл из трёх статей — текстовая версия выступления со Дня Техдира. Выступление было подготовлено совместно с Southbridge и у него два автора:

Сергей Маленко

Руководитель DevOps-юнита в KTS

Сергей Бондарев

Архитектор в Southbridge

Доклад был посвящён истории развития деплоя приложений, основным моделям и их сравнению. Мы достаточно детально пройдёмся по Pull-модели и покажем, как с помощью «передовых» инструментов организовать управление инфраструктурой больших проектов и дать возможность разработчикам самостоятельно заказывать элементы в инфраструктуре под нужды своих приоложений.

Всего на основе доклада мы подготовили три статьи, которые пойдут по порядку:

  1. Как было и развивалось
    Для понимания контекста рассмотрим, как итеративно изменялся подход к развёртыванию приложений

  2. Что такое ArgoCD и зачем он нужен, с примерами использования
    Рассмотрим относительно новый виток в развитии деплоя приложений, посмотрим, какие вопросы можно закрыть с помощью этого инструмента

  3. Как управлять инфраструктурой в 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, который разрабатывает и продвигает облачные технологии.

  • 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

  • этот список постоянно пополняется

Как работать с 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
https://github.com/ktsstudio/provider-jet-selectel
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

Комментарии (2)


  1. BATAZOR
    11.04.2023 06:25

    Собственно в плане Crossplane не очень понятно чем он дополняет Argo CD. Разве что создавать с нуля кластер, а дальше - управление БД - операторы для rabbitmq, kafka и так дают описать все что нужно в Helm-чарте и не понятно зачем использовать кастомный для конкретного кластера mysqlcluster если можно взять оператор, который не будет завесить от вендора


    1. Sermalenk Автор
      11.04.2023 06:25
      +1

      Не совсем верно понят смысл Crossplane. Он создает объекты в облаке, а не в кластере Kubernetes. То есть это такая замена Terraform, где мы описываем инфраструктуру не в отдельном репе с применением языка HCL, а используем те же инструменты Kubernetes (Custom resources).

      То есть в случае установки кластера БД "своими силами" внутри купленного кластера Kubernetes следует использовать операторы. В случае использования managed кластера БД в облаках – Crossplane (или Terraform в не GitOps подходе).