I denne artikkelen skal vi se på hva Terraform består av, og også gradvis lansere vår egen infrastruktur — Vi vil klargjøre tre VM-er for forskjellige formål: proxy, fillagring og CMS.
Om alt i detalj og i tre stadier:
1. Terraform - beskrivelse, fordeler og komponenter
Terraform er et IaC-verktøy (Infrastructure-as-Code) for å bygge og administrere virtuell infrastruktur ved hjelp av kode.
Vi bemerket flere fordeler ved å jobbe med verktøyet:
-
Utplasseringshastighet for nye leietakere (egendefinerte virtuelle miljøer). Vanligvis, jo flere nye kunder det er, jo flere "klikk" må teknisk støttepersonell gjøre for å publisere nye ressurser. Med Terraform kan brukere endre virtuelle maskininnstillinger (for eksempel automatisk slå av OS og øke den virtuelle diskpartisjonen) uten å kreve teknisk støtte eller slå av selve maskinen.
-
Øyeblikkelig verifisering av aktiveringsplanen ny Tennant. Ved å bruke beskrivelsen av infrastrukturkoden kan vi umiddelbart sjekke hva som vil bli lagt til og i hvilken rekkefølge, samt i hvilken endelig tilstand denne eller den virtuelle maskinen eller virtuelt nettverk med tilkoblinger til virtuelle maskiner vil være.
-
Evne til å beskrive de mest populære skyplattformene. Du kan bruke verktøyet fra Amazon og Google Cloud, til private plattformer basert på VMware vCloud Director, som tilbyr tjenester innenfor IaaS, SaaS og PaaS-løsninger.
-
Administrer flere skyleverandører og distribuere infrastrukturen mellom dem for å forbedre feiltoleransen, ved å bruke én enkelt konfigurasjon for å opprette, diagnostisere og administrere skyressurser.
-
Praktisk bruk for å lage demostativer for programvaretesting og feilsøking. Du kan opprette og overføre stativer for testavdelingen, teste programvare i forskjellige miljøer parallelt, og umiddelbart endre og slette ressurser ved å lage én ressursoppbyggingsplan
"Terrarium" Terraform
Vi snakket kort om fordelene med verktøyet, la oss nå dele det ned i komponentene
Leverandører.
I Terraform kan nesten alle typer infrastruktur representeres som en ressurs. Forbindelsen mellom ressurser og API-plattformen leveres av leverandørmoduler, som lar deg opprette ressurser innenfor en bestemt plattform, for eksempel Azure eller VMware vCloud Director.
Som en del av prosjektet kan du samhandle med ulike leverandører på ulike plattformer.
Ressurser (ressursbeskrivelse).
Beskrivelse av ressurser lar deg administrere plattformkomponenter, for eksempel virtuelle maskiner eller nettverk.
Du kan selv lage en ressursbeskrivelse for VMware vCloud Director-leverandøren og bruke denne beskrivelsen til å lage ressurser hos en hvilken som helst vertsleverandør som bruker vCloud Director. Du trenger bare å endre autentiseringsparametrene og nettverkstilkoblingsparametrene til den nødvendige vertsleverandøren
Proviantører.
Denne komponenten gjør det mulig å utføre operasjoner for den første installasjonen og vedlikeholdet av operativsystemet etter å ha opprettet virtuelle maskiner. Når du har opprettet en virtuell maskinressurs, kan du bruke provisjoneringsprogrammer til å konfigurere og koble til via SSH, oppdatere operativsystemet og laste ned og kjøre et skript.
Input og Output variabler.
Inndatavariabler - inndatavariabler for alle blokktyper.
Utdatavariabler lar deg lagre verdier etter å ha opprettet ressurser og kan brukes som inngangsvariabler i andre moduler, for eksempel i Provisioners-blokken.
stater.
Statsfiler lagrer informasjon om konfigurasjonen av leverandørplattformressurser. Når plattformen først opprettes, er det ingen informasjon om ressurser og før enhver operasjon oppdaterer Terraform tilstanden med den reelle infrastrukturen til ressursene som allerede er beskrevet.
Hovedformålet med stater er å lagre en haug med objekter med allerede opprettede ressurser for å sammenligne konfigurasjonen av tilførte ressurser og objekter for å unngå gjentatt oppretting og endringer på plattformen.
Som standard lagres tilstandsinformasjon i den lokale terraform.tfstate-filen, men om nødvendig er det mulig å bruke ekstern lagring for teamarbeid.
Du kan også importere nåværende plattformressurser til staten for å samhandle ytterligere med andre ressurser som igjen ble opprettet uten hjelp fra Terraform.
2. Oppretting av infrastruktur
Komponentene er sortert ut, nå ved hjelp av Terraform vil vi gradvis lage en infrastruktur med tre virtuelle maskiner. Den første med nginx proxy-serveren installert, den andre med fillagring basert på Nextcloud og den tredje med CMS Bitrix.
Vi vil skrive kode og kjøre den ved å bruke vårt eksempel . Våre brukere mottar en konto med organisasjonsadministratorrettigheter. Hvis du bruker en konto med samme rettigheter i en annen VMware-sky, kan du reprodusere koden fra våre eksempler. Gå!
La oss først lage en katalog for vårt nye prosjekt der filer som beskriver infrastrukturen vil bli plassert.
mkdir project01
Deretter beskriver vi infrastrukturkomponentene. Terraform oppretter relasjoner og behandler filer basert på beskrivelsen i filene. Selve filene kan navngis basert på formålet med blokkene som beskrives, for eksempel network.tf - beskriver nettverksparametrene for infrastrukturen.
For å beskrive komponentene i infrastrukturen vår har vi laget følgende filer:
Liste over filer.
main.tf - beskrivelse av parametere for det virtuelle miljøet - virtuelle maskiner, virtuelle beholdere;
network.tf - beskrivelse av virtuelle nettverksparametere og NAT- og brannmurregler;
variables.tf - liste over variabler som vi bruker;
vcd.tfvars - prosjektvariabelverdier for VMware vCloud Director-modulen.
Konfigurasjonsspråket i Terraform er deklarativt og rekkefølgen på blokkene spiller ingen rolle, bortsett fra klargjøringsblokkene, fordi i denne blokken beskriver vi kommandoene som skal utføres når du klargjør infrastrukturen, og de vil bli utført i rekkefølge.
Blokkstruktur.
<BLOCK TYPE> "<BLOCK LABEL>" "<BLOCK LABEL>" {
# Block body
<IDENTIFIER> = <EXPRESSION> # Argument
}
For å beskrive blokker brukes dets eget programmeringsspråk HCL (HashiCorp Configuration Language), det er mulig å beskrive infrastrukturen ved hjelp av JSON. Du kan lære mer om syntaksen .
Miljøvariabelkonfigurasjon, variabler.tf og vcd.tfvars
La oss først lage to filer som beskriver listen over alle brukte variabler og deres verdier for VMware vCloud Director-modulen. Først, la oss lage variables.tf-filen.
Innholdet i 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 verdier som vi mottar fra leverandøren.
-
vcd_org_user — brukernavn med organisasjonsadministratorrettigheter,
-
vcd_org_password — brukerpassord,
-
vcd_org — navnet på organisasjonen,
-
vcd_org_vdc — navnet på det virtuelle datasenteret,
-
vcd_org_url - API URL,
-
vcd_org_edge_name — navnet på den virtuelle ruteren,
-
vcd_org_catalog — navnet på katalogen med virtuelle maskinmaler,
-
vcd_edge_external_ip — offentlig IP-adresse,
-
vcd_edge_external_network — navnet på det eksterne nettverket,
-
vcd_org_hdd_sp — navnet på HDD-lagringspolicyen,
-
vcd_org_ssd_sp — navnet på SSD-lagringspolicyen.
Og skriv inn variablene våre:
-
vcd_edge_local_ip_nginx — IP-adressen til den virtuelle maskinen med NGINX,
-
vcd_edge_local_ip_bitrix - IP-adressen til den virtuelle maskinen med 1C: Bitrix,
-
vcd_edge_local_ip_nextcloud — IP-adressen til den virtuelle maskinen med Nextcloud.
Med den andre filen oppretter og spesifiserer vi variabler for VMware vCloud Director-modulen i vcd.tfvars-filen: La oss huske at vi i vårt eksempel bruker , hvis du jobber med en annen leverandør, sjekk verdiene hos dem.
Innholdet i vcd.tfvars-filen.
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"
Nettverkskonfigurasjon, network.tf.
Miljøvariablene er satt, nå setter vi opp tilkoblingsskjemaet for den virtuelle maskinen - vi tildeler en privat IP-adresse til hver virtuell maskin og bruker Destination NAT til å "videre" portene til det eksterne nettverket. For å begrense tilgangen til administrasjonsporter, vil vi angi tilgang kun for vår IP-adresse.
Nettverksdiagram for Terraform-plattformen som opprettes
Vi oppretter et virtuelt organisasjonsnettverk med navnet net_lan01, standard gateway: 192.168.110.254, og også med adresseområdet: 192.168.110.0/24.
Vi beskriver et virtuelt nettverk.
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"
}
}
La oss lage brannmurregler som lar virtuelle maskiner få tilgang til Internett. Innenfor denne blokken vil alle virtuelle ressurser i skyen ha tilgang til Internett:
Vi beskriver reglene for VM-tilgang til Internett.
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]
}
Etter å ha etablert avhengigheten at etter å ha behandlet vcdnetworkrouted.net-blokken, fortsetter vi med å konfigurere vcdnsxvfirewall-regelblokken, ved bruk av kommer an på. Vi bruker dette alternativet fordi noen avhengigheter kan gjenkjennes implisitt i konfigurasjonen.
Deretter vil vi lage regler som tillater tilgang til porter fra det eksterne nettverket og indikerer vår IP-adresse for tilkobling via SSH til serverne. Enhver Internett-bruker har tilgang til portene 80 og 443 på webserveren, og en bruker med IP-adressen 90.1.15.1 har tilgang til SSH-portene til de virtuelle serverne.
Tillat tilgang til porter fra det eksterne nettverket.
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 lager Source NAT-regler for tilgang til Internett fra et lokalt skynettverk:
Vi beskriver Source NAT-reglene.
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 for å fullføre konfigurasjonen av nettverksblokken, legger vi til Destination NAT-regler for tilgang til tjenester fra det eksterne nettverket:
Legger til NAT-destinasjonsregler.
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]
}
Legg til en NAT-regel for portoversettelse 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]
}
Legg til en NAT-regel for portoversettelse 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]
}
Legg til en NAT-regel for portoversettelse 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]
}
Main.tf virtuelt miljøkonfigurasjon
Som vi planla i begynnelsen av artikkelen, vil vi lage tre virtuelle maskiner. De vil bli forberedt ved hjelp av "Gjestetilpasning". Vi vil sette nettverksparametrene i henhold til innstillingene vi spesifiserte, og brukerpassordet genereres automatisk.
La oss beskrive vApp som de virtuelle maskinene skal være plassert i og deres konfigurasjon.
Konfigurasjon av virtuell maskin
La oss lage en vApp-beholder. For at vi umiddelbart kan koble vApp og VM til det virtuelle nettverket, legger vi også til parameterendependent_on:
Lag en beholder
resource "vcd_vapp" "vapp" {
name = "web"
power_on = "true" depends_on = [vcd_network_routed.net]
}
La oss lage en virtuell maskin 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
}
}
Hovedparametere i VM-beskrivelsen:
-
navn - navnet på den virtuelle maskinen,
-
vappname - navnet på vAppen som skal legges til en ny VM,
-
katalognavn / malnavn - katalognavn og virtuell maskinmalnavn,
-
storageprofile - standard lagringspolicy.
Nettverksblokkparametere:
-
type — type tilkoblet nettverk,
-
navn – hvilket virtuelt nettverk å koble VM-en til,
-
isprimary - primær nettverksadapter,
-
ipallocation_mode — MANUELL / DHCP / POOL adressetildelingsmodus,
-
ip — IP-adresse for den virtuelle maskinen, vi spesifiserer den manuelt.
override_template_disk blokk:
-
sizeinmb — oppstartsdiskstørrelse for den virtuelle maskinen
-
storage_profile — lagringspolicy for disken
La oss lage en annen VM med en beskrivelse av 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 delen vcdvminternal_disk vil vi beskrive en ny virtuell disk som er koblet til den virtuelle maskinen.
Forklaringer for vcdvminternaldisk-blokken:
-
bustype - diskkontrollertype
-
sizeinmb — diskstørrelse
-
bussnummer / enhetsnummer - tilkoblingssted i adapteren
-
storage_profile — lagringspolicy for disken
La oss beskrive den nyeste 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
}
}
Oppdatere OS og installere flere skript
Nettverket er forberedt, de virtuelle maskinene er beskrevet. Før vi importerer infrastrukturen vår, kan vi utføre innledende klargjøring på forhånd ved å bruke klargjøringsblokker og uten å bruke Ansible.
La oss se på hvordan du oppdaterer operativsystemet og kjører CMS Bitrix-installasjonsskriptet ved å bruke provisjonsblokken.
Først, la oss installere CentOS-oppdateringspakker.
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 på komponenter:
-
provisjoner "remote-exec" - koble til den eksterne klargjøringsblokken
-
I tilkoblingsblokken beskriver vi typen og parameterne for tilkoblingen:
-
type — protokoll, i vårt tilfelle SSH;
-
bruker — brukernavn;
-
passord — brukerpassord. I vårt tilfelle peker vi på parameteren vcdvappvm.nginx.customization[0].admin_password, som lagrer det genererte passordet for systembrukeren.
-
vert — ekstern IP-adresse for tilkobling;
-
port — port for tilkobling, som tidligere ble spesifisert i DNAT-innstillingene;
-
inline - liste listen over kommandoer som vil bli lagt inn. Kommandoene vil bli lagt inn i rekkefølge som angitt i denne delen.
Som et eksempel, la oss i tillegg kjøre 1C-Bitrix-installasjonsskriptet. Utdata fra skriptutførelsesresultatet vil være tilgjengelig mens planen kjører. For å installere skriptet, beskriver vi først blokken:
La oss beskrive installasjonen av 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 umiddelbart beskrive Bitrix-oppdateringen.
Et eksempel på 1C-Bitrix-klargjø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"
]
}
}
Viktig! Skriptet fungerer kanskje ikke hvis du ikke deaktiverer SELinux på forhånd! Hvis du trenger en detaljert artikkel om å installere og konfigurere CMS 1C-Bitrix ved å bruke bitrix-env.sh, oo kan du .
3. Initialisering av infrastruktur
Initialisering av moduler og plugins
For arbeid bruker vi et enkelt "gentleman's kit": en bærbar datamaskin med Windows 10 OS og et distribusjonssett fra den offisielle nettsiden . La oss pakke ut og initialisere ved å bruke kommandoen: terraform.exe init
Etter å ha beskrevet data- og nettverksinfrastrukturen, lanserer vi planlegging for å teste konfigurasjonen vår, der vi kan se hva som vil bli opprettet og hvordan det vil bli koblet til hverandre.
-
Utfør kommandoen
- terraform plan -var-file=vcd.tfvars. -
Vi får resultatet
- Plan: 16 to add, 0 to change, 0 to destroy.Det vil si at det etter denne planen skal opprettes 16 ressurser. -
Vi lanserer planen på kommando
- terraform.exe apply -var-file=vcd.tfvars.
Virtuelle maskiner vil bli opprettet, og deretter vil pakkene vi har listet bli utført i provisjoneringsdelen - OS vil bli oppdatert og CMS Bitrix vil bli installert.
Motta tilkoblingsinformasjon
Etter å ha utført planen, ønsker vi å motta data i tekstform for tilkobling til serverne; for dette vil vi formatere utdatadelen som følger:
output "nginxpassword" {
value = vcdvappvm.nginx.customization[0].adminpassword
}
Og følgende utgang forteller oss passordet for den opprettede virtuelle maskinen:
Outputs: nginx_password = F#4u8!!N
Som et resultat får vi tilgang til virtuelle maskiner med oppdatert operativsystem og forhåndsinstallerte pakker for vårt videre arbeid. Alt er klart!
Men hva om du allerede har eksisterende infrastruktur?
3.1. Arbeider Terraform med eksisterende infrastruktur
Det er enkelt, du kan importere gjeldende virtuelle maskiner og deres vApp-beholdere ved å bruke importkommandoen.
La oss beskrive vAPP-ressursen og den virtuelle maskinen.
resource "vcd_vapp" "Monitoring" {
name = "Monitoring"
org = "mClouds"
vdc = "mClouds"
}
resource "vcd_vapp_vm" "Zabbix" {
name = "Zabbix"
org = "mClouds"
vdc = "mClouds"
vapp = "Monitoring"
}
Det neste trinnet er å importere egenskapene til vApp-ressurser i formatet vcdvapp.<vApp> <org>.<orgvdc>.<vApp>, hvor:
-
vApp - vApp navn;
-
org — navnet på organisasjonen;
-
org_vdc — navnet på det virtuelle datasenteret.
Importerer vAPP-ressursegenskaper
La oss importere egenskapene til VM-ressurser i formatet: vcdvappvm.<VM> <org>.<orgvdc>.<vApp>.<VM>, der:
-
VM - VM navn;
-
vApp - vApp navn;
-
org — navnet på organisasjonen;
-
orgvdc er navnet på det virtuelle datasenteret.
Importen var vellykket
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.
Nå kan vi se på den nye importerte ressursen:
Importert ressurs
> 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"
}
}
Nå er vi definitivt klare – vi er ferdige med det siste punktet (import til eksisterende infrastruktur) og har vurdert alle hovedpunktene med å jobbe med Terraform.
Verktøyet viste seg å være veldig praktisk og lar deg beskrive infrastrukturen din som kode, fra virtuelle maskiner fra én skyleverandør til å beskrive ressursene til nettverkskomponenter.
Samtidig gjør uavhengighet fra miljøet det mulig å jobbe med lokale, skyressurser, og til og med administrere plattformen. Og hvis det ikke er noen støttet plattform og du vil legge til en ny, kan du skrive din egen leverandør og bruke den.
Kilde: www.habr.com