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.
# Gérer les exécutions de tâches à l'aide du AWS CLI
Cette rubrique explique comment gérer les exécutions de tâches avec le AWS Command Line Interface (AWS CLI). Il décrit en détail les propriétés, telles que les paramètres de sécurité, le pilote et les divers paramètres de remplacement. Il inclut également des sous-rubriques qui couvrent les différentes manières de configurer la journalisation.
**Topics**
+ [Options de configuration d'une exécution de tâche](#emr-eks-jobs-parameters)
+ [Configuration d'une exécution de tâche pour utiliser les journaux Amazon S3](emr-eks-jobs-s3.md)
+ [Configurer une tâche exécutée pour utiliser Amazon CloudWatch Logs](emr-eks-jobs-cloudwatch.md)
+ [Liste des exécutions de tâches](#emr-eks-jobs-list)
+ [Description d'une exécution de tâche](#emr-eks-jobs-describe)
+ [Annulation d'une exécution de tâche](#emr-eks-jobs-cancel)
## Options de configuration d'une exécution de tâche
Utilisez les options suivantes pour configurer les paramètres d'exécution des tâches :
+ `--execution-role-arn` : vous devez indiquer un rôle IAM utilisé pour exécuter des tâches. Pour de plus amples informations, veuillez consulter [Utilisation des rôles d'exécution de tâches avec Amazon EMR on EKS](iam-execution-role.md).
+ `--release-label` : vous pouvez déployer Amazon EMR on EKS à l'aide d'Amazon EMR en version 5.32.0 et 6.2.0 ou ultérieure. Amazon EMR on EKS n'est pas pris en charge dans les versions précédentes d'Amazon EMR. Pour de plus amples informations, veuillez consulter [Versions Amazon EMR on EKS](emr-eks-releases.md).
+ `--job-driver` : le pilote de tâche est utilisé pour fournir des informations sur la tâche principale. Il s'agit d'un champ de type union dans lequel vous ne pouvez transmettre qu'une seule des valeurs correspondant au type de tâche que vous souhaitez exécuter. Les types de tâches prises en charge incluent :
+ Tâches de soumission Spark : utilisées pour exécuter une commande via la soumission Spark. Vous pouvez utiliser ce type de tâche pour exécuter Scala, SparkR PySpark, SparkSQL et toute autre tâche prise en charge par le biais de Spark Submit. Ce type de tâche a les paramètres suivants :
+ Point d'entrée : il s'agit de la référence HCFS (système de fichiers compatible Hadoop) au jar/py fichier principal que vous souhaitez exécuter.
+ EntryPointArguments - Il s'agit d'un tableau d'arguments que vous souhaitez transmettre à votre jar/py fichier principal. Vous devez gérer la lecture de ces paramètres à l'aide de votre code entrypoint. Chaque argument du tableau doit être séparé par une virgule. EntryPointArguments ne peut pas contenir de crochets ou de parenthèses, tels que (), \$1\$1 ou [].
+ SparkSubmitParameters - Il s'agit des paramètres Spark supplémentaires que vous souhaitez envoyer à la tâche. Utilisez ce paramètre pour remplacer les propriétés Spark par défaut, telles que la mémoire du pilote ou le nombre d'exécuteurs tels que —conf ou —class. Pour plus d'informations, consultez la rubrique [Lancement d'applications à l'aide de spark-submit](https://spark.apache.org/docs/latest/submitting-applications.html#launching-applications-with-spark-submit).
+ Tâches SQL Spark : utilisées pour exécuter un fichier de requête SQL via Spark SQL. Vous pouvez utiliser ce type de tâche pour exécuter des tâches Spark SQL. Ce type de tâche a les paramètres suivants :
+ Entrypoint : c'est la référence HCFS (système de fichiers compatible Hadoop) au fichier de requête SQL que vous souhaitez exécuter.
Pour obtenir la liste des paramètres Spark supplémentaires que vous pouvez utiliser pour une tâche Spark SQL, consultez [Exécution de scripts Spark SQL via l' StartJobRun API](emr-eks-jobs-spark-sql-parameters.md).
+ `--configuration-overrides` : vous pouvez remplacer les configurations par défaut des applications en fournissant un objet de configuration. Vous pouvez utiliser une syntaxe abrégée pour fournir la configuration, ou vous pouvez faire référence à l'objet de configuration dans un fichier JSON. Les objets de configuration sont composés d'une classification, de propriétés et de configurations imbriquées en option. Les propriétés sont les paramètres que vous souhaitez remplacer dans ce fichier. Vous pouvez spécifier plusieurs classifications pour plusieurs applications d'un seul objet JSON. Les classifications de configuration qui sont disponibles varient d'une version d'Amazon EMR à l'autre. Pour obtenir une liste des classifications de configurations disponibles pour chaque version d'Amazon EMR, consultez [Versions Amazon EMR on EKS](emr-eks-releases.md).
Si vous transmettez la même configuration dans un remplacement d'application et dans les paramètres de soumission Spark, les paramètres de soumission Spark auront la priorité. La liste complète des priorités de configuration suit, de la priorité la plus élevée à la plus faible.
+ Configuration fournie lors de la création de `SparkSession`.
+ Configuration fournie dans le cadre de `sparkSubmitParameters` en utilisant `—conf`.
+ Configuration fournie dans le cadre des remplacements d'applications.
+ Configurations optimisées choisies par Amazon EMR pour la version.
+ Configurations open-source par défaut pour l'application.
Pour surveiller les exécutions de tâches à l'aide d'Amazon CloudWatch ou d'Amazon S3, vous devez fournir les détails de configuration pour CloudWatch. Pour plus d’informations, consultez [Configuration d'une exécution de tâche pour utiliser les journaux Amazon S3](emr-eks-jobs-s3.md) et [Configurer une tâche exécutée pour utiliser Amazon CloudWatch Logs](emr-eks-jobs-cloudwatch.md). Si le compartiment ou le groupe de CloudWatch journaux S3 n'existe pas, Amazon EMR le crée avant de télécharger les journaux dans le compartiment.
+ Pour une liste supplémentaire d'options de configuration Kubernetes, consultez la rubrique [Propriétés Spark sur Kubernetes](https://spark.apache.org/docs/latest/running-on-kubernetes.html#configuration).
Les configurations Spark suivantes ne sont pas prises en charge.
+ `spark.kubernetes.authenticate.driver.serviceAccountName`
+ `spark.kubernetes.authenticate.executor.serviceAccountName`
+ `spark.kubernetes.namespace`
+ `spark.kubernetes.driver.pod.name`
+ `spark.kubernetes.container.image.pullPolicy`
+ `spark.kubernetes.container.image`
**Note**
Vous pouvez utiliser `spark.kubernetes.container.image` pour personnaliser les images Docker. Pour de plus amples informations, veuillez consulter [Personnalisation d'images Docker pour Amazon EMR on EKS](docker-custom-images.md).
# Configuration d'une exécution de tâche pour utiliser les journaux Amazon S3
Pour être en mesure de suivre l'avancement des tâches et de résoudre les problèmes d'échec, vous devez configurer vos tâches de manière à envoyer des informations de journal à Amazon S3, Amazon CloudWatch Logs ou aux deux. Cette rubrique vous aide à commencer à publier des journaux d'application sur Amazon S3 pour vos tâches lancées à l'aide d'Amazon EMR on EKS.
**Politique IAM des journaux S3**
Pour que vos tâches puissent envoyer des données de journal à Amazon S3, les autorisations suivantes doivent être incluses dans la politique d'autorisations du rôle d'exécution des tâches. *amzn-s3-demo-logging-bucket*Remplacez-le par le nom de votre bucket de journalisation.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
],
"Sid": "AllowS3Putobject"
}
]
}
```
------
**Note**
Amazon EMR on EKS peut également créer un compartiment Amazon S3. Si aucun compartiment Amazon S3 n'est disponible, incluez l'autorisation `“s3:CreateBucket”` dans la politique IAM.
Une fois que vous avez donné à votre rôle d'exécution les autorisations appropriées pour envoyer des journaux à Amazon S3, les données de vos journaux sont envoyées aux emplacements Amazon S3 suivants lorsque la `s3MonitoringConfiguration` est transmise dans la section `monitoringConfiguration` d'une demande `start-job-run`, comme indiqué dans [Gérer les exécutions de tâches à l'aide du AWS CLI](emr-eks-jobs-CLI.md).
+ Journaux des soumissionnaires -//*virtual-cluster-id*/jobs/ /containers/*logUri*/(*job-id*stderr.gz/stdout.gz) *pod-name*
+ Journaux de pilotes -//*virtual-cluster-id*/jobs/ *logUri* *job-id* /containers/ /spark- -driver/ (stderr.gz/stdout.gz*spark-application-id*) *job-id*
+ Journaux de l'exécuteur -//*virtual-cluster-id*/jobs/ *logUri* *job-id* /containers///(stderr.gz/stdout.gz*spark-application-id*) *executor-pod-name*
# Configurer une tâche exécutée pour utiliser Amazon CloudWatch Logs
Pour suivre l'avancement des tâches et résoudre les problèmes d'échec, vous devez configurer vos tâches de manière à envoyer des informations de journal à Amazon S3, Amazon CloudWatch Logs ou aux deux. Cette rubrique vous aide à commencer à utiliser CloudWatch les journaux sur vos tâches lancées avec Amazon EMR sur EKS. Pour plus d'informations sur CloudWatch les journaux, consultez la section [Surveillance des fichiers journaux](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatchLogs.html) dans le guide de CloudWatch l'utilisateur Amazon.
**CloudWatch Politique IAM des journaux**
Pour que vos tâches envoient des données de journal à CloudWatch Logs, les autorisations suivantes doivent être incluses dans la politique d'autorisation relative au rôle d'exécution des tâches. Remplacez *my\$1log\$1group\$1name* et *my\$1log\$1stream\$1prefix* par les noms de votre groupe de CloudWatch journaux et les noms de vos flux de journaux, respectivement. Amazon EMR on EKS crée le groupe de journaux et le flux de journaux s'ils n'existent pas, à condition que l'ARN du rôle d'exécution dispose des autorisations appropriées.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:CreateLogStream",
"logs:DescribeLogGroups",
"logs:DescribeLogStreams"
],
"Resource": [
"arn:aws:logs:*:*:*"
],
"Sid": "AllowLOGSCreatelogstream"
},
{
"Effect": "Allow",
"Action": [
"logs:PutLogEvents"
],
"Resource": [
"arn:aws:logs:*:*:log-group:my_log_group_name:log-stream:my_log_stream_prefix/*"
],
"Sid": "AllowLOGSPutlogevents"
}
]
}
```
------
**Note**
Amazon EMR on EKS peut également créer un flux de journaux. S'il n'existe pas de flux de journaux, la politique IAM doit inclure l'autorisation `"logs:CreateLogGroup"`.
Une fois que vous avez accordé les autorisations appropriées à votre rôle d'exécution, votre application envoie ses données de journal à CloudWatch Logs lorsqu'elles `cloudWatchMonitoringConfiguration` sont transmises dans la `monitoringConfiguration` section d'une `start-job-run` demande, comme indiqué dans[Gérer les exécutions de tâches à l'aide du AWS CLI](emr-eks-jobs-CLI.md).
Dans l'`StartJobRun`API, *log\$1group\$1name * il s'agit du nom du groupe de journaux pour CloudWatch et *log\$1stream\$1prefix* du préfixe du nom du flux de journaux pour CloudWatch. Vous pouvez afficher et y faire des recherches dans la AWS Management Console.
+ Journaux de l'expéditeur -*logGroup*//*virtual-cluster-id*/jobs/ *logStreamPrefix* /containers//(*job-id*stderr/stdout) *pod-name*
+ Journaux de pilotes -*logGroup*//*virtual-cluster-id*/jobs/ *logStreamPrefix* *job-id* /containers/ /spark- -driver/ (stderrstdout*spark-application-id*) *job-id*
+ Journaux de l'exécuteur -*logGroup*//*virtual-cluster-id*/jobs/ *logStreamPrefix* *job-id* /containers///(*spark-application-id*stderr/stdout) *executor-pod-name*
## Liste des exécutions de tâches
Vous pouvez exécuter `list-job-run` pour afficher l'état des exécutions de tâches, comme le montre l'exemple ci-dessous.
```
aws emr-containers list-job-runs --virtual-cluster-id
```
## Description d'une exécution de tâche
Vous pouvez exécuter `describe-job-run` pour obtenir plus de détails sur la tâche, tels que l'état de la tâche, les détails de l'état et le nom de la tâche, comme le montre l'exemple ci-dessous.
```
aws emr-containers describe-job-run --virtual-cluster-id cluster-id --id job-run-id
```
## Annulation d'une exécution de tâche
Vous pouvez exécuter `cancel-job-run` pour annuler des tâches en cours d'exécution, comme le montre l'exemple ci-dessous.
```
aws emr-containers cancel-job-run --virtual-cluster-id cluster-id --id job-run-id
```