Немного про Infrastructure as Code в VMmanager и про ценности для IT-отделов и всей компании

Привет, Хабр! Недавно мы выпустили новую функциональность в продукте VMmanager — интеграцию с Terraform и Swagger для работы в рамках концепции Infrastructure as Code. В этой статье я хочу крупноуровнево рассказать о таком подходе, немного раскрыть составляющие нашей интеграции и представить пару примеров. 

IaC — про разработку, тестирование и развертывание

IaC — это модель выдачи и обслуживания серверов и связанной с ними инфраструктуры с помощью машиночитаемых файлов-определений, созданная как альтернатива конфигурированию оборудования вручную. Это достаточно модный и молодежный подход в обслуживании IT-инфраструктуры, набирающий популярность в России и мире. Его появление изменило процессы в IT-отделах компаний и добавило DevOps-составляющие в роль классического системного администратора. 

Но модель IaC затронула не только классические IT-отделы, еще она изменила процессы в командах тестирования и разработки. 

С чем связана такая популярность IaC? А связана она с той ценностью и преимуществами, которые предлагает эта модель сотрудникам IT-отдела, с одной стороны, и всего бизнеса — с другой. IaC позволяет эффективно управлять конфигурациями и контролировать любые изменения конфигураций в облаке или on-premise в описательной модели с использованием системы контроля версий состояния инфраструктуры. Подобно тому, как среда разработки компилирует код в один и тот же двоичный файл, IaC при каждом применении формирует одну и ту же конфигурацию окружения, без сюрпризов. 

Специалисты IT-отдела работают с инфраструктурой точно так же, как работали бы с кодом при создании приложений, в том числе возможно использование системы контроля версий.

Модель IaC является одной из ключевых методик в DevOps и часто используется совместно с CI/CD, а ее развитие обусловлено в первую очередь проблемой, которая называется «дрейф конфигураций», в информационной системе. Это связано с тем, что при классическом подходе к администрированию любая информационная система развивается и эволюционирует подобно биологической системе, накапливая артефакты и ошибки в процессе своей жизни. Можно сказать, обретает характер и становится своего рода снежинкой — уникальным объектом с особым подходом, особыми конфигурациями, уникальным обслуживающим персоналом. 

Автоматическое развертывание и обслуживание такой системы связано с выполнением ручных операций которые сложно отследить и автоматизировать. 

Само собой, растет риск ошибок, обусловленных человеческим фактором. Увеличивается time-to-market для новых проектов, а задачи масштабирования оцениваются какими-то космическими ресурсами и трудозатратами и сопровождаются болью.

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

Команды конфигурирования среды для информационной системы описываются в текстовом виде в одном из принятых форматов и выполняются императивно или декларативно.

Разница этих подходов состоит в том что, при императивном подходе указывают, как конкретно выполнить ту или иную задачу. Таким образом работают shell- или ansible-скрипты, в таком стиле выглядит и работа напрямую с API продукта или CLI.

При декларативном подходе DevOps-инженер просто описывает конечное состояние системы — цель, которую нужно достигнуть. Средство автоматизации — в нашем случае это Terraform — провайдер самостоятельно транслирует описанное вами состояние в необходимый набор API-запросов к платформе VMmanager, исключая тот самый злополучный человеческий фактор.

DevOps-инженеры, использующие IaC, начинают управлять вверенной им инфраструктурой абстрактно, без прямого взаимодействия с физическими компонентами инфраструктуры — аппаратными платформами и средствами виртуализации. Независимо от того, где эта инфраструктура находится — в облаке или on-premise, администрирование происходит единообразно.

Очевидно, что IaC-код легко копировать, редактировать и распространять. Но самое приятное в том, что мы имеем контроль версий состояния инфраструктуры. Получается, что у нас есть ветка состояний информационной системы, и мы можем в любой момент откатиться к требуемой версии, используя такой подход.

Это упрощает и ускоряет тестирование и повышает качество выпуска такого объекта инфраструктуры в продакшен. А еще повышается уровень документирования информационных систем, ведь код становится главным источником истины и однозначно описывает состояние информационной системы. А еще такой источник истины никогда не устареет, а ведь многие сталкивались с ситуациями, когда инструкция или документация, с которой нужно работать, не успела за развитием информационной системы и безнадежно устарела.

Чем IaC полезна бизнесу 

Модель IaC стала одним из best-practices в IT-отделах по всему миру. И теперь при помощи IaC компании получают:

• высокую скорость старта и превосходный time-to-market для бизнес-проектов;

• единообразность администрирования облачной и on-premise-инфраструктуры;

• стандартизацию процессов в IT-отделе;

• единый источник истины и контроль версий состояний инфраструктуры;

• идемпотентность;

• автоматизацию рутинных операций;

• минимизацию рисков, связанных с человеческим фактором;

• уменьшение трудозатрат в командах администрирования, тестирования и разработки.

Неудивительно, что бизнес быстро оценил выгоды такого подхода. Возможно, в том числе этим можно объяснить ажиотаж, связанный с вакансиями DevOps-инженеров на рынке труда в России и мире. 

Наша компания тоже не осталась в стороне от модели IaC, а поскольку мы сами являемся пользователями наших продуктов, реализовали следующие интеграции в VMmanager:

• встроенный в платформу Swagger;

• официальный провайдер для Terraform — программный продукт, позволяющий использовать модель IaC в VMmanager. 

Благодаря Swagger взаимодействовать с нашим открытым like REST API можно прямо из интерфейса VMmanager. Это позволит легко и быстро автоматизировать какие-то уникальные бизнес-процессы в вашей компании. Со своей стороны мы всегда соблюдаем обратную совместимость API при развитии продукта. 

Переход во встроенный Swagger доступен только для администраторов, осуществляется прямо из интерфейса продукта и не требует дополнительной авторизации.

Terraform — это инструмент для реализации модели IaC от компании HashiCorp. Использование Terraform имеет несколько дополнительных преимуществ:

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

• Terraform может управлять инфраструктурой on-premise на разных платформах виртуализации, помимо VMmanager. В частности это упрощает переход при задачах импортозамещения.

Использование Terraform-провайдера для VMmanager позволяет описывать требуемое состояние в декларативном стиле, избавиться от «уникальных снежинок» в вашем отделе и в конце концов полностью автоматизировать абсолютно все процессы, связанные с выдачей, обновлением и уничтожением виртуальных объектов в вашей инфраструктуре. 

Хочу рассказать, с какими объектами работает Terraform-провайдер для VMmanager. Прямо сейчас можно управлять:

• созданием, обновлением и уничтожением объектов инфраструктуры;

• конфигурациями виртуальных машин;

• виртуальными дисками;

• физическими сетями, IP-адресами и пулами;

• виртуальными сетями;

• пользователями, группами и доступами.

Что приятно, одни объекты могут быть использованы как параметры конфигурации других, даже если они еще не были созданы.

Подробнее с функциональностью можно познакомится на Github, в документации Terraform и в нашей официальной документации по продукту VMmanager. 

В будущем мы планируем добавить к этому управление в VMmanager:

• подсистемами балансировки нагрузки;

• виртуальными маршрутизаторами;

• файерволом;

• виртуальными кластерами;

• пользователями внутри теннанта;

• облачными проектами и каталогами услуг.

Установка Terraform для работы с VMmanager

Теперь давайте попробуем поработать с Terraform. Предположим, что у нас уже есть установленный и настроенный VMmanager, а если нет, можно ознакомиться с процессом установки по ссылке.

Установим Terraform к себе на машину, в данном случае на macOS, но можно установить и на Linux и даже Windows. Итак: 

1. Установим менеджер пакетов: 

/bin/bash -c ""$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

2. Выполним команды: 

brew tap hashicorp/tap

brew install hashicorp/tap/terraform

brew update

brew upgrade hashicorp/tap/terraform

3. Создадим отдельную директорию под файлы конфигураций Terraform, например так:

mkdir ./terraform

Если репозиторий Terraform недоступен, вы можете скачать дистрибутив ПО из зеркала репозитория. 

Создание файла конфигурации

Теперь нам нужно создать тот самый файл конфигурации с декларативным описанием состояния нужной нам инфраструктуры. Конфигурация — это код, написанный для Terraform с использованием удобочитаемого языка конфигурации HashiCorp (HCL) для описания желаемого состояния ресурсов инфраструктуры. Используется расширение tf. 

В начале файла описывается инициализация провайдера для VMmanager. Провайдер — это плагин, который Terraform использует для управления этими ресурсами через API.

Чтобы использовать провайдер, просто добавьте его в свою конфигурацию как указано в примере ниже. Когда вы запускаете terraform init, Terraform автоматически загрузит все, что ему нужно. Давайте посмотрим пример?

# Инициализация провайдера для VMmanager terraform {   required_providers {     vmmanager6 = {       source  = "usaafko/vmmanager6"       version = ">= 0.0.25"     }   } }  provider "vmmanager6" {   pm_email    = "admin@example.com"             # E-mail администратора   pm_password = "secret"                        # Пароль администратора   pm_api_url  = "https://vmmanager.example.com" # URL сервера с платформой }  # Описание создаваемого ресурса - виртуальной машины (ВМ) resource "vmmanager6_vm_qemu" "test_vm" {    name     = "My_vm"             # Имя ВМ   desc     = "Testing Terraform" # Описание ВМ   cores    = 1                   # Количество ядер CPU   memory   = 512                 # Количество RAM, Mb   disk     = 5000                # Объем дискового пространства,  Mb   os       = 1                   # id шаблона операционной системы   password = "vmsecret"          # Пароль администратора ВМ   cluster  = 1                   # id кластера   # Владелец ВМ. Terraform создаст аккаунт владельца на основе данных   # из ресурса "user" и сохранит его в этом параметре. Вместо    # переменной вы можете указать id существующего пользователя.   account = vmmanager6_account.user.id   domain  = "test.example.com" # Доменное имя ВМ   # Ресурсы, от которых зависит создание ВМ — физическая сеть,   # пул IP-адресов и пользователь. В первую очередь Terraform   # создаст указанные объекты, а затем ВМ.   depends_on = [vmmanager6_network.net1, vmmanager6_pool.pool1, vmmanager6_account.user]   # Из какого пула взять IP-адрес для ВМ. Terraform создаст пул    # на основе данных из ресурса "pool1" и сохранит его в этом   # параметре. Вместо переменной вы можете указать id   # существующего пула.    ipv4_pools  = ["${vmmanager6_pool.pool1.id}"]   ipv4_number = 1 # Количество IP-адресов }  # Описание создаваемого ресурса — физической сети resource "vmmanager6_network" "net1" {   network = "172.31.240.0/20"   # Сеть в формате <адрес сети>/<префикс маски сети>   gateway = "172.31.255.254"    # IP-адрес шлюза   desc    = "Terraform network" # Описание сети }  # Описание создаваемого ресурса — пула IP-адресов resource "vmmanager6_pool" "pool1" {   pool   = "terraform"          # Имя пула   desc   = "Terraform pool"     # Описание пула   ranges = ["172.31.247.16/30"] # Блок IP-адресов, входящих в пул   # Зависимый ресурс — физическая сеть. Terraform создаст пул    # только после создания физической сети.   depends_on = [vmmanager6_network.net1] }  # Описание создаваемого ресурса — учетной записи пользователя resource "vmmanager6_account" "user" {   email    = "user@example.com" # E-mail пользователя   password = "usersecret"       # Пароль пользователя   role     = "@advanced_user"   # Роль пользователя   # Публичный SSH-ключ пользователя. Необязательный параметр.    # Без указания SSH-ключа пользователь сможет подключиться    # к ВМ только по паролю.   ssh_keys {     name = "user123" # Имя пользователя SSH-ключа     # Содержимое публичного SSH-ключа     ssh_pub_key = "ecdsa-sha2-nistp256 AAAAE2VjZ....user@example.com"   } }

Как видно из этого примера, мы можем использовать в качестве параметров ресурсы, которые будут созданы позже. Это очень удобно для описания объекта, параметры которого мы еще не знаем, так как этот они будут определены в будущем под создаваемый объект. 

Запускаем Terraform 

Теперь у нас все готово. И для старта работы с инфраструктурой по модели IaC в декларативном стиле понадобится всего несколько команд с интуитивно понятным названием:

• terraform init — инициализирует проект конфигурации.

• terraform validate — проверит корректность синтаксиса в файле конфигурации, который мы писали выше.

• terraform plan — проверит текущее состояние, запланирует изменения. Вывод команды будет содержать список создаваемых ресурсов и их свойства. 

• terraform aplay — создание объектов инфраструктуры в нужном состоянии.

• terraform destroy — уничтожение объектов. 

Мы не вместо кого-то, мы делаем собственный продукт 

Как бы это ни звучало, мы не развиваем нашу платформу виртуализации в угоду импортозамещению или чьим-то амбициям. И у нас нет задачи реализовывать «то же самое, только отечественное». 

Мы строим собственный продукт. И правильнее было бы сказать, что мы планируем предоставить IT-отделам гибкий и современный инструмент управления серверной виртуализацией, который позволит построить новые, более эффективные процессы обслуживания инфраструктуры в компании. 

Мы хотим поставить на службу ваших IT-отделов автоматизированные, оцифрованные знания и лучшие best-practices в индустрии на данный момент. 

А еще мы, конечно, хотим сделать что-то, чем можно будет гордиться в будущем.

Если вы заинтересовались концепцией IaC и хотите познакомиться с ее вариантом реализации в VMmanager,  предлагаю «пощупать продукт своими руками» и оставить заявку по этой ссылке.

Кстати, все обновления мы анонсируем в telegram-канале ISPsystem — подписывайтесь, если интересно.

Буду очень рад комментариям. А еще, по теме моих статей, можете писать мне в телеграмм.

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