Ajudar a melhorar esta página

Para contribuir com este guia de usuário, escolha o link Editar esta página no GitHub, disponível no painel direito de cada página.

Conceitos do Argo CD

O Argo CD implementa o GitOps ao tratar o Git como a única fonte de verdade para as implantações da aplicação. Este tópico apresenta um exemplo prático e, em seguida, explica os conceitos fundamentais que você precisa entender ao trabalhar com a funcionalidade do EKS para o Argo CD.

Conceitos básicos do Argo CD

Após criar a funcionalidade do Argo CD (consulte Criar um recurso Argo CD), é possível começar a implantar as aplicações. Este exemplo demonstra o registro de um cluster e a criação de uma Application.

Etapa 1: Configurar

Registrar o cluster (obrigatório)

Registre o cluster no local em que você deseja implantar aplicações. Para este exemplo, registraremos o mesmo cluster em que o Argo CD está sendo executado (você pode usar o nome in-cluster para obter compatibilidade com a maioria dos exemplos do Argo CD):

# Get your cluster ARN
CLUSTER_ARN=$(aws eks describe-cluster \
  --name my-cluster \
  --query 'cluster.arn' \
  --output text)

# Register the cluster using Argo CD CLI
argocd cluster add $CLUSTER_ARN \
  --aws-cluster-name $CLUSTER_ARN \
  --name in-cluster \
  --project default

Como alternativa, registre o cluster usando um Kubernetes Secret (consulte Registro de clusters de destino para obter mais detalhes).

Configurar o acesso ao repositório (opcional)

Este exemplo utiliza um repositório público do GitHub, portanto, nenhuma configuração de repositório é necessária. Para repositórios privados, configure o acesso usando o AWS Secrets Manager, o CodeConnections ou o Kubernetes Secrets (consulte Configuração do acesso ao repositório para obter mais detalhes).

No caso de serviços da AWS (como ECR para charts do Helm, CodeConnections e CodeCommit), é possível referenciá-los diretamente nos recursos da Application sem precisar criar um Repository. O perfil da funcionalidade deve ter as permissões do IAM necessárias. Para mais detalhes, consulte Configuração do acesso ao repositório.

Etapa 2: criar um aplicativo

Crie este manifesto da Application em my-app.yaml:

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

Aplique a Application:

kubectl apply -f my-app.yaml

Após aplicar esta Application, o Argo CD: 1. Sincroniza a aplicação do Git com o cluster (implantação inicial) 2. Monitora o repositório do Git em busca de alterações 3. Sincroniza automaticamente as alterações posteriores com o seu cluster 4. Detecta e corrige qualquer desvio em relação ao estado desejado 5. Fornece o status da integridade e o histórico de sincronização na interface do usuário

Visualize o status da aplicação:

kubectl get application guestbook -n argocd

Também é possível visualizar a aplicação usando a CLI do Argo CD ou a interface do usuário do Argo CD (que é acessível a partir do console do EKS, na guia Funcionalidades do seu cluster).

Conceitos principais

Princípios de GitOps e tipos de origem

O Argo CD implementa o GitOps, no qual a origem da sua aplicação é a única fonte de verdade para as implantações:

Tipos de origem com suporte:

Essa flexibilidade permite que as organizações escolham origens que atendam aos seus requisitos de segurança e conformidade. Por exemplo, organizações que restringem o acesso ao Git proveniente de clusters podem usar o ECR para charts do Helm ou imagens OCI.

Para obter mais informações, consulte Application Sources na documentação do Argo CD.

Sincronização e reconciliação

O Argo CD monitora continuamente as origens e os clusters para detectar e corrigir diferenças:

Os ciclos de sincronização controlam a ordem de criação de recursos usando anotações:

metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "0"  # Default if not specified

Os recursos são aplicados na ordem do ciclo (com números menores primeiro, incluindo números negativos como -1). O ciclo 0 é o padrão, caso não seja especificado. Isso permite a criação de dependências, como namespaces (ciclo -1) antes das implantações (ciclo 0) antes dos serviços (ciclo 1).

A autorreparação reverte automaticamente as alterações manuais:

spec:
  syncPolicy:
    automated:
      selfHeal: true

Para obter informações detalhadas sobre as fases de sincronização, os hooks e os padrões avançados, consulte a documentação de sincronização do Argo CD.

Integridade da aplicação

O Argo CD monitora a integridade de todos os recursos da aplicação:

Status de integridade: * Íntegro: todos os recursos estão sendo executados conforme o esperado * Em progresso: os recursos estão sendo criados ou atualizados * Degradado: alguns recursos não estão íntegros (por exemplo, pods falhando e trabalhos com erros) * Suspenso: a aplicação está pausada intencionalmente * Ausente: os recursos definidos no Git não estão presentes no cluster

O Argo CD conta com verificações de integridade integradas para recursos comuns do Kubernetes (por exemplo, Deployments, StatefulSets, Jobs e outros) e oferece suporte a verificações de integridade personalizadas para CRDs.

A saúde da aplicação é determinada por todos os seus recursos. Dessa forma, se qualquer recurso estiver no estado Degraded, a aplicação será considerada Degraded.

Para obter mais informações, consulte Resource Health na documentação do Argo CD.

Padrões de diversos clusters

O Argo CD é compatível com dois padrões principais de implantação:

Hub-and-spoke: execute o Argo CD em um cluster de gerenciamento dedicado que realiza a implantação para diversos clusters de workloads: * Controle e visibilidade centralizados * Políticas consistentes em todos os clusters * Apenas uma instância do Argo CD para gerenciamento * Separação clara entre o ambiente de gerenciamento e as workloads

Por cluster: execute o Argo CD em cada cluster, gerenciando apenas as aplicações daquele cluster específico: * Isolamento de clusters (portanto, uma falha não afeta os demais) * Rede simplificada (sem necessidade de comunicação entre clusters) * Configuração inicial simplificada (sem necessidade de registro de clusters)

Escolha o modelo hub-and-spoke para equipes de plataformas que gerenciam muitos clusters ou o modelo por cluster para equipes independentes ou quando os clusters precisarem de isolamento total.

Para obter configurações detalhadas de diversos clusters, consulte Considerações sobre o Argo CD.

Projetos

Os Projects fornecem agrupamento lógico e controle de acesso para as Applications:

As Applications pertencem a um único projeto. Se não for especificado, elas utilizarão o projeto default, que não conta com restrições por padrão. Para uso em produção, edite o projeto default para restringir o acesso e criar novos projetos com as restrições apropriadas.

Para obter as configurações de projetos e os padrões de RBAC, consulte Configuração das permissões do Argo CD.

Opções de sincronização

Realize um ajuste fino do comportamento de sincronização com estas opções conhecidas:

spec:
  syncPolicy:
    syncOptions:
    - CreateNamespace=true
    - ServerSideApply=true
    - SkipDryRunOnMissingResource=true

Para obter uma lista completa de opções de sincronização, consulte a documentação de opções de sincronização do Argo CD.

Próximas etapas