Come gestire l'infrastruttura cloud con Terraform

Come gestire l'infrastruttura cloud con Terraform

In questo articolo, esamineremo in cosa consiste Terraform e lanceremo anche la nostra infrastruttura in più fasi nel cloud con VMware - preparare tre VM per scopi diversi: proxy, file storage e CMS.

Tutto nel dettaglio e in tre fasi:

1. Terraform: descrizione, vantaggi e componenti

Terraform è uno strumento IaC (Infrastructure-as-Code) per la creazione e la gestione dell'infrastruttura virtuale utilizzando il codice.

Lavorando con lo strumento, abbiamo notato diversi vantaggi:

  • La velocità di implementazione di nuovi inquilini (ambienti virtuali personalizzati). Solitamente, maggiore è il numero di nuovi clienti, maggiore è il numero di "click" necessari al personale di supporto tecnico per pubblicare nuove risorse. Con Terraform, gli utenti possono modificare i parametri delle macchine virtuali (ad esempio, spegnere automaticamente il sistema operativo e aumentare la partizione del disco virtuale) senza la partecipazione del supporto tecnico e spegnendo la macchina stessa.

  • Verifica immediata del piano di attivazione nuovo inquilino. Utilizzando la descrizione del codice dell'infrastruttura, possiamo immediatamente verificare cosa verrà aggiunto e in quale ordine, nonché in quale stato finale sarà questa o quella macchina virtuale o rete virtuale con connessioni a macchine virtuali.

  • Capacità di descrivere le piattaforme cloud più popolari. Puoi usare lo strumento da Amazon e Google Cloud a piattaforme private basate su VMware vCloud Director che offrono soluzioni IaaS, SaaS e PaaS.

  • Gestisci più fornitori di servizi cloud e distribuire l'infrastruttura tra di loro per migliorare la tolleranza ai guasti, utilizzando un'unica configurazione per creare, diagnosticare e gestire le risorse cloud.

  • Uso conveniente per la creazione di stand dimostrativi per il test e il debug del software. Puoi creare e trasferire banchi per il reparto test, testare il software in parallelo in diversi ambienti e modificare ed eliminare istantaneamente le risorse creando un solo piano di costruzione delle risorse

Terraforma "Terrario".

Abbiamo parlato brevemente dei vantaggi dello strumento, ora lo analizzeremo nei suoi componenti

Fornitori (fornitori). 

In Terraform, quasi ogni tipo di infrastruttura può essere rappresentata come una risorsa. La connessione tra le risorse e la piattaforma API è fornita dai moduli del provider, che consentono di creare risorse all'interno di una piattaforma specifica, come Azure o VMware vCloud Director.

All'interno di un progetto, puoi interagire con diversi fornitori su diverse piattaforme.

Risorse (descrizione delle risorse).

La descrizione delle risorse consente di gestire i componenti della piattaforma, come macchine virtuali o reti. 

È possibile creare autonomamente una descrizione della risorsa per un provider di VMware vCloud Director e utilizzare questa descrizione per creare risorse per qualsiasi provider di hosting che utilizza vCloud Director. Devi solo modificare i parametri di autenticazione e i parametri di connessione di rete al provider di hosting richiesto

Fornitori.

Questo componente consente di eseguire operazioni di prima installazione e manutenzione del sistema operativo dopo la creazione delle macchine virtuali. Dopo aver creato una risorsa macchina virtuale, puoi utilizzare i provisioner per configurare e connetterti tramite SSH, aggiornare il sistema operativo e scaricare ed eseguire uno script. 

Ingresso e uscita variabili.

Variabili di input: variabili di input per qualsiasi tipo di blocco. 

Le variabili di output consentono di salvare i valori dopo la creazione della risorsa e possono essere utilizzate come variabili di input in altri moduli, come il blocco Provisioners.

stati.

I file di stato memorizzano informazioni sulla configurazione delle risorse della piattaforma del provider. Quando la piattaforma viene creata per la prima volta, non ci sono informazioni sulle risorse, e prima di qualsiasi operazione, Terraform aggiorna lo stato con l'infrastruttura reale delle risorse già descritte.

Lo scopo principale degli stati è salvare una serie di oggetti di risorse già create per confrontare la configurazione di risorse e oggetti aggiunti al fine di evitare ricreazioni e modifiche alla piattaforma.

Le informazioni sullo stato sono archiviate localmente nel file terraform.tfstate per impostazione predefinita, ma puoi utilizzare l'archiviazione remota per il lavoro in team, se necessario.

Puoi anche importare le risorse della piattaforma corrente nello stato per interagire ulteriormente con altre risorse, che a loro volta sono state create senza l'aiuto di Terraform.  

2. Creazione di infrastrutture

I componenti sono stati smantellati, ora con l'aiuto di Terraform creeremo gradualmente un'infrastruttura con tre macchine virtuali. Il primo con il server proxy nginx installato, il secondo con l'archiviazione file basata su Nextcloud e il terzo con Bitrix CMS.

Scriveremo il codice e lo eseguiremo usando l'esempio del nostro cloud su VMware vCloud Director. Con noi, gli utenti ottengono un account con diritti di amministratore dell'organizzazione, se utilizzi un account con gli stessi diritti in un altro cloud VMware, puoi riprodurre il codice dai nostri esempi. Andare!

Innanzitutto, creiamo una directory per il nostro nuovo progetto, che conterrà i file che descrivono l'infrastruttura.

mkdir project01

Quindi descriviamo i componenti dell'infrastruttura. Terraform crea collegamenti ed elabora i file in base alla descrizione nei file. I file stessi possono essere nominati in base allo scopo dei blocchi descritti, ad esempio network.tf - descrive i parametri di rete per l'infrastruttura.

Per descrivere i componenti della nostra infrastruttura, abbiamo creato i seguenti file:

Elenco dei file.

main.tf - descrizione dei parametri per l'ambiente virtuale - macchine virtuali, contenitori virtuali;

network.tf - descrizione dei parametri della rete virtuale e NAT, regole del firewall;

variabili.tf - un elenco di variabili che usiamo;

vcd.tfvars: valori delle variabili di progetto per il modulo VMware vCloud Director.

Il linguaggio di configurazione in Terraform è dichiarativo e l'ordine dei blocchi non ha importanza, ad eccezione dei blocchi del provisioner, perché in questo blocco descriviamo i comandi da eseguire durante la preparazione dell'infrastruttura e verranno eseguiti in ordine.

Struttura a blocchi.

<BLOCK TYPE> "<BLOCK LABEL>" "<BLOCK LABEL>" {

# Block body

<IDENTIFIER> = <EXPRESSION> # Argument

}

I blocchi sono descritti utilizzando il proprio linguaggio di programmazione HCL (HashiCorp Configuration Language), è possibile descrivere l'infrastruttura utilizzando JSON. Per ulteriori informazioni sulla sintassi, vedere leggi sul sito dello sviluppatore.

Configurazione delle variabili d'ambiente, variable.tf e vcd.tfvars

Per prima cosa, creiamo due file che descrivono l'elenco di tutte le variabili utilizzate e i loro valori per il modulo VMware vCloud Director. Innanzitutto, creiamo il file variable.tf.

Il contenuto del file variable.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" {}

Valori variabili che riceviamo dal provider.

  • vcd_org_user - nome utente con diritti di amministratore dell'organizzazione,

  • vcd_org_password - password utente,

  • vcd_org - nome dell'organizzazione,

  • vcd_org_vdc - il nome del data center virtuale,

  • vcd_org_url - URL dell'API,

  • vcd_org_edge_name - nome del router virtuale,

  • vcd_org_catalog - il nome della directory con i modelli di macchine virtuali,

  • vcd_edge_external_ip - indirizzo IP pubblico,

  • vcd_edge_external_network - il nome della rete esterna,

  • vcd_org_hdd_sp - Nome criterio di archiviazione HDD,

  • vcd_org_ssd_sp è il nome del criterio di archiviazione SSD.

E inserisci le nostre variabili:

  • vcd_edge_local_ip_nginx - Indirizzo IP della macchina virtuale con NGINX,

  • vcd_edge_local_ip_bitrix - Indirizzo IP della macchina virtuale con 1C: Bitrix,

  • vcd_edge_local_ip_nextcloud - Indirizzo IP della macchina virtuale con Nextcloud.

Nel secondo file, creiamo e specifichiamo le variabili per il modulo VMware vCloud Director nel file vcd.tfvars: Ricordiamo che nel nostro esempio usiamo proprio cloud mClouds, se lavori con un altro provider, verifica i valori con lui. 

Il contenuto del file 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"

Configurazione di rete, network.tf.

Le variabili di ambiente sono impostate, ora configuriamo lo schema di connessione della macchina virtuale: assegna un indirizzo IP privato a ciascuna macchina virtuale e usa Destination NAT per "inoltrare" le porte alla rete esterna. Per limitare l'accesso alle porte di gestione, imposteremo l'accesso solo per il nostro indirizzo IP.

Come gestire l'infrastruttura cloud con TerraformDiagramma di rete per la piattaforma Terraform creata

Creiamo una rete organizzativa virtuale con il nome net_lan01, il gateway predefinito: 192.168.110.254, e anche con lo spazio degli indirizzi: 192.168.110.0/24.

Descrivi la rete virtuale.

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"

  }

}

Creiamo regole per il firewall, che consente di fornire alle macchine virtuali l'accesso a Internet. All'interno di questo blocco, tutte le risorse virtuali nel cloud avranno accesso a Internet:

Descriviamo le regole per l'accesso delle VM a Internet.

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]

}

Stabilita la dipendenza che dopo aver elaborato il blocco vcdnetworkrouted.net, si procede alla configurazione del blocco vcdnsxvfirewallrule, usando dipende da. Usiamo questa opzione perché alcune dipendenze possono essere implicitamente riconosciute nella configurazione.

Successivamente, creeremo regole che consentiranno l'accesso alle porte dalla rete esterna e specificheremo il nostro indirizzo IP per la connessione tramite SSH ai server. Qualsiasi utente Internet ha accesso alle porte 80 e 443 sul server Web e un utente con indirizzo IP 90.1.15.1 ha accesso alle porte SSH dei server virtuali.

Consentiamo l'accesso alle porte dalla rete esterna.

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]

}

Crea regole NAT di origine per l'accesso a Internet dalla rete locale cloud:

Descrivere le regole NAT di origine.

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]

}

E alla fine della configurazione del blocco di rete, aggiungiamo le regole NAT di destinazione per l'accesso ai servizi da una rete esterna:

Aggiunta delle regole NAT di destinazione.

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]

}

Aggiungi una regola NAT per convertire le porte nel server SSH in 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]

}

Aggiungiamo una regola NAT per la traduzione delle porte al server SSH con 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]

}

Aggiungi una regola NAT per tradurre le porte sul server SSH con 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]

}

Configurazione dell'ambiente virtuale main.tf

Come pianificato all'inizio dell'articolo, creeremo tre macchine virtuali. Saranno preparati con "Personalizzazione dell'ospite". Scriveremo i parametri di rete in base alle impostazioni che abbiamo specificato e la password dell'utente viene generata automaticamente.

Descriviamo la vApp in cui si troveranno le macchine virtuali e la loro configurazione.

Come gestire l'infrastruttura cloud con TerraformConfigurazione della macchina virtuale

Creiamo un contenitore vApp. Per connettere immediatamente la vApp e la VM alla rete virtuale, aggiungiamo anche il parametrodepends_on:

Crea un contenitore

resource "vcd_vapp" "vapp" {
name = "web"
power_on = "true" depends_on = [vcd_network_routed.net]

}

Crea una macchina virtuale con una descrizione

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

}

}

I parametri principali nella descrizione della VM:

  • name è il nome della macchina virtuale,

  • vappname - il nome della vApp in cui aggiungere una nuova VM,

  • catalogname / templatename - nome del catalogo e nome del modello della macchina virtuale,

  • storageprofile - criterio di archiviazione predefinito.

Parametri del blocco di rete:

  • tipo — tipo di rete connessa,

  • name - a quale rete virtuale connettere la VM,

  • isprimary - scheda di rete primaria,

  • ipallocation_mode - MANUALE / DHCP / modalità di allocazione indirizzo POOL,

  • ip - Indirizzo IP per la macchina virtuale, lo specificheremo manualmente.

blocco override_template_disk:

  • sizeinmb - dimensione del disco di avvio per la macchina virtuale

  • storage_profile - criterio di archiviazione per il disco

Creiamo una seconda VM con una descrizione del file storage di 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 ]

}

Nella sezione vcdvminternal_disk, descriviamo un nuovo disco virtuale connesso alla macchina virtuale.

Spiegazioni sul blocco vcdvminternaldisk:

  • bustype - tipo di controller del disco

  • sizeinmb - dimensione del disco

  • busnumber / unitnumber - punto di connessione nell'adattatore

  • storage_profile - criterio di archiviazione per il disco

Descriviamo l'ultima VM su 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

}

}

Aggiornamento del sistema operativo e installazione di script aggiuntivi

La rete è preparata, le macchine virtuali sono descritte. Prima di importare la nostra infrastruttura, possiamo eseguire il pre-provisioning con blocchi di provisioner e senza utilizzare Ansible.

Consideriamo come aggiornare il sistema operativo ed eseguire lo script di installazione di Bitrix CMS utilizzando il blocco provisioner.

Installiamo prima i service pack CentOS.

resource "null_resource" "nginx_update_install" {

provisioner "remote-exec" {

connection {

type = "ssh"

user = "root"

password = vcd_vapp_vm.nginx.customization[0].admin_password

host = var.vcd_edge_external_ip

port = "58301"

timeout = "30s"

}

inline = [

"yum -y update && yum -y upgrade",

"yum -y install wget nano epel-release net-tools unzip zip" ]

}

}

}

Designazione dei componenti:

  • provisioner "remote-exec" - collega il blocco "provisioning" remoto

  • Nel blocco di connessione, descriviamo il tipo e i parametri per la connessione:

  • tipo - protocollo, nel nostro caso SSH;

  • utente - nome utente;

  • password — la password dell'utente. Nel nostro caso, puntiamo al parametro vcdvappvm.nginx.customization[0].admin_password, che memorizza la password generata dall'utente di sistema.

  • host — indirizzo IP esterno per la connessione;

  • port - porta per la connessione, precedentemente specificata nelle impostazioni DNAT;

  • inline - elenca l'elenco dei comandi che verranno immessi. I comandi verranno immessi nell'ordine, come specificato in questa sezione.

Ad esempio, eseguiamo anche lo script di installazione 1C-Bitrix. L'output del risultato dell'esecuzione dello script sarà disponibile durante l'esecuzione del piano. Per installare lo script, descriviamo prima il blocco:

Descriviamo l'installazione di 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"

]

}

E descriveremo immediatamente l'aggiornamento di Bitrix.

Un esempio di provisioning 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"

]

}

}

Importante! Lo script potrebbe non funzionare a meno che SELinux non sia disabilitato in anticipo! Se hai bisogno di un articolo dettagliato sull'installazione e la configurazione di CMS 1C-Bitrix utilizzando bitrix-env.sh, puoi utilizzare il nostro articolo del blog sul sito web.

3. Inizializzazione dell'infrastruttura

Come gestire l'infrastruttura cloud con TerraformInizializzazione di moduli e plugin

Per lavoro utilizziamo un semplice "set da gentiluomo": un laptop con Windows 10 e un kit di distribuzione dal sito ufficiale terraform.io. Scompattare e inizializzare con il comando: terraform.exe init

Dopo aver descritto l'infrastruttura informatica e di rete, iniziamo a pianificare di testare la nostra configurazione, dove possiamo vedere cosa verrà creato e come è connesso tra loro.

  1. Esegui il comando - terraform plan -var-file=vcd.tfvars.

  2. Otteniamo il risultato - Plan: 16 to add, 0 to change, 0 to destroy. Cioè, secondo questo piano, verranno create 16 risorse.

  3. Lanciare il piano a comando - terraform.exe apply -var-file=vcd.tfvars.

Verranno create macchine virtuali, quindi i pacchetti da noi elencati verranno eseguiti all'interno della sezione provisioner: il sistema operativo verrà aggiornato e verrà installato CMS Bitrix.

Recupero dei dati di connessione

Dopo l'esecuzione del piano, vogliamo ricevere i dati in forma di testo per la connessione ai server, per questo organizzeremo la sezione di output come segue:

output "nginxpassword" {

 value = vcdvappvm.nginx.customization[0].adminpassword

}

E il seguente output ci dice la password dalla macchina virtuale creata:

Outputs: nginx_password = F#4u8!!N

Di conseguenza, otteniamo l'accesso a macchine virtuali con un sistema operativo aggiornato e pacchetti preinstallati per il nostro ulteriore lavoro. Tutto è pronto!

Ma cosa succede se si dispone già di un'infrastruttura esistente?

3.1. Terraform funziona con l'infrastruttura esistente

È semplice, puoi importare le macchine virtuali correnti e i relativi contenitori di vApp utilizzando il comando import.

Descriviamo la risorsa vAPP e la macchina virtuale.

resource "vcd_vapp" "Monitoring" {

name = "Monitoring"

org = "mClouds"

vdc = "mClouds"

}

resource "vcd_vapp_vm" "Zabbix" {

name = "Zabbix"

org = "mClouds"

vdc = "mClouds"

vapp = "Monitoring"

}

Il passaggio successivo consiste nell'importare le proprietà della risorsa vApp nel formato vcdvapp.<vApp> <org>.<orgvdc>.<vApp>, dove:

  • vApp è il nome della vApp;

  • org è il nome dell'organizzazione;

  • org_vdc è il nome del data center virtuale.

Come gestire l'infrastruttura cloud con TerraformImporta le proprietà della risorsa vAPP

Importiamo le proprietà delle risorse VM nel formato: vcdvappvm.<VM> <org>.<orgvdc>.<vApp>.<VM>, in quale:

  • VM - nome VM;

  • vApp è il nome della vApp;

  • org è il nome dell'organizzazione;

  • orgvdc è il nome del data center virtuale.

L'importazione è andata a buon fine

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.

Ora possiamo esaminare la risorsa appena importata:

Risorsa importata

> 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"

}

}

Ora siamo decisamente pronti: abbiamo terminato con l'ultimo momento (importazione in un'infrastruttura esistente) e abbiamo considerato tutti i punti principali del lavoro con Terraform. 

Lo strumento si è rivelato molto conveniente e ti consente di descrivere la tua infrastruttura come codice, dalle macchine virtuali di un provider cloud alla descrizione delle risorse dei componenti di rete.

Allo stesso tempo, l'indipendenza dall'ambiente consente di lavorare con risorse locali, cloud e, per finire, con la gestione della piattaforma. E se non c'è una piattaforma supportata e vuoi aggiungerne una nuova, puoi scrivere il tuo provider e usarlo.

Fonte: habr.com

Aggiungi un commento