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.

# Configurer les actions relatives au cycle de vie des nœuds dans AWS PIÈCES
<a name="cng-node-lifecycle-actions-configure"></a>

Vous définissez les actions du cycle de vie des nœuds dans la configuration de votre groupe de nœuds de calcul. Cette rubrique explique comment définir un script, contrôler s'il s'exécute de nouveau au redémarrage, le stocker, lui transmettre des arguments, gérer les échecs, le mettre en cache, valider son intégrité et lire ses journaux.

**Version de l'agent requise**  
Les actions relatives au cycle de vie des nœuds nécessitent la version 1.5.0-1 ou ultérieure de l'agent AWS PCS. Si vos nœuds de calcul utilisent une AMI personnalisée avec une ancienne version d'agent, mettez à jour l'agent avant de configurer les actions du cycle de vie. Pour de plus amples informations, veuillez consulter [AWS Versions des agents PCS](pcs-agent-versions.md).

## Comment définir un script
<a name="cng-node-lifecycle-actions-configure-define"></a>

Chaque script possède un`name`, a`scriptSource`, facultatif`arguments`, une `onError` politique et un`executionPolicy`. Les champs de localisation et d'intégrité sont regroupés ci-dessous`scriptSource`.

```
{
  "name": "My script",
  "scriptSource": {
    "scriptLocation": "s3://{{my-bucket}}/{{my-script}}.sh",
    "s3VersionId": "optional, S3 only",
    "checksum": "optional 64-char SHA-256 hex"
  },
  "arguments": ["{{arg1}}", "{{arg2}}"],
  "onError": "TERMINATE",
  "executionPolicy": "FIRST_BOOT_ONLY"
}
```

## Ajouter des actions de cycle de vie à un groupe de nœuds de calcul
<a name="cng-node-lifecycle-actions-configure-add"></a>

Vous pouvez ajouter des actions de cycle de vie lorsque vous créez ou mettez à jour un groupe de nœuds de calcul. Utilisez le Console de gestion AWS ou le AWS CLI.

------
#### [ Console de gestion AWS ]

**Pour ajouter des actions de cycle de vie à l'aide de la console**

1. Ouvrez la console [AWS PCS](https://console.aws.amazon.com/pcs/home#/clusters).

1. Ouvrez la page de création ou de mise à jour d'un groupe de nœuds de calcul.

1. Dans la ** section Actions relatives au cycle de vie des ** nœuds, choisissez ** Ajouter un script**. 

1. Sélectionnez la source du script :

   1. **Ajouter depuis la bibliothèque de scripts AWS PCS ** — Faites référence AWSà un script maintenu. Pour de plus amples informations, veuillez consulter [Utilisation AWS-des scripts gérés pour les actions relatives au cycle de vie des nœuds dans AWS PIÈCES](cng-node-lifecycle-actions-vetted-scripts.md).

   1. **Ajouter via S3 ** — Référencez un script par son URI Amazon S3.

   1. **Ajouter via HTTPS ** — Référencez un script par son URL HTTPS.

1. Sélectionnez l'étape du nœud.

1. Pour un script que vous ajoutez via S3 ou HTTPS, spécifiez les paramètres suivants :

   1. **Emplacement du script ** : entrez l'URI S3 ou l'URL HTTPS du script.

   1. **Nom ** — Entrez un nom pour le script.

   1. (Facultatif) ** Somme de contrôle ** : entrez une SHA-256 somme de contrôle pour vérifier l'intégrité du script. Pour de plus amples informations, veuillez consulter [Intégrité du script (sommes de contrôle)](#cng-node-lifecycle-actions-configure-checksums).

   1. (Facultatif) Pour un script que vous ajoutez via S3, entrez une version faisant référence à une version spécifique de l'objet.

1. Pour toutes les sources de script, spécifiez les paramètres suivants :

   1. **Comportement de gestion des erreurs ** : sélectionnez `TERMINATE``STOP_SEQUENCE`, ou`CONTINUE`.

   1. **Politique d'exécution ** : sélectionnez `FIRST_BOOT_ONLY` ou`EVERY_BOOT`.

   1. (Facultatif) ** Arguments ** — Ajoutez des arguments à transmettre au script.

1. Pour ajouter d'autres scripts, répétez ces étapes.

1. Les scripts s'exécutent de haut en bas au cours d'une étape. Pour modifier l'ordre d'exécution, choisissez ** Actions ** pour un script, puis choisissez ** Déplacer vers le haut ** ou ** Déplacer vers le bas**.

1. Pour la politique de ** mise en cache**, sélectionnez `CACHE_ONCE` ou`REFRESH_ON_REBOOT`. La politique de mise en cache s'applique à tous les scripts. Pour de plus amples informations, veuillez consulter [Mise en cache et mises à jour des scripts](#cng-node-lifecycle-actions-configure-caching).

------
#### [ AWS CLI ]

Utilisez le `--node-lifecycle-actions` paramètre à l'aide de la `update-compute-node-group` commande `create-compute-node-group` ou. Pour la structure des paramètres, voir [ NodeLifecycleActionsRequest ](https://docs.aws.amazon.com/pcs/latest/APIReference/API_NodeLifecycleActionsRequest.html) la référence de l'API *AWS PCS*. Pour des exemples de commandes, consultez[Exemples d'actions relatives au cycle de vie des nœuds pour AWS PIÈCES](cng-node-lifecycle-actions-examples.md).

------

## Contrôle du comportement de redémarrage
<a name="cng-node-lifecycle-actions-configure-reboot"></a>

`executionPolicy`Défini par script pour contrôler s'il est réexécuté au redémarrage.


| **Valeur** | **Comportement** | **Quand l’utiliser** | 
| --- | --- | --- | 
| `FIRST_BOOT_ONLY` (par défaut) | Exécutez le script une fois, lors du premier démarrage du nœud. Ignorez-le à chaque redémarrage suivant. | One-time configuration, telle que l'installation de packages, l'adhésion à un domaine ou l'initialisation du stockage. Vous n'êtes pas obligé de rendre ces scripts idempotents. | 
| `EVERY_BOOT` | Exécutez le script au premier démarrage ** et ** à chaque redémarrage. | Configuration qui doit être réappliquée après un redémarrage, telle que le remontage d'un système de fichiers éphémère ou la réaffirmation de l'état d'un nœud. | 

Les scripts sont configurés pour `FIRST_BOOT_ONLY` s'exécuter une seule fois et sont ignorés au redémarrage. Les scripts sont configurés pour `EVERY_BOOT` s'exécuter à chaque démarrage et doivent être idempotents (ils peuvent être exécutés plusieurs fois en toute sécurité avec le même résultat).

## Emplacements de stockage des scripts
<a name="cng-node-lifecycle-actions-configure-storage"></a>

Vous pouvez stocker des scripts dans ** Amazon S3 ** ou les diffuser via ** HTTPS**. Les scripts ne peuvent pas être chargés en ligne via l'API, et chaque script ne doit pas dépasser 2 Mo. L'agent rejette tout script dépassant cette taille.
+ **Amazon S3 (`s3://{{bucket}}/{{key}}`) ** — L'instance que le profil IAM doit avoir `s3:GetObject` sur l'objet. Avec un point de terminaison VPC de passerelle S3, les nœuds des sous-réseaux privés peuvent récupérer des scripts via le point de terminaison VPC. Épinglez une version spécifique avec `scriptSource.s3VersionId` (emplacements S3 uniquement).
+ **HTTPS (`https://{{hostname}}/{{path}}`) ** : l'hôte doit être lisible par le public (pas d'authentification) et le nœud a besoin d'un accès Internet sortant (passerelle Internet, passerelle NAT ou proxy HTTP). Ceci est utile pour les scripts hébergés sur GitHub ou sur d'autres référentiels publics.

Le stockage externe assure le contrôle des versions, l'auditabilité et la réutilisation entre les équipes. Les scripts en ligne ou chargés ne sont pas pris en charge.

## Transmettre des arguments à des scripts
<a name="cng-node-lifecycle-actions-configure-arguments"></a>

Transmettez les arguments sous forme de tableau ordonné. Ils accèdent à votre script en tant que paramètres de ligne de commande positionnels.

```
arguments: ["fs-12345678", "/shared", "nfs4"]
# script.sh fs-12345678 /shared nfs4   ($1=fs-12345678, $2=/shared, $3=nfs4)
```

L'agent exporte des variables d'environnement vers chaque script. Ces variables contiennent des métadonnées de cluster et de nœud. 


| **Variable** | **Description** | 
| --- | --- | 
| `PCS_CLUSTER_ID` / `PCS_CLUSTER_NAME` | Identifiant/nom du cluster | 
| `PCS_COMPUTE_NODE_GROUP_ID` / `PCS_COMPUTE_NODE_GROUP_NAME` | Identifiant/nom du groupe de nœuds de calcul | 
| `PCS_NODE_ID` | Identifiant du nœud | 
| `PCS_IS_FIRST_BOOT` | `1`lors du premier démarrage du nœud, `0` à chaque redémarrage suivant. Utilisez-le pour répartir le comportement dans les `EVERY_BOOT` scripts. | 

```
#!/usr/bin/env bash
echo "Configuring node $PCS_NODE_ID in cluster $PCS_CLUSTER_NAME"
```

## Gestion des erreurs
<a name="cng-node-lifecycle-actions-configure-errors"></a>

Chaque script possède un `onError` champ qui contrôle ce qui se passe lorsqu'un script sort d'une valeur différente de zéro ou est interrompu par un signal.


| **Valeur** | **Comportement** | **Quand l’utiliser** | 
| --- | --- | --- | 
| `TERMINATE` (par défaut) | Marquez le nœud en panne et terminez-le. | Configuration critique (montages de stockage, jointure Active Directory). Empêche de payer pour des nœuds cassés. | 
| `STOP_SEQUENCE` | Arrêtez les scripts restants de la phase ; laissez le nœud en cours d'exécution. | Débogage : inspectez l'instance après une panne. | 
| `CONTINUE` | Enregistrez l'erreur et exécutez le script suivant. | Tâches facultatives ou nécessitant le meilleur effort. | 

Un script échoue s'il sort d'une valeur différente de zéro ou s'il est interrompu par un signal (par exemple,`SIGSEGV`). **Les scripts ne sont pas réessayés. ** Si une opération risque de rencontrer des échecs transitoires, ajoutez une logique de nouvelle tentative dans le script. *La récupération du script * (téléchargement) est toutefois réessayée, jusqu'à 3 tentatives avec un retard exponentiel (environ 17 secondes maximum), avant que le comportement ne s'applique. `onError`

## Mise en cache et mises à jour des scripts
<a name="cng-node-lifecycle-actions-configure-caching"></a>

L'agent télécharge chaque script sur l'instance au premier démarrage et le stocke localement. Deux champs contrôlent le comportement au redémarrage : `scriptCachingPolicy` contrôle le nouveau téléchargement et `executionPolicy` contrôle la réexécution.
+ **`CACHE_ONCE`(par défaut) ** — Téléchargez une fois au premier démarrage ; ne réessayez jamais. Le comportement est identique lors des redémarrages. La mise à jour * du contenu du script * nécessite le remplacement de l'instance.
+ **`REFRESH_ON_REBOOT`**— Re-download à chaque redémarrage, écrasement du cache. Cela vous permet d'envoyer des correctifs de script par le biais d'un redémarrage. Il nécessite un accès réseau à chaque démarrage ; si une actualisation échoue, le téléchargement est traité comme un échec de récupération et le `onError` comportement du script s'applique (il n'y a pas de solution de repli vers la copie en cache). Un script actualisé ne se réexécute réellement au redémarrage que si c'est le cas. `executionPolicy` `EVERY_BOOT`

La * configuration du cycle de vie * (quels scripts sont exécutés, leurs arguments, la gestion des erreurs et la politique d'exécution) est toujours immuable par instance. Le modifier n'`UpdateComputeNodeGroup`affecte que les ** nouvelles ** instances et déclenche la `DRAIN` stratégie afin que les tâches en cours d'exécution se terminent avant que les nœuds ne soient remplacés.

## Intégrité du script (sommes de contrôle)
<a name="cng-node-lifecycle-actions-configure-checksums"></a>

Fournissez éventuellement un SHA-256 `checksum` dans un script`scriptSource`, sous la forme d'une chaîne hexadécimale de 64 caractères. L'agent le valide lors du téléchargement ; une non-concordance est traitée comme un échec de téléchargement et se déclenche. `onError` Nous recommandons une somme de contrôle pour la production, en particulier pour les scripts provenant de sources partagées ou externes.

```
sha256sum mount-efs.sh   # use the 64-char hex hash as the checksum value
```

## Journalisation et débogage
<a name="cng-node-lifecycle-actions-configure-logging"></a>

Chaque script écrit dans son propre fichier journal et l'agent conserve son propre journal opérationnel.

```
# agent: download, caching, checksum, orchestration
/var/log/amazon/pcs/lifecycle/actions/executor.log
# each script's stdout/stderr
/var/log/amazon/pcs/lifecycle/actions/<stage>/<script-name>.log
```

Le nom du fichier journal utilise le nom du script tel que vous l'avez défini. Les espaces sont préservés. Par exemple, un script nommé `Mount EFS home directory` écrit dans`Mount EFS home directory.log`. Connectez-vous à SSH ou à AWS Systems Manager Session Manager pour les lire. Les deux sont disponibles au fur et à `nodeBootstrapped` mesure. Dans la mesure où les nœuds défaillants `TERMINATE` sont remplacés, transférez les journaux hors instance pour les déboguer après la résiliation : ajoutez un script d'amorçage des nœuds qui configure l' CloudWatch agent Amazon pour qu'il envoie le répertoire des journaux du cycle de vie à Amazon Logs. CloudWatch C'est ce que fait `configure-cloudwatch-logs.sh` le script AWS-maintained. Pour de plus amples informations, veuillez consulter [Utilisation AWS-des scripts gérés pour les actions relatives au cycle de vie des nœuds dans AWS PIÈCES](cng-node-lifecycle-actions-vetted-scripts.md).