HCP com Git (VSC)

Vamos utilizar o conceito de GitOps e pegar o código direto do Git ao invés de fazer isso via CLI.

Execuções são acionada automaticamente com base em alterações em seus repositórios Git. Com a CLI podemos trabalhar localmente de forma mais fácil enquanto com o VSC podemos trabalhar de forma colaborativa e compartilhada.

Vamos subir o código para o gitlab. Crie um projeto em branco no Gitlab ou Github e vamos subir o código. Vou fazer no Gitlab

# Como baixei o código de exemplo da documentação vou remover a pasta .git
rm -rf .git

# Inicializando novamente o repositório e setando a origem
git init --initial-branch=main
Initialized empty Git repository in /Users/davidprata/Desktop/tfcloud/learn-terraform/.git/

git remote add origin [email protected]:davidpuziol/learn-terraform.git

# Adicionando tudo e subindo
git add .  
git commit -m "Initial commit"
git push origin main  

Diferente da CLI, não precisamos definir qual a nossa organização e workspace no bloco do terraform pois vamos importar direto de lá, então podemos remover.

# terraform.tf já editado comentando o que não precisamos.
cat terraform.tf
# Copyright (c) HashiCorp, Inc.
# SPDX-License-Identifier: MPL-2.0

terraform {

  # cloud {
  #   organization = "davidpuziol"

  #   workspaces {
  #     name = "learn-terraform"
  #   }
  # }

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.31.0"
    }
  }

  required_version = "~> 1.2"
}

git add terraform.tf
git cm "comment HCP defintions on terraform.tf"
git push origin main  

Agora vamos conectar esse repositório no workspace.

alt text

aqui já irá aparecer os Repositórios Git Configurados nesta conta. Se não tiver configurado vá em Connect to a differente VCS e configure pois é muito simples.

Escolhendo o Gitlab vou apontar qual o repositório.

alt text

E depois selecione o repositório, ele já te dará uma lista de tudo que encontrou nesta conta para ficar mais fácil.

Logo que escolhemos o repositório, podemos definir se vamos trabalhar com branch, com tags, definir qual a branch irá disparar os gatilhos, etc.

Quando fazemos um pull request (merge request no gitlab) podemos definir que rodemos os terraform plan serão mostrados também no próprio repositório via comentário para ajudar na aceitação desse merge. Se aceitarmos o merge request então o apply será feito.

alt text

Obviamente não é interessante que tenhamos variáveis que são definidas no código aqui dentro além daquelas que usamos nos providers. Se o GitOps reflatirá que o que temos no git é a fonte da verdade então não faz sentido mudarmos as variáveis como fizemos com o instance_type, vamos deletar.

Só dele estar mapeando o repositório irá confrontar de primeira o que temos no repositório com o que temos no state file, mas não irá aplicar pois não permitimos isso nas configurações. É bom que essas aceitações sejam manualmente aceitas em produção, mas pode ser tudo automatizado para aceitar, é só querer.

alt text

Vamos aceitar e depois mudar o código e fazer um merge request. Quero que observe uma coisa, Veja que ele está com um plan definido para uma t2.medium, pois quando ele gerou o plan a variável instance_type estava setada no workspace, removermos depois e ele já tinha um plan guardado.

alt text

Agora vamos fazer umas mudanças no código abrindo uma nova branch, fazendo alterações e pedindo um merge na main que irá disparar o nosso plan. Vamos colocar o instance_type para t3.nano.

git checkout -b change/type  

cat variables.tf  
# Copyright (c) HashiCorp, Inc.
# SPDX-License-Identifier: MPL-2.0

variable "region" {
  description = "AWS region"
  default     = "us-west-1"
}

variable "instance_type" {
  description = "Type of EC2 instance to provision"
  default     = "t3.nano" ## Alterado
}

variable "instance_name" {
  description = "EC2 instance name"
  default     = "Provisioned by Terraform"
}
git add.  
git cm "change instance type"  
git push origin change/type