Résoudre les problèmes liés à EC2 Image Builder - EC2 Image Builder

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 à EC2 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.

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.

Recherchez des 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 GetWorkflowExecutionet ListWorkflowStepExecutionsAPI avec votreworkflow 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 :

    LogGroup:

    /aws/imagebuilder/ImageName

    LogStream (x.x.x/x) :

    ImageVersion/ImageBuildVersion

    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 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 sourceimagebuilder.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 parapplication.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 plus de détails, consultez Mettre à jour une configuration d'infrastructure.

Scénarios de résolution des problèmes

Cette section répertorie les scénarios de dépannage détaillés suivants :

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.

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 requises pour accéder aux API ou aux ressources des 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 PutObjectd'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 PutObjectles autorisations d'écriture dans votre compartiment S3. Exécutez ensuite à nouveau le pipeline.

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 la ou 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 requises.

Solution

En fonction de 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.

  • Autorisations manquantes : ajoutez les politiques gérées suivantes à votre rôle lié au service IAM pour Image Builder :

    • EC2 InstanceProfileForImageBuilder

    • EC2 ECR InstanceProfileForImageBuilder ContainerBuilds

    • Amazon SMS ManagedInstanceCore

    Pour plus d'informations sur le rôle lié au service Image Builder, consultez. Utiliser des rôles liés à un service IAM pour EC2 Image Builder

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 votre AMI Windows que celui à 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 guide de l'utilisateur Amazon EC2.

Description

Vous utilisez une image de base renforcée CIS et la compilation échoue.

Cause

Lorsque le /tmp répertoire est classé commenoexec, 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 ImageRecipedonnées.

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 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 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 surfalse. L'exemple suivant montre la propriété définie surfalse.

    { "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ésactivez la case à cocher 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.