Gerenciar infraestrutura em múltiplas nuvens é mais difícil do que parece. Você acaba com dois painéis de faturamento, dois conjuntos de primitivas de IAM, duas CLIs e o risco constante de desvio de configuração entre ambientes. O Terraform não elimina essa complexidade, mas oferece um único lugar para definir tudo e um único fluxo de trabalho para aplicar.

Por Que Usar o Terraform para Implantações Multi-Cloud?

Ferramentas de Infraestrutura como Código permitem definir a infraestrutura em arquivos versionados em vez de clicar em um console. O Terraform é uma escolha sólida para configurações multi-cloud por algumas razões concretas:

  1. Ecossistema de Providers: Os plugins de provider do Terraform suportam GCP, AWS, Azure e dezenas de outros. Você pode gerenciar recursos de nuvens diferentes no mesmo projeto.

  2. Gerenciamento de Estado: O Terraform rastreia o estado real dos recursos em um arquivo de estado. Quando você executa terraform apply, ele reconcilia a configuração desejada com o que existe atualmente, tornando as atualizações previsíveis.

  3. Reusabilidade de Código: Módulos permitem encapsular definições de recursos e reutilizá-las em ambientes e providers. Isso é especialmente útil quando configurações de GCP e AWS compartilham uma estrutura comum.

  4. Controle de Versão: Arquivos Terraform são código, então vão para o Git. Você tem histórico, blame, pull requests e rollbacks para sua infraestrutura.

  5. Fluxo de Trabalho Uniforme: Em vez de alternar entre gcloud, aws e scripts customizados, você executa terraform plan e terraform apply para ambas as nuvens. Essa consistência importa na hora de integrar engenheiros ou depurar às 3h da manhã.

Benefícios do Multi-Cloud com Google Cloud e AWS

Operar em ambos os providers traz vantagens reais:

  1. Redundância: Se um provider tiver uma interrupção, as cargas de trabalho podem ser migradas para o outro sem começar do zero.

  2. Otimização de Custos: Os providers precificam serviços de forma diferente. Executar computação no que for mais barato para uma determinada região ou tipo de carga de trabalho faz diferença ao longo do tempo.

  3. Acesso a Serviços Exclusivos: O AWS Lambda tem um forte ecossistema serverless. O GKE é uma das melhores ofertas de Kubernetes gerenciado. Uma configuração multi-cloud permite usar a melhor ferramenta para cada tarefa.

  4. Migração Gradual: Muitas equipes usam multi-cloud durante uma migração, executando parte da carga de trabalho em cada provider enquanto fazem a transição. O Terraform gerencia os dois lados a partir de uma única fonte de verdade.

Preparando o Ambiente Terraform

Antes de escrever qualquer configuração, coloque as ferramentas no lugar.

1. Instalar o Terraform

Baixe e instale o binário mais recente do Terraform no site oficial da HashiCorp. Verifique a instalação:

terraform -version

2. Configurar as CLIs de Nuvem

Você precisa do Google Cloud SDK (gcloud) e da AWS CLI para autenticar e gerenciar recursos.

  • Google Cloud SDK: Autentique executando gcloud init ou gcloud auth login.
  • AWS CLI: Autentique usando aws configure para definir sua access key, secret key e região padrão.

3. Configurar Contas de Serviço e Chaves de Acesso

Para produção, use credenciais dedicadas em vez de sua conta pessoal:

  • Google Cloud: Crie uma conta de serviço com as funções necessárias (por exemplo, admin de computação, admin de armazenamento). Baixe o arquivo de chave JSON e referencie-o na sua configuração do Terraform ou defina-o como variável de ambiente.
  • AWS: Gere uma access key e secret key com permissões limitadas, seguindo os princípios de menor privilégio.

Estruturando o Projeto Terraform

Um projeto multi-cloud típico pode ter esta aparência:

.
├── modules
│   ├── gcp
│   │   └── compute_instance
│   └── aws
│       └── ec2_instance
├── environments
│   ├── dev
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── terraform.tfvars
│   └── prod
│       ├── main.tf
│       ├── variables.tf
│       └── terraform.tfvars
├── provider.tf
├── versions.tf
└── README.md

Arquivos principais:

  • versions.tf fixa a versão do Terraform e dos providers para consistência entre ambientes.
  • provider.tf configura os providers GCP e AWS com projeto, região e detalhes de credenciais.
  • main.tf referencia módulos ou define recursos inline.
  • variables.tf declara variáveis, mantendo valores sensíveis fora do controle de versão via terraform.tfvars.
  • modules/ contém configurações reutilizáveis, cada uma com seus próprios main.tf, variables.tf e outputs.tf.

Essa estrutura modular permite testar em staging e promover para produção com confiança.

Configurando os Providers

Declarar ambos os providers em um único arquivo de configuração é simples:

terraform {
  required_version = ">= 1.0.0"
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 4.0"
    }
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.0"
    }
  }
}

provider "google" {
  project = var.gcp_project
  region  = var.gcp_region
  credentials = file(var.gcp_credentials_file)
}

provider "aws" {
  region = var.aws_region
  access_key = var.aws_access_key
  secret_key = var.aws_secret_key
}

Em produção, use variáveis de ambiente (GOOGLE_APPLICATION_CREDENTIALS, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) em vez de incorporar credenciais no código. Para configurações mais avançadas, considere AWS assume roles ou GCP Workload Identity.

Provisionando Recursos no Google Cloud

Com o provider GCP configurado, você pode provisionar instâncias do Compute Engine, buckets do Cloud Storage, bancos de dados do Firestore e muito mais. Aqui está uma instância básica do Compute Engine:

resource "google_compute_instance" "web_server" {
  name         = "terraform-gcp-instance"
  machine_type = "e2-micro"
  zone         = "us-central1-a"

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-11"
    }
  }

  network_interface {
    network = "default"
    access_config {}
  }

  metadata = {
    ssh-keys = "terraform:YOUR_PUBLIC_SSH_KEY"
  }
}

Personalize tipos de máquina, imagens e scripts de inicialização nessa configuração.

Provisionando Recursos na AWS

Os recursos da AWS ficam no mesmo projeto junto com os recursos do GCP. Para uma instância EC2:

resource "aws_instance" "web_server" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t2.micro"

  tags = {
    Name = "terraform-aws-instance"
  }
}

data "aws_ami" "ubuntu" {
  most_recent = true
  owners      = ["099720109477"] # Canonical
  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*"]
  }
}

A mesma abordagem orientada a código se estende ao S3, RDS, Elastic Load Balancers e à maioria dos outros serviços da AWS.

Gerenciando o Estado

O gerenciamento de estado multi-cloud exige planejamento antecipado.

  1. Armazenamento Remoto de Estado: Arquivos de estado locais são arriscados em ambientes de equipe. Use o Amazon S3 com DynamoDB para bloqueio de estado, ou o Google Cloud Storage com bloqueio via API do GCP. Isso evita que aplicações concorrentes corrompam o estado.

  2. Estados Separados por Ambiente: Mantenha arquivos de estado distintos para dev, staging e prod. Uma alteração em dev nunca deve tocar o estado de prod.

  3. Criptografia e Controle de Acesso: Arquivos de estado geralmente contêm IDs de recursos e configuração de rede. Aplique políticas de bucket no S3 ou ACLs no GCS para restringir o acesso.

Boas Práticas para Implantações Multi-Cloud

  1. Use Módulos e o Princípio DRY: Encapsule definições de recursos GCP e AWS em módulos reutilizáveis. Copiar e colar blocos de recursos é como o desvio de configuração começa.

  2. Use Workspaces: Os workspaces do Terraform mantêm estados separados para diferentes ambientes, o que é mais rápido de inicializar do que diretórios separados para projetos menores.

  3. Teste em Ambientes Inferiores: Aplique alterações em dev ou staging antes de produção. Verifique se seus planos realmente fazem o que você espera.

  4. Automatize com CI/CD: Execute terraform plan em cada pull request e terraform apply no merge. GitHub Actions, GitLab CI e Jenkins suportam isso.

  5. Etiquete e Rotule os Recursos: Etiquete tudo na AWS e rotule tudo no GCP. A atribuição de custos e o rastreamento de propriedade se tornam impossíveis sem etiquetagem consistente.

  6. Monitore e Observe: Use o Cloud Monitoring no GCP e o CloudWatch na AWS para acompanhar a utilização de recursos, desempenho e logs em ambos os providers.

Lidando com Cenários Multi-Cloud Complexos

À medida que as configurações crescem, alguns padrões avançados se tornam relevantes:

  • Kubernetes Híbrido: Gerencie definições de clusters GKE e EKS com Terraform mais módulos Helm para unificar fluxos de trabalho baseados em contêiner entre providers.

  • Arquiteturas Serverless: GCP Cloud Functions e AWS Lambda podem ser provisionadas lado a lado. A cobertura do Terraform se estende a serviços serverless, então configurações de funções ficam junto com sua infraestrutura principal.

  • Replicação na Camada de Dados: Sincronizar dados entre o Google Cloud Storage e o Amazon S3 para disponibilidade requer Terraform mais soluções de replicação nativas da nuvem ou serviços de terceiros.

  • Rede e Segurança: VPCs em ambas as nuvens precisam de coordenação cuidadosa. Declare funções IAM, políticas e contas de serviço no Terraform para padronizar a configuração de segurança entre providers.

Superando Problemas Comuns

  1. Particularidades por Provider: Cada provider tem comportamentos únicos e limitações ocasionais. Leia a documentação do provider e verifique os módulos da comunidade antes de construir algo do zero.

  2. Gerenciamento de Credenciais: Gerenciar credenciais para dois providers de nuvem fica complicado. O HashiCorp Vault ou o AWS Secrets Manager centraliza segredos e reduz o risco de credenciais vazarem para o código.

  3. Colisões de Nomes de Recursos: Alguns nomes devem ser globalmente únicos, outros apenas dentro de uma região. Estabeleça convenções de nomenclatura cedo para evitar conflitos.

  4. Estouros de Custo: O Terraform pode provisionar recursos rapidamente, e esquecer de destruir ambientes de teste em dois providers de nuvem leva a cobranças inesperadas. Etiquete recursos efêmeros e configure alertas de faturamento.

  5. Consistência nos Padrões de Infraestrutura: Resista à tentação de gerenciar recursos GCP e AWS em estilos completamente diferentes. Uma abordagem uniforme significa que os engenheiros podem alternar entre ambientes sem reaprender convenções.

Perspectivas Futuras

O ecossistema de providers do Terraform e os próprios provedores de nuvem evoluem rapidamente. As habilidades essenciais — escrever configurações modulares, gerenciar o estado com cuidado, integrar com CI/CD e rastrear custos entre providers — continuarão relevantes independentemente dos serviços específicos que você estiver usando.

Multi-cloud é cada vez mais o padrão para organizações com requisitos sérios de confiabilidade ou cargas de trabalho que se beneficiam dos pontos fortes de diferentes providers. O Terraform é atualmente a ferramenta mais prática para gerenciar essa complexidade a partir de uma única base de código, e investir em IaC limpo e bem organizado agora traz dividendos quando a infraestrutura precisa mudar.