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

CodeDeploy Fehler beim Fehlen der Anmeldeinformationen für CommandPoller das Plug-in

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:

Ein IAM Instance-Profil gewährt dem CodeDeploy Agenten die Erlaubnis, mit Amazon S3 zu kommunizieren CodeDeploy und Ihre Version von Amazon S3 herunterzuladen. EC2Instances finden Sie unterIdentity and Access Management für AWS CodeDeploy. Informationen zu lokalen Instances finden Sie unter Working with On-Premises Instances.

Die Bereitstellung schlägt fehl und es wird die Meldung „Die Überprüfung der PKCS7 signierten Nachricht ist fehlgeschlagen“ angezeigt

Diese Fehlermeldung weist darauf hin, dass auf der Instanz eine Version des CodeDeploy Agenten ausgeführt wird, die nur den Hash-Algorithmus SHA -1 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, NOTICE: CodeDeploy Server-Agenten, die älter als Version 1.0.1.85 sind, außer Dienst stellen und. Aktualisieren Sie den Agenten CodeDeploy

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.“ Dies liegt daran, dass bei jeder Bereitstellung CodeDeploy zunächst alle Dateien aus der vorherigen Bereitstellung gelöscht werden, die in einer Bereinigungsprotokolldatei aufgeführt sind. Wenn sich in den Zielinstallationsordnern Dateien befinden, die nicht in dieser Säuberungsdatei aufgeführt sind, interpretiert der CodeDeploy Agent dies standardmäßig als Fehler und schlägt bei der Bereitstellung fehl.

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 Platform-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 möchten, die an Ihren Zielbereitstellungsorten CodeDeploy erkannt wurden (oder wenn Sie in einem programmatischen Befehl keine Bereitstellungsoption für die Verarbeitung vorhandener Inhalte 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:

Um diese Situationen zu beheben, führen Sie einen der folgenden Schritte aus:

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:

Wenn der CodeDeploy Agent bereits installiert wurde:

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, CodeDeploy kann es sein, dass Sie lange auf das Ereignis im Bereitstellungslebenszyklus warten und die Bereitstellung dann fehlschlägt. Das liegt daran, dass, wenn der Prozess länger läuft als die Vordergrund- und Hintergrundprozesse in diesem Fall voraussichtlich dauern, die Bereitstellung CodeDeploy beendet und fehlschlägt, auch wenn der Prozess weiterhin erwartungsgemäß 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), was zwei Minuten (120 Sekunden) nach der CodeDeploy erwarteten sleep.sh (und damit verbundenenafter-install.sh) Unterbrechung der Ausführung entspricht. 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 Balancing-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:

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 den AWS CLI , um den get-deployment-instanceBefehl 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:

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

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-instanceBefehl 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:

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.

Durch Fehlerbehebung bei allen Lebenszyklusereignissen wurden Fehler übersprungen

Wenn alle Lebenszyklusereignisse einer EC2 oder einer 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:

PowerShell Windows-Skripts verwenden standardmäßig nicht die 64-Bit-Version PowerShell von Windows

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