Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Probleme mit Image Builder beheben
EC2 Image Builder lässt sich AWS-Services zur Überwachung und Fehlerbehebung integrieren, um Sie bei der Behebung von Problemen bei der Image-Erstellung zu unterstützen. Image Builder verfolgt und zeigt den Fortschritt für jeden Schritt im Imageerstellungsprozess an. Darüber hinaus kann Image Builder Protokolle an einen von Ihnen angegebenen Amazon S3 S3-Speicherort exportieren.
Für eine erweiterte Problembehandlung können Sie mit Run [Command vordefinierte Befehle und Skripts AWS Systems Manager ausführen](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html).
**Topics**
+ [Problembehandlung bei Pipeline-Buil](#troubleshooting-pipelines)
+ [Fehlerbehebungsszenarien](#image-builder-troubleshooting-scenarios)
## Problembehandlung bei Pipeline-Buil
Wenn ein Image Builder-Pipeline-Build fehlschlägt, gibt Image Builder eine Fehlermeldung zurück, die den Fehler beschreibt. Image Builder gibt auch a `workflow execution ID` in der Fehlermeldung zurück, wie in der folgenden Beispielausgabe:
```
Workflow Execution ID: wf-12345abc-6789-0123-abc4-567890123abc failed with reason: …
```
Image Builder organisiert und leitet die Aktionen zur Image-Erstellung über eine Reihe von Schritten, die für die Laufzeitphasen in seinem standardmäßigen Image-Erstellungsprozess definiert sind. Den Erstellungs- und Testphasen des Prozesses ist jeweils ein Workflow zugeordnet. Wenn Image Builder einen Workflow zum Erstellen oder Testen eines neuen Images ausführt, generiert es eine Workflow-Metadatenressource, die die Laufzeitdetails verfolgt.
Container-Images verfügen über einen zusätzlichen Workflow, der während der Verteilung ausgeführt wird.
**Recherchieren Sie in Ihrem Workflow nach Einzelheiten zu Ausfällen von Runtime-Instances**
Um einen Laufzeitfehler für Ihren Workflow zu beheben, können Sie die [GetWorkflowExecution](https://docs.aws.amazon.com/imagebuilder/latest/APIReference/API_GetWorkflowExecution.html)und [ListWorkflowStepExecutions](https://docs.aws.amazon.com/imagebuilder/latest/APIReference/API_GetWorkflowExecution.html)API-Aktionen mit Ihrem aufrufen`workflow execution ID`.
**Überprüfen Sie die Workflow-Laufzeitprotokolle**
+ ** CloudWatch Amazon-Protokolle**
Image Builder veröffentlicht detaillierte Workflow-Ausführungsprotokolle in der folgenden Image Builder CloudWatch Builder-Protokollgruppe und dem folgenden Stream:
Mit CloudWatch Logs können Sie Protokolldaten mit Filtermustern durchsuchen. Weitere Informationen finden Sie unter [Durchsuchen von Protokolldaten mithilfe von Filtermustern](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SearchDataFilterPattern.html) im *Amazon CloudWatch Logs-Benutzerhandbuch*.
+ **AWS CloudTrail**
Alle Build-Aktivitäten werden ebenfalls protokolliert CloudTrail , wenn sie in Ihrem Konto aktiviert sind. Sie können CloudTrail Ereignisse nach der Quelle filtern`imagebuilder.amazonaws.com`. Alternativ können Sie nach der Amazon EC2 EC2-Instance-ID suchen, die im Ausführungsprotokoll zurückgegeben wird, um weitere Details zur Pipeline-Ausführung zu erhalten.
+ **Amazon Simple Storage Service (S3)**
Wenn Sie in Ihrer Infrastrukturkonfiguration einen S3-Bucket-Namen und ein key prefix angegeben haben, folgt der Laufzeitprotokollpfad des Workflow-Schritts diesem Muster:
```
S3://S3BucketName/KeyPrefix/ImageName/ImageVersion/ImageBuildVersion/WorkflowExecutionId/StepName
```
Die Protokolle, die Sie an Ihren S3-Bucket senden, zeigen die Schritte und Fehlermeldungen für Aktivitäten auf der EC2-Instance während des Image-Build-Prozesses. Die Protokolle enthalten Protokollausgaben des Komponenten-Managers, die Definitionen der Komponenten, die ausgeführt wurden, und die detaillierte Ausgabe (in JSON) aller Schritte, die auf der Instance ausgeführt wurden. Wenn Sie auf ein Problem stoßen, sollten Sie diese Dateien zunächst überprüfen`application.log`, um die Ursache des Problems auf der Instanz zu diagnostizieren.
Standardmäßig fährt Image Builder die Amazon EC2 EC2-Build- oder Test-Instance herunter, die ausgeführt wird, wenn die Pipeline ausfällt. Sie können die Instance-Einstellungen für die Infrastrukturkonfigurationsressource ändern, die Ihre Pipeline verwendet, um Ihre Build- oder Test-Instance zur Fehlerbehebung beizubehalten.
Um die Instanzeinstellungen in der Konsole zu ändern, müssen Sie das Kontrollkästchen **Instanz bei Ausfall beenden** deaktivieren, das sich im Bereich **Einstellungen zur Fehlerbehebung** Ihrer Infrastrukturkonfigurationsressource befindet.
Sie können die Instanzeinstellungen auch mit dem **update-infrastructure-configuration** Befehl in der ändern AWS CLI. Legen Sie den `terminateInstanceOnFailure` Wert `false` in der JSON-Datei, auf die der Befehl mit dem `--cli-input-json` Parameter verweist, auf fest. Details hierzu finden Sie unter [Aktualisieren Sie eine Infrastrukturkonfiguration](update-infra-config.md).
## Fehlerbehebungsszenarien
In diesem Abschnitt werden die folgenden detaillierten Problemlösungsszenarien aufgeführt:
+ [Zugriff verweigert — Statuscode 403](#ts-access-denied)
+ [Timeout beim Erstellen während der Überprüfung der Verfügbarkeit des Systems Manager Agents auf der Build-Instanz](#ts-timeout-ssm-agent)
+ [Die sekundäre Windows-Festplatte ist beim Start offline](#ts-win-disk-offline)
+ [Der Build schlägt mit dem CIS-gehärteten Basis-Image fehl](#ts-cis-base)
+ [AssertInventoryCollection schlägt fehl (Systems Manager Automation)](#ts-ssm-mult-inventory)
Um die Details eines Szenarios zu sehen, wählen Sie den Titel des Szenarios aus, um es zu erweitern. Sie können mehrere Titel gleichzeitig erweitern lassen.
### Zugriff verweigert — Statuscode 403
#### Description
Der Pipeline-Build schlägt mit dem Statuscode "AccessDenied: Zugriff verweigert: 403“ fehl.
#### Ursache
Mögliche Gründe hierfür sind:
+ Das Instanzprofil verfügt nicht über die erforderlichen [Zugriffsberechtigungen für](set-up-ib-env.md#image-builder-IAM-prereq) Komponentenressourcen. APIs
+ In der Instance-Profilrolle fehlen Berechtigungen, die für die Anmeldung bei Amazon S3 erforderlich sind. In den meisten Fällen tritt dies auf, wenn die Instance-Profilrolle keine **PutObject**Berechtigungen für Ihre S3-Buckets hat.
#### Lösung
Je nach Ursache kann dieses Problem wie folgt behoben werden:
+ Im **Instanzprofil fehlen verwaltete Richtlinien** — Fügen Sie die fehlenden Richtlinien zu Ihrer Instanzprofilrolle hinzu. Führen Sie dann die Pipeline erneut aus.
+ **Dem Instanzprofil fehlen Schreibberechtigungen für den S3-Bucket** — Fügen Sie Ihrer Instanzprofilrolle eine Richtlinie hinzu, die **PutObject**Schreibberechtigungen für Ihren S3-Bucket gewährt. Führen Sie dann die Pipeline erneut aus.
### Timeout beim Erstellen während der Überprüfung der Verfügbarkeit des Systems Manager Agents auf der Build-Instanz
#### Description
Der Pipeline-Build schlägt mit „Status = TimedOut ''“ und „Fehlermeldung = 'Timeout für den Schritt bei der Überprüfung der Verfügbarkeit des Systems Manager Manager-Agenten auf den Zielinstanzen“ fehl“.
#### Ursache
Mögliche Gründe hierfür sind:
+ Die Instanz, die gestartet wurde, um die Build-Operationen und Komponenten auszuführen, konnte nicht auf den Systems Manager Manager-Endpunkt zugreifen.
+ Das Instanzprofil verfügt nicht über die erforderlichen [Berechtigungen](set-up-ib-env.md#image-builder-IAM-prereq).
#### Lösung
Abhängig von der möglichen Ursache kann dieses Problem wie folgt behoben werden:
+ **Zugriffsproblem, privates Subnetz** — Wenn Sie ein privates Subnetz einbauen, stellen Sie sicher, dass Sie PrivateLink Endpunkte für Systems Manager, Image Builder und, falls Sie protokollieren möchten, Amazon S3 S3/ eingerichtet haben. CloudWatch [Weitere Informationen zum Einrichten von PrivateLink Endpunkten finden Sie unter Access Services through. AWSAWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html)
+ **Fehlende Berechtigungen** — Fügen Sie Ihrer mit dem IAM-Dienst verknüpften Rolle für Image Builder die folgenden verwalteten Richtlinien hinzu:
+ EC2InstanceProfileForImageBuilder
+ EC2InstanceProfileForImageBuilderECRContainerBuilds
+ Amazon SSMManaged InstanceCore
Weitere Informationen zur dienstverknüpften Image Builder Builder-Rolle finden Sie unter[Verwenden Sie mit dem IAM-Dienst verknüpfte Rollen für Image Builder](image-builder-service-linked-role.md).
### Die sekundäre Windows-Festplatte ist beim Start offline
#### Description
Wenn der Instance-Typ, der zum Erstellen eines Image Builder Builder-Windows-AMI verwendet wird, nicht mit dem Instance-Typ übereinstimmt, der zum Starten über das AMI verwendet wird, kann ein Problem auftreten, wenn Nicht-Root-Volumes beim Start offline sind. Dies ist in erster Linie der Fall, wenn die Build-Instance eine neuere Architektur als die Startinstanz verwendet.
Das folgende Beispiel zeigt, was passiert, wenn ein Image Builder Builder-AMI auf einem EC2-Nitro-Instance-Typ basiert und auf einer EC2-Xen-Instance gestartet wird:
**Build-Instance-Typ**: m5.large (Nitro)
**Instanztyp starten**: 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
```
#### Ursache
Aufgrund der Windows-Standardeinstellungen werden neu entdeckte Festplatten nicht automatisch online geschaltet und formatiert. Wenn der Instanztyp auf EC2 geändert wird, behandelt Windows dies so, als würden neue Festplatten erkannt. Das liegt an der zugrunde liegenden Treiberänderung.
#### Lösung
Wir empfehlen, dass Sie beim Erstellen Ihres Windows-AMI, von dem aus Sie starten möchten, dasselbe System von Instance-Typen verwenden. Nehmen Sie in Ihrer Infrastrukturkonfiguration keine Instance-Typen auf, die auf unterschiedlichen Systemen basieren. Wenn einer der von Ihnen angegebenen Instance-Typen das Nitro-System verwendet, sollten alle das Nitro-System verwenden.
Weitere Informationen zu Instances, die auf dem Nitro-System basieren, finden Sie im *Amazon EC2 EC2-Benutzerhandbuch* unter [Instances, die auf dem Nitro-System basieren](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances).
### Der Build schlägt mit dem CIS-gehärteten Basis-Image fehl
#### Description
Sie verwenden ein CIS-gehärtetes Basis-Image und der Build schlägt fehl.
#### Ursache
Wenn das `/tmp` Verzeichnis als klassifiziert ist`noexec`, kann dies dazu führen, dass Image Builder fehlschlägt.
#### Lösung
Wählen Sie im `workingDirectory` Feld des Image-Rezepts einen anderen Speicherort für Ihr Arbeitsverzeichnis. Weitere Informationen finden Sie in der Beschreibung des [ImageRecipe](https://docs.aws.amazon.com/imagebuilder/latest/APIReference/API_ImageRecipe.html)Datentyps.
### AssertInventoryCollection schlägt fehl (Systems Manager Automation)
#### Description
Systems Manager Automation zeigt einen Fehler im `AssertInventoryCollection` Automatisierungsschritt an.
#### Ursache
Möglicherweise haben Sie oder Ihre Organisation eine Systems Manager State Manager-Zuordnung erstellt, die Inventarinformationen für EC2-Instances sammelt. Wenn die erweiterte Erfassung von Bildmetadaten für Ihre Image Builder-Pipeline aktiviert ist (dies ist die Standardeinstellung), versucht Image Builder, eine neue Inventarzuordnung für die Build-Instanz zu erstellen. Systems Manager lässt jedoch nicht mehrere Inventarzuordnungen für verwaltete Instanzen zu und verhindert eine neue Zuordnung, falls bereits eine vorhanden ist. Dadurch schlägt der Vorgang fehl und der Pipeline-Build schlägt fehl.
#### Lösung
Um dieses Problem zu beheben, deaktivieren Sie die erweiterte Erfassung von Bildmetadaten mit einer der folgenden Methoden:
+ Aktualisieren Sie Ihre Image-Pipeline in der Konsole, um das Kontrollkästchen **Erweiterte Metadatensammlung aktivieren** zu deaktivieren. Speichern Sie Ihre Änderungen und führen Sie einen Pipeline-Build aus.
Weitere Informationen zur Aktualisierung Ihrer AMI-Image-Pipeline mithilfe der EC2 Image Builder Builder-Konsole finden Sie unter[Aktualisieren Sie AMI-Image-Pipelines von der Konsole aus](update-image-pipeline-console.md). Weitere Informationen zur Aktualisierung Ihrer Container-Image-Pipeline mithilfe der EC2 Image Builder Builder-Konsole finden Sie unter[Aktualisieren Sie eine Container-Image-Pipeline von der Konsole aus](update-container-pipeline-console.md).
+ Sie können Ihre Image-Pipeline auch mit dem **update-image-pipeline** Befehl in der AWS CLI aktualisieren. Fügen Sie dazu die `EnhancedImageMetadataEnabled` Eigenschaft in Ihre JSON-Datei ein und setzen Sie sie auf`false`. Das folgende Beispiel zeigt die Eigenschaft, die auf gesetzt ist`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"
}
```
Um zu verhindern, dass dies bei neuen Pipelines passiert, deaktivieren Sie das Kontrollkästchen **Erweiterte Metadatensammlung aktivieren**, wenn Sie mit der EC2 Image Builder Builder-Konsole eine neue Pipeline erstellen, oder setzen Sie den Wert der `EnhancedImageMetadataEnabled` Eigenschaft in Ihrer JSON-Datei auf, `false` wenn Sie Ihre Pipeline mit dem erstellen. AWS CLI