Neste artigo, vamos explorar do que é feito o Terraform e, passo a passo, lançaremos nossa própria infraestrutura — prepararemos três VMs para diferentes propósitos: proxy, armazenamento de arquivos e CMS.
Tudo detalhadamente e em três etapas:
1. Terraform — descrição, vantagens e componentes
Terraform é uma ferramenta IaC (Infrastructure-as-Code) para a construção e gerenciamento de infraestrutura virtual através de código.
Ao trabalhar com a ferramenta, notamos várias vantagens:
Velocidade na implementação de novos tenants (ambientes virtuais de usuários). Geralmente, quanto mais novos clientes, mais 'cliques' a equipe de suporte técnico precisa fazer para publicar novos recursos. Com o Terraform, os usuários podem alterar os parâmetros das máquinas virtuais (por exemplo, desligar automaticamente o sistema operacional e aumentar a partição do disco virtual) sem a intervenção da equipe de suporte técnico e sem desligar a máquina em si.
Verificação imediata do plano de ativação do novo tenant. Com a descrição do código da infraestrutura, podemos imediatamente verificar o que e em que ordem será adicionado, assim como qual será o estado final de uma máquina virtual ou rede virtual com conexões a máquinas virtuais.
Capacidade de descrever a maioria das plataformas de nuvem populares. Você pode usar a ferramenta desde Amazon e Google Cloud até plataformas privadas baseadas em VMware vCloud Director, oferecendo serviços nos modelos IaaS, SaaS e PaaS.
Gerenciar vários provedores de nuvem e distribuir a infraestrutura entre eles para aumentar a resiliência, utilizando uma única configuração para criar, diagnosticar e gerenciar recursos de nuvem.
Facilidade de uso para criar ambientes de demonstração para teste e depuração de software. Você pode criar e transferir ambientes para o departamento de testes, paralelamente verificar o software em diferentes ambientes, além de alterar e remover recursos instantaneamente, criando apenas um plano de construção de recursos.
O 'Terrário' do Terraform
Falamos brevemente sobre as vantagens da ferramenta, agora vamos analisar seus componentes
Providers (provedores).
No Terraform, praticamente qualquer tipo de infraestrutura pode ser representado como um recurso. A conexão entre os recursos e a plataforma API é garantida pelos módulos providers, que permitem a criação de recursos em uma plataforma específica, como Azure ou VMware vCloud Director.
No âmbito do projeto, você pode interagir com diferentes provedores em diferentes plataformas.
Recursos (descrição dos recursos).
A descrição dos recursos permite gerenciar componentes da plataforma, como máquinas virtuais ou redes.
Você pode criar sua própria descrição de recursos para o provedor VMware vCloud Director e usar essa descrição para criar recursos em qualquer provedor de hospedagem que utilize vCloud Director. Você só precisará substituir os parâmetros de autenticação e os parâmetros de conexão de rede pelo provedor de hospedagem necessário.
Provisioners.
Esse componente permite realizar operações de instalação inicial e manutenção do sistema operacional após a criação de máquinas virtuais. Depois de criar o recurso de máquina virtual, você pode usar os provisioners para configurá-la e se conectar via SSH, executar atualizações do sistema operacional e também fazer upload e executar um script.
Variáveis de Input e Output.
As variáveis Input são variáveis de entrada para qualquer tipo de bloco.
As variáveis Output permitem conservar valores após a criação de recursos e podem ser usadas como variáveis de entrada em outros módulos, como no bloco Provisioners.
States (estados).
Os arquivos de States armazenam informações sobre a configuração dos recursos da plataforma do provedor. Ao criar a plataforma pela primeira vez, não há informações sobre os recursos, e antes de qualquer operação o Terraform atualiza o estado com a infraestrutura real dos recursos já descritos.
O principal objetivo dos estados é manter a vinculação de objetos dos recursos já criados para comparar a configuração dos recursos adicionados e objetos, a fim de evitar recreações e alterações na plataforma.
As informações sobre o estado são, por padrão, armazenadas em um arquivo local terraform.tfstate, mas, se necessário, existe a possibilidade de utilizar armazenamento remoto para trabalhar em equipe.
Você também pode importar os recursos atuais da plataforma para o estado, a fim de interagir com outros recursos que por sua vez foram criados sem a ajuda do Terraform.
2. Criação de infraestrutura
Os componentes foram desmontados, agora com o Terraform vamos criar a infraestrutura em etapas com três máquinas virtuais. A primeira com um servidor proxy nginx instalado, a segunda com armazenamento de arquivos baseado no Nextcloud e a terceira com o CMS Bitrix.
Escreveremos o código e o executaremos com base no nosso . Os usuários recebem uma conta com permissões de Administrador da Organização. Se você usar uma conta com as mesmas permissões em outra nuvem VMware, poderá reproduzir o código dos nossos exemplos. Vamos lá!
Primeiro, criaremos um diretório para o nosso novo projeto, onde estarão os arquivos com a descrição da infraestrutura.
mkdir project01
Em seguida, descreveremos os componentes da infraestrutura. O Terraform cria relacionamentos e processa arquivos com base nas descrições contidas nos arquivos. Os arquivos podem ser nomeados de acordo com o propósito dos blocos descritos, por exemplo, network.tf — descreve os parâmetros de rede para a infraestrutura.
Para descrever os componentes da nossa infraestrutura, criamos os seguintes arquivos:
Lista de arquivos.
main.tf — descrição dos parâmetros para o ambiente virtual — máquinas virtuais, contêineres virtuais;
network.tf — descrição dos parâmetros da rede virtual e regras de NAT, Firewall;
variables.tf — lista de variáveis que utilizamos;
vcd.tfvars — valores das variáveis do projeto para o módulo VMware vCloud Director.
A linguagem de configuração no Terraform é declarativa e a ordem dos blocos não importa, exceto para os blocos do provisionador, pois neste bloco descrevemos os comandos a serem executados durante a preparação da infraestrutura, e eles serão executados em ordem.
Estrutura dos blocos.
"" "" {
# Block body
= # Argumento
}
Para descrever os blocos, utiliza-se a linguagem de programação HCL (HashiCorp Configuration Language) e é possível descrever a infraestrutura também usando JSON. Para mais informações sobre a sintaxe, você pode .
Configuração da variável de ambiente, variables.tf e vcd.tfvars
Primeiro, criaremos dois arquivos que descrevem a lista de todas as variáveis utilizadas e seus valores para o módulo VMware vCloud Director. Primeiro, criaremos o arquivo variables.tf.
Conteúdo do arquivo variables.tf.
variável "vcd_org_user" {
descrição = "Usuário do inquilino vCD"
}
variável "vcd_org_password" {
descrição = "Senha do inquilino vCD"
}
variável "vcd_org" {
descrição = "Organização do inquilino vCD"
}
variável "vcd_org_vdc" {
descrição = "VDC do inquilino vCD"
}
variável "vcd_org_url" {
descrição = "URL do inquilino vCD"
}
variável "vcd_org_max_retry_timeout" {
padrão = "60"
}
variável "vcd_org_allow_unverified_ssl" {
padrão = "true"
}
variável "vcd_org_edge_name" {
descrição = "nome da borda vCD"
}
variável "vcd_org_catalog" {
descrição = "catálogo público vCD"
}
variável "vcd_template_os_centos7" {
descrição = "OS CentOS 7"
padrão = "CentOS7"
}
variável "vcd_org_ssd_sp" {
descrição = "Políticas de Armazenamento"
padrão = "Política de Armazenamento de Ouro"
}
variável "vcd_org_hdd_sp" {
descrição = "Políticas de Armazenamento"
padrão = "Política de Armazenamento de Bronze"
}
variável "vcd_edge_local_subnet" {
descrição = "Sub-rede da Rede Organizacional"
}
variável "vcd_edge_external_ip" {
descrição = "IP público externo"
}
variável "vcd_edge_local_ip_nginx" {}
variável "vcd_edge_local_ip_bitrix" {}
variável "vcd_edge_local_ip_nextcloud" {}
variável "vcd_edge_external_network" {}
Valores das variáveis que obtemos do provedor.
vcd_org_user — nome de usuário com direitos de Administrador da Organização,
vcd_org_password — senha do usuário,
vcd_org — nome da organização,
vcd_org_vdc — nome do data center virtual,
vcd_org_url — URL da API,
vcd_org_edge_name — nome do roteador virtual,
vcd_org_catalog — nome do catálogo de modelos de máquinas virtuais,
vcd_edge_external_ip — endereço IP público,
vcd_edge_external_network — nome da rede externa,
vcd_org_hdd_sp — nome da política de armazenamento HDD,
vcd_org_ssd_sp — nome da política de armazenamento SSD.
E introduzimos nossas próprias variáveis:
vcd_edge_local_ip_nginx — endereço IP da máquina virtual com NGINX,
vcd_edge_local_ip_bitrix — endereço IP da máquina virtual com 1C: Bitrix,
vcd_edge_local_ip_nextcloud — endereço IP da máquina virtual com Nextcloud.
No segundo arquivo, criamos e especificamos variáveis para o módulo VMware vCloud Director no arquivo vcd.tfvars: Lembrando que, em nosso exemplo, usamos , se você estiver trabalhando com outro provedor, verifique os valores com ele.
Conteúdo do arquivo 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 = "Política de Armazenamento de Ouro"
vcd_org_hdd_sp = "Política de Armazenamento de Bronze"
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"
Configuração de rede, network.tf.
As variáveis de ambiente estão definidas, agora vamos configurar o esquema de conexão das máquinas virtuais — atribuindo um endereço IP privado a cada máquina virtual e, com o Destination NAT, ‘abrindo’ portas para a rede externa. Para restringir o acesso às portas de gerenciamento, vamos permitir acesso apenas ao nosso endereço IP.
Esquema de rede para a plataforma Terraform que está sendo criada
Criamos uma rede organizacional virtual chamada net_lan01, com um gateway padrão: 192.168.110.254, e um espaço de endereços: 192.168.110.0/24.
Descrevemos a rede virtual.
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"
}
}
Vamos criar regras para o firewall, permitindo que as máquinas virtuais acessem a Internet. Dentro deste bloco, todos os recursos virtuais na nuvem terão acesso à Internet:
Descrevemos as regras para acesso das VMs à internet.
resource "vcd_nsxv_firewall_rule" "fw_internet_access" {
edge_gateway = var.vcdorgedgename
name = "Acesso à Internet"
source {
gateway_interfaces = ["internal"]
}
destination {
gateway_interfaces = ["external"]
}
service {
protocol = "any"
}
depends_on = [vcdnetworkrouted.net]
}
Estabelecendo a dependência, que após o processamento do bloco vcdnetworkrouted.net, começamos a configuração do bloco vcdnsxvfirewallrule, usando dependson. Usamos essa opção, pois algumas dependências podem ser reconhecidas implicitamente na configuração.
Em seguida, criaremos regras que permitem o acesso às portas da rede externa e especificamos nosso endereço IP para conexão SSH aos servidores. Qualquer usuário da Internet terá acesso às portas 80 e 443 do servidor web, e o usuário com o IP 90.1.15.1 terá acesso às portas SSH dos servidores virtuais.
Permitimos acesso às portas da rede externa.
resource "vcd_nsxv_firewall_rule" "fwnatports" {
edge_gateway = var.vcd_org_edge_name
name = "Acesso HTTPs"
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 = "Acesso Admin"
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]
}
Criamos regras Source NAT para acesso à Internet pela rede local em nuvem:
Descrevemos as regras Source NAT.
resource "vcd_nsxv_snat" "snat_local" {
edge_gateway = var.vcd_org_edge_name
network_type = "ext"
network_name = var.vcdedgeexternalnetwork
original_address = var.vcd_edge_local_subnet
translated_address = var.vcd_edge_external_ip
depends_on = [vcd_network_routed.net]
}
E, para finalizar a configuração do bloco de rede, adicionamos regras Destination NAT para acesso aos serviços a partir da rede externa:
Adicionamos regras Destination NAT.
resource "vcd_nsxv_dnat" "dnat_tcp_nginx_https" {
edge_gateway = var.vcd_org_edge_name
network_name = var.vcd_edge_external_network
network_type = "ext"
description = "NGINX HTTPs"
endereço_original = var.vcd_edge_external_ip
porta_original = 443
endereço_traduzido = var.vcd_edge_local_ip_nginx
porta_traduzida = 443
protocolo = "tcp"
depends_on = [vcd_network_routed.net]
}
recurso "vcd_nsxv_dnat" "dnat_tcp_nginx_http" {
edge_gateway = var.vcd_org_edge_name
network_name = var.vcd_edge_external_network
network_type = "ext"
descrição = "NGINX HTTP"
endereço_original = var.vcd_edge_external_ip
porta_original = 80
endereço_traduzido = var.vcd_edge_local_ip_nginx
porta_traduzida = 80
protocolo = "tcp"
depends_on = [vcd_network_routed.net]
}
Adicionamos uma regra de NAT para traduzir portas para o servidor SSH sob Nginx.
recurso "vcd_nsxv_dnat" "dnat_tcp-nginx_ssh" {
edge_gateway = var.vcd_org_edge_name
network_name = var.vcd_edge_external_network
network_type = "ext"
descrição = "SSH NGINX"
endereço_original = var.vcd_edge_external_ip
porta_original = 58301
endereço_traduzido = var.vcd_edge_local_ip_nginx
porta_traduzida = 22
protocolo = "tcp"
depends_on = [vcd_network_routed.net]
}
Adicionamos uma regra de NAT para traduzir portas para o servidor SSH com 1C-Bitrix.
recurso "vcd_nsxv_dnat" "dnat_tcp_bitrix_ssh" {
edge_gateway = var.vcd_org_edge_name
network_name = var.vcd_edge_external_network
network_type = "ext"
descrição = "SSH Bitrix"
endereço_original = var.vcd_edge_external_ip
porta_original = 58302
endereço_traduzido = var.vcd_edge_local_ip_bitrix
porta_traduzida = 22
protocolo = "tcp"
depends_on = [vcd_network_routed.net]
}
Adicionamos uma regra de NAT para traduzir portas para o servidor SSH com Nextcloud.
recurso "vcd_nsxv_dnat" "dnat_tcp_nextcloud_ssh" {
edge_gateway = var.vcd_org_edge_name
network_name = var.vcd_edge_external_network
network_type = "ext"
descrição = "SSH Nextcloud"
endereço_original = var.vcd_edge_external_ip
porta_original = 58303 endereço_traduzido = var.vcd_edge_local_ip_nextcloud
porta_traduzida = 22
protocolo = "tcp"
depends_on = [vcd_network_routed.net]
}
Configuração do ambiente virtual main.tf
Como planejado no início do artigo, criaremos três máquinas virtuais. Elas serão configuradas com "Guest Customization". As configurações de rede serão definidas de acordo com as configurações indicadas, e a senha do usuário será gerada automaticamente.
Descreveremos o vApp onde estarão as máquinas virtuais e suas configurações.
Configuração das máquinas virtuais
Criaremos um container vApp. Para que possamos conectar imediatamente o vApp e a VM à rede virtual também adicionamos o parâmetro depends_on:
Criamos o container
recurso "vcd_vapp" "vapp" {
nome = "web"
ligar = "true" depends_on = [vcd_network_routed.net]
}
Criaremos uma máquina virtual com a descrição
recurso "vcd_vapp_vm" "nginx" {
nome_vapp = vcd_vapp.vapp.name
nome = "nginx"
nome_catalogo = var.vcd_org_catalog
nome_modelo = var.vcd_template_os_centos7
perfil_de_storage = var.vcd_org_ssd_sp
memória = 8192
cpus = 1
cores_cpu = 1
rede {
tipo = "org"
nome = vcd_network_routed.net.name
é_primário = true
tipo_adaptador = "VMXNET3"
modo_alocação_ip = "MANUAL"
ip = var.vcd_edge_local_ip_nginx
}
substitua_template_disco {
tipo_bus = "paravirtual"
tamanho_em_mb = "32768"
número_bus = 0
número_unidade = 0
perfil_de_storage = var.vcd_org_ssd_sp
}
}
Principais parâmetros na descrição da VM:
nome — nome da máquina virtual,
nomevapp — nome do vApp em que adicionar a nova VM,
nome_catalogo / nome_modelo — nome do catálogo e nome do modelo da máquina virtual,
perfil_de_storage — política de armazenamento padrão.
Parâmetros do bloco de rede:
tipo — tipo da rede conectada,
nome — qual rede virtual conectar à VM,
é_principal — adaptador de rede principal,
modo_alocação_ip — modo de alocação de endereço MANUAL / DHCP / POOL,
ip — endereço IP para a máquina virtual, que indicaremos manualmente.
Bloco substituir_template_disco:
tamanhoemmb — tamanho do disco de inicialização para a máquina virtual
perfil_de_storage — política de armazenamento para o disco
Criaremos uma segunda VM com a descrição do armazenamento de arquivos Nextcloud
recurso "vcd_vapp_vm" "nextcloud" {
nome_vapp = vcd_vapp.vapp.name
nome = "nextcloud"
nome_catalogo = var.vcd_org_catalog
nome_modelo = var.vcd_template_os_centos7
perfil_de_storage = var.vcd_org_ssd_sp
memória = 8192
cpus = 1
cores_cpu = 1
rede {
tipo = "org"
nome = vcd_network_routed.net.name
é_primário = true
tipo_adaptador = "VMXNET3"
modo_alocação_ip = "MANUAL"
ip = var.vcd_edge_local_ip_nextcloud
}
substitua_template_disco {
tipo_bus = "paravirtual"
tamanho_em_mb = "32768"
número_bus = 0
número_unidade = 0
perfil_de_storage = 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 ]
}
Na seção vcdvminternal_disk descreveremos um novo disco virtual que será conectado à máquina virtual.
Explicações sobre o bloco vcdvminternaldisk:
bustype — tipo de controlador de disco
sizeinmb — tamanho do disco
busnumber / unitnumber — posição de conexão no adaptador
perfil_de_storage — política de armazenamento para o disco
Descreveremos a última VM no Bitrix
resource "vcd_vapp_vm" "bitrix" {
nome_vapp = vcd_vapp.vapp.name
name = "bitrix"
nome_catalogo = var.vcd_org_catalog
nome_modelo = var.vcd_template_os_centos7
perfil_de_storage = var.vcd_org_ssd_sp
memória = 8192
cpus = 1
cores_cpu = 1
rede {
tipo = "org"
nome = vcd_network_routed.net.name
é_primário = true
tipo_adaptador = "VMXNET3"
modo_alocação_ip = "MANUAL"
ip = var.vcd_edge_local_ip_bitrix
}
substitua_template_disco {
tipo_bus = "paravirtual"
size_in_mb = "81920"
número_bus = 0
número_unidade = 0
perfil_de_storage = var.vcd_org_ssd_sp
}
}
Atualização do sistema operacional e instalação de scripts adicionais
A rede está configurada, as máquinas virtuais estão descritas. Antes de importar nossa infraestrutura, podemos realizar um provissionamento inicial usando blocos de provisioners sem utilizar o Ansible.
Vamos ver como atualizar o sistema operacional e executar o script de instalação do CMS Bitrix usando o bloco provisioner.
Primeiro, faremos a instalação dos pacotes de atualização do 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" ]
}
}
}
Definição dos componentes:
provisioner «remote-exec» — conectamos o bloco de "provissionamento" remoto
No bloco de conexão, descrevemos o tipo e os parâmetros de conexão:
type — protocolo, neste caso SSH;
user — nome do usuário;
password — senha do usuário. Neste caso, referenciamos o parâmetro vcdvappvm.nginx.customization[0].admin_password, que armazena a senha gerada para o usuário do sistema.
host — endereço IP externo para conexão;
port — porta de conexão que foi definida nas configurações de DNAT;
inline — listamos a sequência de comandos que serão inseridos. Os comandos serão executados na ordem indicada nesta seção.
Como exemplo, também executaremos o script de instalação 1C-Bitrix. A saída do resultado da execução do script estará disponível durante a execução do plano. Para instalar o script, primeiro descreveremos o bloco:
Descreveremos a instalação do 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 logo em seguida, descreveremos a atualização do Bitrix.
Exemplo de provissionamento do 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! O script pode não funcionar se o SELinux não for desativado previamente! Se você precisar de um artigo detalhado sobre a instalação e configuração do CMS 1С-Битрикс usando o bitrix-env.sh, você pode .
3. Inicialização da infraestrutura
Inicialização de módulos e plugins
Para nosso trabalho, utilizamos um simples "kit de gentlemans": um laptop com Windows 10 e o distribuidor do site oficial . Vamos descompactá-lo e inicializá-lo usando o comando: terraform.exe init
Após descrever a infraestrutura computacional e de rede, iniciamos o planejamento para verificar nossa configuração, onde podemos ver o que será criado e como está relacionado.
Executamos o comando
- terraform plan -var-file=vcd.tfvars.Recebemos o resultado
- Plano: 16 para adicionar, 0 para alterar, 0 para destruir.Ou seja, com este plano, 16 recursos serão criados.Iniciamos o plano com o comando
- terraform.exe apply -var-file=vcd.tfvars.
As máquinas virtuais serão criadas e, em seguida, os pacotes que listamos na seção provisionador serão executados — o sistema operacional será atualizado e o CMS Bitrix será instalado.
Obtendo dados de conexão
Após a execução do plano, queremos obter os dados de conexão com os servidores em formato de texto, para isso iremos formatar a seção de saída da seguinte forma:
output "nginxpassword" {
value = vcdvappvm.nginx.customization[0].adminpassword
}
E a saída seguinte nos informa a senha da máquina virtual criada:
Outputs: nginx_password = F#4u8!!N
Assim, obtemos acesso às máquinas virtuais com o sistema operacional atualizado e pacotes pré-instalados para nosso trabalho posterior. Tudo pronto!
Mas e se você já tiver uma infraestrutura existente?
3.1. Trabalho do Terraform com uma infraestrutura existente
É simples, você pode importar as máquinas virtuais atuais e seus contêineres vApp usando o comando de importação.
Vamos descrever o recurso vAPP e a máquina virtual.
resource "vcd_vapp" "Monitoring" {
name = "Monitoring"
org = "mClouds"
vdc = "mClouds"
}
resource "vcd_vapp_vm" "Zabbix" {
name = "Zabbix"
org = "mClouds"
vdc = "mClouds"
vapp = "Monitoring"
}
O próximo passo é importar as propriedades dos recursos vApp no formato vcdvapp.<vApp> <org>.<orgvdc>.<vApp>, onde:
vApp — nome do vApp;
org — nome da organização;
org_vdc — nome do data center virtual.
Importando propriedades do recurso vAPP
Iremos importar as propriedades dos recursos VM no formato: vcdvappvm.<VM> <org>.<orgvdc>.<vApp>.<VM>, onde:
VM — nome da VM;
vApp — nome do vApp;
org — nome da organização;
orgvdc — nome do data center virtual.
A importação foi bem-sucedida
C:UsersMikhailDesktopterraform>terraform import vcd_vapp_vm.Zabbix mClouds.mClouds.Monitoring.Zabbix
vcd_vapp_vm.Zabbix: Importando do ID "mClouds.mClouds.Monitoring.Zabbix"...
vcd_vapp_vm.Zabbix: Importação preparada!
vcd_vapp_vm preparado para importação
vcd_vapp_vm.Zabbix: Atualizando estado... [id=urn:vcloud:vm:778f4a89-1c8d-45b9-9d94-0472a71c4d1f]
Importação bem-sucedida!
Os recursos que foram importados estão mostrados acima. Esses recursos agora estão em
seu estado Terraform e serão gerenciados pelo Terraform a partir de agora.
Agora podemos olhar o novo recurso importado:
Recurso importado
> 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 = "alocado"
metadata = {}
name = "Monitoramento"
org = "mClouds"
status = 4
status_text = "LIGADO"
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 = [
{
número_bus = 0
tipo_bus = "paravirtual"
disk_id = "2000"
iops = 0
size_in_mb = 122880
storage_profile = "Política de Armazenamento Ouro"
thin_provisioned = true
número_unidade = 0
},
]
memory = 8192
metadata = {}
name = "Zabbix"
org = "mClouds"
os_type = "centos8_64Guest"
storage_profile = "Política de Armazenamento Ouro"
vapp_name = "Monitoramento"
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
}
rede {
adapter_type = "VMXNET3"
ip_allocation_mode = "DHCP"
is_primary = true
mac = "00:50:56:07:01:b1"
name = "MCLOUDS-LAN01"
type = "org"
}
}
Agora está tudo pronto — terminamos com o último detalhe (importação para a infraestrutura existente) e cobrimos todos os principais pontos ao trabalhar com Terraform.
A ferramenta se mostrou muito conveniente, permitindo descrever sua infraestrutura como código, desde máquinas virtuais de um único provedor de nuvem até a descrição de recursos de componentes de rede.
Essa independência do ambiente permite trabalhar com recursos locais e em nuvem, terminando com a gestão da plataforma. E na ausência de uma plataforma suportada e com o desejo de adicionar nova, é possível escrever seu próprio provedor e usá-lo.
Fonte: habr.com
