Formas efectivas de administrar su estado de Terraform en GCP - Día # 2
Tags: spanish, devops, googlecloud, terraform
Published: 2020-07-08 17:14:41

Terraform es una de las herramientas de infraestructura como código (IaC) más populares disponibles hoy en día en el mundo de IT. No es solo uno de los proyectos de código abierto más activos, sino que también es vanguardista hasta el punto de que cada vez que AWS lanza un nuevo servicio, Terraform tiene un recurso listo incluso antes de CloudFormation de AWS.

Terraform es un software declarativo de IaC. Eso significa que los administradores declaran qué infraestructura quieren, en lugar de preocuparse por el meollo de escribir scripts para aprovisionarlos. Eso hace que Terraform sea extremadamente simple de aprender y administrar.

Es increíblemente flexible y admite múltiples proveedores en la nube. Es extensible hasta el punto de que cualquier proveedor de la nube puede crear sus complementos de proveedor y lanzarlo a sus usuarios. Luego, los usuarios pueden usar los scripts de HashiCorp Configuration Language (HCL) para crear plantillas de sus implementaciones de infraestructura y automatizar la infraestructura como nunca antes.

<h2>¿Cómo funciona Terraform?</h2>

Como Terraform es una herramienta declarativa de IaC, necesita almacenar y mantener un estado. Eso es necesario para comprender las diferencias entre la configuración esperada y la real. Se podría argumentar que Terraform podría consultar los servicios en la nube para que coincidan con la configuración esperada, pero hay un problema aquí.

- ¿Cómo sabría Terraform que alguien ha eliminado una configuración de la plantilla que había aplicado antes?

- ¿Cómo entendería Terraform si un recurso en la nube depende de otro? Por ejemplo, si se especificó una dependencia explícita de un bucket S3 en una instancia EC2, Terraform necesita saber que no puede eliminar el bucket S3 sin eliminar la instancia EC2.

- Si varias personas están cambiando una configuración, ¿cómo entendería Terraform cuál se aplicó antes y cómo hará un seguimiento de varias versiones? Puede haber situaciones en las que dos personas quieran aplicar cambios al mismo tiempo en un equipo. Terraform bloquea el estado para que solo una persona a la vez pueda cambiar el estado.

- El *terraform state* también ayudar a mejorar el rendimiento, ya que actúa como una versión local de la configuración aplicada y ayudar a acelerar el plan. 

<h2>Gestionar el estado de Terraform</h2>

Hay dos tipos de back-end de estado de Terraform: el back-end local y el back-end remoto.
Un back-end local es la configuración predeterminada de Terraform en la que Terraform usa su disco local para almacenar la configuración de estado en un archivo terraform.tfstate. Si usted es el único administrador que administra su infraestructura, no necesita preocuparse demasiado por el estado, ya que puede utilizar su sistema local como back-end estatal.
Un back-end remoto es imprescindible si tiene varias personas administrando la misma infraestructura. En ese escenario, debe compartir el estado, ya que podría terminar poniéndose en el lugar del otro, y eso aumenta exponencialmente la complejidad con la cantidad de personas agregadas.
Eso no significa que no debas usar backends remotos si eres un administrador individual. Ayuda mucho al permitir almacenar su estado en una ubicación segura, como un depósito S3 donde los archivos de estado se cifran en reposo. También le permite acceder a su estado de Terraform con solo una conexión a Internet. Usted almacena sus configuraciones de Terraform en un repositorio de git y el estado en un back-end remoto.

Hay dos formas de back-end remotos:

- Estándar: un back-end estándar proporciona una ubicación compartida para almacenar el estado con posible bloqueo de estado. Los back-end estándar incluyen AWS S3, Google Cloud Storage, Azure Blob Storage, Artifactory y muchos otros.

- Mejorado: un back-end remoto mejorado proporciona el back-end estándar junto con operaciones remotas. Estos son Terraform Cloud y Terraform Enterprise. Estos proporcionan un plan de Terraform remoto y solicitan más colaboración.

Veamos un ejemplo práctico para comprender mejor el back-end remoto estándar.

<h2>Pre-requisitos</h2>

-Terraform 0.12 instalado en su sistema
-Acceso de lectura / escritura al bucket de Google Cloud Storage
- Service accounts con los permisos necesarios para crear una instancia de Google Compute Engine, junto con su clave JSON. Consulte "Configuración de su entorno de nube" para obtener más detalles.

<h2>Configurando el BackEnd</h2>
Para este ejemplo, comencemos con una configuración simple de Terraform para crear una instancia de GCE.

Lo primero a realizar es clonar el siguiente repositorio:

https://github.com/gelopfalcon/terraform-workshop/tree/gcp-parte-1

Inspecciona el archivo provider.tf.
```
provider "google" {
  credentials = file(var.credentials)
  project     = var.project
  region      = var.region
}
```

Lo anterior es un archivo de proveedor directo que utiliza el proveedor de Google y especifica un proyecto, región y el archivo JSON de credenciales de cuenta de servicio como variables.

A continuación, inspecciona el archivo main.tf
```
resource "google_compute_instance" "main" {
  name         = var.instance_name
  machine_type = var.instance_machine_type
  zone         = var.instance_zone
boot_disk {
    initialize_params {
      image = var.instance_image
    }
  }
network_interface {
    subnetwork = var.subnet_name
    access_config {
    }
  }
service_account {
    scopes = ["storage-rw"]
  }
allow_stopping_for_update = true
}
```

El archivo instance.tf crea una instancia de GCE en la red y subred predeterminadas con un scope ACL de storage-rw.

Inspeccione el archivo backend.tf.
```
terraform {
  backend "gcs"{
    bucket      = "<state-bucket-name>"
    prefix      = "dev"
  }
}
```

El archivo backend.tf declara un bucket GCS como back-end y proporciona el bucket, el prefijo y las credenciales en la configuración.

El prefijo opcional es el prefijo GCS dentro del bucket. Si se especifica, Terraform almacena el estado como `<prefijo> / <espacio de trabajo> .tfstate`. Si no especifica el prefijo, almacena el archivo de estado en el nivel raíz del bucket GCS.
Hay otras propiedades opcionales que puede necesitar para su caso de uso. Consulte la documentación oficial de HashiCorp aquí para obtener más detalles.

Actualice el archivo terraform.tfvars con los valores apropiados para las variables, como:
```
instance_name         = "test-instance"
instance_machine_type = "n1-standard-2"
instance_zone         = "us-east1-b"
instance_image        = "centos-cloud/centos-7-v20200309"
subnet_name           = "default"
external_enabled      = true
project               = "<project-name>"
region                = "us-east1"
```

Comencemos con crear un nuevo bucket.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/r3xpb2750ci777cgsp7s.png)

Como puede ver, todavía no hay ningún objeto en este bucket.

<h2>Aplicar a los cambios</h2>

Es tiempo de inicializar terraform
```
$ terraform init
Initializing the backend...
Initializing provider plugins...
- Checking for available provider plugins...
- Downloading plugin for provider "google" (hashicorp/google) 3.25.0...
Terraform has been successfully initialized!
You may now begin working with Terraform. Try running "terraform plan" to see any changes that are required for your infrastructure. All Terraform commands should now work.
If you ever set or change modules or backend configuration for Terraform, rerun this command to reinitialize your working directory. If you forget, other commands will detect it and remind you to do so if necessary.

```
Bien, ahora se inicializa el back-end y se descargan los proveedores.
Ejecutemos el plan.
`terraform plan`

Y el plan genera una instancia para agregar.
Aplica el plan ejecutando:
`terraform apply`

Usted puede ver que la aplicación de terraform se ejecutó con éxito.
Si verificamos la consola GCE, vemos que Terraform ha creado una instancia.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/3m8bc41v6y17e12tm2sf.png)

Es hora de revisar el bucket de GCS.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/l6iasp0oum27x48pm53o.png)

¡Felicidades! El archivo `default.tfstate` está presente en la carpeta `dev`.

A medida que GCS cifra el archivo en rest, es mucho más seguro que almacenar el archivo en su sistema local.

NO olvides ejecutar el `terraform destroy` si deseas no continuar usando la instancia y que no te consuma recursos. 

<h2>Conclusiones</h2>
¡Gracias por leer! Espero que hayas disfrutado el artículo.
Terraform ofrece muchas otras opciones para un estado remoto, y están creciendo. Al momento de escribir esta historia, hay 14 opciones de back-end remotas diferentes, por lo que puede elegir de acuerdo con lo que mejor se adapte a su arquitectura.

Te comparto algunos medios donde regularmente publico y organizo actividades:

https://twitter.com/gelopfalcon
https://www.youtube.com/channel/UCypyV-geyQF6gfBJlhb1DVA?view_as=subscriber
https://www.facebook.com/dockertico
https://www.facebook.com/falconcoach87
https://www.meetup.com/gdg-costarica/