Возможности vRA-провайдера Terraform для создания деплойментов не ограничиваются работой с облачными шаблонами и элементами каталога. Развертывания можно создавать полностью с нуля, собирая их как конструктор из различных ресурсов. Какой из перечисленных методов самый оптимальный? Вначале разберём последний, затем сравним все три варианта.
Ресурсы vRA провайдера
Перед запуском первого примера посмотрите документацию по основным типам ресурсов провайдера vRA, обратите внимание на следующие ресурсы:
- vra_machine – описание ресурса для создания виртуальной машины в облаке;
- vra_network – описание конфигурации сети, мы будем подключать VM к уже настроенным сетям;
- vra_block_device – описание ресурса для создания дополнительных дисков;
- vra_deployment – деплоймент vRA.
Пример 1. Простой деплоймент, одна VM:
# main.tf
provider "vra" {
url = var.vra_url
refresh_token = var.vra_refresh_token
}
data "vra_project" "this" {
name = var.project_name
}
data "vra_network" "this" {
name = var.network_name
}
resource "vra_machine" "vm_test" {
name = "${var.vm_prefix}-as1"
description = var.vm_description
project_id = data.vra_project.this.id
image = var.vm_image
flavor = var.vm_flavor
nics {
network_id = data.vra_network.this.id
addresses = var.vm_ip_address
}
}
Файлы доступны для загрузки на https://github.com/isas2.
По данной конфигурации Terraform будет создана одна виртуальная машина, деплоймент vRA для неё не описан, но он будет создан автоматически. Если Вы добавите в эту конфигурацию ещё одну виртуальную машину, то она будет помещена в отдельный деплоймент. И так каждый ресурс…
Для объединения нескольких ресурсов в одном деплойменте укажите ID деплоймента первого ресурса при создании всех остальных:
resource "vra_machine" "vm_test_1" {
...
}
resource "vra_machine" "vm_test_2" {
...
deployment_id = vra_machine.vm_test_1.deployment_id
...
}Деплоймент на заказ
Следующий пример создаёт инфраструктуру для развёртывания некоторого кластерного ПО: виртуальные машины (несколько мастер нод, несколько рабочих нод), дополнительные диски для рабочих нод, настройка сети. Использование деплоймента упрощает код и позволяет задать ему произвольные имя и описание.
Пример 2. Кластер VM:
# main.tf
provider "vra" {
url = var.vra_url
refresh_token = var.vra_refresh_token
}
data "vra_project" "this" {
name = var.project_name
}
data "vra_network" "this" {
name = var.network_name
}
resource "random_id" "this" {
byte_length = 4
}
resource "vra_deployment" "this" {
name = "${var.deployment_name}-${random_id.this.hex}"
description = var.deployment_descr
project_id = data.vra_project.this.id
}
resource "vra_block_device" "disk" {
count = var.workers_count
capacity_in_gb = 5
name = "${var.workers_prefix}-disk-0${count.index}"
project_id = data.vra_project.this.id
deployment_id = vra_deployment.this.id
}
resource "vra_machine" "masters" {
count = var.masters_count
name = "${var.masters_prefix}-0${count.index}"
description = var.masters_description
project_id = data.vra_project.this.id
image = var.vm_image
flavor = var.masters_flavor
deployment_id = vra_deployment.this.id
nics {
network_id = data.vra_network.this.id
addresses = [var.masters_ip_addresses[count.index]]
}
}
resource "vra_machine" "workers" {
count = var.workers_count
name = "${var.workers_prefix}-0${count.index}"
description = var.workers_description
project_id = data.vra_project.this.id
image = var.vm_image
flavor = var.workers_flavor
deployment_id = vra_deployment.this.id
nics {
network_id = data.vra_network.this.id
addresses = [var.workers_ip_addresses[count.index]]
}
disks {
block_device_id = vra_block_device.disk[count.index].id
}
}
Файлы доступны для загрузки на https://github.com/isas2.
Облачные шаблоны являются основой для работы IaaS в vRA 8, вся остальная логика построена вокруг них. Отказываясь от использования шаблонов из Terraform, Вы теряете связь с некоторыми ключевыми компонентами vRA и за это приходится платить потерей функциональности:
- В приведённых примерах указываются статические IP-адреса VM. Если убрать из конфигурации сетевых интерфейсов поле addresses, то выделение IP будет по DHCP. Использовать встроенный в vRA IPAM для vra_machine пока нет возможности (получалось работать с настроенным в vRA внешним IPAM, указав статический IP за пределами используемой подсети – костыль);
- Выделение ресурсов в обход основной логики системы требует повышенных привилегий: только Cloud Assembly Administrator может работать на таком уровне;
- Terraform провайдер vRA работает не со всеми типами ресурсов, например, нет поддержки Custom Resources;
- Без облачного шаблона на схеме деплоймента не отображаются связи между ресурсами:
Сравнение методов создания деплоймента
1. Создание деплоймента по элементу каталога vRA
Пример и описание смотрите в Terraform + vRA. Быстрый старт.
- Плюсы:
- простота использования;
- возможность вызова любого опубликованного в каталоге элемента, например, процесса vRO;
- Минусы:
- отсутствие гибкости, развертывание создаётся по шаблону администратора vRA.
2. Создание деплойментов из облачных шаблонов
Создание новых шаблонов или использование имеющихся: Terraform + vRA. Blueprints.
- Плюсы:
- возможность создавать новые облачные шаблоны и развёртывания из них;
- внесение изменений в схемы шаблонов для обновления деплойментов;
- Минусы:
- требуется знание синтаксиса написания шаблонов vRA;
- для корректной работы шаблона все его параметры и используемые теги нужно согласовать с администратором vRA;
- добавление кода шаблона vRA в конфигурацию Terraform сильно ухудшает её читаемость.
3. Сборка деплоймента из различных ресурсов
Описание в конфигурации Terraform всех необходимых ресурсов: vra_network, vra_machine, vra_block_device…
- Плюсы:
- полный контроль состава деплоймента;
- описание и изменение каждого ресурса по отдельности;
- Минусы:
- более сложная конфигурация, нужно учесть все параметры будущего развёртывания;
- отсутствует поддержка Custom Resources vRA;
- требуется роль Cloud Assembly Administrator;
- не поддерживается работа со встроенным в vRA IPAM.
На первый взгляд могло показаться, что создание деплойментов через описание отдельных ресурсов – это самый мощный и гибкий способ работы Terraform с vRA. Однако имеющиеся недостатки очень сильно ограничивают возможности его применения в реальных проектах.
По моему мнению, самым оптимальным вариантом является использование облачных шаблонов и хранение кода шаблонов в Git репозитории.