В vRealize Automation 8.2 появилась новая интересная функция – возможность предоставлять Terraform как услугу. Она позволяет расширить каталог vRA, добавив в него облачные шаблоны с манифестами Terraform. А к функционалу Terraform добавляются оркестратор, механизм согласований и управление сроком аренды от vRA.
Подготовка vRA
Официальная документация по работе с Terraform в vRA 8.3: How to include Terraform configurations in vRealize Automation Cloud Assembly.
В текущей реализации (vRA 8.2 и 8.3) Terraform запускается на внешнем кластере Kubernetes. Можно использовать любой из уже подключенных к vRA кластеров Kubernetes или загрузить файл kubeconfig другого кластера. Дополнительно требуется указать существующий namespace для работы и ссылку на образ контейнера, в котором и будут выполняться все задачи Terraform.
Infrastructure -> Integrations -> Add integration -> Terraform Runtime
Данный кластер будет использоваться для всех проектов vRA, можно настроить только один экземпляр Terraform Runtime.
Создание облачного шаблона Terraform
Мы уже делали интеграцию с Яндекс.Облаком с использованием оркестратора и Dymamic Types. Теперь создадим виртуальную машину в облаке Яндекс через Teffaform:
# main.tf terraform { required_providers { yandex = { source = "yandex-cloud/yandex" } } } variable "yc_token" { type = string description = "Yandex Cloud API key" } variable "yc_region" { type = string description = "Yandex Cloud Region (i.e. ru-central1-a)" } variable "yc_cloud_id" { type = string description = "Yandex Cloud id" } variable "yc_folder_id" { type = string description = "Yandex Cloud folder id" } variable "yc_vm_cpu" { type = string description = "Yandex Instance vCPU" } variable "yc_vm_ram" { type = string description = "Yandex Instance RAM" } provider "yandex" { token = var.yc_token cloud_id = var.yc_cloud_id folder_id = var.yc_folder_id zone = var.yc_region } resource "yandex_compute_instance" "vm" { name = "tf-vm-vra-01" allow_stopping_for_update = true resources { cores = var.yc_vm_cpu memory = var.yc_vm_ram } boot_disk { initialize_params { image_id = "fd87va5cc00gaq2f5qfb" } } network_interface { subnet_id = data.yandex_vpc_subnet.subnet-1.id nat = true } metadata = { ssh-keys = "myuser:${file("./id_rsa.pub")}" } } data "yandex_vpc_subnet" "subnet-1" { name = "default-ru-central1-a" } output "internal_ip" { value = yandex_compute_instance.vm.network_interface.0.ip_address } output "external_ip" { value = yandex_compute_instance.vm.network_interface.0.nat_ip_address }
Для работы данного примера потребуется файл id_rsa.pub с открытым SSH-ключом. Свойство allow_stopping_for_update = true необходимо, чтобы иметь возможность изменять конфигурацию инстанса, не останавливая его вручную.
- Создайте конфигурацию Terraform, проверьте её работу и загрузите на Git репозиторий (GitHub, GitLab, Bitbucket). Не загружайте файлы *.tfstate, так как это приведёт к ошибке при развёртывании;
- Подключите данный репозиторий к проекту vRA: Infrastructure > Connections > Integrations. При добавлении репозитория выберите тип Terraform configurations;
- Если в Infrastructure > Configure > Terraform Versions нет нужной версии Terraform, добавьте самостоятельно, официальной поддержки версий 0.13 и старше пока нет;
- В Design > Cloud Templates создайте новый облачный шаблон: New from > Terraform. В форме создания шаблона укажите подключенный репозиторий, выберите нужный commit и подкаталог с файлами конфигураций Terraform.
Все переменные из манифестов будут описаны в шаблоне как входные значения. Для безопасного хранения паролей и токенов лучше использовать новый сервис Infrastructure > Administration > Secrets. Для обращения к сохранённым секретам из облачных шаблонов создан новый объект secret:
.... variables: yc_token: '${secret.YC_TOKEN}' ....
Выходные параметры Terraform (output) будут доступны для использования в выражениях, их можно передавать на вход других ресурсов: ${resource.terraform.outputs.external_ip}.
При добавлении ресурса Terraform Configuration к уже имеющимся шаблонам настраивать его параметры и входные значения придётся вручную, поэтому лучше создать отдельный облачный шаблон Terraform и скопировать из него готовое описание с параметрами.
Запуск и контроль выполнения
Развёртывание выполняется в кластере Kubernetes в виде отдельных заданий (Job):
kubectl get all -n vra
NAME READY STATUS RESTARTS AGE
pod/vra-tf-4814554a-8229-4eb9-9708-841d5c3b7fb5-ltq4v 1/1 Running 0 24s
NAME COMPLETIONS DURATION AGE
job.batch/vra-tf-4814554a-8229-4eb9-9708-841d5c3b7fb5 0/1 24s 24s
Для каждого ресурса Terraform Configuration в кластере последовательно создаётся две задачи: для запуска terraform plan и terraform apply.
Все события, а также полные логи работы Terraform доступны в развёртывании на вкладке History. Ссылка Show Logs покажет логи прямо во вкладке History, это не совсем удобно, ссылка View as plain text откроет их в отдельной вкладке:
Для объекта terraform доступно два действия: Get Terraform State и Refresh Terraform State. На схеме шаблона каждый ресурс из конфигурации Terraform представлен отдельным элементом, по каждому из них можно посмотреть все атрибуты.
Иногда требуется изменить параметры развёртывания, например, добавить vCPU или RAM виртуальной машине. Метод Update позволяет отредактировать входные значения и запустить обновление конфигурации Terraform.
Отображение облачных зон
Существует ещё одна интересная опция, она называется “Отображение облачных зон для ресурсов Terraform”. Опция позволяет разрешить доступ к уже настроенным облачным зонам в рамках проекта vRA.
При включении опции учётные данные связанных облачных учетных записей будут безопасно передаваться механизму запуска Terraform. Создавая манифест Terraform, учетные данные указывать не нужно:
provider "vsphere" {
allow_unverified_ssl = true
}
В облачном шаблоне vRA самостоятельно пропишет провайдера на основе доступной облачной зоны:
providers:
- name: vsphere
# List of available cloud zones: vc.zabedu.ru/Datacenter:datacenter-31
cloudZone: 'vc.zabedu.ru/Datacenter:datacenter-31'
Внимание! vRA передаёт учётные данные, но пока никак не ограничивает пользователя пределами данной облачной зоны. Например, Вы ограничиваете облачную зону одним кластером vSphere или одним пулом ресурсов, но в Terraform будут переданы учётные данные всего облачного аккаунта. Указав в манифесте другой кластер или пул, пользователь получит доступ к нему и ко всем его ресурсам! Без острой необходимости отображение облачных зон включать не рекомендую, ждём следующих релизов vRA.
Краткие итоги
Плюсы использования Terraform в vRealize Automation 8:
- Предоставляет возможность расширить каталог vRA за счет сервисов на основе конфигураций Terraform;
- Позволяет скрыть от пользователей учетные данные провайдеров Terraform, предоставив им только описанный в манифесте и облачном шаблоне функционал;
- Возможности Terraform расширяются за счет vRA: добавляется согласование выполнения, ограничение сроков использования, запуск дополнительных процессов на различных этапах работы.
Минусы сервиса:
- Отсутствие ограничений на действия пользователя при использовании отображения облачных зон;
- Требуется внешний (по отношению к vRA) кластер Kubernetes с доступом в Интернет.
Для работы в полностью изолированной среде:
- При настройке кластера K8S укажите образ из локального реестра;
- Загрузите архив Terraform на локальный сервер и измените ссылку в настройках Terraform Versions;
- Вместе с манифестами загрузите на Git репозиторий локальный каталог с провайдерами (terraform.d или .terraform в зависимости от версии), но это не всегда работает.