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.

Utilisation AWS-des scripts gérés pour les actions relatives au cycle de vie des nœuds dans AWS PIÈCES

AWS publie des scripts gérés pour les actions courantes du cycle de vie. Vous faites référence à un script maintenu directement à partir de la configuration de votre groupe de nœuds de calcul. Les scripts sont idempotents et peuvent être exécutés en toute sécurité à chaque démarrage.

AWS distribue les scripts d'un compartiment Amazon S3 public et AWS géré dans chacun Région AWS d'eux. Vous référencez un script par son URI Amazon S3. Vous faites référence à un script maintenu de la même manière que vous référencez votre propre script. Vous pouvez référencer les scripts directement depuis le compartiment AWS-managed.

Scripts disponibles

Référencer un script

Référencez un script par son URI Amazon S3 dans le scriptLocation champ d'une action du cycle de vie. Les scripts sont stockés sous le aws-pcs-node-lifecycle-scripts préfixe du aws-pcs-repo-region compartiment AWS-managed de chacun. Région AWS Utilisez le bucket dans le même compartiment Région AWS que votre cluster.

s3://aws-pcs-repo-region/aws-pcs-node-lifecycle-scripts/script-vversion.sh

Chaque script est versionné à l'aide d'un versionnage sémantique. Vous pouvez épingler une version spécifique ou suivre la dernière version dans une version majeure :

Chaque script possède un fichier de SHA-256 somme de contrôle associé au même endroit avec un .sha256 suffixe (par exemple,mount-efs-v1.0.0.sh.sha256). Lisez la .sha256 valeur et définissez-la comme celle du scriptchecksum. L'agent vérifie ensuite l'intégrité du script lors du téléchargement. Pour de plus amples informations, veuillez consulter Intégrité du script (sommes de contrôle).

Versions de script disponibles

AWS Versionne chaque script indépendamment. Les tableaux suivants répertorient les versions disponibles de chaque script. Utilisez une version dans l'URI Amazon S3 du script, comme décrit dansRéférencer un script.

mount-efs.sh

mount-fsx-lustre.sh

configure-efs-homes.sh

configure-ldaps.sh

configure-cloudwatch-logs.sh

Exemple : montage d'un système de fichiers EFS à l'aide d'un script géré

L'exemple suivant fait référence au mount-efs.sh script maintenu dans le us-west-2 Région AWS. Vous transmettez des arguments sous forme d'indicateurs nommés. Pour les arguments du script, voirArguments du script.

aws pcs update-compute-node-group \
  --cluster-identifier my-cluster \
  --compute-node-group-identifier my-cng \
  --node-lifecycle-actions '{
    "stages": {
      "nodeBootstrapped": [
        {
          "name": "Mount EFS home directory",
          "scriptSource": {
            "scriptLocation": "s3://aws-pcs-repo-us-west-2/aws-pcs-node-lifecycle-scripts/mount-efs-v1.0.0.sh"
          },
          "arguments": ["--file-system-id", "fs-12345678", "--mount-point", "/shared"],
          "onError": "TERMINATE",
          "executionPolicy": "EVERY_BOOT"
        }
      ]
    }
  }'

Le rôle d'instance du nœud doit disposer d'une s3:GetObject autorisation pour l'objet de script. Les nœuds d'un sous-réseau privé peuvent accéder au compartiment via un point de terminaison VPC de passerelle S3. Pour de plus amples informations, veuillez consulter Emplacements de stockage des scripts.

Arguments du script

Chaque script utilise des arguments de type indicateur nommé. Transmettez chaque indicateur et sa valeur en tant qu'éléments distincts du arguments tableau (par exemple,["--file-system-id", "fs-12345678"]). Tous les scripts s'exécutent root et prennent en charge les systèmes d'exploitation AL2, AL2023, RHEL, Ubuntu et Rocky Linux.

mount-efs.sh

Avec l'iamoption par défaut, le rôle d'instance du nœud doit autoriser elasticfilesystem:ClientMount etelasticfilesystem:ClientWrite. Le sous-réseau du nœud doit avoir une cible de montage EFS dont le groupe de sécurité autorise le NFS entrant (TCP 2049) depuis le nœud.

mount-fsx-lustre.sh

Le sous-réseau du nœud doit atteindre le système de fichiers, et le groupe de sécurité du système de fichiers doit autoriser le trafic Lustre entrant (TCP 988 et 1018-1023 pour les clients qui utilisent des ports source réservés) depuis le nœud.

configure-efs-homes.sh

Ce script nécessite la prise en mkhomedir charge de amazon-efs-utilsnfs-utils, et PAM. Sur RHEL-family les nœudsoddjob, installezoddjob-mkhomedir, etauthselect. Sur AL2023, installez authselect explicitement. Sur Ubuntu, installezlibpam-modules. Les exigences IAM et réseau sont identiquesmount-efs.sh.

configure-ldaps.sh

Ce script nécessite sssdsssd-ldap, etsssd-tools. Sur RHEL-family les nœuds, cela nécessite également authselect ou authconfig etoddjob-mkhomedir. Sur Ubuntu, cela nécessitelibpam-modules.

Avec--secret-arn, le rôle d'instance du nœud doit autoriser secretsmanager:GetSecretValue le secret, et le nœud a besoin des python3 packages awscli et. La valeur du secret doit être le JSON du formulaire{"username": "<bind-dn>", "password": "<bind-password>"}. La liaison anonyme n'effectue aucun appel AWS d'API et ne nécessite aucune autorisation IAM.

configure-cloudwatch-logs.sh

Le script transmet le répertoire du journal des actions du cycle de vie (/var/log/amazon/pcs/lifecycle/actions). Le rôle d'instance du nœud doit autoriser logs:CreateLogGrouplogs:CreateLogStream, et logs:PutLogEvents sur le groupe de journaux cible. Utilisez ce script pour transférer les journaux hors instance à des fins de débogage post-mortem.