**Ayude a mejorar esta página**
Para contribuir a esta guía del usuario, elija el enlace **Edit this page on GitHub** que se encuentra en el panel derecho de cada página.
# Implementación continua con Argo CD
Argo CD es una herramienta declarativa de entrega continua de GitOps para Kubernetes. Con Argo CD, puede automatizar la implementación y la administración del ciclo de vida de sus aplicaciones en múltiples clústeres y entornos. Argo CD admite varios tipos de orígenes, como los repositorios de Git, los registros de Helm (HTTP y OCI) y las imágenes de OCI, lo que proporciona flexibilidad a las organizaciones con diferentes requisitos de seguridad y cumplimiento.
Con las capacidades de EKS, AWS administra Argo CD completamente, lo que elimina la necesidad de instalar, mantener y escalar los controladores de Argo CD y sus dependencias en sus clústeres.
## Cómo funciona Argo CD
Argo CD sigue el patrón de GitOps, donde el origen de la aplicación (repositorio de Git, registro de Helm o imagen de OCI) es el origen de información verdadera para definir el estado de la aplicación deseado. Al crear un recurso `Application` de Argo CD, especifique un origen que contenga los manifiestos de la aplicación y un espacio de nombres y un clúster de Kubernetes de destino. Argo CD supervisa de forma continua tanto el origen como el estado activo del clúster y sincroniza automáticamente cualquier cambio para garantizar que el estado del clúster coincida con el estado deseado.
**nota**
Con la capacidad de EKS para Argo CD, el software de Argo CD se ejecuta en el plano de control de AWS, no en los nodos de trabajo. Esto significa que sus nodos de trabajo no necesitan acceso directo a los repositorios de Git o a los registros de Helm, ya que la capacidad gestiona el acceso al origen desde la cuenta de AWS.
Argo CD proporciona tres tipos de recursos principales:
+ **Aplicación**: define una implementación desde un repositorio de Git a un clúster de destino.
+ **ApplicationSet**: genera múltiples aplicaciones a partir de plantillas para implementaciones de varios clústeres.
+ **AppProject**: proporciona agrupamiento lógico y control de acceso para las aplicaciones.
**Ejemplo: creación de una aplicación de Argo CD**
En el ejemplo siguiente, se muestra cómo crear un recurso `Application` de 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**
Utilice `destination.name` con el nombre del clúster que utilizó al registrar el clúster (como `in-cluster` para el clúster local). El campo `destination.server` también funciona con los ARN de clústeres de EKS, pero se recomienda utilizar los nombres de los clústeres para una mejor legibilidad.
## Ventajas de Argo CD
Argo CD implementa un flujo de trabajo de GitOps en el que define las configuraciones de las aplicaciones en los repositorios de Git y Argo CD sincroniza automáticamente las aplicaciones para que coincidan con el estado deseado. Este enfoque centrado en Git proporciona un registro de auditoría completo de todos los cambios, permite revertirlos fácilmente y se integra de forma natural con sus procesos de revisión y aprobación de código existentes. Argo CD detecta y concilia automáticamente la diferencia entre el estado deseado en Git y el estado real de los clústeres, lo que garantiza que las implementaciones se mantengan coherentes con la configuración declarada.
Con Argo CD, puede implementar y administrar aplicaciones en varios clústeres desde una única instancia de Argo CD, lo que simplifica las operaciones en entornos de varios clústeres y regiones. La interfaz de usuario de Argo CD ofrece capacidades de visualización y supervisión, lo que le permite ver el estado de la implementación, el estado y el historial de sus aplicaciones. La interfaz de usuario se integra con AWS Identity Center (anteriormente AWS SSO) para una autenticación y autorización fluidas, lo que le permite controlar el acceso mediante su infraestructura de administración de identidades existente.
Como parte de las capacidades administradas de EKS, AWS administra completamente Argo CD, lo que elimina la necesidad de instalar, configurar y mantener la infraestructura de Argo CD. AWS administra el escalado, la aplicación de parches y la administración operativa, lo que permite a sus equipos centrarse en la entrega de la aplicación y no en el mantenimiento de la herramienta.
## Integración con AWS Identity Center
Las capacidades administradas de EKS proporcionan una integración directa entre Argo CD y AWS Identity Center, lo que permite una autenticación y autorización fluidas para sus usuarios. Al activar la capacidad de Argo CD, puede configurar la integración de AWS Identity Center para asignar los grupos y usuarios de Identity Center a los roles de RBAC de Argo CD, lo que le permite controlar quién puede acceder a las aplicaciones de Argo CD y administrarlas.
## Integración con otras capacidades administradas de EKS
Argo CD se integra con otras capacidades administradas de EKS.
+ **Controladores de AWS para Kubernetes (ACK)**: utilice Argo CD para administrar la implementación de los recursos de ACK en varios clústeres, lo que activa los flujos de trabajo de GitOps para su infraestructura de AWS.
+ **kro (Kube Resource Orchestrator)**: utilice Argo CD para implementar composiciones de kro en varios clústeres, lo que permite una composición uniforme de los recursos en todo el entorno de Kubernetes.
## Introducción a Argo CD
Para comenzar a utilizar la capacidad de EKS para Argo CD:
1. Cree y configure un rol de capacidad de IAM con los permisos necesarios para que Argo CD acceda a los orígenes y administre aplicaciones.
1. [Cree un recurso de capacidad de Argo CD](create-argocd-capability.md) en su clúster de EKS a través de la consola de AWS, la AWS CLI o su infraestructura preferida como herramienta de código.
1. Configure el acceso al repositorio y registre los clústeres para la implementación de aplicaciones.
1. Cree recursos de aplicación para implementar las aplicaciones desde los orígenes declarativos.
# Creación de una capacidad de Argo CD
En este tema, se explica cómo crear una capacidad de Argo CD en un clúster de Amazon EKS.
## Requisitos previos
Antes de crear una capacidad de Argo CD, asegúrese de que disponga de lo siguiente:
+ Un clúster de Amazon EKS existente que ejecute una versión de Kubernetes compatible (se admiten todas las versiones con soporte estándar y ampliado)
+ **AWS Identity Center configurado**: necesario para la autenticación de Argo CD (no se admiten los usuarios locales)
+ Un rol de capacidad de IAM con permisos para Argo CD
+ Permisos de IAM suficientes para crear recursos de capacidad en los clústeres de EKS
+ `kubectl` configurado para comunicarse con el clúster
+ (Opcional) La CLI de Argo CD instalada para facilitar la administración de clústeres y repositorios
+ (Para la CLI o eksctl) La herramienta de la CLI adecuada instalada y configurada
Para obtener instrucciones sobre cómo crear el rol de capacidad de IAM, consulte [Rol de IAM de capacidad de Amazon EKS](capability-role.md). Para obtener la configuración de Identity Center, consulte [Introducción a AWS Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html).
**importante**
El rol de capacidad de IAM que proporcione determina a qué recursos de AWS puede acceder Argo CD. Esto incluye el acceso al repositorio de Git a través de CodeConnections y los secretos en Secrets Manager. Para obtener orientación sobre cómo crear un rol adecuado con los permisos de privilegio mínimo, consulte [Rol de IAM de capacidad de Amazon EKS](capability-role.md) y [Consideraciones sobre la seguridad para las capacidades de EKS](capabilities-security.md).
## Elección de la herramienta
Puede crear una capacidad de Argo CD mediante la Consola de administración de AWS, la AWS CLI o eksctl:
+ [Creación de una capacidad de Argo CD mediante la consola](argocd-create-console.md): uso de la consola para una experiencia guiada
+ [Creación de una capacidad de Argo CD mediante la AWS CLI](argocd-create-cli.md): uso de la AWS CLI para scripts y automatización
+ [Creación de una capacidad de Argo CD mediante eksctl](argocd-create-eksctl.md): uso de eksctl para una experiencia nativa de Kubernetes
## Qué ocurre cuando se crea una capacidad de Argo CD
Cuando crea una capacidad de Argo CD:
1. EKS crea el servicio de capacidad de Argo CD en el plano de control de AWS.
1. Las definiciones de recursos personalizados (CRD) de Kubernetes se instalan en el clúster.
1. Se crea automáticamente una entrada de acceso para el rol de capacidad de IAM, con políticas de entrada de acceso específicas de la capacidad que conceden permisos básicos de Kubernetes (consulte [Consideraciones sobre la seguridad para las capacidades de EKS](capabilities-security.md)).
1. Argo CD comienza a supervisar sus recursos personalizados (Aplicaciones, ApplicationSets, AppProjects)
1. El estado de la capacidad cambia de `CREATING` a `ACTIVE`.
1. La interfaz de usuario de Argo CD pasa a estar accesible a través de su URL
Una vez activa, puede crear Aplicaciones de Argo CD en el clúster para implementar desde los orígenes declarativos.
**nota**
La entrada de acceso creada automáticamente no concede permisos para implementar aplicaciones en clústeres. Para implementar aplicaciones, debe configurar permisos adicionales de control de acceso basado en roles de Kubernetes para cada clúster de destino. Consulte [Registro de clústeres de destino](argocd-register-clusters.md) para obtener detalles sobre cómo registrar clústeres y configurar el acceso.
## Siguientes pasos
Después de crear la capacidad de Argo CD:
+ [Conceptos de Argo CD](argocd-concepts.md): más información sobre los principios de GitOps, las políticas de sincronización y los patrones de varios clústeres
+ [Uso de Argo CD](working-with-argocd.md): configuración del acceso a repositorios, registro de clústeres de destino y creación de aplicaciones
+ [Consideraciones sobre Argo CD](argocd-considerations.md): exploración de los patrones de arquitectura de varios clústeres y configuración avanzada
# Creación de una capacidad de Argo CD mediante la consola
En este tema, se describe cómo crear una capacidad de Argo CD mediante la Consola de administración de AWS.
## Requisitos previos
+ ** AWS Identity Center configurado**: Argo CD requiere AWS Identity Center para la autenticación. No se admiten usuarios locales. Si no ha configurado AWS Identity Center, consulte [Introducción a AWS Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html) para crear una instancia de Identity Center y [Adición de usuarios](https://docs.aws.amazon.com/singlesignon/latest/userguide/addusers.html) y [Adición de grupos](https://docs.aws.amazon.com/singlesignon/latest/userguide/addgroups.html) para crear usuarios y grupos a fin de acceder a Argo CD.
## Creación de la capacidad de Argo CD
1. Abra la consola de Amazon EKS en https://console.aws.amazon.com/eks/home\$1/clusters.
1. Seleccione el nombre del clúster para abrir la página de detalles del clúster.
1. Elija la pestaña **Capacidades**.
1. En el panel de navegación izquierdo, elija **Argo CD**.
1. Elija **Crear capacidad de Argo CD**.
1. Para el **rol de capacidad de IAM**:
+ Si ya tiene un rol de capacidad de IAM, selecciónelo en el menú desplegable.
+ Si necesita crear un rol, elija **Crear rol de Argo CD**.
De este modo, se abre la consola de IAM en una nueva pestaña con la política de confianza rellenada previamente y el acceso completo de lectura a Secrets Manager. No se agrega ningún otro permiso de forma predeterminada, pero puede agregarlos si es necesario. Si tiene previsto usar los repositorios de CodeCommit u otros servicios de AWS, agregue los permisos adecuados antes de crear el rol.
Después de crear el rol, regrese a la consola de EKS y el rol se seleccionará automáticamente.
**nota**
Si tiene previsto usar las integraciones opcionales con AWS Secrets Manager o AWS CodeConnections, tendrá que agregar permisos al rol. Para ver ejemplos de políticas de IAM y guías de configuración, consulte [Administración de secretos de aplicaciones con AWS Secrets Manager](integration-secrets-manager.md) y [Conexión a los repositorios de Git con AWS CodeConnections](integration-codeconnections.md).
1. Configure la integración de AWS Identity Center:
1. Seleccione **Habilitar la integración de AWS Identity Center**.
1. Elija su instancia de Identity Center en el menú desplegable.
1. Para configurar las asignaciones de roles para RBAC, asigne usuarios o grupos a los roles de Argo CD (ADMIN, EDITOR o VIEWER)
1. Seleccione **Crear**.
Comenzará el proceso de creación de la capacidad.
## Comprobación de la activación de la capacidad
1. En la pestaña **Capacidades**, consulte el estado de la capacidad de Argo CD.
1. Espere a que el estado cambie de `CREATING` a `ACTIVE`.
1. Una vez activa, la capacidad está lista para usarse.
Para obtener información sobre los estados de la capacidad y la solución de problemas, consulte [Uso de recursos de capacidades](working-with-capabilities.md).
## Acceso a la interfaz de usuario de Argo CD
Después de que la capacidad esté activa, puede acceder a la interfaz de usuario de Argo CD:
1. En la página de la capacidad de Argo CD, seleccione **Abrir la interfaz de usuario de Argo CD**.
1. La interfaz de usuario de Argo CD se abre en una nueva pestaña del navegador.
1. Ahora puede crear aplicaciones y administrar las implementaciones a través de la interfaz de usuario.
## Siguientes pasos
+ [Uso de Argo CD](working-with-argocd.md): configuración de repositorios, registro de clústeres y creación de aplicaciones
+ [Consideraciones sobre Argo CD](argocd-considerations.md): arquitectura de varios clústeres y configuración avanzada
+ [Uso de recursos de capacidades](working-with-capabilities.md): administración del recurso de la capacidad de Argo CD
# Creación de una capacidad de Argo CD mediante la AWS CLI
En este tema, se describe cómo crear una capacidad de Argo CD mediante la AWS CLI.
## Requisitos previos
+ **AWS CLI**: versión `2.12.3` o posterior. Para comprobar la versión, ejecute `aws --version`. Para obtener más información, consulte [Instalación](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) en la Guía del usuario de la interfaz de la línea de comandos de AWS.
+ ** `kubectl` ** – una herramienta de línea de comandos para trabajar con clústeres de Kubernetes. Para obtener más información, consulte [Configuración de `kubectl` y `eksctl`](install-kubectl.md).
+ ** AWS Identity Center configurado**: Argo CD requiere AWS Identity Center para la autenticación. No se admiten usuarios locales. Si no ha configurado AWS Identity Center, consulte [Introducción a AWS Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html) para crear una instancia de Identity Center y [Adición de usuarios](https://docs.aws.amazon.com/singlesignon/latest/userguide/addusers.html) y [Adición de grupos](https://docs.aws.amazon.com/singlesignon/latest/userguide/addgroups.html) para crear usuarios y grupos a fin de acceder a Argo CD.
## Paso 1: creación de un rol de capacidad de IAM
Cree un archivo de política de confianza:
```
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
```
Cree el rol de IAM:
```
aws iam create-role \
--role-name ArgoCDCapabilityRole \
--assume-role-policy-document file://argocd-trust-policy.json
```
**nota**
Si tiene previsto usar las integraciones opcionales con AWS Secrets Manager o AWS CodeConnections, tendrá que agregar permisos al rol. Para ver ejemplos de políticas de IAM y guías de configuración, consulte [Administración de secretos de aplicaciones con AWS Secrets Manager](integration-secrets-manager.md) y [Conexión a los repositorios de Git con AWS CodeConnections](integration-codeconnections.md).
## Paso 2: creación de la capacidad de Argo CD
Cree el recurso de la capacidad de Argo CD en su clúster.
En primer lugar, defina las variables de entorno para la configuración de Identity Center:
```
# 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"
```
Cree la capacidad con la integración de Identity Center. Sustituya *region-code* por la región de AWS donde se encuentra el clúster, *my-cluster* por el nombre del clúster e *idc-region-code* por el código de la región donde se ha configurado el IAM Identity Center:
```
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"
}]
}]
}
}'
```
El comando devuelve una respuesta inmediatamente, pero la capacidad tarda algún tiempo en activarse mientras EKS crea la infraestructura y los componentes de la capacidad necesarios. EKS instalará las definiciones de recursos personalizados de Kubernetes relacionadas con esta capacidad en el clúster según se vaya creando.
**nota**
Si recibe un error que indica que el clúster no existe o que no tiene permisos, compruebe lo siguiente:
El nombre del clúster es correcto
La AWS CLI está configurada para la región correcta
Dispone de los permisos de IAM necesarios
## Paso 3: comprobación de la activación de la capacidad
Espere a que se active la capacidad. Reemplace *region-code* por la región de AWS en la que se encuentra el clúster y *my-cluster* por el nombre del clúster.
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-argocd \
--query 'capability.status' \
--output text
```
La capacidad estará lista cuando aparezca el estado `ACTIVE`. No continúe con el paso siguiente hasta que el estado sea `ACTIVE`.
También puede ver todos los detalles de la capacidad:
```
aws eks describe-capability \
--region region-code \
--cluster-name my-cluster \
--capability-name my-argocd
```
## Paso 4: comprobación de la disponibilidad de los recursos personalizados
Una vez que la capacidad esté activa, compruebe que los recursos personalizados de Argo CD estén disponibles en el clúster:
```
kubectl api-resources | grep argoproj.io
```
Debería ver todos los tipos de recursos `Application` y `ApplicationSet` en la lista.
## Siguientes pasos
+ [Uso de Argo CD](working-with-argocd.md): configuración de repositorios, registro de clústeres y creación de aplicaciones
+ [Consideraciones sobre Argo CD](argocd-considerations.md): arquitectura de varios clústeres y configuración avanzada
+ [Uso de recursos de capacidades](working-with-capabilities.md): administración del recurso de la capacidad de Argo CD
# Creación de una capacidad de Argo CD mediante eksctl
En este tema, se describe cómo crear una capacidad de Argo CD mediante eksctl.
**nota**
Los siguientes pasos requieren la versión `0.220.0` o posterior de eksctl. Para comprobar la versión, ejecute `eksctl version`.
## Paso 1: creación de un rol de capacidad de IAM
Cree un archivo de política de confianza:
```
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
```
Cree el rol de IAM:
```
aws iam create-role \
--role-name ArgoCDCapabilityRole \
--assume-role-policy-document file://argocd-trust-policy.json
```
**nota**
Para esta configuración básica, no se necesitan políticas de IAM adicionales. Si tiene previsto usar Secrets Manager para las credenciales del repositorio o CodeConnections, tendrá que agregar permisos al rol. Para ver ejemplos de políticas de IAM y guías de configuración, consulte [Administración de secretos de aplicaciones con AWS Secrets Manager](integration-secrets-manager.md) y [Conexión a los repositorios de Git con AWS CodeConnections](integration-codeconnections.md).
## Paso 2: obtención de la configuración de AWS Identity Center
Obtenga el ARN y el ID de usuario de su instancia de Identity Center para la configuración 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 estos valores, ya que los necesitará en el siguiente paso.
## Paso 3: creación de un archivo de configuración de eksctl
Cree un archivo llamado `argocd-capability.yaml` con el siguiente contenido. Sustituya los valores de marcador de posición por el nombre del clúster, la región del clúster, el ARN del rol de IAM, el ARN de la instancia de Identity Center, la región de Identity Center y el ID de usuario:
```
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**
Puede agregar varios usuarios o grupos a las asignaciones de RBAC. Para los grupos, utilice `type: SSO_GROUP` y proporcione el ID del grupo. Los roles disponibles son `ADMIN`, `EDITOR` y `VIEWER`.
## Paso 4: creación de la capacidad de Argo CD
Aplique el archivo de configuración:
```
eksctl create capability -f argocd-capability.yaml
```
El comando vuelve inmediatamente, pero la capacidad tarda algún tiempo en activarse.
## Paso 5: comprobación de la activación de la capacidad
Compruebe el estado de la capacidad. Reemplace *region-code* por la región de AWS donde creó el clúster y *my-cluster* por el nombre de su clúster.
```
eksctl get capability \
--region region-code \
--cluster my-cluster \
--name my-argocd
```
La capacidad estará lista cuando aparezca el estado `ACTIVE`.
## Paso 6: comprobación de la disponibilidad de los recursos personalizados
Una vez que la capacidad esté activa, compruebe que los recursos personalizados de Argo CD estén disponibles en el clúster:
```
kubectl api-resources | grep argoproj.io
```
Debería ver todos los tipos de recursos `Application` y `ApplicationSet` en la lista.
## Siguientes pasos
+ [Uso de Argo CD](working-with-argocd.md): más información sobre cómo crear y administrar aplicaciones de Argo CD
+ [Consideraciones sobre Argo CD](argocd-considerations.md): configuración del SSO y el acceso a varios clústeres
+ [Uso de recursos de capacidades](working-with-capabilities.md): administración del recurso de la capacidad de Argo CD
# Conceptos de Argo CD
Para implementar GitOps, Argo CD trata a Git como el único origen de información para las implementaciones de aplicaciones. En este tema, se muestra un ejemplo práctico y, a continuación, se explican los conceptos básicos que debe comprender al trabajar con la capacidad de EKS para Argo CD.
## Introducción a Argo CD
Después de crear la capacidad de Argo CD (consulte [Creación de una capacidad de Argo CD](create-argocd-capability.md)), puede comenzar a implementar aplicaciones. En este ejemplo, se explica el registro de un clúster y la creación de una aplicación.
### Paso 1: Configurar
**Registro del clúster** (obligatorio)
Registre el clúster en el que desea implementar las aplicaciones. En este ejemplo, registraremos el mismo clúster en el que se ejecuta Argo CD (puede usar el nombre `in-cluster` por motivos de compatibilidad con la mayoría de los ejemplos de 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 obtener información sobre cómo configurar la CLI de Argo CD para que funcione con la capacidad de Argo CD en EKS, consulte [Uso de la CLI de Argo CD con la capacidad administrada](argocd-comparison.md#argocd-cli-configuration).
Como alternativa, registre el clúster mediante un secreto de Kubernetes (consulte [Registro de clústeres de destino](argocd-register-clusters.md) para obtener más información).
**Configuración del acceso al repositorio** (opcional)
En este ejemplo, se usa un repositorio de GitHub público, por lo que no se requiere ninguna configuración del repositorio. Para los repositorios privados, configure el acceso mediante AWS Secrets Manager, CodeConnections o secretos de Kubernetes (consulte [Configuración del acceso al repositorio](argocd-configure-repositories.md) para obtener más información).
Para los servicios de AWS (ECR para gráficos de Helm, CodeConnections y CodeCommit), puede hacer referencia a ellos directamente en los recursos de la aplicación sin necesidad de crear un repositorio. El rol de capacidad debe tener los permisos para llamar a los permisos de IAM necesarios. Para obtener más información, consulte [Configuración del acceso al repositorio](argocd-configure-repositories.md).
### Paso 2: Cree una aplicación
Cree este manifiesto de aplicación en `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 la aplicación:
```
kubectl apply -f my-app.yaml
```
Después de aplicar esta aplicación, Argo CD: 1. Sincroniza la aplicación de Git con el clúster (implementación inicial). 2. Supervisa el repositorio de Git para detectar cambios. 3. Sincroniza automáticamente los cambios posteriores en el clúster. 4. Detecta y corrige cualquier desviación del estado deseado. 5. Proporciona el estado y el historial de sincronización en la interfaz de usuario.
Consulte el estado de la aplicación:
```
kubectl get application guestbook -n argocd
```
También puede ver la aplicación mediante la CLI de Argo CD o la interfaz de usuario de Argo CD (accesible desde la consola de EKS, en la pestaña Capacidades del clúster).
**nota**
Cuando utilice la CLI de Argo CD con la capacidad administrada, especifique las aplicaciones con el prefijo de espacio de nombres: `argocd app get argocd/guestbook`.
**nota**
Utilice el nombre del clúster en `destination.name` (el nombre que utilizó al registrar el clúster). La capacidad administrada no admite el valor predeterminado local en el clúster (`kubernetes.default.svc`).
## Conceptos clave
### Principios y tipos de orígenes de GitOps
Argo CD implementa GitOps, donde el origen de la aplicación es el único origen de información para las implementaciones:
+ **Declarativo**: el estado deseado se declara mediante manifiestos de YAML, gráficos de Helm o superposiciones de Kustomize.
+ **Con control de versiones**: se hace un seguimiento de cada cambio con un registro de auditoría completo.
+ **Automatizado**: Argo CD supervisa continuamente los orígenes y sincroniza automáticamente los cambios.
+ **Recuperación automática**: detecta y corrige una desviación entre el estado deseado y el real del clúster.
**Tipos de orígenes compatibles**:
+ **Repositorios de Git**: GitHub, GitLab, Bitbucket, CodeCommit (HTTPS, SSH o CodeConnections)
+ **Registros de Helm**: registros HTTP (como `https://aws.github.io/eks-charts`) y registros OCI (como `public.ecr.aws`)
+ **Imágenes OCI**: imágenes de contenedor que incluyen manifiestos o gráficos de Helm (como `oci://registry-1.docker.io/user/my-app`)
Esta flexibilidad permite a las organizaciones elegir orígenes que cumplan con sus requisitos de seguridad y conformidad. Por ejemplo, las organizaciones que restringen el acceso a Git desde clústeres pueden usar ECR para gráficos de Helm o imágenes OCI.
Para obtener más información, consulte [Application Sources](https://argo-cd.readthedocs.io/en/stable/user-guide/application-sources/) en la documentación de Argo CD.
### Sincronización y conciliación
Argo CD supervisa continuamente sus orígenes y clústeres para detectar y corregir las diferencias:
1. Sondea los orígenes para ver si hay cambios (de forma predeterminada, cada 6 minutos).
1. Compara el estado deseado con el estado del clúster.
1. Marca las aplicaciones como `Synced` o `OutOfSync`.
1. Sincroniza los cambios automáticamente (si se configuró) o espera su aprobación manual.
1. Supervisa el estado de los recursos después de la sincronización.
Las **ondas de sincronización** controlan el orden de creación de los recursos mediante anotaciones:
```
metadata:
annotations:
argocd.argoproj.io/sync-wave: "0" # Default if not specified
```
Los recursos se aplican por orden de onda (primero, los números más bajos, incluidos los negativos, como `-1`). La fase `0` es la predeterminada si no se especifica. Esto permite crear dependencias como espacios de nombres (fase `-1`), antes de las implementaciones (fase `0`) y antes de los servicios (fase `1`).
La **recuperación automática** revierte los cambios manuales:
```
spec:
syncPolicy:
automated:
selfHeal: true
```
**nota**
La capacidad administrada utiliza el seguimiento de recursos basado en anotaciones (no en etiquetas) para mejorar la compatibilidad con las convenciones de Kubernetes y otras herramientas.
Para obtener información detallada sobre las fases de la sincronización, los enlaces y los patrones avanzados, consulte la [documentación de sincronización de Argo CD](https://argo-cd.readthedocs.io/en/stable/user-guide/sync-waves/).
### Estado de la aplicación
Argo CD supervisa el estado de todos los recursos de la aplicación:
**Estados**: \$1 **En buen estado** (todos los recursos se ejecutan según lo esperado) \$1 **En curso** (los recursos se están creando o actualizando) \$1 **Degradado** (algunos recursos no están en buen estado: bloqueo de pods, errores de trabajos) \$1 **Suspendido** (la aplicación se pausó de forma intencionada) \$1 **Falta** (los recursos definidos en Git no están en el clúster)
Argo CD tiene comprobaciones de estado integradas para los recursos comunes de Kubernetes (implementaciones, StatefulSets, trabajos, etc.) y admite comprobaciones de estado personalizadas para CRD.
El estado de la aplicación viene determinado por todos sus recursos: si hay algún recurso `Degraded`, el estado de la aplicación será `Degraded`.
Para obtener más información, consulte [Resource Health](https://argo-cd.readthedocs.io/en/stable/operator-manual/health/) en la documentación de Argo CD.
### Patrones de varios clústeres
Argo CD admite dos patrones de implementación principales:
**Radial**: ejecute Argo CD en un clúster de administración dedicado que se implemente en varios clústeres de cargas de trabajo. \$1 Control y visibilidad centralizados \$1 Políticas coherentes en todos los clústeres \$1 Una instancia de Argo CD que administrar \$1 Separación clara entre el plano de control y las cargas de trabajo
**Por clúster**: ejecute Argo CD en cada clúster y administre solo las aplicaciones de ese clúster. \$1 Separación de clústeres (un error no afecta a los demás) \$1 Redes más sencillas (sin comunicación entre clústeres) \$1 Configuración inicial más sencilla (sin registro de clústeres)
Elija la opción radial para los equipos de plataformas que administran varios clústeres, o la opción por clúster para equipos independientes o cuando los clústeres deban estar completamente aislados.
Para obtener información detallada sobre la configuración de varios clústeres, consulte [Consideraciones sobre Argo CD](argocd-considerations.md).
### Proyectos
Los proyectos proporcionan agrupamiento lógico y control de acceso para las aplicaciones:
+ **Restricciones de origen**: limite los repositorios de Git que se pueden usar.
+ **Restricciones de destino**: limite los clústeres y espacios de nombres que se pueden usar como destino.
+ **Restricciones de recursos**: limite los tipos de recursos de Kubernetes que se pueden implementar.
+ **Integración con RBAC**: asigne proyectos a ID de usuarios y grupos de AWS Identity Center.
Las aplicaciones pertenecen a un único proyecto. Si no se especifica, utilizan el proyecto `default`, que no tiene restricciones de forma predeterminada. Para uso en producción, edite el proyecto `default` para restringir el acceso y cree nuevos proyectos con las restricciones adecuadas.
Para obtener información sobre la configuración de proyectos y los patrones RBAC, consulte [Configuración de los permisos de Argo CD](argocd-permissions.md).
### Opciones de sincronización
Refine el comportamiento de la sincronización con opciones comunes:
+ `CreateNamespace=true`: se crea automáticamente el espacio de nombres de destino.
+ `ServerSideApply=true`: se utiliza la aplicación del servidor para una mejor resolución de conflictos.
+ `SkipDryRunOnMissingResource=true`: se omite la ejecución de prueba cuando las CRD aún no existan (útil para instancias de kro).
```
spec:
syncPolicy:
syncOptions:
- CreateNamespace=true
- ServerSideApply=true
- SkipDryRunOnMissingResource=true
```
Para obtener una lista completa de las opciones de sincronización, consulte la [documentación sobre las opciones de sincronización de Argo CD](https://argo-cd.readthedocs.io/en/stable/user-guide/sync-options/).
## Siguientes pasos
+ [Configuración del acceso al repositorio](argocd-configure-repositories.md): configuración del acceso al repositorio de Git
+ [Registro de clústeres de destino](argocd-register-clusters.md): registro de los clústeres de destino para la implementación
+ [Creación de aplicaciones](argocd-create-application.md): creación de la primera aplicación
+ [Consideraciones sobre Argo CD](argocd-considerations.md): patrones específicos de EKS, integración con Identity Center y configuración de varios clústeres
+ [Documentación de Argo CD](https://argo-cd.readthedocs.io/en/stable/): documentación completa de Argo CD que incluye enlaces de sincronización, comprobaciones de estado y patrones avanzados
# Configuración de los permisos de Argo CD
La capacidad administrada de Argo CD se integra con AWS Identity Center para la autenticación y utiliza roles de RBAC integrados para la autorización. En este tema, se explica cómo configurar los permisos para los usuarios y los equipos.
## Cómo funcionan los permisos con Argo CD
La capacidad de Argo CD utiliza AWS Identity Center para la autenticación y proporciona tres roles de RBAC integrados para la autorización.
Cuando un usuario accede a Argo CD:
1. Se autentican mediante AWS Identity Center (que puede federarse con su proveedor de identidad corporativa)
1. AWS Identity Center proporciona información sobre los usuarios y grupos a Argo CD
1. Argo CD asigna usuarios y grupos a roles de RBAC en función de su configuración
1. Los usuarios solo ven las aplicaciones y los recursos a los que tienen permiso de acceso
## Roles de RBAC integrados
La capacidad de Argo CD proporciona tres roles integrados que se asignan a los usuarios y grupos de AWS Identity Center. Son **roles con alcance global** que controlan el acceso a recursos de Argo CD, como proyectos, clústeres y repositorios.
**importante**
Los roles globales controlan el acceso a Argo CD en sí, no a recursos con alcance de proyecto, como las aplicaciones. Los usuarios Editor y Visualizador no pueden ver ni administrar aplicaciones de forma predeterminada; necesitan roles de proyecto para acceder a recursos con alcance de proyecto. Consulte [Roles de proyecto y acceso con alcance de proyecto](#project-roles) para obtener más información sobre cómo conceder acceso a las aplicaciones y a otros recursos con alcance de proyecto.
**ADMIN**
Acceso completo a todos los recursos y configuraciones de Argo CD:
+ Crear, actualizar y eliminar aplicaciones y ApplicationSets en cualquier proyecto
+ Administración de la configuración de Argo CD
+ Registro y administración de los clústeres de destino de la implementación
+ Configuración del acceso al repositorio
+ Crear y administrar proyectos
+ Visualización del estado y el historial de todas las aplicaciones
+ Enumerar y acceder a todos los clústeres y repositorios
**EDITOR**
Puede actualizar proyectos y configurar roles de proyecto, pero no puede modificar la configuración global de Argo CD:
+ Actualizar proyectos existentes (no puede crear ni eliminar proyectos)
+ Configurar roles y permisos de proyecto
+ Ver claves GPG y certificados
+ No puede modificar la configuración global de Argo CD
+ No puede administrar clústeres ni repositorios directamente
+ No puede ver ni administrar aplicaciones sin roles de proyecto
**VIEWER**
Acceso de solo lectura a los recursos de Argo CD:
+ Ver configuraciones de proyectos
+ Enumerar todos los proyectos (incluidos los proyectos a los que el usuario no está asignado)
+ Ver claves GPG y certificados
+ No puede enumerar clústeres ni repositorios
+ Imposibilidad de hacer cambios
+ No puede ver ni administrar aplicaciones sin roles de proyecto
**nota**
Para conceder a los usuarios Editor o Visualizador acceso a las aplicaciones, un Administrador o un Editor debe crear roles de proyecto que asignen grupos de Identity Center a permisos específicos dentro de un proyecto.
## Roles de proyecto y acceso con alcance de proyecto
Los roles globales Administrador, Editor y Visualizador controlan el acceso a Argo CD en sí. Los roles de proyecto controlan el acceso a los recursos y las capacidades dentro de un proyecto específico, incluidos:
+ **Recursos**: aplicaciones, ApplicationSets, credenciales de repositorios y credenciales de clústeres
+ **Capacidades**: acceso a registros y acceso de ejecución (exec) a los pods de aplicaciones
**Explicación del modelo de permisos de dos niveles**:
+ **Alcance global**: los roles integrados determinan lo que los usuarios pueden hacer con los proyectos, los clústeres, los repositorios y la configuración de Argo CD
+ **Alcance de proyecto**: los roles de proyecto determinan lo que los usuarios pueden hacer con los recursos y las capacidades dentro de un proyecto específico
Esto significa:
+ Los usuarios Administrador pueden acceder a todos los recursos y capacidades de los proyectos sin configuración adicional
+ Los usuarios Editor y Visualizador deben recibir roles de proyecto para acceder a los recursos y las capacidades del proyecto
+ Los usuarios Editor pueden crear roles de proyecto para concederse a sí mismos y a otros acceso dentro de los proyectos que pueden actualizar
**Flujo de trabajo de ejemplo**:
1. Un Administrador asigna un grupo de Identity Center al rol Editor a nivel global
1. Un Administrador crea un proyecto para un equipo
1. El Editor configura roles de proyecto dentro de ese proyecto para conceder a los miembros del equipo acceso a recursos con alcance de proyecto
1. Los miembros del equipo (que pueden tener el rol global Visualizador) ahora pueden ver y administrar aplicaciones en ese proyecto según los permisos de su rol de proyecto
Para obtener más información sobre la configuración de roles de proyecto, consulte [Control de acceso basado en proyectos](#_project_based_access_control).
## Configuración de las asignaciones de roles
Asigne los usuarios y grupos de AWS Identity Center a los roles de Argo CD al crear o actualizar la capacidad.
**Ejemplo de asignación de roles**:
```
{
"rbacRoleMapping": {
"ADMIN": ["AdminGroup", "alice@example.com"],
"EDITOR": ["DeveloperGroup", "DevOpsTeam"],
"VIEWER": ["ReadOnlyGroup", "bob@example.com"]
}
}
```
**nota**
Los nombres de los roles distinguen entre mayúsculas y minúsculas y deben estar en mayúsculas (ADMIN, EDITOR, VIEWER).
**importante**
La integración de capacidades de EKS con AWS Identity Center admite hasta 1000 identidades por capacidad de Argo CD. Una identidad puede ser un usuario o un grupo.
**Actualice las asignaciones de roles**:
```
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 de la cuenta de administrador
La cuenta de administrador está diseñada para la configuración inicial y las tareas administrativas, como el registro de clústeres y la configuración de repositorios.
**Cuándo es adecuado usar la cuenta de administrador**:
+ Configuración inicial de la capacidad
+ Desarrollo individual o demostraciones rápidas
+ Tareas administrativas (registro de clústeres, configuración de repositorios, creación de proyectos)
**Prácticas recomendadas para la cuenta de administrador**:
+ No asigne tokens de la cuenta al control de versiones.
+ Cambie los tokens inmediatamente si se han expuesto.
+ Limite el uso de los tokens de la cuenta a las tareas administrativas y de configuración.
+ Establezca tiempos de vencimiento cortos (máximo 12 horas).
+ Solo se pueden crear 5 tokens de la cuenta en un momento determinado.
**Cuándo se usa el acceso basado en proyectos**:
+ Entornos de desarrollo compartidos con varios usuarios
+ Cualquier entorno que se asemeje al de producción
+ Cuando necesite registros de auditoría sobre quién llevó a cabo las acciones
+ Cuando necesite aplicar restricciones de recursos o límites de acceso
Para entornos de producción y escenarios de varios usuarios, utilice el control de acceso basado en proyectos con roles de RBAC dedicados asignados a grupos de AWS Identity Center.
## Control de acceso basado en proyectos
Utilice proyectos de Argo CD (AppProject) para proporcionar un control del acceso y un aislamiento de los recursos detallados para los equipos.
**importante**
Antes de asignar usuarios o grupos a roles específicos de proyecto, primero debe asignarlos a un rol global de Argo CD (Administrador, Editor o Visualizador) en la configuración de la capacidad. Los usuarios no pueden acceder a Argo CD sin una asignación a un rol global, incluso si están asignados a roles de proyecto.
Considere asignar a los usuarios el rol Visualizador a nivel global y, posteriormente, conceder permisos adicionales mediante roles específicos de proyecto. Esto proporciona un acceso básico y permite un control detallado a nivel de proyecto.
Los proyectos proporcionan lo siguiente:
+ **Restricciones de origen**: limite los repositorios de Git que se pueden usar.
+ **Restricciones de destino**: limite los clústeres y espacios de nombres que se pueden usar como destino.
+ **Restricciones de recursos**: limite los tipos de recursos de Kubernetes que se pueden implementar.
+ **Integración con RBAC**: asigne los proyectos a grupos de AWS Identity Center o roles de Argo CD.
**Ejemplo de proyecto para el aislamiento de equipos**:
```
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
```
### Espacios de nombres de origen
Cuando se utiliza la capacidad de Argo CD en EKS, el campo `spec.sourceNamespaces` es obligatorio en las definiciones de AppProject. Este campo especifica qué espacio de nombres puede contener aplicaciones o ApplicationSets que hagan referencia a este proyecto.
**importante**
La capacidad de Argo CD en EKS solo admite un único espacio de nombres para las aplicaciones y los ApplicationSets: el espacio de nombres que especificó al crear la capacidad (normalmente, `argocd`). Esto difiere de Argo CD de código abierto, que admite múltiples espacios de nombres.
**Configuración de AppProject**
Todos los AppProjects deben incluir el espacio de nombres configurado de la capacidad en `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**
Si omite el espacio de nombres de la capacidad en `sourceNamespaces`, las aplicaciones o los ApplicationSets de ese espacio de nombres no podrán hacer referencia a este proyecto, lo que provocará errores en la implementación.
**Asigne usuarios a los proyectos**:
Los roles de proyecto conceden a los usuarios Editor y Visualizador acceso a los recursos del proyecto (aplicaciones, ApplicationSets y credenciales de repositorios y clústeres) y a las capacidades (registros y ejecución [exec]). Sin roles de proyecto, estos usuarios no pueden acceder a estos recursos, incluso si tienen acceso mediante un rol global.
Los usuarios Administrador tienen acceso a todas las aplicaciones sin necesidad de roles de proyecto.
**Ejemplo: concesión de acceso a aplicaciones a los miembros del equipo**
```
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**
Incluya `clusters, get, *, allow` en los roles de proyecto para permitir que los usuarios vean los nombres de los clústeres en la interfaz de usuario. Sin este permiso, el clúster de destino aparece como “desconocido”.
**Explicación sobre las políticas de los roles de proyecto**:
El formato de la política es: `p, proj::, , ,