En ĉi tiu artikolo, ni rigardos el kio konsistas Terraform, kaj ankaŭ lanĉos nian propran infrastrukturon en etapoj - preparu tri VM-ojn por malsamaj celoj: prokurilo, dosierstokado kaj CMS.
Ĉio detale kaj en tri etapoj:
1. Terraform - priskribo, avantaĝoj kaj komponantoj
Terraform estas IaC (Infrastructure-as-Code) ilo por konstrui kaj administri virtualan infrastrukturon uzante kodon.
Laborante kun la ilo, ni rimarkis plurajn avantaĝojn:
-
La rapideco de deplojo de novaj luantoj (personaj virtualaj medioj). Kutime, ju pli da novaj klientoj, des pli da "klakoj" la teknika subtena personaro bezonas fari por eldoni novajn rimedojn. Kun Terraform, uzantoj povas ŝanĝi la parametrojn de virtualaj maŝinoj (ekzemple, aŭtomate malŝalti la OS kaj pliigi la virtualan diskdiskon) sen partopreno de teknika subteno kaj malŝalti la maŝinon mem.
-
Tuja konfirmo de la aktiviga plano nova luanto. Uzante la priskribon de la infrastruktura kodo, ni povas tuj kontroli kio estos aldonita kaj en kia ordo, same kiel en kia fina stato estos tiu aŭ alia virtuala maŝino aŭ virtuala reto kun konektoj al virtualaj maŝinoj.
-
Kapablo priskribi plej popularajn nubajn platformojn. Vi povas uzi la ilon de Amazon kaj Google Cloud ĝis privataj platformoj bazitaj sur VMware vCloud Director proponanta solvojn IaaS, SaaS kaj PaaS.
-
Administri plurajn nubaj provizantoj kaj disdonu infrastrukturon inter ili por plibonigi misfunkciadon, uzante ununuran agordon por krei, diagnozi kaj administri nubajn rimedojn.
-
Oportuna uzo por krei demo-standojn por testado kaj senararigado de programaro. Vi povas krei kaj translokigi benkojn por la testa sekcio, testi programaron paralele en malsamaj medioj, kaj tuj ŝanĝi kaj forigi rimedojn kreante nur unu planon pri konstruado de rimedoj.
"Terrario" Terraform
Ni mallonge parolis pri la avantaĝoj de la ilo, nun ni analizos ĝin en ĝiaj komponantoj
Provizantoj (provizantoj).
En Terraform, preskaŭ ajna speco de infrastrukturo povas esti reprezentita kiel rimedo. La ligo inter rimedoj kaj la API-platformo estas provizita de provizantaj moduloj, kiuj ebligas al vi krei rimedojn ene de specifa platformo, kiel Azure aŭ VMware vCloud Director.
Ene de projekto, vi povas interagi kun malsamaj provizantoj sur malsamaj platformoj.
Rimedoj (priskribo de rimedoj).
Priskribo de rimedoj permesas al vi administri platformajn komponantojn, kiel virtualajn maŝinojn aŭ retojn.
Vi povas mem krei rimedpriskribon por provizanto de VMware vCloud Director kaj uzi ĉi tiun priskribon por krei rimedojn por iu ajn gastiganta provizanto kiu uzas vCloud Director. Vi nur bezonas ŝanĝi la aŭtentikajn parametrojn kaj retajn konektojn al la postulata gastiga provizanto
Provizantoj.
Ĉi tiu komponanto ebligas plenumi operaciojn por la komenca instalado kaj bontenado de la operaciumo post la kreado de virtualaj maŝinoj. Post kiam vi kreis virtualan maŝinan rimedon, vi povas uzi provizantojn por agordi kaj konekti per SSH, ĝisdatigi la operaciumon kaj elŝuti kaj ekzekuti skripton.
Variabloj Enigo kaj Eligo.
Eniga variabloj - enigo variabloj por ajna bloko tipoj.
Eligo-variabloj permesas konservi valorojn post kreado de rimedoj kaj povas esti uzataj kiel eniga variabloj en aliaj moduloj, kiel la bloko Provizantoj.
ŝtatoj.
Ŝtataj dosieroj stokas informojn pri la platforma rimeda agordo de la provizanto. Kiam la platformo unue estas kreita, ne ekzistas informoj pri la rimedoj, kaj antaŭ ajna operacio, Terraform ĝisdatigas la staton kun la reala infrastrukturo de la jam priskribitaj rimedoj.
La ĉefa celo de ŝtatoj estas konservi amason da objektoj de jam kreitaj rimedoj por kompari la agordon de aldonitaj rimedoj kaj objektoj por eviti rekreadon kaj ŝanĝojn al la platformo.
Ŝtataj informoj estas konservitaj loke en la terraform.tfstate-dosiero defaŭlte, sed vi povas uzi fora stokado por teama laboro se necese.
Vi ankaŭ povas importi la nunajn platformajn rimedojn en la ŝtaton por plue interagi kun aliaj rimedoj, kiuj siavice estis kreitaj sen la helpo de Terraform.
2. Kreado de infrastrukturo
La komponantoj estis malmuntitaj, nun kun la helpo de Terraform ni iom post iom kreos infrastrukturon kun tri virtualaj maŝinoj. La unua kun nginx prokurservilo instalita, la dua kun Nextcloud-bazita dosierstokado kaj la tria kun Bitrix CMS.
Ni skribos kodon kaj ekzekutos ĝin uzante la ekzemplon de nia . Ĉe ni, uzantoj ricevas konton kun Organizo-Administranto-rajtoj, se vi uzas konton kun la samaj rajtoj en alia VMware-nubo, vi povas reprodukti la kodon de niaj ekzemploj. Iru!
Unue, ni kreu dosierujon por nia nova projekto, kiu enhavos dosierojn priskribantajn la infrastrukturon.
mkdir project01
Tiam ni priskribas la komponantojn de la infrastrukturo. Terraform kreas ligilojn kaj prilaboras dosierojn surbaze de la priskribo en la dosieroj. La dosieroj mem povas esti nomitaj laŭ la celo de la priskribitaj blokoj, ekzemple, network.tf - priskribas la retajn parametrojn por la infrastrukturo.
Por priskribi la komponantojn de nia infrastrukturo, ni kreis la jenajn dosierojn:
Listo de dosieroj.
main.tf - priskribo de parametroj por la virtuala medio - virtualaj maŝinoj, virtualaj ujoj;
network.tf - priskribo de virtualaj retaj parametroj kaj NAT, Firewall reguloj;
variables.tf - listo de variabloj kiujn ni uzas;
vcd.tfvars - projektaj variaj valoroj por la modulo VMware vCloud Director.
La agorda lingvo en Terraform estas deklara kaj la ordo de blokoj ne gravas, krom provizantaj blokoj, ĉar en ĉi tiu bloko, ni priskribas la ordonojn por esti ekzekutitaj dum preparado de la infrastrukturo kaj ili estos ekzekutitaj en ordo.
Bloka strukturo.
<BLOCK TYPE> "<BLOCK LABEL>" "<BLOCK LABEL>" {
# Block body
<IDENTIFIER> = <EXPRESSION> # Argument
}
Blokoj estas priskribitaj uzante sian propran programlingvon HCL (HashiCorp Configuration Language), eblas priskribi la infrastrukturon uzante JSON. Por pliaj informoj pri sintakso, vidu .
Medivaria agordo, variables.tf kaj vcd.tfvars
Unue, ni kreu du dosierojn, kiuj priskribas la liston de ĉiuj uzataj variabloj kaj iliajn valorojn por la modulo VMware vCloud Director. Unue, ni kreu la dosieron variables.tf.
La enhavo de la dosiero 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" {}
Variaj valoroj, kiujn ni ricevas de la provizanto.
-
vcd_org_user - uzantnomo kun Organizo-Administranto-rajtoj,
-
vcd_org_password - pasvorto de uzanto,
-
vcd_org - nomo de organizo,
-
vcd_org_vdc - la nomo de la virtuala datumcentro,
-
vcd_org_url - API URL,
-
vcd_org_edge_name - nomo de virtuala enkursigilo,
-
vcd_org_catalog - la nomo de la dosierujo kun virtualaj maŝinaj ŝablonoj,
-
vcd_edge_external_ip - publika IP-adreso,
-
vcd_edge_external_network - la nomo de la ekstera reto,
-
vcd_org_hdd_sp - nomo de politiko pri konservado de HDD,
-
vcd_org_ssd_sp estas la nomo de la SSD-stokadopolitiko.
Kaj enigu niajn variablojn:
-
vcd_edge_local_ip_nginx - IP-adreso de la virtuala maŝino kun NGINX,
-
vcd_edge_local_ip_bitrix - IP-adreso de la virtuala maŝino kun 1C: Bitrix,
-
vcd_edge_local_ip_nextcloud - IP-adreso de la virtuala maŝino kun Nextcloud.
En la dua dosiero, ni kreas kaj specifas variablojn por la modulo VMware vCloud Director en la dosiero vcd.tfvars: Memoru, ke en nia ekzemplo ni uzas , se vi laboras kun alia provizanto, kontrolu la valorojn kun li.
La enhavo de la dosiero 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"
Reta agordo, network.tf.
La mediaj variabloj estas fiksitaj, nun ni agordu la skemon de konekto de virtuala maŝino - asignu privatan IP-adreson al ĉiu virtuala maŝino kaj uzu Destination NAT por "sendi" pordojn al la ekstera reto. Por limigi aliron al administradaj havenoj, ni agos aliron nur por nia IP-adreso.
Retodiagramo por la kreita Terraform-platformo
Ni kreas virtualan organizan reton kun la nomo net_lan01, la defaŭlta enirejo: 192.168.110.254, kaj ankaŭ kun la adresspaco: 192.168.110.0/24.
Priskribu la virtualan reton.
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"
}
}
Ni kreu regulojn por la fajroŝirmilo, kiu ebligas al vi provizi virtualajn maŝinojn kun aliro al Interreto. Ene de ĉi tiu bloko, ĉiuj virtualaj rimedoj en la nubo havos aliron al Interreto:
Ni priskribas la regulojn por VM-aliro al Interreto.
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]
}
Establinte la dependecon, ke post prilaborado de la vcdnetworkrouted.net-bloko, ni iras al la agordo de la vcdnsxvfirewallrule-bloko, uzante dependas de. Ni uzas ĉi tiun opcion ĉar iuj dependecoj povas esti implicite rekonitaj en la agordo.
Poste, ni kreos regulojn permesantajn aliron al havenoj de la ekstera reto kaj specifos nian IP-adreson por konekti per SSH al la serviloj. Ĉiu interreta uzanto havas aliron al havenoj 80 kaj 443 en la retservilo, kaj uzanto kun IP-adreso 90.1.15.1 havas aliron al la SSH-havenoj de la virtualaj serviloj.
Ni permesas aliron al havenoj de la ekstera reto.
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]
}
Kreu Font-NAT-regulojn por aliri la Interreton de la nuba loka reto:
Priskribu la Regulojn de Fonto 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]
}
Kaj ĉe la fino de la reto-bloka agordo, ni aldonas Destination NAT-regulojn por aliri servojn de ekstera reto:
Aldonante regulojn de 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]
}
Aldonu NAT-regulon por traduki pordojn al la SSH-servilo sub 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]
}
Ni aldonas NAT-regulon por haventradukado al la SSH-servilo kun 1C-Bitrix.
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]
}
Aldonu NAT-regulon por traduki havenojn al la SSH-servilo kun 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]
}
Virtuala medio agordo main.tf
Kiel ni planis komence de la artikolo, ni kreos tri virtualajn maŝinojn. Ili estos pretaj per "Gasto-Personigo". Ni skribos la retajn parametrojn laŭ la agordoj, kiujn ni specifis, kaj la pasvorto de la uzanto estas generita aŭtomate.
Ni priskribu la vApp, en kiu troviĝos la virtualaj maŝinoj kaj ilia agordo.
Virtuala maŝina agordo
Ni kreu vApp-ujon. Por ke ni povu tuj konekti la vApp kaj VM al la virtuala reto, ni ankaŭ aldonas la depends_on parametron:
Kreu ujon
resource "vcd_vapp" "vapp" {
name = "web"
power_on = "true" depends_on = [vcd_network_routed.net]
}
Kreu virtualan maŝinon kun priskribo
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
}
}
La ĉefaj parametroj en la priskribo de la VM:
-
nomo estas la nomo de la virtuala maŝino,
-
vappname - la nomo de la vApp en kiu aldoni novan VM,
-
katalogonomo / ŝablononomo - katalogonomo kaj virtuala maŝina ŝablono nomo,
-
storageprofile - defaŭlta konservada politiko.
Parametroj de retaj blokoj:
-
tipo — tipo de konektita reto,
-
nomo - al kiu virtuala reto konekti la VM,
-
isprimary - ĉefa retadaptilo,
-
ipallocation_mode - MANUAL / DHCP / POOL-adresreĝimo,
-
ip - IP-adreso por la virtuala maŝino, ni specifos ĝin permane.
override_template_disk-bloko:
-
sizeinmb - lanĉa disko grandeco por la virtuala maŝino
-
storage_profile - konservada politiko por la disko
Ni kreu duan VM kun priskribo de la dosierstokado de 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 ]
}
En la sekcio vcdvminternal_disk, ni priskribas novan virtualan diskon, kiu estas konektita al la virtuala maŝino.
Klarigoj pri la vcdvmininternaldisk-bloko:
-
bustype - tipo de diskregilo
-
sizeinmb - grandeco de disko
-
busnumber / unitnumber - konektopunkto en la adaptilo
-
storage_profile - konservada politiko por la disko
Ni priskribu la lastan VM sur Bitrix
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
}
}
OS-ĝisdatigo kaj instalado de pliaj skriptoj
La reto estas preta, la virtualaj maŝinoj estas priskribitaj. Antaŭ ol importi nian infrastrukturon, ni povas antaŭprovizi per provizantaj blokoj kaj sen uzi Ansible.
Ni konsideru kiel ĝisdatigi la OS kaj ruli la instalan skripton de Bitrix CMS uzante la provizantan blokon.
Ni unue instalu la CentOS-servajn pakojn.
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" ]
}
}
}
Nomo de komponantoj:
-
provisioner "remote-exec" - konektu la foran "provizoran" blokon
-
En la konektobloko, ni priskribas la tipon kaj parametrojn por la konekto:
-
tipo - protokolo, en nia kazo SSH;
-
uzanto - uzantnomo;
-
pasvorto — pasvorto de uzanto. En nia kazo, ni montras al la parametro vcdvappvm.nginx.customization[0].admin_password, kiu konservas la generitan pasvorton de la sistemuzanto.
-
gastiganto — ekstera IP-adreso por konekto;
-
haveno - haveno por konekto, kiu antaŭe estis specifita en la DNAT-agordoj;
-
inline - listigu la liston de komandoj kiuj estos enmetitaj. La komandoj estos enmetitaj en ordo, kiel specifite en ĉi tiu sekcio.
Ekzemple, ni aldone ekzekutu la instalan skripton 1C-Bitrix. La eligo de la rezulto de ekzekuto de skripto estos disponebla dum la ekzekuto de la plano. Por instali la skripton, ni unue priskribas la blokon:
Ni priskribu la instaladon de 1C-Bitrix.
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"
]
}
Kaj ni tuj priskribos la ĝisdatigon de Bitrix.
Ekzemplo de provizora 1C-Bitrix.
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"
]
}
}
Grave! La skripto eble ne funkcias krom se SELinux antaŭe estas malŝaltita! Se vi bezonas detalan artikolon pri instalado kaj agordo de CMS 1C-Bitrix per bitrix-env.sh, vi povas .
3. Infrastrukturo inicialigo
Inicialigo de moduloj kaj kromaĵojn
Por laboro, ni uzas simplan "sinjora aro": tekkomputilo kun Vindozo 10 kaj distribua ilaro de la oficiala retejo . Malpaku kaj pravalorigu per la komando: terraform.exe init
Post priskribi la komputikan kaj retan infrastrukturon, ni komencas plani testi nian agordon, kie ni povas vidi kio estos kreita kaj kiel ĝi estas konektita unu al la alia.
-
Efektivigu la komandon
- terraform plan -var-file=vcd.tfvars. -
Ni ricevas la rezulton
- Plan: 16 to add, 0 to change, 0 to destroy.Tio estas, laŭ ĉi tiu plano, 16 rimedoj estos kreitaj. -
Lanĉante la planon laŭ komando
- terraform.exe apply -var-file=vcd.tfvars.
Virtualaj maŝinoj estos kreitaj, kaj tiam la pakaĵoj listigitaj de ni estos ekzekutitaj ene de la provizanta sekcio - la OS estos ĝisdatigita kaj CMS Bitrix estos instalita.
Akiro de konektodatenoj
Post la plenumo de la plano, ni volas ricevi datumojn en teksta formo por konektiĝi al serviloj, por tio ni aranĝos la eligsekcion jene:
output "nginxpassword" {
value = vcdvappvm.nginx.customization[0].adminpassword
}
Kaj la sekva eligo rakontas al ni la pasvorton de la kreita virtuala maŝino:
Outputs: nginx_password = F#4u8!!N
Kiel rezulto, ni ricevas aliron al virtualaj maŝinoj kun ĝisdatigita operaciumo kaj antaŭinstalitaj pakaĵoj por nia plua laboro. Ĉio estas preta!
Sed kio se vi jam havas ekzistantan infrastrukturon?
3.1. Terraform laboranta kun ekzistanta infrastrukturo
Ĝi estas simpla, vi povas importi nunajn virtualajn maŝinojn kaj iliajn vApp-ujojn uzante la importkomandon.
Ni priskribu la vAPP-rimedon kaj la virtualan maŝinon.
resource "vcd_vapp" "Monitoring" {
name = "Monitoring"
org = "mClouds"
vdc = "mClouds"
}
resource "vcd_vapp_vm" "Zabbix" {
name = "Zabbix"
org = "mClouds"
vdc = "mClouds"
vapp = "Monitoring"
}
La sekva paŝo estas importi vApp-rimedpropraĵojn en la formato vcdvapp.<vApp> <org>.<orgvdc>.<vApp>, kie:
-
vApp estas la nomo de la vApp;
-
org estas la nomo de la organizo;
-
org_vdc estas la nomo de la virtuala datumcentro.
Importu vAPP-rimedopropraĵojn
Ni importu la ecojn de VM-resursoj en la formato: vcdvappvm.<VM> <org>.<orgvdc>.<vApp>.<VM>, en kiu:
-
VM - VM-nomo;
-
vApp estas la nomo de la vApp;
-
org estas la nomo de la organizo;
-
orgvdc estas la nomo de la virtuala datumcentro.
Importo sukcesis
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.
Nun ni povas rigardi la nove importitan rimedon:
Importita rimedo
> 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"
}
}
Nun ni certe estas pretaj - ni finis kun la lasta momento (importado en ekzistantan infrastrukturon) kaj pripensis ĉiujn ĉefajn punktojn de laboro kun Terraform.
La ilo montriĝis tre oportuna kaj permesas vin priskribi vian infrastrukturon kiel kodon, de virtualaj maŝinoj de unu nuba provizanto ĝis priskribado de la rimedoj de retaj komponantoj.
Samtempe, sendependeco de la medio ebligas labori kun lokaj, nubaj rimedoj, kaj, finiĝante kun platforma administrado. Kaj se ne ekzistas subtenata platformo kaj vi volas aldoni novan, vi povas skribi vian propran provizanton kaj uzi ĝin.
fonto: www.habr.com