**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.
# Implantação contínua com o Argo CD
O Argo CD é uma ferramenta de entrega contínua declarativa e baseada em GitOps para Kubernetes. Com o Argo CD, você pode automatizar a implantação e o gerenciamento do ciclo de vida de suas aplicações em vários clusters e ambientes. O Argo CD oferece suporte a vários tipos de origem, incluindo repositórios do Git, registros do Helm (HTTP e OCI) e imagens OCI, proporcionando flexibilidade para organizações com requisitos de segurança e conformidade distintos.
Com as funcionalidades do EKS, o Argo CD é totalmente gerenciado pela AWS, o que elimina a necessidade de instalação, manutenção e escalabilidade dos controladores do Argo CD e de suas dependências nos clusters.
## Funcionamento do Argo CD
O Argo CD segue o padrão de GitOps, no qual a origem da sua aplicação (por exemplo, repositório do Git, registro do Helm ou imagem OCI) é a fonte da verdade para definir o estado desejado da aplicação. Ao criar um recurso `Application` do Argo CD, você especifica a origem que contém os manifestos da aplicação e o cluster e o namespace do Kubernetes de destino. O Argo CD monitora continuamente tanto a origem quanto o estado em execução no cluster, sincronizando automaticamente quaisquer alterações para garantir que o estado do cluster corresponda ao estado desejado.
**nota**
Com a funcionalidade do EKS para o Argo CD, o software do Argo CD é executado no ambiente de gerenciamento da AWS, e não em seus nós de processamento. Isso significa que os nós de processamento não precisam de acesso direto a repositórios do Git ou a registros do Helm, pois a funcionalidade gerencia o acesso à origem a partir da conta da AWS.
O Argo CD fornece três tipos de recursos primários:
+ **Application**: define uma implantação proveniente de um repositório do Git para um cluster de destino
+ **ApplicationSet**: gera diversas Applications usando modelos para implantações em vários clusters
+ **AppProject**: fornece agrupamento lógico e controle de acesso para as Applications
**Exemplo: criação de uma Application do Argo CD**
O exemplo a seguir mostra como criar um recurso `Application` do Argo CD:
```
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
```
**nota**
Use `destination.name` com o nome do cluster utilizado ao registrar o cluster (como `in-cluster` para o cluster local). O campo `destination.server` também funciona com ARNs de cluster de EKS, mas o uso de nomes de cluster é recomendado para melhor legibilidade.
## Benefícios do Argo CD
O Argo CD implementa um fluxo de trabalho de GitOps no qual você define as configurações da aplicação em repositórios do Git e o Argo CD sincroniza automaticamente as aplicações para corresponderem ao estado desejado. Essa abordagem centrada no Git fornece uma trilha de auditoria completa de todas as alterações, permite reversões fáceis e integra-se naturalmente aos seus processos existentes de revisão e aprovação de código. O Argo CD detecta e reconcilia automaticamente o desvio entre o estado desejado no Git e o estado real nos clusters, garantindo que as implantações permaneçam consistentes com a configuração declarada.
Com o Argo CD, é possível implantar e gerenciar aplicações em vários clusters usando uma única instância do Argo CD, simplificando as operações em ambientes com vários clusters e diversas regiões. A interface do usuário do Argo CD fornece funcionalidades de visualização e monitoramento, permitindo que você visualize o status da implantação, a integridade e o histórico das aplicações. A interface do usuário se integra ao Centro de Identidade da AWS (anteriormente AWS SSO) para autenticação e autorização simplificadas, permitindo que você controle o acesso com a infraestrutura de gerenciamento de identidades existente.
Como parte das funcionalidades gerenciadas do EKS, o Argo CD é totalmente gerenciado pela AWS, eliminando a necessidade de instalar, configurar e manter a infraestrutura do Argo CD. A AWS cuida da escalabilidade, da aplicação de patches e do gerenciamento operacional, permitindo que as equipes se concentrem na entrega de aplicações em vez da manutenção de ferramentas.
## Integração com o Centro de Identidade da AWS
As funcionalidades gerenciadas do EKS fornecem integração direta entre o Argo CD e o Centro de Identidade da AWS, permitindo autenticação e autorização simplificadas para os usuários. Ao habilitar a funcionalidade do Argo CD, é possível configurar a integração com o Centro de Identidade da AWS para mapear grupos e usuários do Centro de Identidade para perfis de RBAC do Argo CD, permitindo controlar quem pode acessar e gerenciar aplicações no Argo CD.
## Integração com outras funcionalidades gerenciadas do EKS
O Argo CD pode ser integrado a outras funcionalidades gerenciadas do EKS.
+ **AWS Controllers for Kubernetes (ACK)**: use o Argo CD para gerenciar a implantação de recursos do ACK em diversos clusters, possibilitando fluxos de trabalho de GitOps para a infraestrutura da AWS.
+ **kro (Kube Resource Orchestrator)**: use o Argo CD para implantar composições do kro em vários clusters, possibilitando uma composição de recursos consistente em todo o seu ambiente do Kubernetes.
## Conceitos básicos do Argo CD
Para começar a usar a funcionalidade do EKS para o Argo CD:
1. Crie e configure um perfil da funcionalidade do IAM com as permissões necessárias para que o Argo CD acesse suas fontes e gerencie aplicações
1. [Crie um recurso da funcionalidade do Argo CD](create-argocd-capability.md) em seu cluster de EKS por meio do Console da AWS, da AWS CLI ou da ferramenta de infraestrutura como código de sua preferência.
1. Configure o acesso ao repositório e registre os clusters para a implantação de aplicações.
1. Crie recursos de Application para implantar suas aplicações usando fontes declarativas.
# Criar um recurso Argo CD
Este tópico explica como criar uma funcionalidade do Argo CD no cluster do Amazon EKS.
## Pré-requisitos
Antes de criar uma funcionalidade do Argo CD, certifique-se de ter:
+ Um cluster do Amazon EKS existente executando uma versão compatível do Kubernetes (há suporte para todas as versões nos períodos de suporte padrão e estendido)
+ **Centro de Identidade da AWS configurado**: necessário para a autenticação do Argo CD (não há suporte para usuários locais)
+ Um perfil do IAM da funcionalidade com permissões para o Argo CD
+ Permissões do IAM suficientes para criar recursos de funcionalidades em clusters de EKS
+ `kubectl` configurado para o estabelecimento de comunicação com o cluster
+ (Opcional) A CLI do Argo CD instalada para facilitar o gerenciamento de clusters e repositórios
+ (Para a CLI ou o eksctl) A ferramenta de CLI apropriada instalada e configurada
Para obter instruções sobre como criar o perfil do IAM para a funcionalidade, consulte [Perfil do IAM para a funcionalidade do Amazon EKS](capability-role.md). Para obter a configuração do Centro de Identidade, consulte [Conceitos básicos do Centro de Identidade da AWS](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html).
**Importante**
O perfil do IAM para a funcionalidade que você fornece determina quais recursos da AWS o Argo CD pode acessar. Isso inclui o acesso a repositórios do Git por meio do CodeConnections e a segredos no Secrets Manager. Para obter orientações sobre como criar um perfil apropriado com permissões de privilégio mínimo, consulte [Perfil do IAM para a funcionalidade do Amazon EKS](capability-role.md) e [Considerações sobre segurança para funcionalidades do EKS](capabilities-security.md).
## Escolha da ferramenta
É possível criar uma funcionalidade do Argo CD por meio do Console de gerenciamento da AWS, da AWS CLI ou do eksctl:
+ [Criação de uma funcionalidade do Argo CD por meio do Console](argocd-create-console.md): use o Console para obter uma experiência guiada
+ [Criação de uma funcionalidade do Argo CD por meio da AWS CLI](argocd-create-cli.md): use a AWS CLI para obter scripts e automação
+ [Criação de uma funcionalidade do Argo CD por meio do eksctl](argocd-create-eksctl.md): use o eksctl para obter uma experiência nativa do Kubernetes
## O que ocorre durante a criação de uma funcionalidade do Argo CD
Ao criar uma funcionalidade do Argo CD:
1. O EKS cria o serviço da funcionalidade do Argo CD no ambiente de gerenciamento da AWS
1. As definições de recursos personalizados (CRDs, na sigla em inglês) são instaladas no cluster
1. Uma entrada de acesso é criada automaticamente para seu perfil de funcionalidade do IAM com políticas de entrada de acesso específicas de recursos que concedem permissões básicas do Kubernetes (consulte [Considerações sobre segurança para funcionalidades do EKS](capabilities-security.md))
1. O Argo CD começa a monitorar os recursos personalizados (ApplicationSets, AppProjects)
1. O status da funcionalidade é alterado de `CREATING` para `ACTIVE`
1. A interface de usuário do Argo CD torna-se acessível por meio de seu URL
Uma vez ativa, será possível criar Applications do Argo CD no seu cluster para realizar implantações a partir das suas fontes declarativas.
**nota**
A entrada de acesso criada automaticamente não concede permissões para implantar aplicações em clusters. Para implantar aplicações, é necessário configurar permissões de RBAC adicionais do Kubernetes para cada cluster de destino. Consulte [Registro de clusters de destino](argocd-register-clusters.md) para obter detalhes sobre como registrar clusters e configurar o acesso.
## Próximas etapas
Após criar a funcionalidade do Argo CD:
+ [Conceitos do Argo CD](argocd-concepts.md): aprenda sobre os princípios de GitOps, as políticas de sincronização e os padrões para vários clusters
+ [Como trabalhar com o Argo CD](working-with-argocd.md): configure o acesso ao repositório, registre os clusters de destino e crie Applications
+ [Considerações sobre o Argo CD](argocd-considerations.md): conheça os padrões de arquitetura de vários clusters e a configuração avançada
# Criação de uma funcionalidade do Argo CD por meio do Console
Este tópico descreve como criar uma funcionalidade do Argo CD usando o Console de gerenciamento da AWS.
## Pré-requisitos
+ **Centro de Identidade da AWS configurado**: o Argo CD requer o Centro de Identidade da AWS para autenticação. Não há suporte para usuários locais. Se você não tiver o Centro de Identidade da AWS configurado, consulte [Conceitos básicos do Centro de Identidade da AWS](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html) para criar uma instância do Centro de Identidade, e [Adicionar usuários](https://docs.aws.amazon.com/singlesignon/latest/userguide/addusers.html) e [Adicionar grupos](https://docs.aws.amazon.com/singlesignon/latest/userguide/addgroups.html) para criar usuários e grupos para acesso ao Argo CD.
## Criação da funcionalidade do Argo CD
1. Abra o console do Amazon EKS em https://console.aws.amazon.com/eks/home\$1/clusters.
1. Selecione o nome do cluster para abrir a página de detalhes do cluster.
1. Escolha a guia **Funcionalidades**.
1. Na barra de navegação à esquerda, selecione **Argo CD**.
1. Escolha **Criar funcionalidade do Argo CD**.
1. No **perfil da funcionalidade do IAM**:
+ Se você já tiver um perfil da funcionalidade do IAM, selecione-o no menu suspenso
+ Se a criação de um perfil for necessária, escolha **Criar perfil do Argo CD**
Isso abre o console do IAM em uma nova guia com a política de confiança preenchida previamente e fornece acesso total de leitura ao Secrets Manager. Nenhuma outra permissão é adicionada por padrão, mas você pode adicioná-las se necessário. Se você planeja usar repositórios do CodeCommit ou outros serviços da AWS, adicione as permissões adequadas antes de criar o perfil.
Após criar o perfil, retorne ao console do EKS e o perfil será selecionado automaticamente.
**nota**
Se você planeja usar as integrações opcionais com o AWS Secrets Manager ou o AWS CodeConnections, precisará adicionar permissões ao perfil. Para obter exemplos da política do IAM e de orientações de configuração, consulte [Gerenciamento de segredos de aplicações com o AWS Secrets Manager](integration-secrets-manager.md) e [Estabelecimento de conexão com repositórios do Git usando o AWS CodeConnections](integration-codeconnections.md).
1. Configure a integração com o Centro de Identidade da AWS:
1. Selecione **Habilitar integração com o Centro de Identidade da AWS**.
1. Escolha sua instância do Centro de Identidade no menu suspenso.
1. Configure os mapeamentos de perfil para RBAC atribuindo usuários ou grupos aos perfis do Argo CD (ADMIN, EDITOR ou VIEWER).
1. Escolha **Criar**.
O processo de criação da funcionalidade é iniciado.
## Verificação da ativação da funcionalidade
1. Na guia **Funcionalidades**, visualize o status da funcionalidade do Argo CD.
1. Aguarde até que o status mude de `CREATING` para `ACTIVE`.
1. Assim que estiver com o status ativo, a funcionalidade estará pronta para uso.
Para obter informações sobre os status das funcionalidades e sobre a solução de problemas, consulte [Como trabalhar com recursos de funcionalidade](working-with-capabilities.md).
## Acesso à interface do usuário do Argo CD
Depois que a funcionalidade estiver ativa, você poderá acessar a interface do usuário do Argo CD:
1. Na página da funcionalidade do Argo CD, escolha **Abrir interface do usuário do Argo CD**.
1. A interface do usuário do Argo CD será aberta em uma nova guia do navegador.
1. Em seguida, você pode criar Applications e gerenciar implantações por meio da interface do usuário.
## Próximas etapas
+ [Como trabalhar com o Argo CD](working-with-argocd.md): configure repositórios, registre clusters e crie Applications
+ [Considerações sobre o Argo CD](argocd-considerations.md): acesse a arquitetura de vários clusters e a configuração avançada
+ [Como trabalhar com recursos de funcionalidade](working-with-capabilities.md): gerencie os recursos da funcionalidade do Argo CD
# Criação de uma funcionalidade do Argo CD por meio da AWS CLI
Este tópico descreve como criar uma funcionalidade do Argo CD usando a AWS CLI.
## Pré-requisitos
+ **AWS CLI**: versão `2.12.3` ou em versões posteriores. Para verificar a versão, execute `aws --version`. Para obter mais informações, consulte [Instalação](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) no Guia do Usuário da Interface de Linha de Comando AWS.
+ ** `kubectl` ** – uma ferramenta de linha de comando para trabalhar com clusters do Kubernetes. Para obter mais informações, consulte [Configurar o `kubectl` e o `eksctl`](install-kubectl.md).
+ **Centro de Identidade da AWS configurado**: o Argo CD requer o Centro de Identidade da AWS para autenticação. Não há suporte para usuários locais. Se você não tiver o Centro de Identidade da AWS configurado, consulte [Conceitos básicos do Centro de Identidade da AWS](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html) para criar uma instância do Centro de Identidade, e [Adicionar usuários](https://docs.aws.amazon.com/singlesignon/latest/userguide/addusers.html) e [Adicionar grupos](https://docs.aws.amazon.com/singlesignon/latest/userguide/addgroups.html) para criar usuários e grupos para acesso ao Argo CD.
## Etapa 1: criação de um perfil da funcionalidade do IAM
Crie um arquivo de política de confiança:
```
cat > argocd-trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "capabilities.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
EOF
```
Crie o perfil do IAM:
```
aws iam create-role \
--role-name ArgoCDCapabilityRole \
--assume-role-policy-document file://argocd-trust-policy.json
```
**nota**
Se você planeja usar as integrações opcionais com o AWS Secrets Manager ou o AWS CodeConnections, precisará adicionar permissões ao perfil. Para obter exemplos da política do IAM e de orientações de configuração, consulte [Gerenciamento de segredos de aplicações com o AWS Secrets Manager](integration-secrets-manager.md) e [Estabelecimento de conexão com repositórios do Git usando o AWS CodeConnections](integration-codeconnections.md).
## Etapa 2: criação da funcionalidade do Argo CD
Crie o recurso da funcionalidade do Argo CD no cluster.
Primeiro, defina as variáveis de ambiente para a sua configuração do Centro de Identidade:
```
# Get your Identity Center instance ARN (replace region if your IDC instance is in a different region)
export IDC_INSTANCE_ARN=$(aws sso-admin list-instances --region [.replaceable]`region` --query 'Instances[0].InstanceArn' --output text)
# Get a user ID for RBAC mapping (replace with your username and region if needed)
export IDC_USER_ID=$(aws identitystore list-users \
--region [.replaceable]`region` \
--identity-store-id $(aws sso-admin list-instances --region [.replaceable]`region` --query 'Instances[0].IdentityStoreId' --output text) \
--query 'Users[?UserName==`your-username`].UserId' --output text)
echo "IDC_INSTANCE_ARN=$IDC_INSTANCE_ARN"
echo "IDC_USER_ID=$IDC_USER_ID"
```
Crie a funcionalidade com integração ao Centro de Identidade. Substitua *region-code* pela região da AWS em que seu cluster está localizado e *my-cluster* pelo nome do seu cluster e *idc-region-code* pelo código da região em que seu Centro de Identidade do IAM foi configurado:
```
aws eks create-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-argocd \
--type ARGOCD \
--role-arn arn:aws:iam::$(aws sts get-caller-identity --query Account --output text):role/ArgoCDCapabilityRole \
--delete-propagation-policy RETAIN \
--configuration '{
"argoCd": {
"awsIdc": {
"idcInstanceArn": "'$IDC_INSTANCE_ARN'",
"idcRegion": "'[.replaceable]`idc-region-code`'"
},
"rbacRoleMappings": [{
"role": "ADMIN",
"identities": [{
"id": "'$IDC_USER_ID'",
"type": "SSO_USER"
}]
}]
}
}'
```
O comando é concluído de imediato, mas a funcionalidade demora algum tempo para se tornar ativa, conforme o EKS cria a infraestrutura e os componentes necessários para a funcionalidade. O EKS instalará as definições de recursos personalizados do Kubernetes relacionadas a essa funcionalidade no cluster durante o processo de criação.
**nota**
Caso ocorra um erro indicando a inexistência do cluster ou falta de permissões, verifique o seguinte:
Se o nome do cluster está correto
Se a AWS CLI está configurada para a região correta
Se você tem as permissões do IAM obrigatórias
## Etapa 3: verificação da ativação da funcionalidade
Aguarde até que a funcionalidade se torne ativa. Substitua *region-cod*e pela região da AWS em que seu cluster está localizado e *my-cluster* pelo nome do seu cluster.
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-argocd \
--query 'capability.status' \
--output text
```
A funcionalidade estará pronta assim que o status mostrar `ACTIVE`. Não prossiga para a próxima etapa até que o status seja `ACTIVE`.
Também é possível visualizar os detalhes completos da funcionalidade:
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-argocd
```
## Etapa 4: verificação da disponibilidade de recursos personalizados
Após a funcionalidade estar ativa, verifique se os recursos personalizados do Argo CD estão disponíveis no cluster:
```
kubectl api-resources | grep argoproj.io
```
Os tipos de recursos `Application` e `ApplicationSet` devem aparecer na lista apresentada.
## Próximas etapas
+ [Como trabalhar com o Argo CD](working-with-argocd.md): configure repositórios, registre clusters e crie Applications
+ [Considerações sobre o Argo CD](argocd-considerations.md): acesse a arquitetura de vários clusters e a configuração avançada
+ [Como trabalhar com recursos de funcionalidade](working-with-capabilities.md): gerencie os recursos da funcionalidade do Argo CD
# Criação de uma funcionalidade do Argo CD por meio do eksctl
Este tópico descreve como criar uma funcionalidade do Argo CD usando o eksctl.
**nota**
Para realizar as etapas seguintes, é necessário estar utilizando o eksctl na versão `0.220.0` ou em versões posteriores. Para verificar a versão, execute `eksctl version`.
## Etapa 1: criação de um perfil da funcionalidade do IAM
Crie um arquivo de política de confiança:
```
cat > argocd-trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "capabilities.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
EOF
```
Crie o perfil do IAM:
```
aws iam create-role \
--role-name ArgoCDCapabilityRole \
--assume-role-policy-document file://argocd-trust-policy.json
```
**nota**
Para esta configuração básica, não são necessárias políticas do IAM adicionais. Se você planeja usar o Secrets Manager para credenciais de repositório ou para o CodeConnections, precisará adicionar permissões ao perfil. Para obter exemplos da política do IAM e de orientações de configuração, consulte [Gerenciamento de segredos de aplicações com o AWS Secrets Manager](integration-secrets-manager.md) e [Estabelecimento de conexão com repositórios do Git usando o AWS CodeConnections](integration-codeconnections.md).
## Etapa 2: obtenção da configuração do Centro de Identidade da AWS
Obtenha o ARN da instância do Centro de Identidade e o ID do usuário para a configuração de RBAC:
```
# Get your Identity Center instance ARN
aws sso-admin list-instances --query 'Instances[0].InstanceArn' --output text
# Get a user ID for admin access (replace 'your-username' with your Identity Center username)
aws identitystore list-users \
--identity-store-id $(aws sso-admin list-instances --query 'Instances[0].IdentityStoreId' --output text) \
--query 'Users[?UserName==`your-username`].UserId' --output text
```
Anote esses valores. Você precisará deles na próxima etapa.
## Etapa 3: criação de um arquivo de configuração do eksctl
Crie um arquivo chamado `argocd-capability.yaml` com o conteúdo a seguir. Substitua os valores com espaços reservados pelo nome do seu cluster, região, ARN do perfil do IAM, ARN da instância do Centro de Identidade, região do Centro de Identidade e ID do usuário:
```
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: my-cluster
region: cluster-region-code
capabilities:
- name: my-argocd
type: ARGOCD
roleArn: arn:aws:iam::[.replaceable]111122223333:role/ArgoCDCapabilityRole
deletePropagationPolicy: RETAIN
configuration:
argocd:
awsIdc:
idcInstanceArn: arn:aws:sso:::instance/ssoins-123abc
idcRegion: idc-region-code
rbacRoleMappings:
- role: ADMIN
identities:
- id: 38414300-1041-708a-01af-5422d6091e34
type: SSO_USER
```
**nota**
É possível adicionar vários usuários ou grupos aos mapeamentos de RBAC. Para grupos, use `type: SSO_GROUP` e forneça o ID do grupo. Os perfis disponíveis são `ADMIN`, `EDITOR` e `VIEWER`.
## Etapa 4: criação da funcionalidade do Argo CD
Aplique o arquivo de configuração:
```
eksctl create capability -f argocd-capability.yaml
```
O comando é executado de forma imediata, mas a funcionalidade demora algum tempo para se tornar ativa.
## Etapa 5: verificação da ativação da funcionalidade
Verifique o status da funcionalidade. Substitua *region-code* pela região AWS em que seu cluster se encontra e substitua *my-cluster* pelo nome do seu cluster.
```
eksctl get capability \
--region region-code \
--cluster my-cluster \
--name my-argocd
```
A funcionalidade estará pronta assim que o status mostrar `ACTIVE`.
## Etapa 6: verificação da disponibilidade de recursos personalizados
Após a funcionalidade estar ativa, verifique se os recursos personalizados do Argo CD estão disponíveis no cluster:
```
kubectl api-resources | grep argoproj.io
```
Os tipos de recursos `Application` e `ApplicationSet` devem aparecer na lista apresentada.
## Próximas etapas
+ [Como trabalhar com o Argo CD](working-with-argocd.md): aprenda a criar e gerenciar Applications do Argo CD
+ [Considerações sobre o Argo CD](argocd-considerations.md): configure o SSO e o acesso a vários clusters
+ [Como trabalhar com recursos de funcionalidade](working-with-capabilities.md): gerencie os recursos da funcionalidade do Argo CD
# 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
# Configuração das permissões do Argo CD
A funcionalidade gerenciada do Argo CD se integra ao Centro de Identidade da AWS para autenticação e usa perfis de RBAC integrados para autorização. Este tópico explica como configurar permissões para usuários e equipes.
## Funcionamento de permissões com o Argo CD
A funcionalidade do Argo CD usa o Centro de Identidade da AWS para autenticação e fornece três perfis de RBAC integrados para autorização.
Quando um usuário acessa o Argo CD:
1. A autenticação é realizada por meio do Centro de Identidade da AWS (que pode ser federado ao seu provedor de identidades corporativo)
1. O Centro de Identidade da AWS fornece informações de usuários e grupos ao Argo CD
1. O Argo CD mapeia usuários e grupos para perfis de RBAC com base na sua configuração
1. Os usuários visualizam somente as aplicações e os recursos aos quais têm permissão de acessar
## Perfis de RBAC integrados
A funcionalidade do Argo CD fornece três perfis integrados que você mapeia para usuários e grupos do Centro de Identidade da AWS. Esses são **perfis com escopo global** que controlam o acesso aos recursos do Argo CD, como projetos, clusters e repositórios.
**Importante**
Os perfis globais controlam o acesso ao próprio Argo CD, não aos recursos do escopo do projeto, como Applications. Os usuários EDITOR e VIEWER não podem ver nem gerenciar Applications por padrão, eles precisam de perfis no projeto para acessar os recursos do escopo do projeto. Consulte [Perfis do projeto e acesso ao escopo do projeto](#project-roles) para obter detalhes sobre como conceder acesso a Applications e outros recursos do escopo do projeto.
**ADMIN**
Acesso total a todos os recursos e configurações do Argo CD:
+ Criação, atualização e exclusão de Applications e ApplicationSets
+ Gerenciamento da configuração do Argo CD
+ Registro e gerenciamento de clusters de destino para implantação
+ Configuração do acesso ao repositório
+ Crie e gerencie projetos.
+ Visualização do status e do histórico de todas as aplicações
+ Liste e acesse todos os clusters e repositórios
**EDITOR**
Pode atualizar projetos e configurar perfis do projeto, mas não pode alterar as configurações globais do Argo CD:
+ Atualize projetos existentes (não é possível criar ou excluir projetos)
+ Configure perfis e permissões de projetos.
+ Visualize chaves e certificados GPG
+ Não é possível alterar a configuração do Argo CD
+ Não é possível gerenciar clusters ou repositórios diretamente
+ Não é possível ver ou gerenciar Applications sem perfis do projeto
**VIEWER**
Acesso somente de leitura a recursos do Argo CD:
+ Exiba a configuração do projeto
+ Liste todos os projetos (incluindo projetos aos quais o usuário não está atribuído)
+ Visualize chaves e certificados GPG
+ Sem permissão para o registro de clusters ou de repositórios
+ Sem permissão para a realização de quaisquer alterações
+ Não é possível ver ou gerenciar Applications sem perfis do projeto
**nota**
Para conceder aos usuários EDITOR ou VIEWER acesso a Applications, um ADMINISTRADOR ou EDITOR deve criar perfis do projeto que mapeiem os grupos do Centro de Identidade para permissões específicas em um projeto.
## Perfis do projeto e acesso ao escopo do projeto
Perfis globais (ADMIN, EDITOR e VIEWER) controlam o acesso ao Argo CD em si. Os perfis do projeto controlam o acesso a recursos e funcionalidades em um projeto específico, incluindo:
+ **Recursos**: Applications, ApplicationSets, credenciais do repositório, credenciais do cluster
+ **Funcionalidades**: acesso a registros, acesso executivo aos pods de aplicações
**Noções básicas sobre o modelo de permissão de dois níveis**:
+ **Escopo global**: perfis integrados determinam o que os usuários podem fazer com projetos, clusters, repositórios e configurações de CD do Argo
+ **Escopo do projeto**: os perfis do projeto determinam o que os usuários podem fazer com recursos e funcionalidades em um projeto específico
Isso significa que:
+ Os usuários ADMIN podem acessar todos os recursos e funcionalidades do projeto sem configuração adicional
+ Os usuários EDITOR e VIEWER devem receber perfis de projeto para acessar os recursos e funcionalidades do projeto
+ Os usuários EDITOR podem criar perfis do projeto para conceder a si mesmos e a outras pessoas acesso aos projetos que possam ser atualizados
**Exemplo de fluxo de trabalho**
1. Um ADMIN mapeia um grupo do Centro de Identidade para o perfil EDITOR globalmente
1. Um ADMINISTRADOR cria um projeto para uma equipe
1. O EDITOR configura os perfis do projeto dentro desse projeto para conceder aos membros da equipe acesso aos recursos do escopo do projeto
1. Os membros da equipe (que podem ter o perfil global VIEWER) agora podem ver e gerenciar aplicações nesse projeto com base nas permissões de perfil do projeto
Para obter detalhes sobre como configurar os perfis do projeto, consulte [Controle de acesso baseado em projetos](#_project_based_access_control).
## Configuração de mapeamentos de perfil
Mapeie usuários e grupos do Centro de Identidade da AWS para os perfis do Argo CD durante a criação ou a atualização da funcionalidade.
**Exemplo de mapeamento de perfil**:
```
{
"rbacRoleMapping": {
"ADMIN": ["AdminGroup", "alice@example.com"],
"EDITOR": ["DeveloperGroup", "DevOpsTeam"],
"VIEWER": ["ReadOnlyGroup", "bob@example.com"]
}
}
```
**nota**
Os nomes dos perfis diferenciam maiúsculas de minúsculas e devem estar em letras maiúsculas (ADMIN, EDITOR e VIEWER).
**Importante**
A integração das funcionalidades do EKS com o Centro de Identidade da AWS fornece suporte para até mil identidades por funcionalidade do Argo CD. Uma identidade pode ser um usuário ou um grupo.
**Atualize os mapeamentos de perfil**:
```
aws eks update-capability \
--region us-east-1 \
--cluster-name cluster \
--capability-name capname \
--endpoint "https://eks.ap-northeast-2.amazonaws.com" \
--role-arn "arn:aws:iam::[.replaceable]111122223333:role/[.replaceable]`EKSCapabilityRole`" \
--configuration '{
"argoCd": {
"rbacRoleMappings": {
"addOrUpdateRoleMappings": [
{
"role": "ADMIN",
"identities": [
{ "id": "686103e0-f051-7068-b225-e6392b959d9e", "type": "SSO_USER" }
]
}
]
}
}
}'
```
## Uso da conta de administrador
A conta de administrador é destinada à configuração inicial e às tarefas administrativas, como o registro de clusters e a configuração de repositórios.
**Situações apropriadas para o uso da conta de administrador**:
+ Configuração inicial da funcionalidade
+ Desenvolvimento individual ou demonstrações rápidas
+ Tarefas administrativas (como registro de cluster, configuração de repositórios e criação de projetos)
**Práticas recomendadas para a conta de administrador**:
+ Sem permissão para a confirmação de tokens da conta para o controle de versão
+ Rotação imediata de tokens em caso de exposição
+ Limitação do uso de tokens da conta para tarefas de configuração e de administração
+ Definição de prazos curtos de expiração (máximo de 12 horas)
+ Limite de criação de apenas cinco tokens simultâneos na conta
**Situações para uso do acesso baseado em projetos**:
+ Ambientes de desenvolvimento compartilhados com vários usuários
+ Qualquer ambiente com características do ambiente de produção
+ Quando há necessidade de trilhas de auditoria para identificação de ações por parte dos usuários
+ Quando há necessidade da aplicação de restrições de recursos ou limites de acesso
Para ambientes de produção e cenários com vários usuários, use o controle de acesso baseado em projetos com perfis de RBAC dedicados e mapeados para grupos do Centro de Identidade da AWS.
## Controle de acesso baseado em projetos
Use o Argo CD Projects (AppProject) para a disponibilização de controle de acesso detalhado e isolamento de recursos para as equipes.
**Importante**
Antes de atribuir usuários ou grupos aos perfis específicos do projeto, é necessário primeiro mapeá-los para um perfil global do Argo CD (ADMIN, EDITOR ou VIEWER) na configuração do recurso. Os usuários não podem acessar o Argo CD sem um mapeamento global de perfis, mesmo que estejam atribuídos aos perfis do projeto.
Considere mapear usuários para o perfil VIEWER globalmente e, em seguida, conceder permissões adicionais por meio de perfis específicos do projeto. Isso fornece acesso básico e, ao mesmo tempo, permite um controle refinado no nível do projeto.
Os projetos fornecem:
+ **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 de RBAC**: mapeamento de projetos para grupos do Centro de Identidade da AWS ou perfis do Argo CD
**Exemplo de projeto para isolamento de equipes**:
```
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: team-a
namespace: argocd
spec:
description: Team A applications
# Required: Specify which namespaces this project watches for Applications
sourceNamespaces:
- argocd
# Source restrictions
sourceRepos:
- https://github.com/myorg/team-a-apps
# Destination restrictions
destinations:
- namespace: team-a-*
server: arn:aws:eks:us-west-2:111122223333:cluster/production
# Resource restrictions
clusterResourceWhitelist:
- group: ''
kind: Namespace
namespaceResourceWhitelist:
- group: 'apps'
kind: Deployment
- group: ''
kind: Service
- group: ''
kind: ConfigMap
```
### Namespaces da origem
Ao usar a funcionalidade EKS do Argo CD, o campo `spec.sourceNamespaces` é obrigatório nas definições de AppProject. Esse campo especifica qual namespace pode conter Applications or ApplicationSets que façam referência a esse projeto.
**Importante**
A funcionalidade EKS do Argo CD oferece suporte a apenas um único namespace para Applications and ApplicationSets, o namespace que você especificou ao criar a funcionalidade (normalmente `argocd`). Isso difere do Argo CD de código aberto, que oferece suporte a vários namespaces.
**Configuração do AppProject**
Todos os AppProjects devem incluir o namespace configurado da funcionalidade em `sourceNamespaces`:
```
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: team-a-project
namespace: argocd
spec:
description: Applications for Team A
# Required: Specify the capability's configured namespace (configuration.argoCd.namespace)
sourceNamespaces:
- argocd # Must match your capability's namespace configuration
# Source repositories this project can deploy from
sourceRepos:
- 'https://github.com/my-org/team-a-*'
# Destination restrictions
destinations:
- namespace: 'team-a-*'
server: arn:aws:eks:us-west-2:111122223333:cluster/my-cluster
```
**nota**
Se você omitir o namespace da funcionalidade de `sourceNamespaces`, Applications ou ApplicationSets nesse namespace não poderão referenciar esse projeto, resultando em falhas de implantação.
**Atribua usuários a projetos**:
Os perfis do projeto concedem aos usuários EDITOR e VIEWER acesso aos recursos do projeto (Applications, ApplicationSets, credenciais de repositório e cluster) e funcionalidades (logs, exec). Sem os perfis do projeto, esses usuários não podem acessar esses recursos, mesmo que tenham acesso global ao perfil.
Usuários com perfil de ADMIN têm acesso a todas as Applications sem precisar de perfis do projeto.
**Exemplo: concessão de acesso a Applications aos membros da equipe**
```
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: team-a
namespace: argocd
spec:
# ... project configuration ...
sourceNamespaces:
- argocd
# Project roles grant Application-level access
roles:
- name: developer
description: Team A developers - can manage Applications
policies:
- p, proj:team-a:developer, applications, *, team-a/*, allow
- p, proj:team-a:developer, clusters, get, *, allow # See cluster names in UI
groups:
- 686103e0-f051-7068-b225-e6392b959d9e # Identity Center group ID
- name: viewer
description: Team A viewers - read-only Application access
policies:
- p, proj:team-a:viewer, applications, get, team-a/*, allow
- p, proj:team-a:viewer, clusters, get, *, allow # See cluster names in UI
groups:
- 786203e0-f051-7068-b225-e6392b959d9f # Identity Center group ID
```
**nota**
Inclua `clusters, get, *, allow` nos perfis do projeto para permitir que os usuários vejam os nomes dos clusters na interface do usuário. Sem essa permissão, o cluster de destino será exibido como “desconhecido”.
**Noções básicas das políticas de perfis do projeto**:
O formato da política é: `p, proj::, , ,