I denne artikel vil vi se på, hvad Terraform består af, og også lancere vores egen infrastruktur i etaper - klargør tre VM'er til forskellige formål: proxy, fillagring og CMS.
Alt i detaljer og i tre faser:
1. Terraform - beskrivelse, fordele og komponenter
Terraform er et IaC-værktøj (Infrastructure-as-Code) til at bygge og administrere virtuel infrastruktur ved hjælp af kode.
I arbejdet med værktøjet bemærkede vi flere fordele:
-
Hastigheden af indsættelse af nye lejere (tilpassede virtuelle miljøer). Normalt, jo flere nye kunder, jo flere "klik" skal den tekniske supportmedarbejder foretage for at udgive nye ressourcer. Med Terraform kan brugere ændre parametrene for virtuelle maskiner (f.eks. automatisk lukke OS og øge den virtuelle diskpartition) uden deltagelse af teknisk support og at lukke selve maskinen ned.
-
Øjeblikkelig verifikation af aktiveringsplanen ny lejer. Ved hjælp af beskrivelsen af infrastrukturkoden kan vi straks kontrollere, hvad der vil blive tilføjet og i hvilken rækkefølge, samt i hvilken endelig tilstand denne eller hin virtuelle maskine eller virtuelt netværk med forbindelser til virtuelle maskiner vil være.
-
Evne til at beskrive de mest 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 IaaS, SaaS og PaaS løsninger.
-
Administrer flere cloud-udbydere og distribuere infrastruktur mellem dem for at forbedre fejltolerancen ved at bruge én konfiguration til at oprette, diagnosticere og administrere cloud-ressourcer.
-
Praktisk brug til at skabe demo stande til softwaretest og fejlfinding. Du kan oprette og overføre bænke til testafdelingen, teste software parallelt i forskellige miljøer og øjeblikkeligt ændre og slette ressourcer ved at oprette én ressourceopbygningsplan
"Terrarium" Terraform
Vi talte kort om fordelene ved værktøjet, nu vil vi analysere det i dets komponenter
Udbydere (udbydere).
I Terraform kan næsten enhver form for infrastruktur repræsenteres som en ressource. Forbindelsen mellem ressourcer og API-platformen leveres af udbydermoduler, som giver dig mulighed for at oprette ressourcer inden for en bestemt platform, såsom Azure eller VMware vCloud Director.
Inden for et projekt kan du interagere med forskellige udbydere på forskellige platforme.
Ressourcer (beskrivelse af ressourcer).
Beskrivelse af ressourcer giver dig mulighed for at administrere platformskomponenter, såsom virtuelle maskiner eller netværk.
Du kan selv oprette en ressourcebeskrivelse for en VMware vCloud Director-udbyder og bruge denne beskrivelse til at oprette ressourcer til enhver hostingudbyder, der bruger vCloud Director. Du behøver kun at ændre godkendelsesparametrene og netværksforbindelsesparametrene til den nødvendige hostingudbyder
Forsørgere.
Denne komponent gør det muligt at udføre operationer til den indledende installation og vedligeholdelse af operativsystemet efter oprettelsen af virtuelle maskiner. Når du har oprettet en virtuel maskinressource, kan du bruge provisioners til at konfigurere og oprette forbindelse via SSH, opgradere operativsystemet og downloade og udføre et script.
Variabler Input og Output.
Inputvariabler — inputvariabler for alle bloktyper.
Outputvariabler tillader, at værdier gemmes efter ressourceoprettelse og kan bruges som inputvariabler i andre moduler, såsom Provisioners-blokken.
stater.
Statsfiler gemmer oplysninger om udbyderens platformsressourcekonfiguration. Når platformen først oprettes, er der ingen information om ressourcerne, og før enhver operation opdaterer Terraform tilstanden med den reelle infrastruktur for de allerede beskrevne ressourcer.
Hovedformålet med stater er at gemme en masse objekter af allerede oprettede ressourcer for at sammenligne konfigurationen af tilføjede ressourcer og objekter for at undgå genskabelse og ændringer af platformen.
Statusoplysninger gemmes lokalt i terraform.tfstate-filen som standard, men du kan bruge fjernlagring til teamarbejde, hvis det er nødvendigt.
Du kan også importere de nuværende platformsressourcer til staten for yderligere at interagere med andre ressourcer, som igen blev oprettet uden hjælp fra Terraform.
2. Oprettelse af infrastruktur
Komponenterne er blevet demonteret, nu vil vi ved hjælp af Terraform gradvist skabe en infrastruktur med tre virtuelle maskiner. Den første med nginx-proxyserver installeret, den anden med Nextcloud-baseret fillagring og den tredje med Bitrix CMS.
Vi vil skrive kode og udføre den ved at bruge eksemplet med vores . Hos os får brugerne en konto med Organisationsadministratorrettigheder, hvis du bruger en konto med samme rettigheder i en anden VMware-sky, kan du gengive koden fra vores eksempler. Gå!
Lad os først oprette en mappe til vores nye projekt, som vil indeholde filer, der beskriver infrastrukturen.
mkdir project01
Derefter beskriver vi komponenterne i infrastrukturen. Terraform opretter links og behandler filer ud fra beskrivelsen i filerne. Selve filerne kan navngives ud fra formålet med de beskrevne blokke, for eksempel netværk.tf - beskriver netværksparametrene 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 virtuelle netværksparametre og NAT, Firewall-regler;
variables.tf - en liste over variabler, som vi bruger;
vcd.tfvars - projektvariable værdier for VMware vCloud Director-modulet.
Konfigurationssproget i Terraform er deklarativt, og rækkefølgen af blokke har ingen betydning, undtagen for provisioner-blokke, fordi i denne blok beskriver vi de kommandoer, der skal udføres, når infrastrukturen forberedes, og de vil blive udført i rækkefølge.
Blokstruktur.
<BLOCK TYPE> "<BLOCK LABEL>" "<BLOCK LABEL>" {
# Block body
<IDENTIFIER> = <EXPRESSION> # Argument
}
Blokke er beskrevet ved hjælp af deres eget programmeringssprog HCL (HashiCorp Configuration Language), det er muligt at beskrive infrastrukturen ved hjælp af JSON. For mere information om syntaks, se .
Miljøvariabelkonfiguration, variabler.tf og vcd.tfvars
Lad os først oprette to filer, der beskriver listen over alle anvendte variabler og deres værdier for VMware vCloud Director-modulet. Lad os først oprette filen variables.tf.
Indholdet af variables.tf-filen.
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" {}
Variable værdier, som vi modtager fra udbyderen.
-
vcd_org_user - brugernavn med organisationsadministratorrettigheder,
-
vcd_org_password - brugeradgangskode,
-
vcd_org - organisationens navn,
-
vcd_org_vdc - navnet på det virtuelle datacenter,
-
vcd_org_url - API URL,
-
vcd_org_edge_name - virtuel routernavn,
-
vcd_org_catalog - navnet på mappen med virtuelle maskine skabeloner,
-
vcd_edge_external_ip - offentlig IP-adresse,
-
vcd_edge_external_network - navnet på det eksterne netværk,
-
vcd_org_hdd_sp - HDD-lagerpolitiknavn,
-
vcd_org_ssd_sp er navnet på SSD-lagerpolitikken.
Og indtast vores 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 og specificerer vi variabler for VMware vCloud Director-modulet i filen vcd.tfvars: Husk, at vi i vores eksempel bruger , hvis du arbejder med en anden udbyder, så tjek værdierne hos ham.
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 = "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"
Netværkskonfiguration, netværk.tf.
Miljøvariablerne er indstillet, lad os nu konfigurere forbindelsesskemaet for den virtuelle maskine - tildel en privat IP-adresse til hver virtuel maskine og brug Destination NAT til at "viderestille" porte til det eksterne netværk. For at begrænse adgangen til administrationsporte sætter vi kun adgang til vores IP-adresse.
Netværksdiagram for den oprettede Terraform platform
Vi opretter et virtuelt organisatorisk netværk med navnet net_lan01, standardgatewayen: 192.168.110.254, og også med adresserummet: 192.168.110.0/24.
Beskriv 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"
}
}
Lad os lave regler for firewallen, som giver dig mulighed for at give virtuelle maskiner adgang til internettet. Inden for denne blok vil alle virtuelle ressourcer i skyen have adgang til internettet:
Vi beskriver reglerne for VM-adgang til internettet.
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 etableret den afhængighed, at efter at have behandlet vcdnetworkrouted.net-blokken, fortsætter vi til konfigurationen af vcdnsxvfirewallrule-blokken, ved hjælp af afhænger af. Vi bruger denne mulighed, fordi nogle afhængigheder implicit kan genkendes i konfigurationen.
Dernæst vil vi oprette regler, der tillader adgang til porte fra det eksterne netværk og specificere vores IP-adresse til at oprette forbindelse via SSH til serverne. Enhver internetbruger har adgang til porte 80 og 443 på webserveren, og en bruger med IP-adresse 90.1.15.1 har adgang til SSH-portene på de virtuelle servere.
Vi tillader adgang til porte 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]
}
Opret Source NAT-regler for adgang til internettet fra cloud-lokalnetværket:
Beskriv Source NAT-reglerne.
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]
}
Og i slutningen af netværksblokkonfigurationen tilføjer vi Destination NAT-regler for adgang til tjenester fra et eksternt netværk:
Tilføjelse af destinations-NAT-regler.
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]
}
Tilføj en NAT-regel for at oversætte porte 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
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]
}
Vi tilføjer en NAT-regel for portoversættelse 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
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]
}
Tilføj en NAT-regel for at oversætte porte 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
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]
}
Konfiguration af virtuelt miljø main.tf
Som vi planlagde i begyndelsen af artiklen, vil vi oprette tre virtuelle maskiner. De vil blive forberedt med "Gæstetilpasning". Vi skriver netværksparametrene i henhold til de indstillinger, vi har angivet, og adgangskoden fra brugeren genereres automatisk.
Lad os beskrive den vApp, hvori de virtuelle maskiner og deres konfiguration vil være placeret.
Virtuel maskine konfiguration
Lad os oprette en vApp-beholder. For at vi straks kan forbinde vApp og VM til det virtuelle netværk, tilføjer vi også parameterendependent_on:
Opret en beholder
resource "vcd_vapp" "vapp" {
name = "web"
power_on = "true" depends_on = [vcd_network_routed.net]
}
Opret en virtuel maskine med en beskrivelse
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
}
}
De vigtigste parametre i beskrivelsen af VM'en:
-
navn er navnet på den virtuelle maskine,
-
vappname - navnet på den vApp, hvori der skal tilføjes en ny VM,
-
katalognavn / skabelonnavn - katalognavn og virtuel maskine skabelonnavn,
-
storageprofile - standard opbevaringspolitik.
Netværksblokparametre:
-
type — type forbundet netværk,
-
navn - hvilket virtuelt netværk den VM skal forbindes til,
-
isprimary - primær netværksadapter,
-
ipallocation_mode - MANUEL / DHCP / POOL adressetildelingstilstand,
-
ip - IP-adresse for den virtuelle maskine, vi angiver den manuelt.
override_template_disk blok:
-
sizeinmb - størrelse på startdisken for den virtuelle maskine
-
storage_profile - lagerpolitik for disken
Lad os oprette en anden VM med en beskrivelse af Nextcloud-fillagringen
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 ]
}
I afsnittet vcdvminternal_disk beskriver vi en ny virtuel disk, der er forbundet til den virtuelle maskine.
Forklaringer på vcdvminternaldisk-blokken:
-
bustype - diskcontrollertype
-
sizeinmb - diskstørrelse
-
busnummer / enhedsnummer - tilslutningspunkt i adapteren
-
storage_profile - lagerpolitik for disken
Lad os beskrive den sidste VM på 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 opdatering og installation af yderligere scripts
Netværket er forberedt, de virtuelle maskiner er beskrevet. Inden vi importerer vores infrastruktur, kan vi forudprovisionere med provisioneringsblokke og uden at bruge Ansible.
Lad os overveje, hvordan du opdaterer operativsystemet og kører Bitrix CMS-installationsscriptet ved hjælp af provisioneringsblokken.
Lad os først installere CentOS service packs.
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" ]
}
}
}
Betegnelse af komponenter:
-
provisioner "remote-exec" - tilslut den eksterne "provisioning"-blok
-
I forbindelsesblokken beskriver vi typen og parametrene for forbindelsen:
-
type - protokol, i vores tilfælde SSH;
-
bruger - brugernavn;
-
password — brugerens adgangskode. I vores tilfælde peger vi på parameteren vcdvappvm.nginx.customization[0].admin_password, som gemmer den genererede adgangskode fra systembrugeren.
-
vært — ekstern IP-adresse til forbindelse;
-
port - port til forbindelse, som tidligere var angivet i DNAT-indstillingerne;
-
inline - lister listen over kommandoer, der vil blive indtastet. Kommandoerne vil blive indtastet i rækkefølge, som specificeret i dette afsnit.
Som et eksempel, lad os desuden udføre 1C-Bitrix installationsscriptet. Outputtet af scriptudførelsesresultatet vil være tilgængeligt under udførelsen af planen. For at installere scriptet beskriver vi først blokken:
Lad os beskrive 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 vil straks beskrive Bitrix-opdateringen.
Et eksempel på 1C-Bitrix-klargøring.
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"
]
}
}
Vigtig! Scriptet virker muligvis ikke, medmindre SELinux er deaktiveret på forhånd! Hvis du har brug for en detaljeret artikel om installation og konfiguration af CMS 1C-Bitrix ved hjælp af bitrix-env.sh, kan du .
3. Infrastrukturinitialisering
Initialisering af moduler og plugins
Til arbejde bruger vi et simpelt "gentleman's set": en bærbar computer med Windows 10 og et distributionssæt fra den officielle hjemmeside . Pak ud og initialiser med kommandoen: terraform.exe init
Efter at have beskrevet computer- og netværksinfrastrukturen, begynder vi at planlægge at teste vores konfiguration, hvor vi kan se, hvad der vil blive oprettet, og hvordan det er forbundet med hinanden.
-
Udfør kommandoen
- terraform plan -var-file=vcd.tfvars. -
Vi får resultatet
- Plan: 16 to add, 0 to change, 0 to destroy.Det vil sige, at der ifølge denne plan bliver skabt 16 ressourcer. -
Lancering af planen på kommando
- terraform.exe apply -var-file=vcd.tfvars.
Virtuelle maskiner vil blive oprettet, og derefter vil de pakker, der er angivet af os, blive eksekveret i provisioner-sektionen - OS vil blive opdateret, og CMS Bitrix vil blive installeret.
Henter forbindelsesdata
Efter udførelse af planen ønsker vi at modtage data i tekstform til tilslutning til servere, til dette arrangerer vi outputsektionen som følger:
output "nginxpassword" {
value = vcdvappvm.nginx.customization[0].adminpassword
}
Og følgende output fortæller os adgangskoden fra den oprettede virtuelle maskine:
Outputs: nginx_password = F#4u8!!N
Som et resultat får vi adgang til virtuelle maskiner med et opdateret styresystem og forudinstallerede pakker til vores videre arbejde. Alt er klar!
Men hvad hvis du allerede har en eksisterende infrastruktur?
3.1. Terraform arbejder med eksisterende infrastruktur
Det er enkelt, du kan importere aktuelle virtuelle maskiner og deres vApp-beholdere ved hjælp af importkommandoen.
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"
}
Det næste trin er at importere vApp-ressourceegenskaber i formatet vcdvapp.<vApp> <org>.<orgvdc>.<vApp>, Hvor:
-
vApp er navnet på vAppen;
-
org er navnet på organisationen;
-
org_vdc er navnet på det virtuelle datacenter.
Importér vAPP-ressourceegenskaber
Lad os importere egenskaberne for VM-ressourcer i formatet: vcdvappvm.<VM> <org>.<orgvdc>.<vApp>.<VM>, hvori:
-
VM - VM navn;
-
vApp er navnet på vAppen;
-
org er navnet på organisationen;
-
orgvdc er navnet på det virtuelle datacenter.
Importen lykkedes
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.
Nu kan vi se på den nyligt importerede ressource:
Importeret 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 = "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"
}
}
Nu er vi helt klart klar - vi er færdige med det sidste øjeblik (import til en eksisterende infrastruktur) og har overvejet alle hovedpunkterne i arbejdet med Terraform.
Værktøjet viste sig at være meget praktisk og giver dig mulighed for at beskrive din infrastruktur som kode, lige fra virtuelle maskiner fra én cloud-udbyder til at beskrive ressourcerne i netværkskomponenter.
Samtidig gør uafhængighed af miljøet det muligt at arbejde med lokale, cloud-ressourcer og, afsluttende med platformsstyring. Og hvis der ikke er nogen understøttet platform, og du vil tilføje en ny, kan du skrive din egen udbyder og bruge den.
Kilde: www.habr.com