Terraform no Google Cloud
Neste Alura+ vamos aprender como podemos criar uma máquina virtual no Google Cloud Platform usando o Terraform e ver as diferenças entre o Google Cloud Platform e a AWS. * [Site do Terraform]( * [Download do Terraform]( * [Console do Google Cloud]( * [Documentação do Google Cloud no Terraform]( # Transcrição Na formação de Infraestrutura como Código, utilizamos sempre a AWS como provedora. Mas como fazemos para usar o Terraform com outros provedores, como o Google Cloud, por exemplo? Para tirar essa dúvida, vamos subir uma máquina no Google Cloud e verificar o quanto esse processo difere de uma máquina na AWS. Vamos lá? De início, vamos entrar no site do Terraform e clicar em "Tutoriais", no painel superior, para carregar os tutoriais iniciais e podermos mexer com cada plataforma. No caso, sempre usamos AWS; desta vez, acessaremos os **tutoriais do Google Cloud**. Nessa nova página, veremos todos os tutoriais disponíveis, como "O que é Infraestrutura como Código com o Terraform?" e "Instalando Terrafom". Caso você ainda não conheça o conceito de infraestrutura como código ou ainda não tenha o Terraform instalado, recomendamos dar uma olhada nesses dois primeiros tutoriais e fazer a nossa formação de Infraestrutura com Código também. Nesse vídeo, vamos direto para o tutorial "*Build Infrastructure*" (em português, "**Montando a Infraestrutura**") para começarmos a construir nossa infraestrutura com o Google Cloud. Primeiramente, há uma breve explicação sobre o que é o Google Cloud e temos um aviso inicial de que usaremos o nível gratuito (*free tier*) do Google Cloud Platform (GCP) para o provisionamento dos componentes desse tutorial. Caso comecemos a provisionar outros recursos, podemos mudar para a versão paga. No nosso caso, a máquina virtual que pretendemos provisionar faz parte do *free tier*. A seguir, temos a seção de pré-requisitos. É preciso ter uma **conta no Google Cloud Platform**. Caso você ainda não tenha, é possível criá-la no site do GCP — é de graça. Para conhecer mais sobre os serviços inclusos no *free tier*, podemos acessar a página de informações do Programa Gratuito do Google Cloud. Outro pré-requisito é ter, **no mínimo, a versão 0.15.3 do Terraform** instalada no seu computador. Se você estiver com o Terraform atualizado, já tem uma versão compatível, provavelmente 1.0 ou posterior. Atendidos os pré-requisitos, vamos checar o que precisamos para realmente começar a criar, na seção "*Set up GCP*". O primeiro item é **criar um projeto no GCP**. Vamos clicar no link disponibilizado no tutorial, que nos direcionará ao console do GCP para criar um projeto. Daremos o nome "Alura" para nosso projeto. Logo abaixo do campo de nome, será gerado um ID. No meu caso, é "alura-348223". O seu será diferente, pois os identificadores são únicos, nunca se repetem. À direita desse ID, temos a opção de editá-lo, se for de nosso interesse. Eu vou manter "alura-348223". Não vamos modificar os campos "Billing account" nem "Location", relativos respectivamente à cobrança (caso sejam criados recursos fora do *free tier*) e à organização. Podemos clicar no botão "Create" e, após alguns segundos, veremos nosso projeto criado, com todas as partes prontas. Voltando ao tutorial do site do Terraform, o segundo item é **ligar o *compute engine* do nosso projeto**. Novamente, vamos clicar no link disponibilizado no tutorial, que nos direcionará para a tela do *Compute Engine API* no console do GCP. Outra forma de chegar nessa página é acessando o menu do GCP, no canto esquerdo superior, selecionando a opção "Compute Engine". Nessa tela, clicaremos no botão "Enable" para habilitar e conseguirmos criar elementos relacionados às máquinas virtuais. Esse processo pode demorar alguns minutos, dependerá da carga sobre o Google no momento. De volta ao tutorial, o terceiro item em "Set up GCP" é **criar uma chave de serviço para nossa conta**. Clicaremos no link disponibilizado no tutorial, que nos direcionará para a página *Service Accounts*, dentro da área "IAM & Admin" do console do GCP. Outra maneira de chegar a esta tela é pelo menu do GCP, acessando "IAM & Admin > Service Accounts". Em seguida, vamos selecionar o projeto "Alura". Nessa nova página, constataremos que já temos uma conta de serviços. Para manter a organização e não nos confundirmos com as chaves e credenciais (partes de segurança muito importantes), vamos **criar outra conta de serviços**. No painel superior da tela, pressionaremos "Create Service Account". O campo relativo ao nome é opcional. Já o ID é obrigatório, como indicado pela presença do asterisco. Nosso ID será "terraform". Logo abaixo desse campo, será automaticamente criado um e-mail para essa conta de serviços. No momento, não precisamos nos preocupar com ele. A seguir, clicaremos no botão "Create and Continue". Agora, precisamos **selecionar um cargo (*role*)**. No tutorial do Terraform, no item 4 referente à criação da chave de serviço, é especificado que nesse campo devemos escolher "Project > Editor" e clicar em "Continue". Dessa forma, essa conta terá permissão para editar qualquer parte do projeto. Pressionaremos o botão "Done" para concluir a criação da conta do Terraform. Na sequência, vamos **criar uma chave para essa conta**. Seguindo o tutorial, vamos selecionar a conta de serviços e acessar a aba "Keys" (chaves) no painel superior. Em seguida, clicando em "Add Key", vamos escolher a opção "Create new key", definir o "Key Type" como JSON e clicar em "Create". O *download* da chave será feito automaticamente em nosso computador e veremos uma mensagem contendo o nome dela. Voltando ao tutorial, antes da seção "Write configuration", temos outro aviso (*warning*). Ele nos informa que ***esse arquivo da chave dá acesso total ao nosso projeto no Google Cloud Platform, então é importante o tratarmos como qualquer outra credencial secreta***, como a senha que usamos para entrar no console do GCP. Ou seja, não é uma boa prática salvar essa chave de acesso em um repositório, por exemplo, pois qualquer pessoa terá acesso ao projeto, se essa chave "vazar". Porém, caso isso aconteça, podemos acessar o menu "IAM & Admin > Service Accounts", entrar na nossa conta e apagar a chave. Depois, criamos outra. Temos a opção de criar várias chaves, só é importante mantermos o controle e a organização delas. Podemos, então, **começar a escrever as configurações do nosso projeto**. Em nosso computador, vamos criar uma pasta chamada "GCP" (abreviação de Google Cloud Platform) e abri-la no Visual Studio Code. Dentro dela, criaremos um arquivo chamado main.tf — um arquivo Terraform. Tudo que formos escrever ficará dentro dele. No tutorial, o início da seção "Write Configuration" explica como criar essa pasta e o arquivo main.tf por comandos no terminal. No caso, optamos pela criação manual. Em seguida, temos um bloco de código de exemplo: terraform { required_providers { google = { source = "hashicorp/google" version = "3.5.0" } } } provider "google" { credentials = file(".json") project = "" region = "us-central1" zone = "us-central1-c" } resource "google_compute_network" "vpc_network" { name = "terraform-network" } Vamos analisar esse trecho, composto por três blocos. De início, temos um bloco terraform referente às configurações que usaremos no projeto do Terraform. Da linha 2 a 6, constam dados do provedor: trata-se do provedor do Google, já com informações da fonte (source) e da versão (version). Da linha 10 a 16, temos o segundo bloco, com configurações desse provedor. A linha 11 contém as credenciais que serão carregadas de um arquivo .json. Na linha 13, precisamos informar o ID do projeto. Nas linhas seguintes, teremos dados relativos à região e à zona — assim como a AWS, o Google trabalha com regiões. Nesse exemplo, temos region = "us-central1" e zone = "us-central1-c", ou seja, estaremos usando o provedor do Google na região central dos Estados Unidos, na zona de disponibilidade C. Das linhas 18 a 20, temos o último bloco, com a opção de criação de um recurso, uma VPC. No momento, não queremos uma VPC, apenas uma máquina virtual. Mais adiante, consultaremos a documentação com esse objetivo. Portanto, vamos copiar apenas os dois primeiros blocos (da linha 1 até a 16) e colá-lo no arquivo main.tf. Feito isso, ainda precisamos configurar dois itens nesse arquivo: **indicar a chave de acesso na linha 11 e definir o ID do projeto na linha 13**. Vamos incluir a chave de acesso no projeto, movendo o arquivo .json para a pasta GCP. Em seguida, daremos uma olhada na estrutura e no conteúdo dessa chave. Primeiramente, ela contém um tipo, que é uma conta de serviço. Depois, temos o ID do projeto e o ID de uma chave privada. Em seguida, consta a chave privada em si, que é bastante longa. Vemos, então, o e-mail do cliente (no caso, da conta de serviço), o ID desse cliente e um link de autorização seguido de um link do *token* para poder acessar as informações. Por fim, há dois certificados, um do provedor e outro do cliente. Voltando ao arquivo main.tf, é necessário alterar a origem das credenciais, na linha 11. Como o nome do arquivo .json é muito extenso, no painel à esquerda vamos clicar com o botão direito do *mouse* sobre ele e renoméa-lo para chave.json. Desse modo, podemos modificar a linha 11 para credentials = file("chave.json"), indicando que as credenciais vêm desse arquivo. Quanto ao ID do projeto (na linha 13), podemos obter essa informação no console do Google Cloud Platform ou no arquivo chave.json, em project_id. No meu caso, a linha 13 ficará project = "alura-348223", lembrando que cada usuário terá um ID diferente. Assim, temos nosso Google Cloud configurado para uso. O próximo passo será **criar a máquina virtual**. No navegador, vamos voltar à página inicial do site do Terraform. Desta vez, no painel superior, acessaremos "Registry" — o registro Terraform. Descendo um pouco a página, temos as opções de *providers*. Vamos clicar em Google Cloud Platform. A princípio, veremos o *overview* do que é o Google Cloud. No topo da página, à direita, acessaremos a **documentação**. Na lateral esquerda, há uma lista extensa de recursos à nossa disposição. Anteriormente no Google Cloud, acionamos o *Compute Engine API*, portanto vamos expandir o tópico "*Compute Engine*" dessa lista. Dentro dele, temos uma série de recursos — estamos buscando por máquinas virtuais, que geralmente têm o nome VM (*virtual machine*) ou *Instance* (instância). No caso, encontraremos o subtópico "google_compute_instance". Clicando em "**google_compute_instance**", descobriremos que se trata de um recurso que gerencia uma instância de uma máquina virtual utilizando o Google Cloud Engine (GCE). Para mais informações, podemos acessar a documentação oficial da API. Aparentemente, este recurso faz exatamente o que precisamos. Mais abaixo nessa página, temos um exemplo de uso. Vamos deixar de lado as primeiras cinco linhas referentes à *service account* e copiar o resto. Colaremos esse trecho ao final do nosso arquivo main.tf: # código anterior omitido resource "google_compute_instance" "default" { name = "test" machine_type = "e2-medium" zone = "us-central1-a" tags = ["foo", "bar"] boot_disk { initialize_params { image = "debian-cloud/debian-9" } } // Local SSD disk scratch_disk { interface = "SCSI" } network_interface { network = "default" access_config { // Ephemeral public IP } } metadata = { foo = "bar" } metadata_startup_script = "echo hi > /test.txt" service_account { # Google recommends custom service accounts that have cloud-platform scope and permissions granted via IAM Roles. email = google_service_account.default.email scopes = ["cloud-platform"] } } Em seguida, vamos remover as partes que não são necessárias para nós. Na linha 18, temos o recurso "google_compute_instance". Vamos substituir o nome lógico "default" por "PrimeiraVM". Na linha seguinte, podemos alterar o nome que aparecerá no console do Google: em vez de "test", usaremos "PrimeiraVM" também. Em machine_type (tipo de máquina), precisamos tomar um pouco de cuidado. A máquina atual, "e2-medium", não é suportada pelo *free tier*! Então, vamos mudar para "e2-micro", que se enquadra no nível gratuito. Quanto à zona, vamos usar a mesma que especificamos anteriormente: "us-central1-c": # código anterior omitido resource "google_compute_instance" "PrimeiraVM" { name = "PrimeiraVM" machine_type = "e2-micro" zone = "us-central1-c" # código posterior omitido As tags não são necessárias, podemos removê-las (linha 23). Por outro lado, precisaremos do disco de *boot* (boot_disk), porque é o disco principal do nosso sistema. Na linha 24, temos os parâmetros iniciais: segundo o exemplo, usaremos uma imagem do Debian, na versão 9. Vamos manter desta forma. Em seguida, é oferecido um SSD local: o scratch_disk, um disco para escrever e ler itens temporários. Não precisamos disso e ele não é suportado no *free tier*, então vamos removê-lo (linhas 29 a 32). Agora, na linha 29, temos a interface de rede, necessária para a comunicação. Vamos manter network = "default" e não modificaremos o access_config, para que ele gere um IP público para nossa máquina. Os metadados (linhas 36 a 38) são desnecessários, vamos removê-los. Em seguida, temos o metadata_startup_script. Se quisermos rodar algum comando no momento de criação da nossa máquina, podemos utilizar essa *tag*. Vamos mantê-la e mudar seu valor para "echo oi > /teste.txt". Dessa forma, será escrito "oi" no arquivo teste.txt, no *root*. Por fim, a partir da linha 38, temos um *service account*. Como já configuramos anteriormente o *provider*, essa parte também não é necessária, vamos apagar da linha 38 até a 42. Então, **a segunda parte do arquivo ficará assim**: # código anterior omitido resource "google_compute_instance" "PrimeiraVM" { name = "PrimeiraVM" machine_type = "e2-micro" zone = "us-central1-c" boot_disk { initialize_params { image = "debian-cloud/debian-9" } } network_interface { network = "default" access_config { // Ephemeral public IP } } metadata_startup_script = "echo oi > /teste.txt" } Pressionando "Ctrl + S", salvaremos o arquivo. Já podemos **executar essas configurações para verificar se funcionam**. Na barra superior do VS Code, vamos em "Terminal > Novo Terminal". No terminal, vamos checar se estamos na pasta GCP. Uma vez dentro da pasta, executaremos o comando ls para verificar se os arquivos estão conforme o esperado: temos chave.json e main.tf. Tudo em ordem, vamos rodar um clear para limpar o terminal. Então, vamos **executar o comando terraform init** para iniciar todas as configurações do Terrafom, fazer o *download* da infraestrutura do provedor e deixar tudo pronto para a execução. Terminado esse processo, vamos **rodar o terraform apply**. Assim, a ideia é pegar o nosso plano e criar uma *compute instance* chamada PrimeiraVM. No console, podemos verificar todas as configurações dessa instância e, ao final, temos o plano total "Plan: 1 to add, 0 to change, 0 to destroy" (1 para criar, 0 para mudar e 0 para destruir). Para confirmar, digitaremos "yes". Durante essa operação, teremos um erro alegando que o nome "PrimeiraVM" é inválido, pois não podemos usar letras maiúsculas, apenas caracteres no padrão [a-z0-9]. Logo, na linha 19 do arquivo main.tf, vamos alterar para name = "primeiravm" e salvar. Em seguida, executaremos o terraform apply novamente, digitaremos "yes" para confirmar e esperaremos enquanto esse processo é executado. No meu caso, a operação foi rápida, apenas 11 segundos. Mas esse tempo pode variar de acordo com a conexão da internet ou da carga sobre os servidores do Google e assim por diante. Para verificar se a máquina foi devidamente criada, vamos voltar ao console do Google Cloud Platform, no navegador. No menu, vamos em "Compute Engine". Nesta página, há uma tabela com as instâncias de máquina virtual e veremos a "primeiravm". O IP dela está na coluna "External IP". Para acessá-la via SSH, selecionaremos o *checkbox* à esquerda e clicaremos no botão "SSH". Dessa forma, a chave SSH será colocada dentro da nossa máquina virtual, pois não fizemos isso antes. Essa é uma das vantagem do Google sobre a AWS: não precisamos colocar as chaves logo que criamos a máquina, ele faz esse procedimento para nós depois. Após alguns segundos, estaremos na nossa máquina. Vamos executar o comando ls / para ver os arquivos que temos dentro da máquina virtual. Um deles é o teste.txt, vamos abri-lo com cat /teste.text. Veremos o texto "oi" que configuramos anteriormente, ou seja, a instância foi criada e o arquivo .txt foi inserido no *root* da máquina virtual. Pronto, criamos a configuramos uma máquina virtual com o Google Cloud! **E se não quisermos mais essa infraestrutura?** Podemos encerrá-la por meio do comando terraform destroy, que vai **destruir a infraestrutura**. Assim, o plano não terá nada para criar ou modificar e um recurso para destruir. Vamos digitar "yes" para confirmar a ação e a máquina será apagada. No meu caso, esse processo demorou 37 segundos, mas esse tempo pode variar. Dessa forma, a infraestrutura foi destruída. O projeto não foi apagado, apenas removemos a infraestrutura, que podia gerar custos. Agora que vimos tudo isso, vamos elencar as **diferenças entre a máquina virtual que criamos no Google Cloud e uma máquina virtual que geralmente criamos na AWS**. Primeiro, no arquivo main.tf, no bloco terrafom que vai da linha 1 a 8, temos que trocar o nome do provedor, bem como o source. Além disso, o método de utilizar credenciais e fazer *login* no Google e na AWS são diferentes. Na AWS, fazemos o *login* pela linha de comando com aws configure. No Google, usamos credenciais via arquivo. O recurso criado também muda de nome entre esses dois provedores. **Na AWS, temos o EC2 Instance e, no Google, o Google Compute Instance**. São nomes e recursos diferentes e também têm configurações distintas. Por exemplo, na AWS especificamos zonas por VPC, não por máquinas. Ambos, porém, precisam de um nome e de um tipo de maáquina (machine_type). Quanto ao boot_disk, no Google definimos pela imagem. No caso, escolhemos o Debian, versão 9. Na AWS, usamos as AMIs, que são parecidas, porém têm nome diferente. Precisamos saber a AMI correta para cada região. Em questão de rede, na AWS não precisamos configurar uma interface de rede. Ele já vem com uma interface e um IP público por padrão. No Google Cloud, temos que especificar esses elementos. Ademais, temos o metadata_startup_script que determina o que será feito inicialmente, em que inserimos o código entre aspas. Na AWS, esse processo é mais complicado, temos que colocar o end_of_file ou end_of_tape, algo nesse sentido para identificar onde começa e onde termina. De forma geral, **esses provedores são bem próximos em termos de criação**. O Google também fornece uma VPC padrão, que é um jeito que de acessarmos essas máquinas. Por fim, vamos revisar tudo que fizemos nesse vídeo. Criamos um projeto e uma chave de acesso para acessá-lo. Depois, configuramos uma máquina virtual do tipo e2-micro (suportada no *free tier*) e especificamos a zona onde ela ficaria — no *datacenter* central dos Estados Unidos, na zona de disponibilidade C. Determinamos o sistema utilizado na máquina, uma interface de rede e um *script* para rodar na criação da instância. Espero que você tenham gostado. Até o próximo Alura+!
