Cómo usan los equipos GitLab y Terraform para la infraestructura como código: Demostración

Cuando varios equipos usan un repositorio de Git como la fuente única de la verdad para toda la infraestructura y el código de implementación de la aplicación, están llevando a cabo un buen procedimiento de GitOps. Los equipos de infraestructura pueden colaborar e implementar código en varios servicios en la nube mediante el uso de Terraform para la automatización. En este artículo se demuestra cómo los equipos pueden crear un clúster de Kubernetes mediante la colaboración con compañeros de equipo dentro de GitLab.

En esta demostración verá cómo seguir un buen procedimiento de GitOps para implementar la infraestructura como código mediante el uso de Terraform para la automatización y GitLab como la fuente única de la verdad (y la CI).

Cómo empezar

Este grupo gitops-demo ilustra los pasos que pueden seguir los equipos.

Para comenzar, inicie sesión en el grupo donde reside el proyecto dentro de GitLab. El siguiente paso es abrir el archivo README.md, que muestra la estructura subyacente del grupo gitops-demo. Hay algunos proyectos individuales y dos subgrupos: infraestructura y aplicaciones.

Hay un repositorio separado para cada nube: Azure, GCP y AWS, y un repositorio para plantillas.
Se pueden encontrar archivos similares en los tres repositorios de la nube. Todos los archivos están escritos en Terraform para automatizar el proceso de implementación, mientras que el archivo gitlab-ci.yml también se almacena en el repositorio a fin de proporcionar instrucciones para la automatización.

El archivo de back-end

Al usar el servicio Terraform Cloud de HashiCorp como ubicación remota para el archivo de estado, mantiene el archivo de estado seguro y en una ubicación central para que cualquier proceso pueda acceder a él. Una ventaja de usar Terraform Cloud es que tiene la capacidad de bloquear el estado para garantizar que solo se pueda ejecutar un job a la vez. De este modo, se evita que varios jobs realicen cambios que creen conflictos. El código almacena los archivos de estado en Terraform Cloud en una organización llamada gitops-demo en un espacio de trabajo llamado aws. Esto mantiene el estado de ejecución en el proveedor de servicios en la nube, de forma que cualquier miembro del equipo tiene acceso en todo momento.

terraform {
  backend "remote" {
    hostname     = "app.terraform.io"
    organization = "gitops-demo"
    workspaces {
      name = "aws"
    }
  }
}

EKS.tf file

El EKS es otro archivo de Terraform que utiliza el módulo EKS para el clúster de Terraform. Los equipos pueden definir parámetros como el tipo de subredes y la cantidad de nodos en el archivo de Terraform EKS.

module "eks" {
  source           = "terraform-aws-modules/eks/aws"
  cluster_name     = "gitops-demo-eks"
  subnets          = "${module.vpc.public_subnets}"
  write_kubeconfig = "false"
  tags = {
    Terraform   = "true"
    Environment = "dev"
  }
  vpc_id = "${module.vpc.vpc_id}"
  worker_groups = [
    {
      instance_type = "m4.large"
      asg_max_size  = 5
      tags = [{
        key                 = "Terraform"
        value               = "true"
        propagate_at_launch = true
      }]
    }
  ]
}

Definir el administrador de GitLab

El proveedor de Kubernetes se puede usar para crear un usuario administrador de GitLab y configurar automáticamente como código y gestionado por Terraform.

Registrar el clúster con GitLab

Tras crear un clúster de Kubernetes, se debe registrar en GitLab para implementar más código en el clúster en el futuro. El primer paso es usar el proveedor de GitLab para crear un clúster de grupo llamado clúster de AWS.

data "gitlab_group" "gitops-demo-apps" {
  full_path = "gitops-demo/apps"
}
provider "gitlab" {
  alias   = "use-pre-release-plugin"
  version = "v2.99.0"
}
resource "gitlab_group_cluster" "aws_cluster" {
  provider           = "gitlab.use-pre-release-plugin"
  group              = "${data.gitlab_group.gitops-demo-apps.id}"
  name               = "${module.eks.cluster_id}"
  domain             = "eks.gitops-demo.com"
  environment_scope  = "eks/*"
  kubernetes_api_url = "${module.eks.cluster_endpoint}"
  kubernetes_token   = "${data.kubernetes_secret.gitlab-admin-token.data.token}"
  kubernetes_ca_cert = "${trimspace(base64decode(module.eks.cluster_certificate_authority_data))}"
}

El código contiene el nombre de dominio, el alcance del entorno y las credenciales de Kubernetes.

Después de ejecutar esto, el clúster se creará en AWS y se registrará automáticamente en el grupo gitops-demo/apps.

Plantilla de Terraform

Vuelva al grupo de infraestructura y abra la carpeta Templates (Plantillas). Al mirar el archivo terraform.gitlab-ci.yml, se puede observar cómo funciona la CI para implementar código de infraestructura en la nube mediante el uso de Terraform.

Dentro del archivo de CI, los equipos pueden ver diversas etapas: validar, planificar, aplicar y destruir. Al usar la imagen de base de Terraform de Hashicorp, los usuarios pueden ejecutar diferentes tareas.

El primer paso es inicializar Terraform.

before_script:
  - terraform --version
  - terraform init
  - apk add --update curl
  - curl -o kubectl https://amazon-eks.s3-us-west-2.amazonaws.com/1.13.7/2019-06-11/bin/linux/amd64/kubectl
  - install kubectl /usr/local/bin/ && rm kubectl
  - curl -o aws-iam-authenticator https://amazon-eks.s3-us-west-2.amazonaws.com/1.13.7/2019-06-11/bin/linux/amd64/aws-iam-authenticator
  - install aws-iam-authenticator /usr/local/bin/ && rm aws-iam-authenticator

El siguiente paso es validar que todo sea correcto.

validate:
  stage: validate
  script:
    - terraform validate
    - terraform fmt -check=true
  only:
    - branches

Es importante recordar que los buenos flujos de trabajo de GitOps incorporan la creación de una solicitud de fusión para los cambios.

merge review:
  stage: plan
  script:
    - terraform plan -out=$PLAN
    - echo \`\`\`diff > plan.txt
    - terraform show -no-color ${PLAN} | tee -a plan.txt
    - echo \`\`\` >> plan.txt
    - sed -i -e 's/  +/+/g' plan.txt
    - sed -i -e 's/  ~/~/g' plan.txt
    - sed -i -e 's/  -/-/g' plan.txt
    - MESSAGE=$(cat plan.txt)
    - >-
      curl -X POST -g -H "PRIVATE-TOKEN: ${GITLAB_TOKEN}"
      --data-urlencode "body=${MESSAGE}"
      "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests/${CI_MERGE_REQUEST_IID}/discussions"
  artifacts:
    name: plan
    paths:
      - $PLAN
  only:
    - merge_requests

La solicitud de fusión

La solicitud de fusión (MR) es el paso más importante en GitOps. Este es el proceso para revisar todos los cambios y ver su impacto. La solicitud de fusión (MR) también es una herramienta de colaboración donde los miembros del equipo pueden discutir los cambios y las partes interesadas pueden aprobar los cambios antes de la fusión final en la rama principal.

La solicitud de fusión define lo que sucederá cuando se ejecute la infraestructura como código. Una vez creada la MR, el plan de Terraform se carga en ella. Después de que se hayan revisado y aprobado todos los cambios, el código puede fusionarse con la rama principal. Una vez que se fusionen los cambios de código, todos los cambios se implementarán en producción.

• ¿Qué significa infraestructura como código?
• Qué es GitOps
• Descubra cómo GitLab optimiza los flujos de trabajo de GitOps
• Descubra el futuro de GitOps de la mano de los líderes de la industria
• Lea la guía para principiantes de GitOps