У цій статті ми розглянемо те, що складається з Terraform, а також поетапно запустимо власну інфраструктуру. - підготуємо три VM для різних цілей: проксі, файлове сховище та CMS.
Про все докладно і в три етапи:
1. Terraform - опис, переваги та складові
Terraform – це IaC (Infrastructure-as-Code) інструмент для побудови та управління віртуальною інфраструктурою за допомогою коду .
У роботі з інструментом ми відзначили кілька переваг:
-
Швидкість розгортання нових тенантів (Спосіб користувача віртуальних середовищ). Зазвичай чим більше нових клієнтів, тим більше «кліків» потрібно зробити співробітникам технічної підтримки для публікації нових ресурсів. З Terraform користувачі можуть змінювати параметри віртуальних машин (наприклад, автоматично вимикати ОС та збільшувати розділ віртуального диска) без участі технічної підтримки та вимкнення самої машини.
-
Миттєва перевірка плану активації нового тенанта. За допомогою опису коду інфраструктури ми можемо одразу ж перевірити, що і в якому порядку буде додано, а також у якому кінцевому стані буде та чи інша віртуальна машина або віртуальна мережа з підключенням до віртуальних машин.
-
Можливість описувати більшість популярних хмарних платформ. Ви можете використовувати інструмент від Amazon і Google Cloud до приватних платформ на базі VMware vCloud Director, що пропонують послуги в рамках IaaS, SaaS і PaaS рішень.
-
Управляти кількома хмарними провайдерами і розповсюджувати інфраструктуру між ними для підвищення стійкості до відмов, використовуючи одну конфігурацію для створення, діагностики та управління хмарними ресурсами.
-
Зручне використання для створення демо-стендів під тестування та налагодження програмного забезпечення. Ви можете створювати та передавати стенди для відділу тестування, паралельно перевіряти ПЗ у різних середовищах, а також моментально змінювати та видаляти ресурси, створивши лише один план побудови ресурсів
«Тераріум» Terraform
Коротко розповіли про переваги інструменту, тепер розберемо його на складові
Providers (провайдери).
У Terraform практично будь-який тип інфраструктури можна як ресурсу. Зв'язок між ресурсами та платформою API забезпечується providers модулями, які дозволяють створювати ресурси в рамках певної платформи, наприклад Azure або VMware vCloud Director.
В рамках проекту ви можете взаємодіяти із різними провайдерами на різних платформах.
Resources (опис ресурсів).
Опис ресурсів дозволяє керувати компонентами платформи, наприклад, віртуальними машинами або мережами.
Ви можете самостійно створити опис ресурсів для провайдера VMware vCloud Director та використовувати цей опис для створення ресурсів у будь-якого хостинг-провайдера, який використовує vCloud Director. Вам потрібно лише замінити параметри аутентифікації та параметри мережного підключення до необхідного хостинг-провайдера
Provisioners.
Ця складова дає можливість виконувати операції з початкового встановлення та обслуговування операційної системи після створення віртуальних машин. Після того, як ви створили ресурс віртуальної машини, за допомогою provisioners ви можете налаштувати та підключитись по SSH, виконати оновлення операційної системи, а також завантажити та виконати скрипт.
Змінні Input та Output.
Input змінні — вхідні змінні будь-яких типів блоків.
Output змінні дозволяють зберегти значення після створення ресурсів і можуть бути використані як вхідні змінні в інших модулях, наприклад, у блоці Provisioners.
States (стану).
Файли States зберігають інформацію про конфігурацію ресурсів платформи провайдера. При першому створенні платформи жодних відомостей про ресурси немає і перед будь-якою операцією Terraform оновлює стан реальної інфраструктури вже описаних ресурсів.
Основна мета станів, це збереження зв'язки об'єктів вже створених ресурсів для порівняння конфігурації доданих ресурсів та об'єктів, щоб уникнути повторного створення та змін платформи.
Інформація про стан за замовчуванням зберігається в локальному файлі terraform.tfstate, але при необхідності можна використовувати віддалене зберігання для роботи в команді.
Також ви можете імпортувати поточні ресурси платформи в стан, щоб взаємодіяти з іншими ресурсами, які в свою чергу були створені без допомоги Terraform.
2. Створення інфраструктури
Складники розібрали, тепер за допомогою Terraform ми поетапно створимо інфраструктуру із трьома віртуальними машинами. Перша із встановленим проксі-сервером nginx, друга з файловим сховищем на базі Nextcloud та третя з CMS Bitrix.
Писати код та виконувати його ми будемо на прикладі нашого . У нас користувачі отримують обліковий запис правами Organization Administrator, якщо ви використовуєте обліковий запис з тими ж правами в іншій хмарі VMware, то зможете відтворити код наших прикладів. Поїхали!
Спочатку створимо для нашого нового проекту директорію, де будуть розміщені файли з описом інфраструктури.
mkdir project01
Потім опишемо компоненти інфраструктури. Terraform створює зв'язки та обробляє файли на підставі опису у файлах. Самі файли можна назвати з цільового призначення описуваних блоків, наприклад, network.tf - визначає мережні параметри для інфраструктури.
Для опису компонентів нашої інфраструктури ми створили такі файли:
Список файлів.
main.tf – опис параметрів для віртуального середовища – віртуальні машини, віртуальні контейнери;
network.tf - опис параметрів віртуальної мережі та правил NAT, Firewall;
variables.tf - Список змінних, які використовуємо;
vcd.tfvars – значення змінних проекту для модуля VMware vCloud Director.
Мова конфігурації в Terraform є декларативною і порядок блоків не має значення, крім блоків provisioner, т.к. у цьому блоці ми описуємо команди для виконання під час підготовки інфраструктури і вони будуть виконуватися по порядку.
структура блоків.
<BLOCK TYPE> "<BLOCK LABEL>" "<BLOCK LABEL>" {
# Block body
<IDENTIFIER> = <EXPRESSION> # Argument
}
Для опису блоків використовується власна мова програмування HCL (HashiCorp Configuration Language), можна описувати інфраструктуру і за допомогою JSON. Докладніше про синтаксис можна .
Конфігурація змінної оточення, variables.tf та vcd.tfvars
Спочатку створимо два файли, які описують список всіх змінних та їх значень для модуля VMware vCloud Director. Першим створимо файл variables.tf.
Вміст файлу variables.tf.
variable "vcd_org_user" {
description = "vCD Tenant User"
}
variable "vcd_org_password" {
description = "vCD Tenant Password"
}
variable "vcd_org" {
description = "vCD Tenant Org"
}
variable "vcd_org_vdc" {
description = "vCD Tenant VDC"
}
variable "vcd_org_url" {
description = "vCD Tenant URL"
}
variable "vcd_org_max_retry_timeout" {
default = "60"
}
variable "vcd_org_allow_unverified_ssl" {
default = "true"
}
variable "vcd_org_edge_name" {
description = "vCD edge name"
}
variable "vcd_org_catalog" {
description = "vCD public catalog"
}
variable "vcd_template_os_centos7" {
description = "OS CentOS 7"
default = "CentOS7"
}
variable "vcd_org_ssd_sp" {
description = "Storage Policies"
default = "Gold Storage Policy"
}
variable "vcd_org_hdd_sp" {
description = "Storage Policies"
default = "Bronze Storage Policy"
}
variable "vcd_edge_local_subnet" {
description = "Organization Network Subnet"
}
variable "vcd_edge_external_ip" {
description = "External public IP"
}
variable "vcd_edge_local_ip_nginx" {}
variable "vcd_edge_local_ip_bitrix" {}
variable "vcd_edge_local_ip_nextcloud" {}
variable "vcd_edge_external_network" {}
Значення змінних ми отримуємо від провайдера.
-
vcd_org_user - ім'я користувача з правами Organization Administrator,
-
vcd_org_password - пароль користувача,
-
vcd_org - назва організації,
-
vcd_org_vdc - назва віртуального дата-центру,
-
vcd_org_url - API URL,
-
vcd_org_edge_name - назва віртуального маршрутизатора,
-
vcd_org_catalog — назва каталогу із шаблонами віртуальних машин,
-
vcd_edge_external_ip — публічна IP-адреса,
-
vcd_edge_external_network - назва зовнішньої мережі,
-
vcd_org_hdd_sp - назва політики зберігання HDD,
-
vcd_org_ssd_sp – назва політики зберігання SSD.
І вводимо свої змінні:
-
vcd_edge_local_ip_nginx - IP-адреса віртуальної машини з NGINX,
-
vcd_edge_local_ip_bitrix - IP-адреса віртуальної машини з 1С: Бітрікс,
-
vcd_edge_local_ip_nextcloud - IP-адреса віртуальної машини з Nextcloud.
Другим файлом створюємо та вказуємо змінні для модуля VMware vCloud Director у файлі vcd.tfvars: Нагадаємо, що у нашому прикладі ми використовуємо Якщо ви працюєте з іншим провайдером, уточніть значення у нього.
Зміст файлу vcd.tfvars.
vcd_org_url = "https://vcloud.mclouds.ru/api"
vcd_org_user = "orgadmin"
vcd_org_password = "*"
vcd = "org"
vcd_org_vdc = "orgvdc"
vcd_org_maxretry_timeout = 60
vcd_org_allow_unverified_ssl = true
vcd_org_catalog = "Templates"
vcd_templateos_centos7 = "CentOS7"
vcd_org_ssd_sp = "Gold Storage Policy"
vcd_org_hdd_sp = "Bronze Storage Policy"
vcd_org_edge_name = "MCLOUDS-EDGE"
vcd_edge_external_ip = "185.17.66.1"
vcd_edge_local_subnet = "192.168.110.0/24"
vcd_edge_local_ip_nginx = "192.168.110.1"
vcd_edge_local_ip_bitrix = "192.168.110.10"
vcd_edge_local_ip_nextcloud = "192.168.110.11"
vcd_edge_external_network = "NET-185-17-66-0"
Мережева конфігурація, network.tf.
Змінні оточення задані, тепер налаштуємо схему підключення віртуальних машин — до кожної віртуальної машини призначимо приватну IP-адресу та за допомогою Destination NAT «прокидаємо» порти у зовнішню мережу. Для обмеження доступу до портів керування встановимо доступ тільки для нашої IP-адреси.
Схема мережі для створюваної платформи Terraform
Створюємо віртуальну організаційну мережу з назвою net_lan01, стандартним шлюзом: 192.168.110.254, а також з адресним простором: 192.168.110.0/24.
Описуємо віртуальну мережу.
resource "vcd_network_routed" "net" {
name = "net_lan01"
edge_gateway = var.vcd_org_edge_name
gateway = "192.168.110.254"
dns1 = "1.1.1.1"
dns2 = "8.8.8.8"
static_ip_pool {
start_address = "192.168.110.1"
end_address = "192.168.110.253"
}
}
Створимо правила для міжмережевого екрану, що дозволяє надати віртуальним машинам доступ до мережі Інтернет. В рамках цього блоку всі віртуальні ресурси у хмарі матимуть доступ до мережі Інтернет:
Описуємо правила для доступу VM до інтернету.
resource "vcd_nsxv_firewall_rule" "fw_internet_access" {
edge_gateway = var.vcdorgedgename
name = "Internet Access"
source {
gateway_interfaces = ["internal"]
}
destination {
gateway_interfaces = ["external"]
}
service {
protocol = "any"
}
depends_on = [vcdnetworkrouted.net]
}
Встановивши залежність, що після обробки блоку vcdnetworkrouted.net ми приступаємо до конфігурації блоку vcdnsxvfirewallrule, з допомогою dependson. Використовуємо цю опцію, оскільки деякі залежності можуть бути розпізнані неявно у конфігурації.
Далі створимо правила, що дозволяє доступ до портів із зовнішньої мережі і вказуємо нашу IP-адресу для підключення по SSH до серверів. Будь-який користувач мережі Інтернет має доступ до портів 80 та 443 на веб-сервері та користувач з IP-адресою 90.1.15.1 має доступ до портів SSH віртуальних серверів.
Дозволяємо доступ до портів із зовнішньої мережі.
resource "vcd_nsxv_firewall_rule" "fwnatports" {
edge_gateway = var.vcd_org_edge_name
name = "HTTPs Access"
source {
gateway_interfaces = ["external"]
}
destination {
gateway_interfaces = ["internal"]
}
service {
protocol = "tcp"
port = "80"
}
service {
protocol = "tcp"
port = "443"
}
depends_on = [vcd_network_routed.net]
}
resource "vcd_nsxv_firewall_rule" "fw_nat_admin_ports" {
edge_gateway = var.vcd_org_edge_name
name = "Admin Access"
source {
ip_addresses = [ "90.1.15.1" ]
}
destination {
gateway_interfaces = ["internal"]
}
service {
protocol = "tcp"
port = "58301"
}
service {
protocol = "tcp"
port = "58302"
}
service {
protocol = "tcp"
port = "58303"
}
depends_on = [vcd_network_routed.net]
}
Створюємо правила Source NAT для доступу до мережі Інтернет із хмарної локальної мережі:
Описуємо правила Source NAT.
resource "vcd_nsxv_snat" "snat_local" {
edge_gateway = var.vcd_org_edge_name
network_type = "ext"
network_name = var.vcdedgeexternalnetwork
original_address = var.vcd_edge_local_subnet
translated_address = var.vcd_edge_external_ip
depends_on = [vcd_network_routed.net]
}
І на завершення конфігурації мережевого блоку додаємо правила Destination NAT для доступу до сервісів із зовнішньої мережі:
Додаємо правила Destination NAT.
resource "vcd_nsxv_dnat" "dnat_tcp_nginx_https" {
edge_gateway = var.vcd_org_edge_name
network_name = var.vcd_edge_external_network
network_type = "ext"
description = "NGINX HTTPs"
original_address = var.vcd_edge_external_ip
original_port = 443
translated_address = var.vcd_edge_local_ip_nginx
translated_port = 443
protocol = "tcp"
depends_on = [vcd_network_routed.net]
}
resource "vcd_nsxv_dnat" "dnat_tcp_nginx_http" {
edge_gateway = var.vcd_org_edge_name
network_name = var.vcd_edge_external_network
network_type = "ext"
description = "NGINX HTTP"
original_address = var.vcd_edge_external_ip
original_port = 80
translated_address = var.vcd_edge_local_ip_nginx
translated_port = 80
protocol = "tcp"
depends_on = [vcd_network_routed.net]
}
Додаємо правило NAT для трансляції портів до SSH-сервера під Nginx.
resource "vcd_nsxv_dnat" "dnat_tcp-nginx_ssh" {
edge_gateway = var.vcd_org_edge_name
network_name = var.vcd_edge_external_network
network_type = "ext"
description = "SSH NGINX"
original_address = var.vcd_edge_external_ip
original_port = 58301
translated_address = var.vcd_edge_local_ip_nginx
translated_port = 22
protocol = "tcp"
depends_on = [vcd_network_routed.net]
}
Додаємо правило NAT для трансляції портів до SSH-сервера з 1С-Бітрікс.
resource "vcd_nsxv_dnat" "dnat_tcp_bitrix_ssh" {
edge_gateway = var.vcd_org_edge_name
network_name = var.vcd_edge_external_network
network_type = "ext"
description = "SSH Bitrix"
original_address = var.vcd_edge_external_ip
original_port = 58302
translated_address = var.vcd_edge_local_ip_bitrix
translated_port = 22
protocol = "tcp"
depends_on = [vcd_network_routed.net]
}
Додаємо правило NAT для трансляції портів до SSH-сервера з Nextcloud.
resource "vcd_nsxv_dnat" "dnat_tcp_nextcloud_ssh" {
edge_gateway = var.vcd_org_edge_name
network_name = var.vcd_edge_external_network
network_type = "ext"
description = "SSH Nextcloud"
original_address = var.vcd_edge_external_ip
original_port = 58303 translated_address = var.vcd_edge_local_ip_nextcloud
translated_port = 22
protocol = "tcp"
depends_on = [vcd_network_routed.net]
}
Конфігурація віртуального середовища main.tf
Як ми планували на початку статті, створимо три віртуальні машини. Вони будуть підготовлені за допомогою "Guest Customization". Мережеві параметри пропишемо згідно з вказаними нами налаштуваннями, а пароль від користувача генерується автоматично.
Опишемо vApp в якому будуть віртуальні машини та їх конфігурацію.
Конфігурація віртуальних машин
Створимо контейнер vApp. Щоб ми могли відразу ж підключити vApp і ВМ до віртуальної мережі, також додаємо параметр depends_on:
Створюємо контейнер
resource "vcd_vapp" "vapp" {
name = "web"
power_on = "true" depends_on = [vcd_network_routed.net]
}
Створимо віртуальну машину з описом
resource "vcd_vapp_vm" "nginx" {
vapp_name = vcd_vapp.vapp.name
name = "nginx"
catalog_name = var.vcd_org_catalog
template_name = var.vcd_template_os_centos7
storage_profile = var.vcd_org_ssd_sp
memory = 8192
cpus = 1
cpu_cores = 1
network {
type = "org"
name = vcd_network_routed.net.name
is_primary = true
adapter_type = "VMXNET3"
ip_allocation_mode = "MANUAL"
ip = var.vcd_edge_local_ip_nginx
}
override_template_disk {
bus_type = "paravirtual"
size_in_mb = "32768"
bus_number = 0
unit_number = 0
storage_profile = var.vcd_org_ssd_sp
}
}
Основні параметри в описі VM:
-
name - ім'я віртуальної машини,
-
vappname — назва vApp до якого додати нову ВМ,
-
catalogname / templatename - назва каталогу та назва шаблону віртуальної машини,
-
storageprofile — політика зберігання за промовчанням.
Параметри блоку network:
-
type — тип мережі, що підключається,
-
name - до якої віртуальної мережі підключити ВМ,
-
isprimary - основний мережевий адаптер,
-
ipallocation_mode - режим виділення адреси MANUAL/DHCP/POOL,
-
ip - IP-адреса для віртуальної машини, вкажемо вручну.
Блок override_template_disk:
-
sizeinmb – розмір boot-диска для віртуальної машини
-
storage_profile – політика зберігання для диска
Створимо другу VM із описом файлового сховища Nextcloud
resource "vcd_vapp_vm" "nextcloud" {
vapp_name = vcd_vapp.vapp.name
name = "nextcloud"
catalog_name = var.vcd_org_catalog
template_name = var.vcd_template_os_centos7
storage_profile = var.vcd_org_ssd_sp
memory = 8192
cpus = 1
cpu_cores = 1
network {
type = "org"
name = vcd_network_routed.net.name
is_primary = true
adapter_type = "VMXNET3"
ip_allocation_mode = "MANUAL"
ip = var.vcd_edge_local_ip_nextcloud
}
override_template_disk {
bus_type = "paravirtual"
size_in_mb = "32768"
bus_number = 0
unit_number = 0
storage_profile = var.vcd_org_ssd_sp
}
}
resource "vcd_vm_internal_disk" "disk1" {
vapp_name = vcd_vapp.vapp.name
vm_name = "nextcloud"
bus_type = "paravirtual"
size_in_mb = "102400"
bus_number = 0
unit_number = 1
storage_profile = var.vcd_org_hdd_sp
allow_vm_reboot = true
depends_on = [ vcd_vapp_vm.nextcloud ]
}
У секції vcdvminternal_disk опишемо новий віртуальний диск, який підключається до віртуальної машини.
Пояснення щодо блоку vcdvminternaldisk:
-
bustype - тип дискового контролера
-
sizeinmb - розмір диска
-
busnumber / unitnumber – місце підключення в адаптері
-
storage_profile – політика зберігання для диска
Опишемо останню VM на Бітрікс
resource "vcd_vapp_vm" "bitrix" {
vapp_name = vcd_vapp.vapp.name
name = "bitrix"
catalog_name = var.vcd_org_catalog
template_name = var.vcd_template_os_centos7
storage_profile = var.vcd_org_ssd_sp
memory = 8192
cpus = 1
cpu_cores = 1
network {
type = "org"
name = vcd_network_routed.net.name
is_primary = true
adapter_type = "VMXNET3"
ip_allocation_mode = "MANUAL"
ip = var.vcd_edge_local_ip_bitrix
}
override_template_disk {
bus_type = "paravirtual"
size_in_mb = "81920"
bus_number = 0
unit_number = 0
storage_profile = var.vcd_org_ssd_sp
}
}
Оновлення ОС та встановлення додаткових скриптів
Мережа підготовлена, описані віртуальні машини. Перед імпортом нашої інфраструктури ми можемо заздалегідь провести початковий провіжинінг за допомогою блоків provisioners і без використання Ansible.
Розглянемо як оновити ОС та запустити інсталяційний скрипт CMS Bitrix за допомогою provisioner блоку.
Спочатку виконаємо інсталяцію пакетів оновлення CentOS.
resource "null_resource" "nginx_update_install" {
provisioner "remote-exec" {
connection {
type = "ssh"
user = "root"
password = vcd_vapp_vm.nginx.customization[0].admin_password
host = var.vcd_edge_external_ip
port = "58301"
timeout = "30s"
}
inline = [
"yum -y update && yum -y upgrade",
"yum -y install wget nano epel-release net-tools unzip zip" ]
}
}
}
Позначення складових:
-
provisioner "remote-exec" - підключаємо блок віддаленого "провіжинінгу"
-
У блоці connection описуємо тип та параметри для підключення:
-
type - протокол, у нашому випадку SSH;
-
user - ім'я користувача;
-
password - пароль користувача. У нашому випадку вказуємо параметр vcdvappvm.nginx.customization[0].admin_password, який зберігає згенерований пароль від користувача системи.
-
host — зовнішня IP-адреса для підключення;
-
port — порт для підключення, який раніше вказували на налаштуваннях DNAT;
-
inline - перераховуємо список команд, які вводяться. Команди будуть введені по порядку, як і зазначено у цій секції.
Як приклад, додатково виконаємо скрипт установки 1С-Бітрікс. Виведення результату виконання скрипта буде доступним під час виконання плану. Для встановлення скрипта, спочатку опишемо блок:
Опишемо встановлення 1С-Бітрікс.
provisioner "file" {
source = "prepare.sh"
destination = "/tmp/prepare.sh"
connection {
type = "ssh"
user = "root"
password = vcd_vapp_vm.nginx.customization[0].admin_password
host = var.vcd_edge_external_ip
port = "58301"
timeout = "30s"
}
}
provisioner "remote-exec" {
inline = [
"chmod +x /tmp/prepare.sh", "./tmp/prepare.sh"
]
}
І одразу ж опишемо оновлення Бітрікс.
Приклад провіжинінгу 1С-Бітрікс.
resource "null_resource" "install_update_bitrix" {
provisioner "remote-exec" {
connection {
type = "ssh"
user = "root"
password = vcd_vapp_vm.bitrix.customization[0].admin_password
host = var.vcd_edge_external_ip
port = "58302"
timeout = "60s"
}
inline = [
"yum -y update && yum -y upgrade",
"yum -y install wget nano epel-release net-tools unzip zip",
"wget http://repos.1c-bitrix.ru/yum/bitrix-env.sh -O /tmp/bitrix-env.sh",
"chmod +x /tmp/bitrix-env.sh",
"/tmp/bitrix-env.sh"
]
}
}
Важливо! Скрипт може не спрацювати, якщо не вимкнути заздалегідь SELinux! Якщо вам потрібна докладна стаття щодо встановлення та налаштування CMS 1С-Бітрікс за допомогою bitrix-env.sh, оо ви можете .
3. Ініціалізація інфраструктури
Ініціалізація модулів та плагінів
Для роботи ми використовуємо простий "джентльменський набір": лептоп з ОС Windows 10 і дистрибутив з офіційного сайту . Розпакуємо та проініціалізуємо за допомогою команди: terraform.exe init
Після опису обчислювальної та мережної інфраструктури ми запускаємо планування для перевірки нашої конфігурації, де ми можемо побачити, що буде створено і як між собою пов'язано.
-
Виконуємо команду
- terraform plan -var-file=vcd.tfvars. -
Отримуємо результат
- Plan: 16 to add, 0 to change, 0 to destroy.Тобто, за цим планом буде створено 16 ресурсів. -
Запускаємо план за командою
- terraform.exe apply -var-file=vcd.tfvars.
Віртуальні машини будуть створені, а потім виконуються перелічені нами пакети в рамках секції provisioner – ОС буде оновлено та встановиться CMS Bitrix.
Отримання даних для підключення
Після виконання плану ми хочемо отримати у текстовому вигляді дані для підключення до серверів, для цього оформимо секцію output наступним чином:
output "nginxpassword" {
value = vcdvappvm.nginx.customization[0].adminpassword
}
І наступний висновок повідомляє нам пароль від створеної віртуальної машини:
Outputs: nginx_password = F#4u8!!N
У результаті ми отримуємо доступ до віртуальних машин з оновленою операційною системою та встановленими пакетами для нашої подальшої роботи. Все готово!
Але якщо у вас вже є існуюча інфраструктура?
3.1. Робота Terraform із вже існуючою інфраструктурою
Все просто, ви можете імпортувати поточні віртуальні машини та їхні контейнери vApp за допомогою команди import.
Опишемо ресурс vAPP та віртуальну машину.
resource "vcd_vapp" "Monitoring" {
name = "Monitoring"
org = "mClouds"
vdc = "mClouds"
}
resource "vcd_vapp_vm" "Zabbix" {
name = "Zabbix"
org = "mClouds"
vdc = "mClouds"
vapp = "Monitoring"
}
Наступний крок, це виконати імпорт властивостей ресурсів vApp у форматі vcdvapp.<vApp> <org>.<orgvdc>.<vApp>, Де:
-
vApp - ім'я vApp;
-
org - назва організації;
-
org_vdc – назва віртуального дата-центру.
Імпорт властивостей ресурсу vAPP
Виконаємо імпорт властивостей ресурсів VM у форматі: vcdvappvm.<VM> <org>.<orgvdc>.<vApp>.<VM>, в якому:
-
VM - ім'я VM;
-
vApp - ім'я vApp;
-
org - назва організації;
-
orgvdc – назва віртуального дата-центру.
Імпорт пройшов успішно
C:UsersMikhailDesktopterraform>terraform import vcd_vapp_vm.Zabbix mClouds.mClouds.Monitoring.Zabbix
vcd_vapp_vm.Zabbix: Importing from ID "mClouds.mClouds.Monitoring.Zabbix"...
vcd_vapp_vm.Zabbix: Import prepared!
Prepared vcd_vapp_vm for import
vcd_vapp_vm.Zabbix: Refreshing state... [id=urn:vcloud:vm:778f4a89-1c8d-45b9-9d94-0472a71c4d1f]
Import successful!
The resources that were imported are shown above. These resources are now in
your Terraform state and will henceforth be managed by Terraform.
Тепер ми можемо подивитися на новий імпортований ресурс:
Імпортований ресурс
> terraform show
...
# vcd_vapp.Monitoring:
resource "vcd_vapp" "Monitoring" {
guest_properties = {}
href = "https://vcloud.mclouds.ru/api/vApp/vapp-fe5db285-a4af-47c4-93e8-55df92f006ec"
id = "urn:vcloud:vapp:fe5db285-a4af-47c4-93e8-55df92f006ec"
ip = "allocated"
metadata = {}
name = "Monitoring"
org = "mClouds"
status = 4
status_text = "POWERED_ON"
vdc = "mClouds"
}
…
# vcd_vapp_vm.Zabbix:
resource "vcd_vapp_vm" "Zabbix" {
computer_name = "Zabbix"
cpu_cores = 1
cpus = 2
expose_hardware_virtualization = false
guest_properties = {}
hardware_version = "vmx-14"
href = "https://vcloud.mclouds.ru/api/vApp/vm-778f4a89-1c8d-45b9-9d94-0472a71c4d1f"
id = "urn:vcloud:vm:778f4a89-1c8d-45b9-9d94-0472a71c4d1f"
internal_disk = [
{
bus_number = 0
bus_type = "paravirtual"
disk_id = "2000"
iops = 0
size_in_mb = 122880
storage_profile = "Gold Storage Policy"
thin_provisioned = true
unit_number = 0
},
]
memory = 8192
metadata = {}
name = "Zabbix"
org = "mClouds"
os_type = "centos8_64Guest"
storage_profile = "Gold Storage Policy"
vapp_name = "Monitoring"
vdc = "mClouds"
customization {
allow_local_admin_password = true
auto_generate_password = true
change_sid = false
enabled = false
force = false
join_domain = false
join_org_domain = false
must_change_password_on_first_login = false
number_of_auto_logons = 0
}
network {
adapter_type = "VMXNET3"
ip_allocation_mode = "DHCP"
is_primary = true
mac = "00:50:56:07:01:b1"
name = "MCLOUDS-LAN01"
type = "org"
}
}
Тепер точно готово – ми закінчили з останнім моментом (імпорт у існуючу інфраструктуру) та розглянули всі основні моменти роботи з Terraform.
Інструмент виявився дуже зручним та дозволяє описати вашу інфраструктуру як код, починаючи від віртуальних машин одного хмарного провайдера до опису ресурсів мережевих компонентів.
При цьому незалежність від оточення дає можливість як працювати з локальними, хмарними ресурсами, так і, закінчуючи управлінням платформою. А за відсутності підтримуваної платформи та бажання додавання нового можна написати свій провайдер і використовувати його.
Джерело: habr.com