**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](create-argocd-capability.md)), é 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
```
**nota**
Para obter informações sobre a configuração da CLI do Argo CD para trabalho com a funcionalidade do Argo CD no EKS, consulte [Uso da CLI do Argo CD com a funcionalidade gerenciada](argocd-comparison.md#argocd-cli-configuration).
Como alternativa, registre o cluster usando um Kubernetes Secret (consulte [Registro de clusters de destino](argocd-register-clusters.md) 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](argocd-configure-repositories.md) 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](argocd-configure-repositories.md).
### 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).
**nota**
Ao usar a CLI do Argo CD com o recurso gerenciado, especifique as aplicações com o prefixo do namespace: `argocd app get argocd/guestbook`.
**nota**
Use o nome do cluster em `destination.name` (o nome que você utilizou ao registrar o cluster). A funcionalidade gerenciada não oferece suporte ao padrão local “in-cluster” (`kubernetes.default.svc`).
## 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:
+ **Declarativo**: o estado desejado é declarado usando manifestos no formato YAML, charts do Helm ou sobreposições do Kustomize
+ **Versionado**: cada alteração é rastreada com uma trilha de auditoria completa
+ **Automatizado** o Argo CD monitora continuamente as origens e sincroniza as alterações automaticamente
+ **Autorreparação**: detecta e corrige desvios entre o estado desejado e o estado atual do cluster
**Tipos de origem com suporte**:
+ **Repositórios do Git**: GitHub, GitLab, Bitbucket, CodeCommit (HTTPS, SSH ou CodeConnections)
+ **Registros do Helm**: registros HTTP (como `https://aws.github.io/eks-charts`) e registros OCI (como `public.ecr.aws`)
+ **Imagens OCI**: imagens de contêiner contendo manifestos ou charts do Helm (como `oci://registry-1.docker.io/user/my-app`)
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](https://argo-cd.readthedocs.io/en/stable/user-guide/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:
1. Realiza a verificação de alterações nas origens (padrão: a cada seis minutos)
1. Compara o estado desejado com o estado do cluster
1. Marca as aplicações como `Synced` ou `OutOfSync`
1. Sincroniza as alterações automaticamente (se configurado) ou aguarda aprovação manual
1. Monitora a integridade do recurso após a sincronização
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
```
**nota**
A funcionalidade gerenciada usa o rastreamento de recursos baseado em anotações (em vez de empregar o rastreamento baseado em rótulos) para obter melhor compatibilidade com as convenções do Kubernetes e com as outras ferramentas.
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](https://argo-cd.readthedocs.io/en/stable/user-guide/sync-waves/).
### Integridade da aplicação
O Argo CD monitora a integridade de todos os recursos da aplicação:
**Status de integridade**: \$1 **Íntegro**: todos os recursos estão sendo executados conforme o esperado \$1 **Em progresso**: os recursos estão sendo criados ou atualizados \$1 **Degradado**: alguns recursos não estão íntegros (por exemplo, pods falhando e trabalhos com erros) \$1 **Suspenso**: a aplicação está pausada intencionalmente \$1 **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](https://argo-cd.readthedocs.io/en/stable/operator-manual/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: \$1 Controle e visibilidade centralizados \$1 Políticas consistentes em todos os clusters \$1 Apenas uma instância do Argo CD para gerenciamento \$1 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: \$1 Isolamento de clusters (portanto, uma falha não afeta os demais) \$1 Rede simplificada (sem necessidade de comunicação entre clusters) \$1 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](argocd-considerations.md).
### Projetos
Os Projects fornecem agrupamento lógico e controle de acesso para as Applications:
+ **Restrições de origem**: limitam quais repositórios do Git podem ser utilizados
+ **Restrições de destino**: limitam quais clusters e namespaces podem ser destinos de implantação
+ **Restrições de recursos**: limitam quais tipos de recursos do Kubernetes podem ser implantados
+ **Integração com o RBAC**: mapeia projetos para IDs de usuários e de grupos do Centro de Identidade da AWS
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](argocd-permissions.md).
### Opções de sincronização
Realize um ajuste fino do comportamento de sincronização com estas opções conhecidas:
+ `CreateNamespace=true`: cria automaticamente o namespace de destino
+ `ServerSideApply=true`: usa o Server-Side Apply para obter uma melhor resolução de conflitos
+ `SkipDryRunOnMissingResource=true`: ignora a simulação quando as CRDs ainda não existem (sendo útil para instâncias do kro)
```
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](https://argo-cd.readthedocs.io/en/stable/user-guide/sync-options/).
## Próximas etapas
+ [Configuração do acesso ao repositório](argocd-configure-repositories.md): configure o acesso ao repositório do Git
+ [Registro de clusters de destino](argocd-register-clusters.md): registre os clusters de destino para a implantação
+ [Criação de Applications](argocd-create-application.md): crie sua primeira Application
+ [Considerações sobre o Argo CD](argocd-considerations.md): acesse os padrões específicos para EKS, a integração com o Centro de Identidade e a configuração de diversos clusters
+ [Documentação do Argo CD](https://argo-cd.readthedocs.io/en/stable/): acesse a documentação abrangente do Argo CD, incluindo hooks de sincronização, verificações de integridade e padrões avançados