**Aidez à améliorer cette page**
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub ** lien ** Modifier cette page qui se trouve dans le volet droit de chaque page.
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Configuration des paramètres d'Argo CD
Grâce à la fonctionnalité EKS pour Argo CD, vous bénéficiez d'une expérience Argo CD entièrement gérée. Upstream Argo CD propose de nombreux paramètres et fonctionnalités optionnels, et la fonctionnalité EKS d'Argo CD prend en charge un sous-ensemble d'entre eux. Pour les paramètres pris en charge, vous les configurez de la même manière qu'Argo CD en amont, via l'interface `argocd-cm` ConfigMap de votre cluster. AWS lit les champs pris en charge à partir de celui-ci ConfigMap et les applique à l'instance Argo CD gérée.
Les sections suivantes décrivent comment configurer les `argocd-cm` ConfigMap paramètres pris en charge.
## Conditions préalables
Avant de configurer les paramètres d'Argo CD, vous devez disposer des éléments suivants :
+ Un cluster EKS avec la fonctionnalité Argo CD a été créé (voir[Création d’une fonctionnalité Argo CD](create-argocd-capability.md))
+ L'espace de noms configuré pour Argo CD dans la fonctionnalité (par défaut, l'`argocd`espace de noms)
+ La `kubectl` CLI configurée pour communiquer avec votre cluster
## Configurez l'argocd-cm ConfigMap
Pour configurer les paramètres Argo CD pris en charge, créez un ConfigMap nom `argocd-cm` dans votre cluster. La fonctionnalité gérée lit les champs pris en charge à partir de celui-ci ConfigMap et les applique à l'instance Argo CD gérée. La fonctionnalité ignore tous les champs et fonctionnalités non pris en charge que vous définissez. Consultez la liste des champs pris en charge pour vérifier qu'un paramètre est pris en compte.
Créez le ConfigMap avec les exigences suivantes :
+ Nommez le ConfigMap `argocd-cm`.
+ Créez-le dans l'espace de noms configuré pour Argo CD dans la fonctionnalité (l'espace de noms que vous avez défini dans la configuration Argo CD lorsque vous avez créé la fonctionnalité). Par défaut, il s'agit de l'espace de `argocd` noms.
+ Appliquez l'étiquette`app.kubernetes.io/part-of: argocd`. Cette étiquette est obligatoire et correspond au comportement en amont d'Argo CD.
+ Utilisez le même format de champ et les mêmes clés que le CD Argo en amont.
L'exemple suivant montre la ConfigMap structure :
```
apiVersion: v1
kind: ConfigMap
metadata:
name: argocd-cm
namespace: argocd
labels:
app.kubernetes.io/part-of: argocd
data:
# Supported settings go here (see the following sections)
```
**Important**
A n' ConfigMap est pas un magasin sécurisé. Ne mettez pas de secrets, d'informations d'identification ou d'autres informations sensibles dans le `argocd-cm` ConfigMap.
### Paramètres pris en charge
La capacité gérée prend en charge le `argocd-cm` champ suivant :
| Champ | Description |
| --- | --- |
| `resource.customizations.health.*` | Scripts de contrôle de santé personnalisés pour les ressources personnalisées. Consultez [Surveillances d'état personnalisées](#argocd-custom-health-checks). |
## Surveillances d'état personnalisées
Argo CD évalue l'état des ressources qu'il déploie. Pour les ressources Kubernetes standard telles que les déploiements et les services, Argo CD intègre une logique de santé. Pour les ressources personnalisées qu'Argo CD ne reconnaît pas, il n'a pas de logique de santé intégrée et ne signale aucun état de santé.
Lorsqu'une ressource personnalisée ne fait l'objet d'aucun bilan de santé, Argo CD ne signale aucun état de santé pour elle et l'exclut de l'état général de l'application. Par conséquent, une application peut signaler `Healthy` même si ses ressources sont toujours en cours d'approvisionnement ou en cas de défaillance. Cela signifie également que les vagues de synchronisation peuvent avancer avant que ces ressources ne soient prêtes, car l'ordre de synchronisation dépend de l'état de santé déclaré.
Grâce à des bilans de santé personnalisés, vous pouvez définir une logique d'intégrité pour vos ressources personnalisées, afin qu'Argo CD affiche un état de santé précis et séquence correctement les déploiements. Vous définissez des bilans de santé personnalisés de la même manière que dans Argo CD en amont, à l'aide des mêmes clés de configuration. Les scripts en amont et les exemples communautaires existants fonctionnent avec la fonctionnalité EKS pour Argo CD sans modification.
### Built-in bilans de santé pour ACK et kro
La fonctionnalité EKS pour Argo CD inclut des contrôles de santé intégrés pour les ressources [AWS Controllers for Kubernetes (ACK) ](ack.md) et [ kro (Kube Resource Orchestrator). ](kro.md) Ces ressources fournissent des informations précises sur l'état de santé sans aucune configuration supplémentaire.
Pour modifier la façon dont la fonctionnalité évalue l'état d'une ressource ACK ou KRO, vous pouvez définir un bilan de santé personnalisé pour ce type de ressource. Un bilan de santé personnalisé que vous définissez pour un type de ressource remplace le bilan de santé intégré pour ce type.
### Rédiger un bilan de santé personnalisé
Définissez un bilan de santé personnalisé en ajoutant un script Lua au `argocd-cm` ConfigMap, à l'aide d'une clé au format suivant :
```
resource.customizations.health._
```
{{}}Remplacez-le par le groupe d'API de la ressource personnalisée et {{}} par son type. Par exemple, la clé d'une ressource personnalisée avec le groupe d'API `example.com` et le type `Database` est`resource.customizations.health.example.com_Database`.
Le script Lua a accès à l'objet ressource via la `obj` variable globale. Le script doit renvoyer une table dont `status` le champ est défini sur l'une des `Healthy` valeurs `Progressing` suivantes :`Degraded`, ou`Suspended`. Le script peut également définir un `message` champ facultatif pour fournir un message d'état descriptif.
L'exemple suivant ConfigMap définit un bilan de santé pour une ressource `Database` personnalisée. Le script indique la ressource au `Healthy` moment où se trouve sa phase d'état`Ready`, et dans le `Progressing` cas contraire :
```
apiVersion: v1
kind: ConfigMap
metadata:
name: argocd-cm
namespace: argocd
labels:
app.kubernetes.io/part-of: argocd
data:
resource.customizations.health.example.com_Database: |
hs = {}
hs.status = "Progressing"
hs.message = "Waiting for the resource to become ready"
if obj.status ~= nil then
if obj.status.phase == "Ready" then
hs.status = "Healthy"
hs.message = "Database is ready"
end
end
return hs
```
Pour plus d'informations sur le format de script de contrôle de santé, la liste des bilans de santé intégrés et des exemples communautaires que vous pouvez adapter, consultez [ Resource Health ](https://argo-cd.readthedocs.io/en/stable/operator-manual/health/) sur le site Web de documentation d'Argo CD.
### Sécurité et limites
Grâce à la fonctionnalité gérée, vos scripts de contrôle de santé personnalisés s'exécutent dans un environnement informatique isolé et entièrement géré. L'environnement d'exécution est isolé par fonctionnalité et n'a pas accès aux données de votre cluster ni aux AWS API. Vous ne provisionnez, ne corrigez ni n'exploitez aucune partie de l'environnement d'exécution.
Lorsque vous rédigez des bilans de santé personnalisés à utiliser avec la fonctionnalité EKS, tenez compte des points suivants :
+ **Les bibliothèques Lua standard ne sont pas disponibles. ** L'`useOpenLibs`option est toujours désactivée, ce qui est la valeur par défaut dans Argo CD en amont. Les scripts ne peuvent pas accéder au système d'exploitation ou au système de fichiers. Si vous migrez un script depuis un CD Argo autogéré qui repose sur des bibliothèques Lua standard, il se peut qu'il ne s'exécute pas de la même manière dans cette fonctionnalité. Nous vous recommandons de tester vos scripts de contrôle de santé dans un environnement de développement avant de les utiliser en production.
Si l'évaluation de l'état de santé est temporairement indisponible, les rapports de fonctionnalité ont affecté les ressources personnalisées `Progressing` au lieu de supprimer leur état de santé. Cela permet de garder les ressources affectées visibles dans l'état de santé de l'application jusqu'à la reprise de l'évaluation.
### Vérifier un bilan de santé personnalisé
Après avoir appliqué ou mis à jour le `argocd-cm` ConfigMap, confirmez que le bilan de santé est actif :
1. Dans l'interface utilisateur d'Argo CD, choisissez une application qui inclut une ressource personnalisée du type pour lequel vous avez défini un bilan de santé. Vérifiez que la ressource indique l'état de santé renvoyé par votre script. Vous pouvez également exécuter `argocd app get {{}} ` et revoir l'état de santé de la ressource.
1. Si la ressource n'indique pas l'état de santé attendu, vérifiez les points suivants :
+ Le ConfigMap est nommé `argocd-cm` et se trouve dans l'espace de noms configuré pour Argo CD dans la fonctionnalité.
+ ConfigMap Possède l'`app.kubernetes.io/part-of: argocd`étiquette requise.
+ La touche de contrôle de santé utilise la valeur correcte `_` pour le type de ressource.