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.
# Résoudre les problèmes liés à Image Builder
EC2 Image Builder s'intègre à la surveillance et Services AWS au dépannage afin de vous aider à résoudre les problèmes liés à la création d'images. Image Builder suit et affiche la progression de chaque étape du processus de création d'image. Image Builder peut également exporter les journaux vers un emplacement Amazon S3 que vous fournissez.
Pour un dépannage avancé, vous pouvez exécuter des commandes et des scripts prédéfinis à l'aide de [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html).
**Topics**
+ [Résoudre les problèmes liés aux builds de pipelines](#troubleshooting-pipelines)
+ [Scénarios de résolution des problèmes](#image-builder-troubleshooting-scenarios)
## Résoudre les problèmes liés aux builds de pipelines
Si la génération d'un pipeline Image Builder échoue, Image Builder renvoie un message d'erreur décrivant l'échec. Image Builder renvoie également un `workflow execution ID` message d'échec, tel que celui de l'exemple de sortie suivant :
```
Workflow Execution ID: wf-12345abc-6789-0123-abc4-567890123abc failed with reason: …
```
Image Builder organise et dirige les actions de création d'images à travers une série d'étapes définies pour les étapes d'exécution de son processus de création d'image standard. Les étapes de création et de test du processus sont chacune associées à un flux de travail. Lorsqu'Image Builder exécute un flux de travail pour créer ou tester une nouvelle image, il génère une ressource de métadonnées de flux de travail qui assure le suivi des détails de l'exécution.
Les images de conteneur disposent d'un flux de travail supplémentaire qui s'exécute pendant la distribution.
**Informations détaillées sur les défaillances des instances d'exécution de votre flux de travail**
Pour résoudre un problème d'échec d'exécution de votre flux de travail, vous pouvez appeler les actions [GetWorkflowExecution](https://docs.aws.amazon.com/imagebuilder/latest/APIReference/API_GetWorkflowExecution.html)et [ListWorkflowStepExecutions](https://docs.aws.amazon.com/imagebuilder/latest/APIReference/API_GetWorkflowExecution.html)API avec votre`workflow execution ID`.
**Consulter les journaux d'exécution du flux de travail**
+ **Amazon CloudWatch Logs**
Image Builder publie des journaux d'exécution détaillés du flux de travail dans le groupe et le flux de CloudWatch journaux Image Builder suivants :
Avec CloudWatch Logs, vous pouvez rechercher les données des journaux à l'aide de modèles de filtre. Pour plus d'informations, consultez la section [Rechercher dans les données des journaux à l'aide de modèles de filtre](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SearchDataFilterPattern.html) dans le *guide de l'utilisateur Amazon CloudWatch Logs*.
+ **AWS CloudTrail**
Toutes les activités de construction sont également enregistrées CloudTrail si elles sont activées dans votre compte. Vous pouvez filtrer CloudTrail les événements par source`imagebuilder.amazonaws.com`. Vous pouvez également rechercher l'ID d'instance Amazon EC2 renvoyé dans le journal d'exécution pour obtenir plus de détails sur l'exécution du pipeline.
+ **Amazon Simple Storage Service (S3)**
Si vous avez spécifié un nom de compartiment S3 et un préfixe de clé dans la configuration de votre infrastructure, le chemin du journal d'exécution des étapes du flux de travail suit le modèle suivant :
```
S3://S3BucketName/KeyPrefix/ImageName/ImageVersion/ImageBuildVersion/WorkflowExecutionId/StepName
```
Les journaux que vous envoyez à votre compartiment S3 indiquent les étapes et les messages d'erreur relatifs à l'activité sur l'instance EC2 pendant le processus de création de l'image. Les journaux incluent les sorties de journal du gestionnaire de composants, les définitions des composants exécutés et le résultat détaillé (au format JSON) de toutes les étapes effectuées sur l'instance. Si vous rencontrez un problème, vous devez consulter ces fichiers, en commençant par`application.log`, pour diagnostiquer la cause du problème sur l'instance.
Par défaut, Image Builder arrête l'instance de build ou de test Amazon EC2 en cours d'exécution lorsque le pipeline échoue. Vous pouvez modifier les paramètres d'instance pour la ressource de configuration d'infrastructure utilisée par votre pipeline, afin de conserver votre instance de build ou de test à des fins de dépannage.
Pour modifier les paramètres de l'instance dans la console, vous devez décocher la case **Terminer l'instance en cas de défaillance** située dans la section **Paramètres de résolution** des problèmes de la ressource de configuration de votre infrastructure.
Vous pouvez également modifier les paramètres de l'instance à l'aide de la **update-infrastructure-configuration** commande figurant dans le AWS CLI. Définissez la `terminateInstanceOnFailure` valeur sur `false` dans le fichier JSON auquel la commande fait référence avec le `--cli-input-json` paramètre. Pour en savoir plus, consultez [Mettre à jour une configuration d'infrastructure](update-infra-config.md).
## Scénarios de résolution des problèmes
Cette section répertorie les scénarios de dépannage détaillés suivants :
+ [Accès refusé — code d'état 403](#ts-access-denied)
+ [Expect des délais de construction lors de la vérification de la disponibilité de l'agent Systems Manager sur l'instance de build](#ts-timeout-ssm-agent)
+ [Le disque secondaire Windows est hors ligne au lancement](#ts-win-disk-offline)
+ [La compilation échoue avec l'image de base renforcée CIS](#ts-cis-base)
+ [AssertInventoryCollection échoue (Systems Manager Automation)](#ts-ssm-mult-inventory)
Pour voir les détails d'un scénario, choisissez le titre du scénario pour le développer. Vous pouvez étendre plusieurs titres en même temps.
### Accès refusé — code d'état 403
#### Description
La construction du pipeline échoue avec le code d'état « AccessDenied : Accès refusé : 403 ».
#### Cause
Les causes possibles incluent :
+ Le profil d'instance ne dispose pas des [autorisations](set-up-ib-env.md#image-builder-IAM-prereq) requises pour accéder aux ressources APIs ou aux composants.
+ Le rôle de profil d'instance ne dispose pas des autorisations requises pour se connecter à Amazon S3. Cela se produit le plus souvent lorsque le rôle de profil d'instance ne dispose pas **PutObject**d'autorisations pour vos compartiments S3.
#### Solution
Selon la cause, ce problème peut être résolu comme suit :
+ **Le profil d'instance ne contient pas de politiques gérées** : ajoutez les politiques manquantes à votre rôle de profil d'instance. Exécutez ensuite à nouveau le pipeline.
+ **Le profil d'instance ne dispose pas d'autorisations d'écriture pour le compartiment S3** — Ajoutez une politique à votre rôle de profil d'instance qui accorde **PutObject**les autorisations d'écriture dans votre compartiment S3. Exécutez ensuite à nouveau le pipeline.
### Expect des délais de construction lors de la vérification de la disponibilité de l'agent Systems Manager sur l'instance de build
#### Description
La construction du pipeline échoue avec « status = 'TimedOut' » et « message d'échec = 'L'étape a expiré pendant que l'étape vérifie la disponibilité de l'agent Systems Manager sur les instances cibles ».
#### Cause
Les causes possibles incluent :
+ L'instance qui a été lancée pour effectuer les opérations de génération et exécuter les composants n'a pas pu accéder au point de terminaison Systems Manager.
+ Le profil d'instance ne dispose pas des [autorisations](set-up-ib-env.md#image-builder-IAM-prereq) requises.
#### Solution
Selon la cause possible, ce problème peut être résolu comme suit :
+ **Problème d'accès, sous-réseau privé** — Si vous créez un sous-réseau privé, assurez-vous d'avoir configuré des PrivateLink points de terminaison pour Systems Manager, Image Builder et, si vous souhaitez vous connecter, Amazon S3/. CloudWatch Pour plus d'informations sur la configuration des PrivateLink points de terminaison, consultez la section [Accès aux AWS services via AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html).
+ **Autorisations manquantes** : ajoutez les politiques gérées suivantes à votre rôle lié au service IAM pour Image Builder :
+ EC2InstanceProfileForImageBuilder
+ EC2InstanceProfileForImageBuilderECRContainerConstruit
+ Amazon SSMManaged InstanceCore
Pour plus d'informations sur le rôle lié au service Image Builder, consultez. [Utiliser des rôles liés à un service IAM pour Image Builder](image-builder-service-linked-role.md)
### Le disque secondaire Windows est hors ligne au lancement
#### Description
Lorsque le type d'instance utilisé pour créer une AMI Windows Image Builder ne correspond pas au type d'instance utilisé pour le lancement à partir de l'AMI, un problème peut survenir lorsque les volumes non root sont hors ligne au lancement. Cela se produit principalement lorsque l'instance de construction utilise une architecture plus récente que l'instance de lancement.
L'exemple suivant montre ce qui se passe lorsqu'une AMI Image Builder est créée sur un type d'instance EC2 Nitro et lancée sur une instance EC2 Xen :
**Type d'instance de build** : m5.large (Nitro)
**Type d'instance de lancement** : t2.medium (Xen)
```
PS C:\Users\Administrator> get-disk
Number Friendly Name Serial Number Health Status Operational Status Total Size Partition Style
------ ------------- ------------- ------------- ------------------ ---------- ---------------
0 AWS PVDISK vol0abc12d34e567f8a9 Healthy Online 30 GB MBR
1 AWS PVDISK vol1bcd23e45f678a9b0 Healthy Offline 8 GB MBR
```
#### Cause
En raison des paramètres par défaut de Windows, les disques récemment découverts ne sont pas automatiquement mis en ligne ni formatés. Lorsque le type d'instance est modifié sur EC2, Windows le traite comme de nouveaux disques découverts. Cela est dû au changement de moteur sous-jacent.
#### Solution
Nous vous recommandons d'utiliser le même système de types d'instances lors de la création de l'AMI Windows à partir duquel vous souhaitez le lancer. N'incluez pas de types d'instances créés sur différents systèmes dans la configuration de votre infrastructure. Si l'un des types d'instances que vous spécifiez utilise le système Nitro, il doit tous utiliser le système Nitro.
Pour plus d'informations sur les instances créées sur le système Nitro, consultez [Instances créées sur le système Nitro dans le](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances) guide de l'utilisateur *Amazon EC2*.
### La compilation échoue avec l'image de base renforcée CIS
#### Description
Vous utilisez une image de base renforcée CIS et la compilation échoue.
#### Cause
Lorsque le `/tmp` répertoire est classé comme`noexec`, cela peut entraîner l'échec d'Image Builder.
#### Solution
Choisissez un autre emplacement pour votre répertoire de travail dans le `workingDirectory` champ de la recette d'image. Pour plus d'informations, consultez la description du type de [ImageRecipe](https://docs.aws.amazon.com/imagebuilder/latest/APIReference/API_ImageRecipe.html)données.
### AssertInventoryCollection échoue (Systems Manager Automation)
#### Description
Systems Manager Automation montre un échec lors de l'étape `AssertInventoryCollection` d'automatisation.
#### Cause
Vous ou votre organisation avez peut-être créé une association Systems Manager State Manager qui collecte des informations d'inventaire pour les instances EC2. Si la collecte améliorée de métadonnées d'image est activée pour votre pipeline Image Builder (il s'agit de la valeur par défaut), Image Builder tente de créer une nouvelle association d'inventaire pour l'instance de génération. Toutefois, Systems Manager n'autorise pas plusieurs associations d'inventaire pour les instances gérées et empêche toute nouvelle association si elle existe déjà. Cela entraîne l'échec de l'opération et l'échec de la construction du pipeline.
#### Solution
Pour résoudre ce problème, désactivez la collecte améliorée des métadonnées d'image à l'aide de l'une des méthodes suivantes :
+ Mettez à jour votre pipeline d'images dans la console, pour désactiver la case à cocher **Activer la collecte améliorée de métadonnées**. Enregistrez vos modifications et exécutez une génération de pipeline.
Pour plus d'informations sur la mise à jour de votre pipeline d'images AMI à l'aide de la console EC2 Image Builder, [Mettre à jour les pipelines d'images AMI depuis la console](update-image-pipeline-console.md) consultez. Pour plus d'informations sur la mise à jour de votre pipeline d'images de conteneur à l'aide de la console EC2 Image Builder, [Mettre à jour un pipeline d'images de conteneur depuis la console](update-container-pipeline-console.md) consultez.
+ Vous pouvez également mettre à jour votre pipeline d'images à l'aide de la **update-image-pipeline** commande figurant dans le AWS CLI. Pour ce faire, incluez la `EnhancedImageMetadataEnabled` propriété dans votre fichier JSON, définie sur`false`. L'exemple suivant montre la propriété définie sur`false`.
```
{
"name": "MyWindows2019Pipeline",
"description": "Builds Windows 2019 Images",
"enhancedImageMetadataEnabled": false,
"imageRecipeArn": "arn:aws:imagebuilder:us-west-2:123456789012:image-recipe/my-example-recipe/2020.12.03",
"infrastructureConfigurationArn": "arn:aws:imagebuilder:us-west-2:123456789012:infrastructure-configuration/my-example-infrastructure-configuration",
"distributionConfigurationArn": "arn:aws:imagebuilder:us-west-2:123456789012:distribution-configuration/my-example-distribution-configuration",
"imageTestsConfiguration": {
"imageTestsEnabled": true,
"timeoutMinutes": 60
},
"schedule": {
"scheduleExpression": "cron(0 0 * * SUN *)",
"pipelineExecutionStartCondition": "EXPRESSION_MATCH_AND_DEPENDENCY_UPDATES_AVAILABLE"
},
"status": "ENABLED"
}
```
Pour éviter que cela ne se produise pour les nouveaux pipelines, décochez la case **Activer la collecte améliorée de métadonnées** lorsque vous créez un nouveau pipeline à l'aide de la console EC2 Image Builder, ou définissez la valeur de `EnhancedImageMetadataEnabled` la propriété dans votre fichier JSON sur lorsque vous créez votre pipeline `false` à l'aide AWS CLI du.