Despliegue con Terraform en Azure a través de BitBucket Pipelines

BitBucket es otra alternativa muy interesante para la automatización de nuestros pipelines de CI/CD. En este caso integraremos, con esta herramienta, un pipeline para despliegue automatico de Terraform en Azure.

Para el despligue de CI/CD utilizaremos BitBucket Pipelines que es una herramienta que nos da minutos de ejecución gratuitos para poder probar nuestro codigo.

Utilizaremos el siguiente repo: https://bitbucket.org/mb-terraform-proj/bb-terraform-lab/

Table of Contents

¿Que es BitBucket?

Bitbucket es otra plataforma como Azure Repos o GitHub que ofrece control de versiones y permite a los equipos colaborar en el código, con soporte para Git y Mercurial. Esta plataforma es de Atlassian y ofrece integración optimizada con productos como Jira y Trello.

¿Qué es Bitbucket Pipelines?

Bitbucket Pipelines es una herramienta integrada dentro de Bitbucket que permite implementar procesos de integración y despliegue continuo (CI/CD). Esta funcionalidad automatiza el proceso de prueba y despliegue de software, permitiendo a los equipos liberar versiones de manera más rápida y eficiente.

Ofrece una integración más estrecha con Docker, incluyendo la capacidad de construir y subir imágenes a Docker Hub y otros registros de Docker directamente desde los pipelines.

Archivo bitbucket-pipelines.yml

El archivo bitbucket-pipelines.yml es un archivo de configuración clave para Bitbucket Pipelines, una herramienta de integración y despliegue continuo (CI/CD) proporcionada por Bitbucket. Este archivo, escrito en formato YAML, define cómo Bitbucket debería construir, testear y desplegar tu código.

Para utilizar BitBucket pipelines debemos:

Generar el archivo bitbucket-pipelines.yml en el root de nuestro directorio de archivos.
Escribir nuestro pipeline en YAML.

Componentes basicos de bitbucket-pipelines.yml

El archivo tiene 2 componentes principales:

Image: aquí debemos colocar la imagen de contenedor en la que se ejecutará el pipeline. Podemos utilizar Runners propios o los provistos en BitBucket Cloud.
Pipelines: aquí especificaremos el nombre y pasos de las pipelines.

Vamos a ver un poco sobre las condiciones de ejecución de los pipelines. Tenemos diferentes tipos de Inicio del pipeline:

Por “Default:” La pipeline se activa automáticamente cada vez que se realiza un commit en cualquier rama del repositorio.
Por “Branches:” Permite especificar ramas concretas en las que la pipeline se activará. Por ejemplo, podrías configurar la pipeline para que solo se ejecute en la rama main o en ramas de características específicas. Esto es útil para controlar en qué ramas quieres realizar CI/CD.
Por “Pull Requests:” Esta condición se enfoca en pull requests. La pipeline se activará cuando se cree o actualice un pull request que esté dirigido a ramas específicas. Esto es particularmente útil para validar y probar cambios antes de que se fusionen con tu rama principal.
Por “Tags:” Con esta condición, la pipeline se ejecuta cuando se crea una etiqueta Git. Esto es útil para escenarios como despliegues, donde puedes querer activar un proceso de despliegue cuando marcas una versión específica con una etiqueta.
Inicio Personalizado: Esta opción permite iniciar la pipeline manualmente. Es útil para ejecutar flujos de trabajo que no necesitas correr con cada cambio, como despliegues manuales, limpiezas o tareas administrativas.

Pipeline de demo

Aca dejo el ejemplo que utilizaremos en este caso:

image: hashicorp/terraform:latest

pipelines:
  branches:
    main:
        - step:
            name: Security Scan
            script:
              # Run a security scan for sensitive data.
              # See more security tools at https://bitbucket.org/product/features/pipelines/integrations?&category=security
              - pipe: atlassian/git-secrets-scan:0.5.1
        - step:
            name: Deploy to Production
            deployment: Production

            script:
              - terraform init
              - terraform plan
              - terraform apply -auto-approve

Imagen de Docker:

image: hashicorp/terraform:latest

Esta línea especifica que el pipeline utilizará la imagen de Docker hashicorp/terraform:latest. Esto significa que todas las operaciones de pipeline se ejecutarán en un contenedor Docker que tiene la última versión de Terraform instalada.

Pipelines para Branches:

pipelines: 
  branches: 
    main:

Define que las siguientes configuraciones de pipeline se aplicarán a la rama main del repositorio.

Security Scan:

    - step:
            name: Security Scan
            script:
              # Run a security scan for sensitive data.
              # See more security tools at https://bitbucket.org/product/features/pipelines/integrations?&category=security
              - pipe: atlassian/git-secrets-scan:0.5.1

Dentro de este paso, se ejecuta un script que utiliza atlassian/git-secrets-scan:0.5.1. Este es un “pipe” de Bitbucket, una herramienta preconfigurada que se utiliza para escanear el código en busca de datos sensibles o secretos que no deberían estar expuestos.
Incorpora un paso adicional “integrado” con bitbucket para escanear la seguirdad de nuestro codigo.

Paso de Despliegue en Producción:

        - step:
            name: Deploy to Production
            deployment: Production

            script:
              - terraform init
              - terraform plan
              - terraform apply -auto-approve

Luego del Scan de seguridad dedicado, se inicia el step de despliegue en el entorno de producción.
El script de este paso consta de tres comandos de Terraform.
terraform init: Inicializa el directorio de trabajo de Terraform, instalando los plugins necesarios.
terraform plan: Crea un plan de ejecución, mostrando qué acciones se realizarán cuando se aplique el cambio de infraestructura.
terraform apply -auto-approve: Aplica los cambios de infraestructura definidos en Terraform. La opción -auto-approve evita que se pida confirmación manual para aplicar los cambios.

Consideraciones para el login en Azure utilizando la imagen de Terraform

Segun se indica en la siguiente documentación:

https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/guides/service_principal_client_secret#configuring-the-service-principal-in-terraform

Debemos generar un service principal en Azure, darle los permisos necesarios y usar los datos de dicho SP para el login de Azure. Es importante que utilicemos el Least Privilage en entornos de producción. Para este caso de laboratorio no nos enfocaremos en este punto y para simplificar daremos permisos de Contributor sobre la suscripción. Es importante tener en cuenta que esto NO DEBE REALIZARSE en entornos de producción.

Entonces debemos:

Crear Service Principal:

az ad sp create-for-rbac --name {principalname} --role {role|Contributor} --scopes {scope|/subscriptions/{subscription}/resourceGroups/{resourcegroup}}

Como resultado de este comando obtendremos el siguiente output:

{
  "appId": "...",
  "displayName": "test-principal",
  "password": "...",
  "tenant": "..."
}

Con dicha información debemos configurar las siguientes variables de repositorio en BitBucket.
Debemos ir al Repositorio>Configuraciones del repositorio>Variables del repositorio
Configurar las siguientes variables:

Variables de Repositorio

Debemos crear las siguientes variables con los nombres exactos:

ARM_CLIENT_ID. Asignar el valor de “appId” del output del SP.
ARM_CLIENT_SECRET. Asignar el valor de “password” del output del SP.
ARM_TENANT_ID. Asignar el valor de “tenant” del output del SP.
ARM_SUBSCRIPTION_ID. Asignar el valor del ID de la suscripción, que no está en el output del SP.

Una vez completados estos pasos, podemos iniciar con el despliegue 🙂

Demo de despliegue a Azure con Terraform

Repo: https://bitbucket.org/mb-terraform-proj/bb-terraform-lab/

Recomiendo hacer el fork del repo!

Localizar el Repositorio a Forkar:

Navega al repositorio que deseas forkear. Por ejemplo, si quieres forkear el repositorio https://bitbucket.org/mb-terraform-proj/bb-terraform-lab/, ve a esa URL en tu navegador.

Forkar el Repositorio:

En la página del repositorio, busca el botón “Fork” (puede aparecer como un ícono de bifurcación). Este botón generalmente se encuentra en la parte superior derecha de la página.
Haz clic en el botón “Fork”.

Configurar el Fork:

Al hacer clic en “Fork”, se te pedirá que configures tu nuevo repositorio bifurcado.
Puedes cambiar el nombre del repositorio y ajustar otras configuraciones, como la descripción o la visibilidad (público o privado).
Una vez que hayas terminado de configurar tu fork, haz clic en el botón para crear el fork.

Clonar el Repositorio Forkado:

git clone https://bitbucket.org/tu-usuario/tu-fork-repo.git
cd tu-fork-repo

Luego debemos crear el Service Principal para Terraform

Realizar algun cambio minimo del codigo y configurar las variables de repositorio (nombrado más arriba en este post!). Debemos configurar las variables:

az ad sp create-for-rbac --name Terraform-sp --role Contributor --scopes {scope|/subscriptions/{subscription}}

El output será algo como esto:

{
  "appId": "...",
  "displayName": "test-principal",
  "password": "...",
  "tenant": "..."
}

ARM_CLIENT_ID. Asignar el valor de “appId” del output del SP.
ARM_CLIENT_SECRET. Asignar el valor de “password” del output del SP.
ARM_TENANT_ID. Asignar el valor de “tenant” del output del SP.
ARM_SUBSCRIPTION_ID. Asignar el valor del ID de la suscripción, que no está en el output del SP.

Una vez que pusheamos el cambio a nuestro repo, se iniciará el BitBucket Pipeline.

En primera instancia, veremos que se ejecuta exitosamente el paso de

Luego podremos ver que inicia la ejecución de Terraform Init.

En segundo lugar se verá el resultado de Terraform Plan

Por ultimo, se ejecutará Terraform Apply sin aprobación manual.

Podemos ver como se crea nuestro AKS.

Luego de la creación veremos nuestro recurso creado en Azure 🙂