I denne artikel vil vi undersøge, hvad Terraform består af, samt trin for trin oprette vores egen infrastruktur – vi klargør tre VM'er til forskellige formål: proxy, filopbevaring og CMS.
Alt bliver beskrevet i detaljer og i tre trin:
1. Terraform – beskrivelse, fordele og komponenter
Terraform er et IaC (Infrastructure-as-Code) værktøj til opbygning og administration af virtuel infrastruktur ved hjælp af kode.
I arbejdet med værktøjet har vi bemærket flere fordele:
Hastighed ved udrulning af nye tenant (brugerspecifikke virtuelle miljøer). Normalt, jo flere nye kunder, jo flere 'klik' skal teknisk support stå for for at offentliggøre nye ressourcer. Med Terraform kan brugerne ændre indstillinger for virtuelle maskiner (f.eks. automatisk slukke operativsystemet og øge partitionen på den virtuelle disk) uden teknisk supports involvering og uden at slukke for selve maskinen.
Sofort kontrol af aktiveringsplanen for en ny tenant. Ved hjælp af infrastrukturen beskrives koden, kan vi straks kontrollere, hvad der vil blive tilføjet, og i hvilken rækkefølge, samt i hvilken endelig tilstand en bestemt virtuel maskine eller virtuelt netværk med tilslutninger til virtuelle maskiner vil være.
Muligheden for at beskrive de fleste populære cloud-platforme. Du kan bruge værktøjet fra Amazon og Google Cloud til private platforme baseret på VMware vCloud Director, der tilbyder tjenester inden for IaaS, SaaS og PaaS-løsninger.
Administrere flere cloud-udbydere og distribuere infrastruktur imellem dem for at øge fejltolerance ved at bruge en enkelt konfiguration til at oprette, diagnosticere og administrere cloud-ressourcer.
Brugervenlighed til oprettelse af demo-stande til test og fejlfinding af software. Du kan oprette og overføre stande til testafdelingen, samtidig tjekke softwaren i forskellige miljøer, samt straks ændre og fjerne ressourcer ved kun at oprette én plan for opbygning af ressourcer
«Terrarium» Terraform
Vi har kort fortalt om fordelene ved værktøjet, nu vil vi analysere det i detaljer.
Udbydere.
I Terraform kan næsten hvilken som helst type infrastruktur repræsenteres som en ressource. Forbindelsen mellem ressourcerne og API-platformen sker via provider-moduler, som gør det muligt at oprette ressourcer på bestemte platforme, såsom Azure eller VMware vCloud Director.
I projektet kan du interagere med forskellige udbydere på forskellige platforme.
Ressourcer.
Beskrivelsen af ressourcer gør det muligt at administrere platformskomponenter, såsom virtuelle maskiner eller netværk.
Du kan selv oprette en beskrivelse af ressourcer for VMware vCloud Director og bruge denne beskrivelse til at oprette ressourcer hos enhver hostingudbyder, der bruger vCloud Director. Du skal blot ændre godkendelsesoplysningerne og parametrene for netværksforbindelse til den nødvendige hostingudbyder.
Provisioners.
Denne del giver mulighed for at udføre operationer til den indledende installation og vedligeholdelse af operativsystemet efter oprettelsen af virtuelle maskiner. Efter du har oprettet en ressource til en virtuel maskine, kan du med provisioners konfigurere og oprette forbindelse via SSH, udføre opdatering af operativsystemet samt uploade og køre et script.
Input- og Output-variabler.
Input-variabler er indgangsvariabler for alle typer blokke.
Output-variabler gør det muligt at gemme værdier efter oprettelsen af ressourcer og kan bruges som input-variabler i andre moduler, såsom Provisioners-blokken.
Tilstande..
States-filer gemmer information om konfigurationen af ressourcerne fra udbyderen. Ved den første oprettelse af platformen er der ingen oplysninger om ressourcerne, og før enhver operation opdaterer Terraform tilstanden med den faktiske infrastruktur af allerede beskrevne ressourcer.
Hovedformålet med tilstande er at gemme forbindelsen mellem objekter af allerede oprettede ressourcer for at sammenligne konfigurationen af de tilføjede ressourcer og objekterne, så man undgår gentagen oprettelse og ændringer af platformen.
Standardtilstanden gemmes i den lokale fil terraform.tfstate, men hvis nødvendigt, er det muligt at bruge ekstern opbevaring til teamarbejde.
Du kan også importere de aktuelle ressourcer fra platformen til tilstanden for at interagere med andre ressourcer, der er oprettet uden hjælp fra Terraform.
2. Oprettelse af infrastruktur
Komponenterne er blevet gennemgået, nu vil vi trin for trin oprette infrastrukturen med tre virtuelle maskiner. Den første med en installeret proxyserver nginx, den anden med en filopbevaringsløsning baseret på Nextcloud, og den tredje med CMS Bitrix.
Vi vil skrive kode og udføre den med vores . Brugere får en konto med rettigheder som Organisation Administrator. Hvis du bruger en konto med de samme rettigheder i en anden VMware cloud, kan du genskabe koden fra vores eksempler. Lad os gå i gang!
Først opretter vi et bibliotek til vores nye projekt, hvor filerne med infrastrukturen vil blive placeret.
mkdir project01
Derefter beskriver vi komponenterne i infrastrukturen. Terraform opretter forbindelser og behandler filer baseret på beskrivelsen i filerne. Selve filerne kan navngives ud fra den tilsigtede funktionalitet af de beskrevne blokke, for eksempel beskriver network.tf de netværksparametre for infrastrukturen.
For at beskrive komponenterne i vores infrastruktur har vi oprettet følgende filer:
Liste over filer.
main.tf — beskrivelse af parametre for det virtuelle miljø — virtuelle maskiner, virtuelle containere;
network.tf — beskrivelse af parametre for det virtuelle netværk og NAT, Firewall regler;
variables.tf — liste over variabler, som vi bruger;
vcd.tfvars — værdier for projektvariabler til VMware vCloud Director-modulet.
Konfigurationsspråket i Terraform er deklarativt, og rækkefølgen af blokke har ingen betydning, bortset fra provisioner-blokken, da vi her beskriver kommandoer til udførelse under forberedelsen af infrastrukturen, og de vil blive udført i rækkefølge.
Struktur af blokke.
"" "" {
# Block body
= # Argument
}
Blokke beskrives med det eget programmeringssprog HCL (HashiCorp Configuration Language); det er også muligt at beskrive infrastrukturen med JSON. Du kan læse mere om syntaksen .
Konfiguration af miljøvariabel, variables.tf og vcd.tfvars
Først opretter vi to filer, der beskriver listen over alle anvendte variabler og deres værdier for VMware vCloud Director-modulet. Vi starter med at oprette filen variables.tf.
Indholdet af filen variables.tf.
variabel "vcd_org_user" {
beskrivelse = "vCD Tenants Bruger"
}
variabel "vcd_org_password" {
beskrivelse = "vCD Tenants Adgangskode"
}
variabel "vcd_org" {
beskrivelse = "vCD Tenants Organisation"
}
variabel "vcd_org_vdc" {
beskrivelse = "vCD Tenants VDC"
}
variabel "vcd_org_url" {
beskrivelse = "vCD Tenants URL"
}
variabel "vcd_org_max_retry_timeout" {
standard = "60"
}
variabel "vcd_org_allow_unverified_ssl" {
standard = "true"
}
variabel "vcd_org_edge_name" {
beskrivelse = "vCD kantnavn"
}
variabel "vcd_org_catalog" {
beskrivelse = "vCD offentlig katalog"
}
variabel "vcd_template_os_centos7" {
beskrivelse = "OS CentOS 7"
standard = "CentOS7"
}
variabel "vcd_org_ssd_sp" {
beskrivelse = "Lagringspolitikker"
standard = "Guld Lagringspolitik"
}
variabel "vcd_org_hdd_sp" {
beskrivelse = "Lagringspolitikker"
standard = "Bronze Lagringspolitik"
}
variabel "vcd_edge_local_subnet" {
beskrivelse = "Organisationsnetværk Subnet"
}
variabel "vcd_edge_external_ip" {
beskrivelse = "Ekstern offentlig IP"
}
variabel "vcd_edge_local_ip_nginx" {}
variabel "vcd_edge_local_ip_bitrix" {}
variabel "vcd_edge_local_ip_nextcloud" {}
variabel "vcd_edge_external_network" {}
Værdierne for variablerne, som vi modtager fra udbyderen.
vcd_org_user — brugernavnet med rettigheder som Organisation Administrator,
vcd_org_password — brugerens adgangskode,
vcd_org — navnet på organisationen,
vcd_org_vdc — navnet på det virtuelle datacenter,
vcd_org_url — API URL,
vcd_org_edge_name — navnet på den virtuelle router,
vcd_org_catalog — navnet på kataloget med skabeloner for virtuelle maskiner,
vcd_edge_external_ip — offentlig IP-adresse,
vcd_edge_external_network — navnet på det eksterne netværk,
vcd_org_hdd_sp — navnet på HDD-lagringspolitikken,
vcd_org_ssd_sp — navnet på SSD-lagringspolitikken.
Og vi indtaster vores egne variabler:
vcd_edge_local_ip_nginx — IP-adressen på den virtuelle maskine med NGINX,
vcd_edge_local_ip_bitrix — IP-adressen på den virtuelle maskine med 1C: Bitrix,
vcd_edge_local_ip_nextcloud — IP-adressen på den virtuelle maskine med Nextcloud.
I den anden fil opretter vi og angiver variablerne for VMware vCloud Director-modulet i filen vcd.tfvars: Lad os huske, at vi i vores eksempel bruger , hvis du arbejder med en anden udbyder, skal du bekræfte værdierne med dem.
Indholdet af filen 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 = "Skabeloner"
vcd_templateos_centos7 = "CentOS7"
vcd_org_ssd_sp = "Guld Lagringspolitik"
vcd_org_hdd_sp = "Bronze Lagringspolitik"
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"
Netværkskonfiguration, network.tf.
Miljøvariablerne er angivet, nu konfigurerer vi forbindelsesskemaet for virtuelle maskiner - vi tildeler hver virtuel maskine en privat IP-adresse og bruger Destination NAT til at "viderebefordre" porte til det eksterne netværk. For at begrænse adgangen til administrationsportene vil vi give adgang kun til vores IP-adresse.
Netværksskema for den oprettede Terraform-platform
Vi opretter et virtuelt organisationsnetværk med navnet net_lan01, standard gateway: 192.168.110.254, samt med adresseområdet: 192.168.110.0/24.
Vi beskriver det virtuelle netværk.
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"
}
}
Vi opretter regler for firewallen, der muliggør, at de virtuelle maskiner får adgang til internettet. Inden for dette blok vil alle virtuelle ressourcer i skyen have adgang til internettet:
Vi beskriver reglerne for internetadgang for 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]
}
Efter at have angivet afhængigheden, begynder vi konfigurationen af blokken vcdnsxvfirewallrule efter at have behandlet blokken vcdnetworkrouted.net., ved hjælp af depends_on. Vi bruger denne mulighed, da nogle afhængigheder muligvis ikke genkendes eksplicit i konfigurationen.
Derefter vil vi oprette regler, der tillader adgang til portene fra det eksterne netværk og angive vores IP-adresse for at oprette forbindelse via SSH til serverne. Enhver bruger på internettet har adgang til portene 80 og 443 på webserveren, og en bruger med IP-adressen 90.1.15.1 har adgang til SSH-portene på de virtuelle servere.
Vi tillader adgang til portene fra det eksterne netværk.
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]
}
Vi opretter Source NAT-regler for adgang til internettet fra den cloud-baserede lokale netværk:
Vi beskriver Source NAT-reglerne.
resource "vcd_nsxv_snat" "snat_local" {
edge_gateway = var.vcd_org_edge_name
netværk_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]
}
Og til slut i konfigurationen af netværksblokken tilføjer vi Destination NAT-regler for adgang til tjenester fra det eksterne netværk:
Vi tilføjer Destination NAT-regler.
resource "vcd_nsxv_dnat" "dnat_tcp_nginx_https" {
edge_gateway = var.vcd_org_edge_name
network_name = var.vcd_edge_external_network
netværk_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
netværk_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]
}
Vi tilføjer en NAT-regel for porttranslating til SSH-serveren under Nginx.
resource "vcd_nsxv_dnat" "dnat_tcp-nginx_ssh" {
edge_gateway = var.vcd_org_edge_name
network_name = var.vcd_edge_external_network
netværk_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]
}
Vi tilføjer en NAT-regel for porttranslating til SSH-serveren med 1C-Bitrix.
resource "vcd_nsxv_dnat" "dnat_tcp_bitrix_ssh" {
edge_gateway = var.vcd_org_edge_name
network_name = var.vcd_edge_external_network
netværk_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]
}
Vi tilføjer en NAT-regel for porttranslating til SSH-serveren med Nextcloud.
resource "vcd_nsxv_dnat" "dnat_tcp_nextcloud_ssh" {
edge_gateway = var.vcd_org_edge_name
network_name = var.vcd_edge_external_network
netværk_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]
}
Konfiguration af det virtuelle miljø main.tf
Som vi planlagde i begyndelsen af artiklen, vil vi oprette tre virtuelle maskiner. De vil blive forberedt ved hjælp af "Guest Customization". Netværksparametrene vil blive angivet i henhold til de indstillinger, vi har angivet, og adgangskoden til brugeren genereres automatisk.
Vi beskriver vApp, hvor de virtuelle maskiner og deres konfiguration vil befinde sig.
Konfiguration af de virtuelle maskiner
Vi opretter en vApp-container. Så vi straks kan tilslutte vApp og VM til det virtuelle netværk, tilføjer vi også parameteren depends_on:
Vi opretter en container
resource "vcd_vapp" "vapp" {
name = "web"
power_on = "true" depends_on = [vcd_network_routed.net]
}
Vi opretter en virtuel maskine med beskrivelsen
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
}
}
Hovedparametre i VM-beskrivelsen:
name — navnet på den virtuelle maskine,
vappname — navnet på vApp, hvor den nye VM skal tilføjes,
catalogname / templatename — navnet på katalogen og navnet på skabelonen til den virtuelle maskine,
storageprofile — standard opbevaringspolitik.
Parametre for netværksblokken:
type — typen af den tilsluttede netværk,
name — hvilken virtuel netværk, der skal tilsluttes VM,
isprimary — den primære netværksadapter,
ipallocation_mode — IP-uddannelsesmodus MANUAL / DHCP / POOL,
ip — IP-adressen til den virtuelle maskine, lad os angive den manuelt.
Blokken override_template_disk:
sizeinmb — størrelsen på boot-disken for den virtuelle maskine
storage_profile — opbevaringspolitikken for disken
Vi opretter den anden VM med beskrivelsen af Nextcloud-filopbevaringen.
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
}
}
ressource "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 ]
}
I sektionen vcdvminternal_disk beskriver vi en ny virtuel disk, der tilsluttes den virtuelle maskine.
Forklaringer til blokken vcdvminternaldisk:
bustype — typen af diskcontroller
sizeinmb — diskens størrelse
busnumber / unitnumber — tilslutningsstedet i adapteren
storage_profile — opbevaringspolitikken for disken
Vi beskriver den sidste VM på Bitrix
ressource "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
}
}
Opdatering af OS og installation af ekstra scripts
Netværket er klar, de virtuelle maskiner er beskrevet. Før importen af vores infrastruktur kan vi på forhånd udføre en indledende provisionering ved hjælp af provisioners blokke uden at bruge Ansible.
Lad os se på, hvordan vi kan opdatere OS og køre installationsscriptet for CMS Bitrix ved hjælp af provisioner-blokken.
Først installerer vi opdateringspakkerne til CentOS.
ressource "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" ]
}
}
}
Betegnelser af komponenterne:
provisioner «remote-exec» — vi tilslutter blokken for fjernprovisionering
I connection-blokken beskriver vi typen og parametrene for tilslutning:
type — protokol, i vores tilfælde SSH;
user — brugernavn;
password — brugernes adgangskode. I vores tilfælde angiver vi parameteren vcdvappvm.nginx.customization[0].admin_password, som gemmer den genererede adgangskode til systembrugeren.
host — den eksterne IP-adresse til tilslutning;
port — porten for tilslutning, som vi tidligere har angivet i DNAT-indstillingerne;
inline — vi angiver en liste over kommandoer, der vil blive indtastet. Kommandoerne vil blive indtastet i den rækkefølge, som er angivet i denne sektion.
Som et eksempel vil vi også køre installationsscriptet til 1C-Bitrix. Resultatet af scriptets udførelse vil være tilgængeligt under udførelsen af planen. For at installere scriptet beskriver vi først blokken:
Vi beskriver installationen af 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"
]
}
Og vi beskriver straks opdateringen af Bitrix.
Eksempel på provisionering af 1C-Bitrix.
ressource "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"
]
}
}
Vigtigt! Scriptet fungerer muligvis ikke, hvis SELinux ikke er deaktiveret på forhånd! Hvis du har brug for en detaljeret artikel om installation og opsætning af CMS 1C-Bitrix ved hjælp af bitrix-env.sh, kan du .
3. Initiering af infrastrukturen
Initiering af moduler og plugins
Til arbejdet bruger vi et simpelt “gentleman-sæt”: en bærbar computer med Windows 10 og distributionen fra den officielle hjemmeside . Lad os pakke den ud og initialisere det med følgende kommando: terraform.exe init
Efter beskrivelsen af den beregnings- og netværksinfrastruktur, starter vi planlægningen for at tjekke vores konfiguration, hvor vi kan se, hvad der vil blive oprettet, og hvordan det hænger sammen.
Kør kommandoen
- terraform plan -var-file=vcd.tfvars.Vi får resultatet
- Plan: 16 tilføjelser, 0 ændringer, 0 sletninger.Det vil sige, at 16 ressourcer vil blive oprettet i henhold til denne plan.Vi starter planen med kommandoen
- terraform.exe apply -var-file=vcd.tfvars.
Virtuelle maskiner vil blive oprettet, og derefter vil de pakker, vi har angivet i provisionssektionen, blive udført - OS vil blive opdateret, og CMS Bitrix vil blive installeret.
Modtagelse af data til forbindelse
Efter gennemførelsen af planen ønsker vi at få data til serverforbindelse i tekstformat; derfor opretter vi output-sektionen som følger:
output "nginxpassword" {
value = vcdvappvm.nginx.customization[0].adminpassword
}
Og den følgende output viser os adgangskoden for den oprettede virtuelle maskine:
Outputs: nginx_password = F#4u8!!N
I sidste ende får vi adgang til de virtuelle maskiner med det opdaterede operativsystem og de forudinstallerede pakker til vores videre arbejde. Alt er klar!
Men hvad hvis du allerede har en eksisterende infrastruktur?
3.1. Terraform med allerede eksisterende infrastruktur
Det er enkelt, du kan importere de nuværende virtuelle maskiner og deres vApp-containere ved hjælp af import-kommandoen.
Lad os beskrive vAPP-ressourcen og den virtuelle maskine.
resource "vcd_vapp" "Monitoring" {
name = "Monitoring"
org = "mClouds"
vdc = "mClouds"
}
resource "vcd_vapp_vm" "Zabbix" {
name = "Zabbix"
org = "mClouds"
vdc = "mClouds"
vapp = "Monitoring"
}
Næste skridt er at udføre import af vApp-ressourcens egenskaber i formatet vcdvapp.<vApp> <org>.<orgvdc>.<vApp>, hvor:
vApp — navnet på vApp;
org — navnet på organisationen;
org_vdc — navnet på det virtuelle datacenter.
Import af vAPP-ressourceegenskaber
Lad os importere VM-ressourceegenskaberne i formatet: vcdvappvm.<VM> <org>.<orgvdc>.<vApp>.<VM>, hvor:
VM — navnet på VM;
vApp — navnet på vApp;
org — navnet på organisationen;
orgvdc — navnet på det virtuelle datacenter.
Importen blev gennemført med succes
C:UsersMikhailDesktopterraform>terraform import vcd_vapp_vm.Zabbix mClouds.mClouds.Monitoring.Zabbix
vcd_vapp_vm.Zabbix: Importerer fra ID "mClouds.mClouds.Monitoring.Zabbix"...
vcd_vapp_vm.Zabbix: Importen er forberedt!
vcd_vapp_vm er forberedt til import
vcd_vapp_vm.Zabbix: Opdaterer tilstand... [id=urn:vcloud:vm:778f4a89-1c8d-45b9-9d94-0472a71c4d1f]
Importen var succesfuld!
De ressourcer, der blev importeret, vises ovenfor. Disse ressourcer er nu i
din Terraform-tilstand og vil fremover blive administreret af Terraform.
Nu kan vi tage et kig på den nye importerede ressource:
Importerede ressource
> 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 = "allokeret"
metadata = {}
name = "Overvågning"
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 = "Overvågning"
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"
}
}
Nu er det endelig klart — vi har afsluttet den sidste detalje (import i eksisterende infrastruktur) og dækket alle væsentlige aspekter ved arbejdet med Terraform.
Værktøjet har vist sig at være meget praktisk og giver mulighed for at beskrive din infrastruktur som kode, fra virtuelle maskiner af én cloud-udbyder til beskrivelse af netværkskomponenters ressourcer.
Samtidig giver uafhængigheden af miljøet mulighed for at arbejde med både lokale og cloud-ressourcer og endda styre platforme. Og hvis der ikke findes en støttet platform, og der er ønsker om at tilføje en ny, kan du skrive din egen udbyder og bruge den.
Kilde: habr.com
