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.
# Beheben Sie Probleme mit der EC2/On-Premises-Bereitstellung
**Topics**
+ [CodeDeploy Fehler beim Fehlen der Anmeldeinformationen für das Plugin CommandPoller](#troubleshooting-agent-commandpoller-error)
+ [Die Bereitstellung schlägt fehl und es wird die Meldung „Validierung der PKCS7 signierten Nachricht fehlgeschlagen“ angezeigt](#troubleshooting-deployments-agent-SHA-256)
+ [Bereitstellung oder erneute Bereitstellung derselben Dateien in denselben Instance-Standorten schlägt fehl mit dem Fehler „The deployment failed because a specified file already exists at this location“](#troubleshooting-same-files-different-app-name)
+ [Lange Dateipfade führen zu der Fehlermeldung „Keine solche Datei oder kein solches Verzeichnis“](#troubleshooting-long-file-paths)
+ [Lange laufende Prozesse können zum Fehlschlagen von Bereitstellungen führen](#troubleshooting-long-running-processes)
+ [Behebung eines fehlgeschlagenen AllowTraffic Lebenszyklusereignisses, bei dem kein Fehler in den Bereitstellungsprotokollen gemeldet wurde](#troubleshooting-deployments-allowtraffic-no-logs)
+ [Behebung eines Fehlers oder eines ApplicationStop BeforeBlockTraffic Ereignisses im Lebenszyklus einer AfterBlockTraffic Bereitstellung](#troubleshooting-deployments-lifecycle-event-failures)
+ [Behebung eines fehlgeschlagenen DownloadBundle Deployment-Lifecycle-Ereignisses mit UnknownError: nicht zum Lesen geöffnet](#troubleshooting-deployments-downloadbundle)
+ [Durch Fehlerbehebung bei allen Lebenszyklusereignissen wurden Fehler übersprungen](#troubleshooting-skipped-lifecycle-events)
+ [PowerShell Windows-Skripts verwenden standardmäßig nicht die 64-Bit-Version von Windows PowerShell](#troubleshooting-deployments-powershell)
**Anmerkung**
Die Ursachen für viele Bereitstellungsfehler können identifiziert werden, indem Sie die während der Bereitstellung erstellten Protokolldateien überprüfen. Der Einfachheit halber empfehlen wir, Amazon CloudWatch Logs zu verwenden, um Protokolldateien zentral zu überwachen, anstatt sie instanzweise anzuzeigen. Weitere Informationen finden Sie unter [ CodeDeploy Logs in der CloudWatch Logs-Konsole anzeigen](https://aws.amazon.com/blogs/devops/view-aws-codedeploy-logs-in-amazon-cloudwatch-console/).
**Tipp**
*Ein Runbook, das viele Problembehandlungsaufgaben im Zusammenhang mit EC2/lokalen Bereitstellungen automatisiert, finden Sie [AWSSupport-TroubleshootCodeDeploy](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awssupport-troubleshootcodedeploy.html)in der AWS Runbook-Referenz zu Systems Manager Automation.*
## CodeDeploy Fehler beim Fehlen der Anmeldeinformationen für das Plugin CommandPoller
Wenn Sie eine Fehlermeldung wie `InstanceAgent::Plugins::CodeDeployPlugin::CommandPoller: Missing credentials - please check if this instance was started with an IAM instance profile` erhalten, kann dies eine der folgenden Ursachen haben:
+ Der Instanz, für die Sie die Bereitstellung durchführen, ist kein IAM-Instanzprofil zugeordnet.
+ Für Ihr IAM-Instanzprofil sind nicht die richtigen Berechtigungen konfiguriert.
Ein IAM-Instance-Profil gewährt dem CodeDeploy Agenten die Erlaubnis, mit Amazon S3 zu kommunizieren CodeDeploy und Ihre Version von Amazon S3 herunterzuladen. Informationen zu EC2-Instances finden Sie unter [Identitäts- und Zugriffsmanagement für AWS CodeDeploy](security-iam.md). Informationen zu lokalen Instances finden Sie unter [Arbeiten mit lokalen Instanzen für CodeDeploy](instances-on-premises.md).
## Die Bereitstellung schlägt fehl und es wird die Meldung „Validierung der PKCS7 signierten Nachricht fehlgeschlagen“ angezeigt
Diese Fehlermeldung weist darauf hin, dass auf der Instanz eine Version des CodeDeploy Agenten ausgeführt wird, die nur den SHA-1-Hash-Algorithmus unterstützt. Die Support für den SHA-2-Hash-Algorithmus wurde in Version 1.0.1.854 des CodeDeploy Agenten eingeführt, die im November 2015 veröffentlicht wurde. Ab dem 17. Oktober 2016 schlagen Bereitstellungen fehl, wenn eine Version des CodeDeploy Agenten vor 1.0.1.854 installiert ist. Weitere Informationen finden Sie unter [AWS So wechseln Sie zum SHA256 Hash-Algorithmus für SSL-Zertifikate](https://aws.amazon.com/security/security-bulletins/aws-to-switch-to-sha256-hash-algorithm-for-ssl-certificates/), [HINWEIS: CodeDeploy Host-Agents, die älter als Version 1.0.1.85 sind, außer Dienst](https://forums.aws.amazon.com/thread.jspa?threadID=223319) stellen, und. [Aktualisieren Sie den Agenten CodeDeploy](codedeploy-agent-operations-update.md)
## Bereitstellung oder erneute Bereitstellung derselben Dateien in denselben Instance-Standorten schlägt fehl mit dem Fehler „The deployment failed because a specified file already exists at this location“
Wenn CodeDeploy versucht wird, eine Datei auf einer Instance bereitzustellen, aber eine Datei mit demselben Namen bereits am angegebenen Zielspeicherort existiert, schlägt die Bereitstellung für diese Instanz möglicherweise fehl. Möglicherweise erhalten Sie die Fehlermeldung „Die Bereitstellung ist fehlgeschlagen, weil eine angegebene Datei bereits an diesem Speicherort vorhanden ist:*location-name*.“ Der Grund hierfür ist, dass CodeDeploy bei jeder Bereitstellung zuerst alle Dateien aus der vorherigen Bereitstellung löscht, die in einer Cleanup-Protokolldatei aufgelistet sind. Wenn sich in den Zielinstallationsordnern Dateien befinden, die nicht in dieser Bereinigungsdatei aufgeführt sind, interpretiert der CodeDeploy Agent dies standardmäßig als Fehler und schlägt bei der Bereitstellung fehl.
**Anmerkung**
Auf Amazon Linux-, RHEL- und Ubuntu Server-Instances befindet sich die Cleanup-Datei unter. `/opt/codedeploy-agent/deployment-root/deployment-instructions/` Auf Windows Server-Instances lautet der Speicherort. `C:\ProgramData\Amazon\CodeDeploy\deployment-instructions\`
Am einfachsten lässt sich dieser Fehler verhindern, indem Sie eine andere Option als das Standardverhalten für das Fehlschlagen der Bereitstellung angeben. Für jede Bereitstellung können Sie wählen, ob die Bereitstellung fehlschlagen soll, die nicht in der Cleanup-Datei aufgeführten Dateien überschrieben werden oder die bereits in der Instance vorhandenen Dateien beibehalten werden sollen.
Die Option zum Überschreiben ist beispielsweise nützlich, wenn Sie nach der letzten Bereitstellung manuell eine Datei in einer Instance platziert haben, aber dann eine Datei mit demselben Namen zu der nächsten Anwendungsrevision hinzugefügt haben.
Sie können die Option zum Beibehalten für Dateien wählen, die Sie in der Instance platzieren, die Teil der nächsten Bereitstellung sein soll, ohne sie dem Anwendungsrevisionspaket hinzuzufügen. Die Option Retain ist auch nützlich, wenn sich Ihre Anwendungsdateien bereits in Ihrer Produktionsumgebung befinden und Sie sie CodeDeploy zum ersten Mal bereitstellen möchten. Weitere Informationen erhalten Sie unter [Erstellen Sie eine EC2/On-Premises-Compute-Plattform-Bereitstellung (Konsole)](deployments-create-console.md) und [Rollback-Verhalten bei vorhandenem Inhalt](deployments-rollback-and-redeploy.md#deployments-rollback-and-redeploy-content-options).
### Beheben von `The deployment failed because a specified file already exists at this location`-Bereitstellungsfehlern
Wenn Sie keine Option zum Überschreiben oder Beibehalten von Inhalten angeben, die CodeDeploy in Ihren Ziel-Bereitstellungsstandorten erkennt (oder wenn Sie keine Bereitstellungsoption für die Behandlung vorhandener Inhalte in einem programmatischen Befehl angeben), können Sie den Fehler beheben.
Die folgenden Informationen gelten nur, wenn Sie angeben, dass Inhalte nicht beibehalten oder überschrieben werden sollen.
Wenn Sie versuchen, Dateien mit denselben Namen und Speicherorten erneut bereitzustellen, ist es wahrscheinlicher, dass die erneute Bereitstellung erfolgreich ist, wenn Sie den Anwendungsnamen und die Bereitstellungsgruppe mit derselben zugrunde liegenden Bereitstellungsgruppen-ID angeben, die Sie zuvor verwendet haben. CodeDeploy verwendet die zugrunde liegende Bereitstellungsgruppen-ID, um Dateien zu identifizieren, die vor einer erneuten Bereitstellung entfernt werden müssen.
Das Bereitstellen neuer Dateien oder die erneute Bereitstellung der gleichen Dateien an denselben Standorten in Instances kann aus folgenden Gründen fehlschlagen:
+ Sie haben einen anderen Anwendungsnamen für eine erneute Bereitstellung der gleichen Revision in denselben Instances angegeben. Die erneute Bereitstellung schlägt fehl, weil auch beim gleichen Bereitstellungsgruppennamen die Verwendung eines anderen Anwendungsnamens bedeutet, dass eine andere zugrunde liegende Bereitstellungsgruppen-ID verwendet wird.
+ Sie haben eine Bereitstellungsgruppe für eine Anwendung gelöscht und neu erstellt und dann versucht, die gleiche Revision für die Bereitstellungsgruppe erneut bereitzustellen. Die erneute Bereitstellung schlägt fehl, da selbst wenn der Name der Bereitstellungsgruppe identisch ist, CodeDeploy auf eine andere zugrunde liegende Bereitstellungsgruppen-ID verwiesen wird.
+ Sie haben eine Anwendung und eine Bereitstellungsgruppe in CodeDeploy gelöscht und dann eine neue Anwendung und Bereitstellungsgruppe mit denselben Namen wie die gelöschten erstellt. Danach haben Sie versucht, eine Revision, die für die vorherige Bereitstellungsgruppe bereitgestellt wurde, erneut für die neue mit demselben Namen bereitzustellen. Die erneute Bereitstellung schlägt fehl, da die Namen der Anwendung und der Bereitstellungsgruppe zwar identisch sind, aber CodeDeploy dennoch auf die ID der Bereitstellungsgruppe verwiesen wird, die Sie gelöscht haben.
+ Sie haben eine Revision für eine Bereitstellungsgruppe bereitgestellt und dann dieselbe Revision für eine andere Bereitstellungsgruppe für dieselben Instances bereitgestellt. Die zweite Bereitstellung schlägt fehl, da CodeDeploy auf eine andere zugrunde liegende Bereitstellungsgruppen-ID verweist.
+ Sie haben eine Revision für eine Bereitstellungsgruppe bereitgestellt und dann eine andere Revision für eine andere Bereitstellungsgruppe für dieselben Instances bereitgestellt. Es ist mindestens eine Datei mit demselben Namen an demselben Standort vorhanden, die in der zweiten Bereitstellungsgruppe bereitgestellt werden soll. Die zweite Bereitstellung schlägt fehl, weil die vorhandene Datei CodeDeploy nicht entfernt wird, bevor die zweite Bereitstellung gestartet wird. Beide Bereitstellungen verweisen auf unterschiedliche Bereitstellungsgruppen. IDs
+ Sie haben eine Revision in bereitgestellt CodeDeploy, aber es gibt mindestens eine Datei mit demselben Namen und am selben Speicherort. Die Bereitstellung schlägt fehl, da die vorhandene Datei standardmäßig CodeDeploy nicht entfernt wird, bevor die Bereitstellung gestartet wird.
Um diese Situationen zu beheben, führen Sie einen der folgenden Schritte aus:
+ Entfernen Sie die Dateien aus den Standorten und Instances, für die sie zuvor bereitgestellt wurden, und versuchen Sie dann die Bereitstellung erneut.
+ Geben Sie in der AppSpec Datei Ihrer Revision entweder bei den Ereignissen im Lebenszyklus ApplicationStop oder bei der BeforeInstall Bereitstellung ein benutzerdefiniertes Skript an, um Dateien an beliebigen Speicherorten zu löschen, die mit den Dateien übereinstimmen, die Ihre Revision gerade installieren wird.
+ Stellen Sie die Dateien in Standorten oder Instances (erneut) bereit, die nicht Teil vorheriger Bereitstellungen waren.
+ Bevor Sie eine Anwendung oder eine Bereitstellungsgruppe löschen, stellen Sie eine Revision bereit, die eine AppSpec Datei enthält, in der angegeben ist, dass keine Dateien in die Instanzen kopiert werden sollen. Geben Sie für die Bereitstellung den Namen der Anwendung und der Bereitstellungsgruppe an, die dieselbe zugrunde liegende Anwendung und Bereitstellungsgruppe verwenden IDs wie die, die Sie löschen möchten. (Sie können den [get-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-group.html)Befehl verwenden, um die Bereitstellungsgruppen-ID abzurufen.) CodeDeployverwendet die zugrunde liegende Bereitstellungsgruppen-ID und AppSpec -Datei, um alle Dateien zu entfernen, die bei der vorherigen erfolgreichen Bereitstellung installiert wurden.
## Lange Dateipfade führen zu der Fehlermeldung „Keine solche Datei oder kein solches Verzeichnis“
Wenn Sie bei Bereitstellungen für Windows-Instanzen einen Dateipfad mit mehr als 260 Zeichen im Dateibereich Ihrer appspec.yml-Datei angeben, schlagen Bereitstellungen möglicherweise mit einer Fehlermeldung ähnlich der folgenden fehl:
`No such file or directory @ dir_s_mkdir - C:\your-long-file-path`
[Dieser Fehler tritt auf, weil Windows standardmäßig keine Dateipfade mit mehr als 260 Zeichen zulässt, wie in der Dokumentation von Microsoft beschrieben.](https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=powershell#enable-long-paths-in-windows-10-version-1607-and-later)
Für CodeDeploy Agentenversionen 1.4.0 oder höher können Sie lange Dateipfade je nach Agenteninstallationsprozess auf zwei Arten aktivieren:
Wenn der CodeDeploy Agent noch nicht installiert wurde:
1. Aktivieren Sie auf dem Computer, auf dem Sie den CodeDeploy Agenten installieren möchten, den `LongPathsEnabled` Windows-Registrierungsschlüssel mit diesem Befehl:
```
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem"
-Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force
```
1. Installieren Sie den CodeDeploy Agenten. Weitere Informationen finden Sie unter [Installieren Sie den CodeDeploy Agenten](codedeploy-agent-operations-install.md).
Wenn der CodeDeploy Agent bereits installiert wurde:
1. Aktivieren Sie auf dem CodeDeploy Agent-Computer den `LongPathsEnabled` Windows-Registrierungsschlüssel mit diesem Befehl:
```
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem"
-Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force
```
1. Starten Sie den CodeDeploy Agenten neu, damit die Änderung des Registrierungsschlüssels wirksam wird. Verwenden Sie diesen Befehl, um den Agenten neu zu starten:
```
powershell.exe -Command Restart-Service -Name codedeployagent
```
## Lange laufende Prozesse können zum Fehlschlagen von Bereitstellungen führen
Wenn Sie bei Bereitstellungen auf Amazon Linux-, Ubuntu Server- und RHEL-Instances über ein Bereitstellungsskript verfügen, das einen lang andauernden Prozess startet, warten Sie CodeDeploy möglicherweise lange auf das Ereignis im Bereitstellungslebenszyklus und schlagen dann bei der Bereitstellung fehl. Der Grund hierfür ist: Wenn der Prozess länger läuft als die erwartete Dauer der Vorder- und Hintergrundprozesse in dem Ereignis, stoppt CodeDeploy die Bereitstellung und lässt sie fehlschlagen, auch wenn der Prozess noch wie erwartet ausgeführt wird.
Beispiel: Eine Anwendungsrevision enthält zwei Dateien im Stammverzeichnis, `after-install.sh` und `sleep.sh`. Die AppSpec Datei enthält die folgenden Anweisungen:
```
version: 0.0
os: linux
files:
- source: ./sleep.sh
destination: /tmp
hooks:
AfterInstall:
- location: after-install.sh
timeout: 60
```
Die `after-install.sh` Datei wird während des AfterInstall Anwendungslebenszyklus ausgeführt. Der Inhalt lautet folgendermaßen:
```
#!/bin/bash
/tmp/sleep.sh
```
Die Datei `sleep.sh` enthält folgenden Code, der die Ausführung des Programms für drei Minuten (180 Sekunden) unterbricht. Dadurch werden einige lange laufende Prozesse simuliert:
```
#!/bin/bash
sleep 180
```
Bei `after-install.sh` Aufrufen `sleep.sh` `sleep.sh` startet und läuft drei Minuten (180 Sekunden), also zwei Minuten (120 Sekunden) nach CodeDeploy der `sleep.sh` erwarteten (und damit verbundenen`after-install.sh`) Unterbrechung der Ausführung. Nach Ablauf des Timeouts von einer Minute (60 Sekunden) wird die Bereitstellung zum Zeitpunkt des AfterInstall Anwendungslebenszyklus CodeDeploy angehalten und schlägt fehl, obwohl sie `sleep.sh` weiterhin wie erwartet ausgeführt wird. Der folgende Fehler wird angezeigt:
`Script at specified location: after-install.sh failed to complete in 60 seconds`.
Sie können nicht einfach ein kaufmännisches Und-Zeichen (`&`) in `after-install.sh` einfügen, um `sleep.sh` im Hintergrund auszuführen.
```
#!/bin/bash
# Do not do this.
/tmp/sleep.sh &
```
Dadurch kann die Bereitstellung bis zum standardmäßigen Timeout von einer Stunde im Status „Ausstehend“ verbleiben. Danach wird die Bereitstellung beim AfterInstall Anwendungslebenszyklus-Ereignis wie zuvor CodeDeploy beendet und schlägt fehl.
Rufen Sie in `after-install.sh` `sleep.sh` wie folgt auf, sodass CodeDeploy Sie nach dem Start des Prozesses weitermachen können:
```
#!/bin/bash
/tmp/sleep.sh > /dev/null 2> /dev/null < /dev/null &
```
Im vorherigen Aufruf ist `sleep.sh` der Name des Prozesses, der im Hintergrund ausgeführt werden soll, wobei stdout, stderr und stdin nach `/dev/null` umgeleitet werden.
## Behebung eines fehlgeschlagenen AllowTraffic Lebenszyklusereignisses, bei dem kein Fehler in den Bereitstellungsprotokollen gemeldet wurde
In einigen Fällen schlägt eine blue/green Bereitstellung während des AllowTraffic Lebenszyklusereignisses fehl, aber die Bereitstellungsprotokolle geben keinen Hinweis auf die Ursache des Fehlers.
Dieser Fehler ist in der Regel auf falsch konfigurierte Zustandsprüfungen in Elastic Load Balancing für den Classic Load Balancer, Application Load Balancer oder Network Load Balancer zurückzuführen, der zur Verwaltung des Datenverkehrs für die Bereitstellungsgruppe verwendet wird.
Um das Problem zu lösen, überprüfen Sie die Konfiguration der Zustandsprüfung für den Load Balancer und korrigieren Sie eventuelle Fehler.
Informationen zu Classic Load Balancers finden [Sie unter Configure Health Checks](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-healthchecks.html) im *Benutzerhandbuch für Classic Load Balancers* und [ConfigureHealthCheck](https://docs.aws.amazon.com/elasticloadbalancing/2012-06-01/APIReference/API_ConfigureHealthCheck.html)in der *Elastic Load Balancing API-Referenzversion* 2012-06-01.
Informationen zu Application Load Balancers finden Sie unter [Health Checks für Ihre Zielgruppen](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html) im *Benutzerhandbuch für Application Load Balancers*.
Informationen zu Network Load Balancers finden Sie unter [Health Checks für Ihre Zielgruppen](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-health-checks.html) im *Network Load Balancer User Guide*.
## Behebung eines Fehlers oder eines ApplicationStop BeforeBlockTraffic Ereignisses im Lebenszyklus einer AfterBlockTraffic Bereitstellung
Während einer Bereitstellung führt der CodeDeploy Agent die Skripts aus, die für ApplicationStop BeforeBlockTraffic, und AfterBlockTraffic in der AppSpec Datei aus der vorherigen erfolgreichen Bereitstellung angegeben sind. (Alle anderen Skripts werden von der AppSpec Datei in der aktuellen Bereitstellung aus ausgeführt.) Wenn eines dieser Skripts einen Fehler enthält und nicht erfolgreich ausgeführt wird, kann Bereitstellung fehlschlagen.
Mögliche Gründe für diese Ausfälle sind:
+ Der CodeDeploy Agent findet die `deployment-group-id_last_successful_install` Datei am richtigen Speicherort, aber der in der `deployment-group-id_last_successful_install` Datei aufgeführte Speicherort ist nicht vorhanden.
**Auf Amazon Linux-, Ubuntu Server- und RHEL-Instances** muss diese Datei in `/opt/codedeploy-agent/deployment-root/deployment-instructions` vorhanden sein.
**Auf Windows Server-Instances** muss diese Datei im `C:\ProgramData\Amazon\CodeDeploy\deployment-instructions` Ordner gespeichert werden.
+ An dem in der `deployment-group-id_last_successful_install` Datei angegebenen Speicherort ist entweder die AppSpec Datei ungültig oder die Skripts werden nicht erfolgreich ausgeführt.
+ Das Skript enthält einen Fehler, der nicht korrigiert werden kann, sodass es nie erfolgreich ausgeführt werden wird.
Verwenden Sie die CodeDeploy Konsole, um zu untersuchen, warum eine Bereitstellung bei einem dieser Ereignisse möglicherweise fehlgeschlagen ist. Wählen Sie auf der Detailseite für die Bereitstellung **View events (Ereignisse anzeigen)** aus. Wählen Sie auf der Detailseite für die Instance in der **AfterBlockTraffic**Zeile **ApplicationStop**BeforeBlockTraffic****, oder die Option **Logs anzeigen** aus. Oder verwenden Sie den AWS CLI , um den [get-deployment-instance](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-instance.html)Befehl aufzurufen.
Wenn die Ursache des Fehlers ein Skript aus der letzten erfolgreichen Bereitstellung ist, das nie erfolgreich ausgeführt wird, erstellen Sie ein Deployment und geben Sie an ApplicationStop BeforeBlockTraffic, dass die AfterBlockTraffic Fehler, und ignoriert werden sollen. Es gibt zwei Möglichkeiten dafür:
+ Verwenden Sie die CodeDeploy Konsole, um eine Bereitstellung zu erstellen. Wählen Sie auf der Seite **Bereitstellung erstellen** unter **ApplicationStop Lifecycle-Event Failure** die Option **Don't fail the deployment to an instance if this Lifecycle event on the instance failed if this Lifecycle Event in the Instance failed**.
+ Verwenden Sie den AWS CLI , um den **[create-deployment](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html)** Befehl aufzurufen und die `--ignore-application-stop-failures` Option einzufügen.
Wenn Sie die Anwendungsrevision erneut bereitstellen, wird die Bereitstellung fortgesetzt, auch wenn eines dieser drei Lebenszyklusereignisse fehlschlägt. Wenn die neue Revision korrigierte Skripts für diese Lebenszyklusereignisse umfasst, können künftige Bereitstellungen erfolgreich ausgeführt werden, ohne diese Korrektur anzuwenden.
## Behebung eines fehlgeschlagenen DownloadBundle Deployment-Lifecycle-Ereignisses mit UnknownError: nicht zum Lesen geöffnet
Wenn Sie versuchen, eine Anwendungsrevision von Amazon S3 aus bereitzustellen, und die Bereitstellung während des Bereitstellungslebenszyklus mit dem folgenden `UnknownError: not opened for reading` Fehler fehlschlägt: DownloadBundle
+ Es gab einen internen Amazon S3 S3-Servicefehler. Stellen Sie die Anwendungsrevision erneut bereit.
+ Das IAM-Instance-Profil auf Ihrer EC2-Instance hat keine Berechtigungen für den Zugriff auf die Anwendungsversion in Amazon S3. Informationen zu den Amazon S3 S3-Bucket-Richtlinien finden Sie unter [Eine Revision CodeDeploy auf Amazon S3 übertragen (nur EC2/On-Premises-Bereitstellungen)](application-revisions-push.md) und[Voraussetzungen für die Bereitstellung](deployments-create-prerequisites.md).
+ Die Instances, für die Sie bereitstellen, sind einer AWS Region zugeordnet (z. B. USA West (Oregon)), aber der Amazon S3 S3-Bucket, der die Anwendungsrevision enthält, ist einer anderen AWS Region zugeordnet (z. B. USA Ost (Nord-Virginia)). Stellen Sie sicher, dass sich die Anwendungsversion in einem Amazon S3 S3-Bucket befindet, der derselben AWS Region wie die Instances zugeordnet ist.
Wählen Sie auf der Ereignisdetail-Seite für die Bereitstellung auf der Zeile **Download bundle (Bundle herunterladen)** die Option **View logs (Protokolle anzeigen)**. Oder verwenden Sie den AWS CLI , um den [get-deployment-instance](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-instance.html)Befehl aufzurufen. Wenn dieser Fehler aufgetreten ist, sollte die Ausgabe einen Fehler mit dem Fehlercode `UnknownError` und die Fehlermeldung `not opened for reading` enthalten.
So ermitteln Sie den Grund für diesen Fehler:
1. Aktivieren Sie die Übertragungsprotokollierung in mindestens einer der Instances und stellen Sie dann die Anwendungsrevision erneut bereit.
1. Überprüfen Sie die Übertragungsprotokollierungsdatei, um den Fehler zu ermitteln. Allgemeine Fehlermeldungen für dieses Problem enthalten den Ausdruck „access denied“.
1. Nachdem Sie die Protokolldateien geprüft haben, sollten Sie die Übertragungsprotokollierung deaktivieren, um die Größe der Protokolldatei und die Menge der vertraulichen Informationen zu reduzieren, die zukünftig unverschlüsselt in der Ausgabe auf der Instance erscheinen.
Informationen zum Auffinden der Wire-Logging-Datei und zum Aktivieren und Deaktivieren von Wire Logging finden Sie `:log_aws_wire:` in der [CodeDeploy Agent-Konfigurationsreferenz](https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-agent-configuration.html).
## Durch Fehlerbehebung bei allen Lebenszyklusereignissen wurden Fehler übersprungen
Wenn alle Lebenszyklusereignisse einer EC2- oder lokalen Bereitstellung übersprungen werden, erhalten Sie möglicherweise eine ähnliche Fehlermeldung wie. `The overall deployment failed because too many individual instances failed deployment, too few healthy instances are available for deployment, or some instances in your deployment group are experiencing problems. (Error code: HEALTH_CONSTRAINTS)` Hier finden Sie einige möglichen Ursachen und Lösungen:
+ Der CodeDeploy Agent ist möglicherweise nicht auf der Instance installiert oder läuft nicht. Um festzustellen, ob der CodeDeploy Agent läuft:
+ Unter Amazon Linux RHEL oder Ubuntu Server führen Sie die folgenden Schritte aus:
```
systemctl status codedeploy-agent
```
+ Unter Windows führen Sie die folgenden Schritte aus:
```
powershell.exe -Command Get-Service -Name CodeDeployagent
```
Wenn der CodeDeploy Agent nicht installiert ist oder nicht ausgeführt wird, finden Sie weitere Informationen unter[Stellen Sie sicher, dass der CodeDeploy Agent läuft](codedeploy-agent-operations-verify.md).
Ihre Instance ist möglicherweise nicht in der Lage, den öffentlichen Endpunkt CodeDeploy oder den öffentlichen Amazon S3 S3-Endpunkt über Port 443 zu erreichen. Führen Sie einen der folgenden Schritte aus:
+ Weisen Sie der Instance eine öffentliche IP-Adresse zu und verwenden Sie ihre Routing-Tabelle, um den Internetzugriff zu ermöglichen. Stellen Sie sicher, dass die der Instance zugeordnete Sicherheitsgruppe den ausgehenden Zugriff über Port 443 (HTTPS) zulässt. Weitere Informationen finden Sie unter [Kommunikationsprotokoll und Port für den CodeDeploy Agenten](codedeploy-agent.md#codedeploy-agent-outbound-port).
+ Wenn eine Instance in einem privaten Subnetz bereitgestellt wird, verwenden Sie einen NAT-Gateway anstelle eines Internet-Gateways in der Routing-Tabelle. Weitere Informationen finden Sie unter [NAT-Gateways](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html).
+ Für die Servicerolle für sind CodeDeploy möglicherweise keine Berechtigungen erforderlich. Informationen zum Konfigurieren einer Servicerolle für CodeDeploy finden Sie unter [Schritt 2: Erstellen Sie eine Servicerolle für CodeDeploy](getting-started-create-service-role.md).
+ Wenn Sie einen HTTP-Proxy verwenden, stellen Sie sicher, dass dieser in der `:proxy_uri:` Einstellung in der CodeDeploy Agentenkonfigurationsdatei angegeben ist. Weitere Informationen finden Sie unter [CodeDeploy Referenz zur Agentenkonfiguration](reference-agent-configuration.md).
+ Die Datums- und Uhrzeitsignatur Ihrer Bereitstellungs-Instance stimmt möglicherweise nicht mit der Signatur für Datum und Uhrzeit Ihrer Bereitstellungsanfrage überein. Suchen Sie nach einem ähnlichen Fehler wie `Cannot reach InstanceService: Aws::CodeDeployCommand::Errors::InvalidSignatureException - Signature expired` in Ihrer CodeDeploy Agenten-Protokolldatei. Wenn dieser Fehler angezeigt wird, befolgen Sie die Schritte in [Behebung von Bereitstellungsfehlern „InvalidSignatureException — Signatur abgelaufen: [Zeit] ist jetzt vor [Zeit]“](troubleshooting-ec2-instances.md#troubleshooting-instance-time-failures). Weitere Informationen finden Sie unter [Protokolldaten für CodeDeploy EC2/On-Premises-Bereitstellungen anzeigen](deployments-view-logs.md).
+ Der CodeDeploy Agent wird möglicherweise nicht mehr ausgeführt, weil einer Instanz nur noch wenig Arbeitsspeicher oder Festplattenspeicher zur Verfügung steht. Versuchen Sie, die Anzahl der archivierten Bereitstellungen auf Ihrer Instanz zu verringern, indem Sie die `max_revisions` Einstellung in der CodeDeploy Agentenkonfiguration aktualisieren. Wenn Sie dies für eine EC2-Instance tun und das Problem weiterhin besteht, sollten Sie die Verwendung einer größeren Instance in Betracht ziehen. Beispiel: Wenn Ihr Instance-Typ `t2.small` ist, verwenden Sie `t2.medium`. Weitere Informationen finden Sie unter [Vom Agenten installierte Dateien CodeDeploy](codedeploy-agent.md#codedeploy-agent-install-files)[CodeDeploy Referenz zur Agentenkonfiguration](reference-agent-configuration.md), und [Instanztypen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html).
+ Der Instance, für die Sie die Bereitstellung durchführen, ist möglicherweise kein IAM-Instanzprofil angehängt, oder es ist ein IAM-Instanzprofil angehängt, das nicht über die erforderlichen Berechtigungen verfügt.
+ Wenn Ihrer Instanz kein IAM-Instanzprofil angehängt ist, erstellen Sie eines mit den erforderlichen Berechtigungen und hängen Sie es dann an.
+ Wenn Ihrer Instance bereits ein IAM-Instanzprofil angehängt ist, stellen Sie sicher, dass es über die erforderlichen Berechtigungen verfügt.
Nachdem Sie überprüft haben, dass Ihr zugeordnetes Instance-Profil mit den erforderlichen Berechtigungen konfiguriert ist, starten Sie Ihre Instance neu. Weitere Informationen finden Sie unter [Schritt 4: Erstellen Sie ein IAM-Instance-Profil für Ihre Amazon EC2 EC2-Instances](getting-started-create-iam-instance-profile.md) und [IAM-Rollen für Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-EC2.html) im *Amazon EC2 EC2-Benutzerhandbuch*.
## PowerShell Windows-Skripts verwenden standardmäßig nicht die 64-Bit-Version von Windows PowerShell
Wenn ein PowerShell Windows-Skript, das als Teil einer Bereitstellung ausgeführt wird, auf 64-Bit-Funktionalität angewiesen ist (z. B. weil es mehr Speicher beansprucht, als eine 32-Bit-Anwendung zulässt, oder Bibliotheken aufruft, die nur in einer 64-Bit-Version angeboten werden), stürzt das Skript möglicherweise ab oder wird nicht wie erwartet ausgeführt. Das liegt daran, dass standardmäßig die 32-Bit-Version von Windows CodeDeploy verwendet wird, PowerShell um PowerShell Windows-Skripts auszuführen, die Teil einer Anwendungsrevision sind.
Fügen Sie am Anfang jedes Skripts, das mit der 64-Bit-Version von Windows ausgeführt werden muss, Code wie den folgenden hinzu PowerShell:
```
# Are you running in 32-bit mode?
# (\SysWOW64\ = 32-bit mode)
if ($PSHOME -like "*SysWOW64*")
{
Write-Warning "Restarting this script under 64-bit Windows PowerShell."
# Restart this script under 64-bit Windows PowerShell.
# (\SysNative\ redirects to \System32\ for 64-bit mode)
& (Join-Path ($PSHOME -replace "SysWOW64", "SysNative") powershell.exe) -File `
(Join-Path $PSScriptRoot $MyInvocation.MyCommand) @args
# Exit 32-bit script.
Exit $LastExitCode
}
# Was restart successful?
Write-Warning "Hello from $PSHOME"
Write-Warning " (\SysWOW64\ = 32-bit mode, \System32\ = 64-bit mode)"
Write-Warning "Original arguments (if any): $args"
# Your 64-bit script code follows here...
# ...
```
Obwohl die Dateipfadinformationen in diesem Code nicht intuitiv erscheinen mögen, PowerShell verwendet 32-Bit-Windows einen Pfad wie den folgenden:
`c:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe`
64-Bit-Windows PowerShell verwendet einen Pfad wie:
`c:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe`