Desafio 6: Sync Windows + Break-glass

Configurar janelas de sincronização em um AppProject para bloquear deploys em produção durante o horário comercial, e executar um procedimento de break-glass para forçar um deploy de emergência fora da janela.

Em ambientes de produção, deploys não controlados durante o horário de pico são um risco operacional. O ArgoCD resolve isso com Sync Windows - regras de tempo configuradas no AppProject que controlam quando aplicações podem ou não ser sincronizadas.

Existem dois tipos:

• allow - sync só acontece dentro dessa janela
• deny - sync é bloqueado durante essa janela

No self-managed ArgoCD, você poderia ajustar isso via argocd-cm ConfigMap. No EKS Capabilities, esse ConfigMap não é acessível - a única forma suportada é via spec.syncWindows no AppProject. Isso é um diferencial importante de operação.

O break-glass é o procedimento de emergência: forçar um sync mesmo com a janela bloqueada. No ArgoCD, isso é feito com a flag --bypass-sync-window no CLI, disponível apenas para usuários com role ADMIN.

• AppProject production com deny window de segunda a sexta, das 8h às 18h
• Aplicação associada ao projeto production com sync automático habilitado
• Simular um commit durante a janela bloqueada e observar o sync bloqueado na UI
• Executar break-glass via CLI para forçar o deploy

Configure o AppProject com a Sync Window e valide o comportamento de bloqueio. Em seguida, use o procedimento de break-glass para forçar o sync.

Dica: O cron da Sync Window usa o formato padrão. 0 8 * * 1-5 significa “às 8h de segunda a sexta”. A duração é em horas: 10h cobre das 8h às 18h.

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: production
  namespace: argocd
spec:
  description: "Projeto de produção com janela de deploy controlada"
  sourceRepos:
  - '*'
  destinations:
  - namespace: '*'
    server: '*'
  sourceNamespaces:
  - argocd
  clusterResourceWhitelist:
  - group: '*'
    kind: '*'
  syncWindows:
  - kind: deny
    schedule: "0 8 * * 1-5"
    duration: 10h
    applications:
    - "*"
    namespaces:
    - "*"
    clusters:
    - "*"
    manualSync: false

kubectl apply -f production-project.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: minha-app-prod
  namespace: argocd
spec:
  project: production
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    path: guestbook
    targetRevision: HEAD
  destination:
    name: in-cluster
    namespace: guestbook
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

# Verificar sync windows ativas
argocd proj windows list production

# Requer role ADMIN no ArgoCD
argocd app sync minha-app-prod --bypass-sync-window

syncWindows:
- kind: allow
  schedule: "0 22 * * 5"   # sexta às 22h
  duration: 6h              # até sábado às 4h
  applications:
  - "*"

Por padrão, o ArgoCD EKS Capability faz polling dos repositórios a cada 6 minutos - diferente do self-managed que é 3 minutos. Para ambientes onde velocidade de feedback importa, configure webhooks para sync em segundos.

O endpoint do webhook no EKS Capabilities segue o padrão:

https://<seu-argocd-server>.eks-capabilities.<region>.amazonaws.com/api/webhook

Dica: A URL completa do seu ArgoCD está disponível no EKS Console em Clusters → Capabilities → Argo CD, ou via CLI:

aws eks describe-capability \
  --cluster-name meu-cluster \
  --capability-name meu-cluster-argocd \
  --query 'capability.configuration.argoCd.serverUrl' \
  --output text

{
  "source": ["aws.codecommit"],
  "detail-type": ["CodeCommit Repository State Change"],
  "detail": {
    "event": ["referenceUpdated"],
    "repositoryName": ["meu-repo"]
  }
}

• Configurar Sync Windows por namespace para granularidade maior
• Integrar com EventBridge para notificar o time quando break-glass é acionado
• Combinar com AppProject RBAC para restringir quem pode fazer break-glass