HCP con Git (VCS)
Vamos a utilizar el concepto de GitOps y tomar el código directo del Git en lugar de hacer eso vía CLI.
Ejecuciones son activadas automáticamente con base en alteraciones en sus repositorios Git. Con la CLI podemos trabajar localmente de forma más fácil mientras con el VCS podemos trabajar de forma colaborativa y compartida.
Vamos a subir el código para gitlab. Crea un proyecto en blanco en Gitlab o Github y vamos a subir el código. Voy a hacer en Gitlab
# Como descargué el código de ejemplo de la documentación voy a remover la carpeta .git
rm -rf .git
# Inicializando nuevamente el repositorio y seteando el origen
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 todo y subiendo
git add .
git commit -m "Initial commit"
git push origin main
Diferente de la CLI, no necesitamos definir cuál es nuestra organización y workspace en el bloque del terraform pues vamos a importar directo de allá, entonces podemos remover.
# terraform.tf ya editado comentando lo que no necesitamos.
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
Ahora vamos a conectar ese repositorio en el workspace.


aquí ya aparecerán los Repositorios Git Configurados en esta cuenta. Si no tienes configurado ve en Connect to a different VCS y configura pues es muy simple.
Escogiendo el Gitlab voy a apuntar cuál es el repositorio.

Y después selecciona el repositorio, ya te dará una lista de todo lo que encontró en esta cuenta para que sea más fácil.
Luego que escogemos el repositorio, podemos definir si vamos a trabajar con branch, con tags, definir cuál branch disparará los gatillos, etc.
Cuando hacemos un pull request (merge request en gitlab) podemos definir que corramos los terraform plan serán mostrados también en el propio repositorio vía comentario para ayudar en la aceptación de ese merge. Si aceptamos el merge request entonces el apply será hecho.

Obviamente no es interesante que tengamos variables que son definidas en el código aquí dentro además de aquellas que usamos en los providers. Si GitOps reflejará que lo que tenemos en git es la fuente de verdad entonces no tiene sentido cambiar las variables como hicimos con instance_type, vamos a borrar.
Solo de estar mapeando el repositorio confrontará de primera lo que tenemos en el repositorio con lo que tenemos en el state file, pero no aplicará pues no permitimos eso en las configuraciones. Es bueno que esas aceptaciones sean manualmente aceptadas en producción, pero puede ser todo automatizado para aceptar, es solo querer.

Vamos a aceptar y después cambiar el código y hacer un merge request. Quiero que observes una cosa, Vea que está con un plan definido para una t2.medium, pues cuando generó el plan la variable instance_type estaba seteada en el workspace, removimos después y ya tenía un plan guardado.

Ahora vamos a hacer unos cambios en el código abriendo una nueva branch, haciendo alteraciones y pidiendo un merge en main que disparará nuestro plan. Vamos a colocar el 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
Vamos a crear el merge request para de change/type para main.

Y vea que la pipeline fue disparada.

Haciendo clic en esta pipeline podemos ver..


Y si hacer clic en el link vamos directo para HCP Terraform en el workspace de ese proyecto para conferir el plan y poder aplicar.

No podemos aplicar, pues eso fue solamente un plan de lectura, pero vamos a aceptar ese merge que cambiará el código en la branch main.
Vea que otro pipeline fue disparado.


Y la pestaña Apply Running correrá y tenemos nuestra infra modificada.

Si comentamos el recurso en el repositorio obviamente borrará. Haz la prueba.
Para destruir todo ya hicimos el proceso anteriormente igual que en CLI.