У гэтым артыкуле мы разгледзім з чаго складаецца 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