Estrategias Multi-Cloud: Orquestación Híbrida con Terraform y Ansible

La adopción de estrategias Multi-Cloud ha dejado de ser una simple medida de mitigación de riesgos (vendor lock-in) para convertirse en una arquitectura core orientada a la resiliencia, el cumplimiento normativo y la optimización de costes. Sin embargo, gobernar múltiples proveedores (AWS, Azure, GCP) introduce una complejidad operativa significativa. La clave para dominar este ecosistema fragmentado reside en la separación de responsabilidades: Terraform para el aprovisionamiento de infraestructura inmutable y Ansible para la gestión de configuración y orquestación de estado.

La Sinergia Terraform-Ansible en Entornos Distribuidos#

Mientras que Terraform destaca en la gestión del ciclo de vida de la infraestructura mediante su enfoque declarativo y la gestión del estado (state file), sufre cuando se trata de ejecutar tareas post-despliegue complejas. Ansible, por otro lado, brilla en la configuración de sistemas operativos, despliegue de aplicaciones y orquestación de flujos de trabajo sin agentes.

Nota Importante: El anti-patrón más común en arquitecturas Multi-Cloud es intentar forzar a Terraform a realizar tareas de configuración pesadas mediante local-exec o remote-exec, lo que rompe la inmutabilidad y dificulta la idempotencia.

Arquitectura de Integración Dinámica

Para integrar ambas herramientas de forma robusta, no dependemos de inventarios estáticos. En su lugar, utilizamos el Dynamic Inventory de Ansible para consultar directamente las APIs de los proveedores de nube basándonos en las etiquetas (tags) aplicadas por Terraform.

Aprovisionamiento Base con Terraform#

El primer paso es definir nuestra infraestructura abstrayendo las particularidades de cada nube mediante módulos. A continuación, mostramos un patrón para inyectar metadatos que posteriormente Ansible consumirá.

# main.tf - Despliegue Multi-Cloud Estandarizado
provider "aws" {
  region = "eu-west-1"
}

provider "azurerm" {
  features {}
}

module "aws_frontend_nodes" {
  source = "./modules/aws_compute"

  instance_type = "t3.medium"
  environment   = "production"
  role          = "web-server"

  # Tags críticas para el Dynamic Inventory de Ansible
  tags = {
    AnsibleGroup = "frontend_nodes"
    Environment  = "prod"
  }
}

module "azure_backend_nodes" {
  source = "./modules/azure_compute"

  vm_size     = "Standard_DS2_v2"
  environment = "production"
  role        = "api-server"

  tags = {
    AnsibleGroup = "backend_nodes"
    Environment  = "prod"
  }
}

Orquestación y Configuración de Estado con Ansible#

Una vez que Terraform ha establecido la topología de red, las reglas de firewall y las instancias de cómputo, Ansible toma el control. Utilizamos los plugins de inventario dinámico aws_ec2 y azure_rm.

Configuración del Inventario Dinámico

# aws_ec2.yml
plugin: aws_ec2
regions:
  - eu-west-1
keyed_groups:
  - key: tags.AnsibleGroup
    prefix: role
  - key: tags.Environment
    prefix: env

Con este inventario dinámico, podemos dirigir nuestros Playbooks específicamente a los nodos correctos sin importar en qué nube residan:

# site.yml - Orquestación Multi-Cloud
---
- name: "Configurar Frontend Nodes (AWS)"
  hosts: role_frontend_nodes
  become: yes
  roles:
    - role: nginx_ingress
    - role: security_hardening

- name: "Configurar Backend Nodes (Azure)"
  hosts: role_backend_nodes
  become: yes
  roles:
    - role: docker_runtime
    - role: api_services

Ejecución Segregada en Pipelines CI/CD

El pipeline de despliegue (GitOps) debe reflejar esta separación de responsabilidades, asegurando que el estado de la infraestructura converja antes de aplicar configuraciones.

# fragmento de pipeline (.gitlab-ci.yml o GitHub Actions)
deploy_infrastructure:
  stage: provision
  script:
    - terraform init
    - terraform plan -out=tfplan
    - terraform apply -auto-approve tfplan

configure_systems:
  stage: configure
  needs: [deploy_infrastructure]
  script:
    # Ansible consultará dinámicamente AWS/Azure
    - ansible-playbook -i aws_ec2.yml -i azure_rm.yml site.yml

Conclusión#

Delegar el "qué" a Terraform (infraestructura física/virtual) y el "cómo" a Ansible (estado del software interno) permite a los arquitectos IT construir ecosistemas Multi-Cloud resilientes. Esta separación reduce la fricción en operaciones de Day 2, facilita las rotaciones de credenciales y asegura que nuestras flotas de servidores, independientemente de si residen en AWS, Azure o GCP, mantengan un estándar de configuración unificado y auditable.