Los módulos en Terraform son una colección de recursos que se pueden vincular o simplemente crear individualmente. Cuando llamamos a un módulo, estamos llamando a un archivo con una serie de recursos y algunos parámetros, los cuales necesitamos especificar o bien en el propio recurso o en otro archivo que almacene nuestras variables.

¿Por qué usar Terraform?

• Es una herramienta muy útil para desarrollar, cambiar y tener un versioning de nuestra infraestructura de manera eficiente y segura.
• Es una herramienta que permite definir infraestructura como código y habilita cambiar y hacer un seguimiento de la infraestructura con facilidad.
• Es independiente de la plataforma o ‘cloud agnostic’ y permite trabajar con múltiples proveedores cloud.

¿Qué necesitamos para este lab?

• Terraform instalado. En este caso, ejecutamos la v.0.12.7.
• En nuestro caso, utilizamos AWS como nuestro proveedor de servicios en la nube, por lo que necesitamos un usuario con acceso mediante programación. También necesitamos dar acceso a este usuario con la Política de IAM adecuada.
• Tu editor de código preferido.

¡Empecemos!

Por lo general, primero deberíamos configurar un módulo Terraform con nuestros parámetros requeridos o simplemente obtener algún módulo oficial de la red. En nuestro caso, estamos usando un módulo propio con un Bucket S3 y su propia política y, por lo tanto, especificamos qué parámetros queremos en nuestro módulo.

resource "aws_s3_bucket" "this" {
  bucket            = var.bucket_name
  acl               = var.type_acl
  force_destroy     = var.destroy

  tags = {
    Name            = var.tag_name
  }
  versioning {
    enabled         = var.versioning
  } 
}

resource "aws_s3_bucket_policy" "this" {
  bucket = var.bucket_name
  policy = templatefile("${path.module}/templates/s3_origin_access_identity.json", {
    origin_access_identity_arn         = aws_cloudfront_origin_access_identity.this.iam_arn,
    origin_access_identity_bucket_name = var.bucket_name
  })
}

Como veis, hay algunos valores que los introducimos con variables por lo tanto, necesitaremos un fichero llamado «variables.tf» en el cuál introduciremos los valores.

En la misma carpeta que tenemos nuestro archivo “main.tf”, creamos nuestro fichero “variables.tf”:

### S3 VARIABLES

variable "bucket_name"      { }
variable "tag_name"         { }
variable "type_acl"         { }
variable "versioning"       { }
variable "destroy"          { }
variable "aliases"          { }
variable "certificate_arn"  { }

En este caso particular, puede que os preguntéis por qué estas variables no tienen ningún valor almacenado. Y la respuesta es que estamos usando un archivo principal llamado «terragrunt.hcl» el cuál almacenará todos nuestros valores cuando llamemos al módulo.

Otra cosa que puede resultar confusa es cómo especificar la política del Bucket. Podemos especificarla o bien con un archivo heredoc (EOF) o directamente con una función de Terraform llamada «templatefile».

El primer ejemplo está en la documentación oficial de Terraform, una web que os sugiero visitar para entender el verdadero poder de los módulos y sus recursos.

En nuestro caso usamos el segundo ejemplo y necesitamos que en la misma carpeta, haya otra llamada «templates» y dentro de ella, la política del Bucket como un archivo JSON.

{
    "Version": "2012-10-17",
    "Id": "PolicyForCloudFrontPrivateS3Content",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "${origin_access_identity_arn}"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::${origin_access_identity_bucket_name}/*"
        }
    ]
  }

Como seguramente os habréis dado cuenta, hemos introducido varias variables ${origin_access_identity_arn} y ${origin_access_identity_bucket_name} y eso es porque así, introduciremos los valores desde fuera de esa política, desde el propio archivo ‘main.tf».

policy = templatefile("${path.module}/templates/s3_origin_access_identity.json", {
    origin_access_identity_arn         = aws_cloudfront_origin_access_identity.this.iam_arn,
    origin_access_identity_bucket_name = var.bucket_name
  })

Así, introducimos el arn llamando a otro recurso llamado «aws_cloudfront_origin_access_identity» y el nombre del bucket lo introducimos como hemos visto antes con nuestro archivo de variables.

Ahora solo necesitamos especificar el proveedor de Terraform y llamar al módulo con otro archivo que llamaremos «provider.tf» con los valores que hemos especificado:

provider "aws" {
  region     = var.region
  version    = "~> 2.0"
}

provider "aws" {
  alias  = "aws_us_east_1"
  region = "us-east-1"
}
module "s3" {
    source               = "../../../../../../modules/s3-cloudfront/"
    bucket_name          = var.bucket_name
    tag_name             = var.tag_name
    type_acl             = var.type_acl
    versioning           = var.versioning
    destroy              = var.destroy
    aliases              = var.aliases
    certificate_arn      = var.certificate_arn    
}

Y por último, desplegar nuestro módulo con los comandos terraform init, terraform plan y terraform apply.

Conclusión

En este post, hemos visto como desplegar un Bucket S3 con su respectiva política con Terraform. Os sugiero que visitéis la documentación oficial de Terraform para seguir aprendiendo sobre los módulos, recursos y sus parámetros.

También os invito a contactar con nosotros en caos de que necesitéis información acerca del mundo DevOps y no dudéis en seguir nuestro blog para descubrir otros posts útiles.

La entrada Una vista rápida de los módulos de Terraform se publicó primero en Geko Cloud.

De vez en cuando, Google introduce nuevas características y cambios que a veces también obligan a los módulos de Terraform a actualizarse. En Geko, estábamos usando el módulo GKE para la implementación y administración de clústeres públicos en la versión 5.x. Hace unos días, cuando planeamos actualizar algunos parámetros, descubrimos que Google había eliminado la compatibilidad con el panel de control de Kubernetes. Estaba completamente en desuso y el módulo estaba fallando debido a ello, por lo que nos vimos obligados a actualizar el módulo para cumplir con las nuevas condiciones. Hubo hasta 3 actualizaciones de versiones principales disponibles, por lo que decidimos probarlo y usar la última. Sin embargo, no era una solución independiente, ya que requería gestionar las incoherencias del estado de Terraform.

El objetivo de este laboratorio es aprender cómo actualizar el módulo oficial Terraform destinado a implementar y administrar un clúster GKE público. Nos ocuparemos especialmente de los cambios de ruptura del módulo (kubernetes-engine.beta-public-cluster), y lograremos obtener el estado consistente que teníamos antes de la falla que precedió a la actualización.

Tiempo estimado para terminar este laboratorio: ~ 20 minutos

1. Eliminar los recursos anteriores

¡Se recomienda encarecidamente realizar una copia de seguridad de archivos tfstate antes de continuar!

Es especialmente importante eliminar todos los recursos conflictivos del tfstate de Terraform ya que están vinculados entre ellos como dependencias. El objetivo aquí es eliminar cualquier enlace obsoleto antes de importarlo nuevamente desde la «imagen» actual que ya se ha desplegado.

Los componentes principales en un clúster de Kubernetes son las redes (y subredes), el grupo de nodos y el clúster en sí. Centrémonos en ellos.

terraform state rm module.gke.google_container_cluster.primary
terraform state rm module.gke.google_container_node_pool.pools[0]
terraform state rm module.vpc.google_compute_network.network
terraform state rm module.vpc.google_compute_subnetwork.subnetwork[0]
terraform state rm module.vpc.google_compute_subnetwork.subnetwork[1]

2. Actualizar versiones

Una vez eliminados los estados anteriores, el siguiente paso es configurar la última versión los módulos requeridos. Para el módulo GKE, la última versión disponible a fecha de hoy es 8.1.0, pero se permite aplicar automáticamente actualizaciones menores («~>»).

Actualizar el módulo clúster GKE

 module "gke" {
   source  = "terraform-google-modules/kubernetes-engine/google//modules/beta-public-cluster"
-  version = "~> 5.0"
+  version = "~> 8.1"

Actualizar el módulo VPC

 module "vpc" {
-  source  = "github.com/terraform-google-modules/terraform-google-network?ref=v1.1.0"
+  source  = "github.com/terraform-google-modules/terraform-google-network?ref=v2.3.0"

Comprobar los nuevos recursos

Para saber si los nuevos recursos han experimentado un cambio de nombre (debido a la actualización de los módulos), se recomienda encarecidamente lanzar un plan de Terraform.

En este caso, se ha encontrado que la jerarquía interna de algunos módulos y también los índices de la lista han cambiado.

  module.gke.google_container_cluster.primary
  
- module.gke.google_container_node_pool.pools[0]
+ module.gke.google_container_node_pool.pools["default-node-pool"]

  module.vpc.google_compute_network.network
  
- module.vpc.google_compute_subnetwork.subnetwork[0]
+ module.vpc.module.subnets.google_compute_subnetwork.subnetwork["southamerica-east1/my-cluster-public"]

- module.vpc.google_compute_subnetwork.subnetwork[1]
+ module.vpc.module.subnets.google_compute_subnetwork.subnetwork["southamerica-east1/my-cluster-private"]

3. Importar los nuevos recursos

Ten en cuenta que la zona/región depende del tipo de clúster. Si es de zona, debe usar la zona maestra (por ejemplo, southamerica-east1-a). Por otro lado, si se trata de un clúster regional, debe usar la región (por ejemplo, southamerica-east1). El siguiente ejemplo supone un clúster regional ubicado en southamerica-east1, en el proyecto «my-project» y con el nombre de clúster «my-cluster». Los nombres de red se configuraron de acuerdo con el nombre del clúster, simplemente agregando los sufijos «private» y «public» a las subredes para diferenciarlos adecuadamente.

Ten en cuenta también la nueva jerarquía de módulos e indexación.

# Global vars
REGION="southamerica-east1"
PROJECT="my-project"
CLUSTER="my-cluster"

# Cluster
CLUSTER_LOCAL="module.gke.google_container_cluster.primary"
CLUSTER_REMOTE="${PROJECT}/${REGION}/${CLUSTER}"
terraform import $CLUSTER_LOCAL $CLUSTER_REMOTE

# Node pool
POOL_LOCAL="module.gke.google_container_node_pool.pools["default-node-pool"]"
POOL_REMOTE="${CLUSTER_REMOTE}/default-node-pool"
terraform import $POOL_LOCAL $POOL_REMOTE

# Subnetworks
BASE_SUBNET_LOCAL="module.vpc.module.subnets.google_compute_subnetwork.subnetwork"

## Public
PUBLIC_SUBNET_LOCAL="${BASE_SUBNET_LOCAL}["${REGION}/${CLUSTER}-public"]"
PUBLIC_SUBNET_REMOTE="${CLUSTER_REMOTE}-public"
terraform import $PUBLIC_SUBNET_LOCAL $PUBLIC_SUBNET_REMOTE

## Private
PRIVATE_SUBNET_LOCAL="${BASE_SUBNET_LOCAL}["${REGION}/${CLUSTER}-private"]"
PRIVATE_SUBNET_REMOTE="${CLUSTER_REMOTE}-private"
terraform import $PRIVATE_SUBNET_LOCAL $PRIVATE_SUBNET_REMOTE

# Network
NETWORK_LOCAL="module.vpc.module.vpc.google_compute_network.network"
NETWORK_REMOTE="${PROJECT}/${CLUSTER}"
terraform import $NETWORK_LOCAL $NETWORK_REMOTE

 4. Actualizar parámetros

Es muy probable que encuentres que, después de lanzar un plan de Terraform, el recurso google_container_cluster todavía necesite actualizarse debido a un cambio en el parámetro de subred. Las nuevas claves de subred han hecho que los índices cambien su orden. Simplemente edita el módulo GKE para reemplazar el parámetro subnetwork como se muestra a continuación.

- subnetwork = module.vpc.subnets_names[0]
+ subnetwork = module.vpc.subnets_names[1]

Conclusión

Como habrás visto anteriormente, a veces, al depender de terceros, puede suceder que se introduzca un cambio importante y tengas problemas para recuperar el servicio nuevamente. Además de esto, la solución podría introducir daños colaterales que requerirán subsoluciones adicionales. En este caso particular con respecto a Terraform, lidiar con estados inconsistentes no es realmente común ni recomendado, pero es el único método que tiene disponible para resolverlos en su conjunto de herramientas.

Espero que hayas disfrutado de este post y te animo a que revises nuestro blog para leer otrosposts que puedan ser de tu interés. No dudes en contactarnos si deseas que te ayudemos en tus proyectos.

¡Nos vemos en la próxima entrada!

La entrada Actualización del módulo Terraform en los clústeres públicos de GKE se publicó primero en Geko Cloud.