Beheben Sie Probleme mit der EC2/On-Premises-Bereitstellung

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.

Tipp

Ein Runbook, das viele Problembehandlungsaufgaben im Zusammenhang mit EC2/lokalen Bereitstellungen automatisiert, finden Sie unter AWSSupport- TroubleshootCodeDeploy in der AWS Runbook-Referenz für Systems Manager Automation.

CodeDeploy Fehler CommandPoller mit fehlenden Anmeldeinformationen für das Plugin

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 Identity and Access Management für AWS CodeDeploy. Informationen zu lokalen Instances finden Sie unter Working with On-Premises Instances.

Bereitstellung schlägt mit der Meldung "Validation of PKCS7 signed message failed" fehl

Diese Fehlermeldung weist darauf hin, dass auf der Instance 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 AWSSo wechseln Sie zum SHA256-Hash-Algorithmus für SSL-Zertifikate, HINWEIS: CodeDeploy Server-Agents, die älter als Version 1.0.1.85 sind, außer Dienst stellen, und. Aktualisieren des CodeDeploy Agenten

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 für eine Instanz bereitzustellen, aber eine Datei mit demselben Namen bereits am angegebenen Zielspeicherort existiert, schlägt die Bereitstellung für diese Instanz möglicherweise fehl. Sie erhalten unter Umständen die Fehlermeldung "The deployment failed because a specified file already exists at this location: 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 finden Sie unter Erstellen Sie eine EC2/On-Premises-Compute-Plattform-Bereitstellung (Konsole) und Rollback-Verhalten bei vorhandenem Inhalt.

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 beziehen sich auf verschiedene 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 Anwendungsnamen und den Bereitstellungsgruppennamen an, denen dieselben Anwendungs- und Bereitstellungsgruppen-IDs zugrunde liegen wie denen, die Sie löschen möchten. (Sie können den get-deployment-groupBefehl 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.

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

2. Installieren Sie den CodeDeploy Agenten. Weitere Informationen finden Sie unter Installieren des CodeDeploy Agenten.

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
   

2. 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 verbundenenafter-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 blaue/grüne 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 im Benutzerhandbuch für Classic Load Balancers und ConfigureHealthCheckin der Elastic Load Balancing API-Referenzversion 2012-06-01.

Informationen zu Application Load Balancers finden Sie unter Health Checks für Ihre Zielgruppen im Benutzerhandbuch für Application Load Balancers.

Informationen zu Network Load Balancers finden Sie unter Health Checks für Ihre Zielgruppen 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 AfterBlockTrafficZeile ApplicationStopBeforeBlockTraffic, oder die Option Logs anzeigen aus. Oder verwenden Sie die AWS CLI zum Aufrufen des get-deployment-instance-Befehls.

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 die AWS CLI, um den Befehl create-deployment aufzurufen, und schließen Sie die Option --ignore-application-stop-failures ein.

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.

Fehlerbehebung bei einem Ereignis im Lebenszyklus einer fehlgeschlagenen DownloadBundle Bereitstellung 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 für Amazon S3 CodeDeploy senden (nur EC2-/On-Premises Bereitstellungen) undVoraussetzungen für die Bereitstellung.

• 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 Anwendungsversion 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 die AWS CLI zum Aufrufen des get-deployment-instance-Befehls. 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.

2. Überprüfen Sie die Übertragungsprotokollierungsdatei, um den Fehler zu ermitteln. Allgemeine Fehlermeldungen für dieses Problem enthalten den Ausdruck „access denied“.

3. 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 Referenz zur CodeDeploy Agentenkonfiguration.

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Überprüfen, ob der CodeDeploy Agent ausgeführt wird.

  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.

  • 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.

• 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.

• Wenn Sie einen HTTP-Proxy verwenden, stellen Sie sicher, dass dieser in der :proxy_uri: Einstellung in der CodeDeploy Agent-Konfigurationsdatei angegeben ist. Weitere Informationen finden Sie unter CodeDeploy Referenz zur Agentenkonfiguration.

• 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]“. Weitere Informationen finden Sie unter Log-Bereitstellung ausgeführt in CodeDeploy EC2-/On-Premises-BEC2-/On-Premises-B.

• Der CodeDeploy Agent wird möglicherweise nicht mehr ausgeführt, weil einer Instanz nicht mehr genügend 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 CodeDeploy Agenten installierte Dateien CodeDeploy Referenz zur Agentenkonfiguration, und Instanztypen.

• 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 und IAM-Rollen für Amazon EC2 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