DevOps Infraestrutura como Código

GitOps para Infraestrutura: Gerenciando Recursos AWS com ArgoCD e Crossplane

Do Git ao Cloud: a evolução do gerenciamento de infraestrutura

Nos últimos anos, a prática de gitops tem se consolidado como a ponte definitiva entre desenvolvimento de software e operações de infraestrutura. Ao tratar a configuração da nuvem como código versionado, equipes podem aplicar os mesmos fluxos de CI/CD usados para aplicações a recursos críticos como VPCs, clusters EKS, bancos de dados RDS e políticas IAM. Essa abordagem reduz a deriva de configuração, aumenta a auditabilidade e permite rollback instantâneo via git revert. Quando combinada com ferramentas nativas da aws, como o crossplane, e um controlador de entrega contínua como o argocd, o GitOps se torna um mecanismo robusto para provisionamento declarativo e reconciliação automática de recursos.

Arquitetura de referência: ArgoCD + Crossplane + AWS

A arquitetura típica para GitOps na AWS envolve três camadas principais:

  • Repositório Git: armazena manifests em YAML que descrevem tanto aplicações (Deployments, Services) quanto recursos de infraestrutura (VPC, Subnet, RDS).
  • ArgoCD: operador que monitora o repositório, detecta mudanças e aplica os manifests ao cluster Kubernetes de controle.
  • Crossplane: extensões do Kubernetes que traduz os recursos customizados (CompositeResources, ManagedResources) em chamadas API da AWS, criando ou atualizando recursos reais.

O fluxo de dados segue: git push → webhook → ArgoCD sync → Crossplane reconcile → AWS API. Cada etapa gera eventos auditáveis no kubectl get events e logs centralizados no CloudWatch, facilitando a observabilidade.

Instalação e configuração do ArgoCD no cluster de controle

Para iniciar, crie um cluster EKS dedicado ao controle de GitOps (por exemplo, gitops-control). Em seguida, instale o ArgoCD usando o manifesto oficial:

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Após a instalação, exponha o serviço argocd-server via LoadBalancer ou Ingress, configure um admin.password seguro e habilite o SSO com o AWS Cognito para integração corporativa. O acesso ao UI do ArgoCD será a porta de entrada para definir applications que apontam para diretórios específicos do repositório Git.

Provisionando o Crossplane no mesmo cluster

Com o ArgoCD pronto, adicione o Crossplane:

kubectl create namespace crossplane-system
kubectl apply -f https://raw.githubusercontent.com/crossplane/crossplane/release-1.13/install.yaml

Em seguida, registre o provedor da AWS:

kubectl apply -f - <<EOF
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: provider-aws
spec:
  package: crossplane/provider-aws:master
EOF

Crie um ProviderConfig que contenha as credenciais da conta AWS (geralmente via IRSA ou Secret com AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY). Essa configuração permite que o Crossplane invoque a API da AWS em nome do cluster.

Definindo recursos AWS como objetos Kubernetes

O grande diferencial do Crossplane é a capacidade de declarar recursos AWS usando CRDs padrão. Por exemplo, para criar um VPC:

apiVersion: ec2.aws.crossplane.io/v1beta1
kind: VPC
metadata:
  name: prod-vpc
spec:
  forProvider:
    cidrBlock: 10.0.0.0/16
    enableDnsSupport: true
    enableDnsHostnames: true
  providerConfigRef:
    name: aws-provider
  writeConnectionSecretToRef:
    name: prod-vpc-conn
    namespace: crossplane-system
EOF

Esses manifests podem ser versionados no mesmo repositório que contém os manifests de aplicação, permitindo que o ArgoCD sincronize tudo em um único sync wave. O Crossplane observa o recurso VPC, cria a VPC na AWS e armazena as credenciais de conexão (ID da VPC, subnets) em um Secret que pode ser consumido por outros recursos, como Subnet ou EKSCluster.

Orquestrando dependências com Sync Waves

Em ambientes complexos, a ordem de criação é crucial. O ArgoCD oferece o recurso syncWave via anotação argocd.argoproj.io/sync-wave. Por exemplo, a VPC deve ser provisionada antes das subnets, que por sua vez precedem o cluster EKS. Um exemplo de aplicação ArgoCD que engloba toda a pilha:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: infra-aws
spec:
  project: default
  source:
    repoURL: https://github.com/empresa/infra-aws.git
    targetRevision: HEAD
    path: manifests
  destination:
    server: https://kubernetes.default.svc
    namespace: crossplane-system
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true
    - ApplyOutOfSyncOnly=true
  ignoreDifferences:
  - group: iam.aws.crossplane.io
    kind: Role
    jsonPointers:
    - /spec/forProvider/assumeRolePolicyDocument

Dentro do diretório manifests, cada recurso pode ter a anotação argocd.argoproj.io/sync-wave: "0" (VPC), "1" (subnets) e "2" (EKS). O ArgoCD garante que a sincronização siga essa sequência, evitando falhas de dependência.

Políticas de segurança e controle de acesso

Ao expor recursos críticos via Git, a segurança deve ser tratada em três camadas:

  1. IAM Roles for Service Accounts (IRSA): cada pod do ArgoCD e Crossplane recebe uma role mínima que permite apenas as ações necessárias (ex.: ec2:CreateVpc, eks:CreateCluster).
  2. RBAC no Kubernetes: limite quem pode criar ou modificar ManagedResources usando ClusterRole e RoleBinding. Por exemplo, somente o time de plataforma tem permissão para aplicar manifests no namespace crossplane-system.
  3. Políticas de repositório Git: habilite branch protection, revisão obrigatória e assinatura GPG para commits que alteram infraestrutura.

Essas medidas reduzem a superfície de ataque e garantem que mudanças não autorizadas sejam rejeitadas antes de chegar ao cluster.

Observabilidade e auditoria

O GitOps traz rastreabilidade nativa, mas complementar com ferramentas de observabilidade é essencial. Recomenda‑se:

  • ArgoCD Metrics: exponha /metrics para Prometheus, monitorando argocd_app_sync_total e argocd_app_health_status.
  • Crossplane Events: use kubectl get events -n crossplane-system ou configure o Crossplane Provider AWS para enviar logs ao CloudWatch.
  • Git Audit: integre o git log com o ArgoCD UI para correlacionar commits a mudanças de recursos.

Com esses dados centralizados, equipes podem criar dashboards que exibem tempo de provisionamento, taxa de falhas e histórico de rollbacks, facilitando a análise de incidentes.

Estratégias de rollback e recuperação de desastres

Em caso de falha, o GitOps simplifica o rollback: basta reverter o commit que introduziu a mudança e deixar o ArgoCD sincronizar novamente. O Crossplane detecta a divergência, exclui o recurso indesejado e recria o estado desejado. Para recuperação de desastres (DR), combine:

  • Snapshots de EBS e RDS automatizados.
  • Armazenamento do estado do cluster (etcd) em S3 com versionamento.
  • Repositório Git replicado em múltiplas regiões.

Essas práticas garantem que, mesmo que a região primária falhe, o pipeline GitOps pode ser reexecutado em outra região, recriando toda a pilha de forma idempotente.

Casos de uso avançados: composição de recursos e políticas de custo

O Crossplane permite criar CompositeResources que encapsulam múltiplos recursos AWS em um único objeto de alto nível. Por exemplo, um XRCluster que inclui VPC, subnets, EKS, e IAM roles. Essa abstração facilita a reutilização entre ambientes (dev, staging, prod) e reduz a duplicação de YAML.

Além disso, é possível integrar o Crossplane Provider AWS com o Cost Explorer API via um ExternalResource que coleta métricas de custo e as expõe como um ConfigMap. O ArgoCD pode então aplicar políticas de budget guardrails, bloqueando a criação de recursos que excedam limites predefinidos.

Melhores práticas para escalar GitOps na AWS

Ao adotar GitOps em larga escala, siga estas recomendações:

  1. Monorepo vs Multirepo: escolha a estratégia que melhor se alinha ao seu modelo de equipe. Monorepos simplificam a visão global, enquanto multirepos isolam domínios de responsabilidade.
  2. Modularização de manifests: use Kustomize ou Helm para parametrizar VPC CIDRs, tags e nomes de cluster, evitando hard‑coding.
  3. Teste de validação: implemente pipelines de CI que executam kubeval, conftest e crossplane validate antes de mesclar mudanças.
  4. Versionamento de providers: fixe a versão do provider AWS no Crossplane (ex.: crossplane/provider-aws:v0.30.0) para garantir consistência entre ambientes.
  5. Segurança de segredos: armazene credenciais no AWS Secrets Manager e injete-as via ExternalSecret (ex.: external-secrets controller) ao invés de manter Secret estáticos no cluster.

Seguindo essas práticas, a equipe de plataforma pode escalar a entrega de infraestrutura com alta confiabilidade e velocidade.

Conclusão prática: primeiro deploy em 15 minutos

Para validar a pilha, siga este checklist rápido:

  1. Crie um cluster EKS gitops-control (t2.medium).
  2. Instale ArgoCD e Crossplane conforme os blocos de código acima.
  3. Configure o ProviderConfig usando IRSA.
  4. Commit um manifest VPC simples no repositório Git.
  5. Crie a Application ArgoCD apontando para o diretório.
  6. Observe o UI do ArgoCD sincronizar e o Crossplane criar a VPC na AWS.

Se tudo ocorrer como esperado, você terá um pipeline GitOps funcional que provisiona recursos AWS de forma declarativa, auditável e reversível. A partir daí, basta expandir a árvore de manifests para incluir bancos de dados, filas SQS e políticas de segurança, sempre mantendo a fonte da verdade no Git.

Posts Relacionados