AppSpec Abschnitt „Hooks“ - AWS CodeDeploy
AppSpec Abschnitt „Hooks“ für eine Amazon ECS-BereitstellungAppSpec Abschnitt „Hooks“ für eine AWS Lambda-BereitstellungAppSpec Abschnitt „Hooks“ für eine EC2/On-Premises-Bereitstellung

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.

AppSpec Abschnitt „Hooks“

Der Inhalt des 'hooks' Abschnitts der AppSpec Datei variiert je nach Rechenplattform für Ihre Bereitstellung. Der 'hooks' Abschnitt für eine EC2/lokale Bereitstellung enthält Zuordnungen, die Event-Hooks für den Bereitstellungslebenszyklus mit einem oder mehreren Skripten verknüpfen. Der 'hooks' Abschnitt für eine Lambda- oder Amazon ECS-Bereitstellung spezifiziert Lambda-Validierungsfunktionen, die während eines Deployment-Lifecycle-Ereignisses ausgeführt werden sollen. Wenn ein Ereignis-Hook nicht vorhanden ist, wird kein Vorgang für dieses Ereignis ausgeführt. Dieser Abschnitt ist nur erforderlich, wenn Sie im Rahmen der Bereitstellung Skripts oder Lambda-Validierungsfunktionen ausführen.

AppSpec Abschnitt „Hooks“ für eine Amazon ECS-Bereitstellung

Liste der Lifecycle-Event-Hooks für eine Amazon ECS-Bereitstellung

Ein AWS Lambda-Hook ist eine Lambda-Funktion, die mit einer Zeichenfolge in einer neuen Zeile nach dem Namen des Lebenszyklusereignisses angegeben wird. Jeder Hook wird einmal pro Bereitstellung ausgeführt. Im Folgenden finden Sie Beschreibungen der Lebenszyklusereignisse, bei denen Sie während einer Amazon ECS-Bereitstellung einen Hook ausführen können.

  • BeforeInstall— Wird verwendet, um Aufgaben auszuführen, bevor der Ersatzaufgabensatz erstellt wird. Eine Zielgruppe wird dem ursprünglichen Aufgabesatz zugeordnet. Wenn ein optionaler Test-Listener angegeben wird, wird er dem ursprünglichen Aufgabensatz zugeordnet. Ein Rollback ist zu diesem Zeitpunkt nicht möglich.

  • AfterInstall— Wird verwendet, um Aufgaben auszuführen, nachdem der Ersatz-Tasksatz erstellt wurde und ihm eine der Zielgruppen zugeordnet wurde. Wenn ein optionaler Test-Listener angegeben wird, wird er dem ursprünglichen Aufgabensatz zugeordnet. Die Ergebnisse einer hook-Funktion bei diesem Lebenszyklus-Ereignis können einen Rollback auslösen.

  • AfterAllowTestTraffic— Wird verwendet, um Aufgaben auszuführen, nachdem der Test-Listener Traffic an den Ersatz-Tasksatz weitergeleitet hat. Die Ergebnisse einer hook-Funktion können zu diesem Zeitpunkt einen Rollback auslösen.

  • BeforeAllowTraffic— Wird verwendet, um Aufgaben auszuführen, nachdem die zweite Zielgruppe dem Ersatz-Task-Set zugeordnet wurde, aber bevor der Verkehr auf den Ersatz-Tasksatz umgeleitet wird. Die Ergebnisse einer hook-Funktion bei diesem Lebenszyklus-Ereignis können einen Rollback auslösen.

  • AfterAllowTraffic— Wird verwendet, um Aufgaben auszuführen, nachdem die zweite Zielgruppe Traffic an den Ersatz-Tasksatz weitergeleitet hat. Die Ergebnisse einer hook-Funktion bei diesem Lebenszyklus-Ereignis können einen Rollback auslösen.

Weitere Informationen finden Sie unter Was passiert während einer Amazon ECS-Bereitstellung und Tutorial: Bereitstellen eines Amazon ECS-Service mit einem Validierungstest.

Führen Sie die Reihenfolge der Hooks in einer Amazon ECS-Bereitstellung aus.

In einer Amazon ECS-Bereitstellung werden Event-Hooks in der folgenden Reihenfolge ausgeführt:

Die Reihenfolge der Event-Hooks in einer Amazon ECS-Bereitstellung.
Anmerkung

Für die Ereignisse Start TestTraffic, Install AllowTraffic, und End in der Bereitstellung kann kein Skript erstellt werden, weshalb sie in diesem Diagramm grau dargestellt werden.

Struktur des Abschnitts „Hooks“

Die folgenden Beispiele veranschaulichen die Struktur des Abschnitts 'hooks'.

Mit YAML:

Hooks:
  - BeforeInstall: "BeforeInstallHookFunctionName"
  - AfterInstall: "AfterInstallHookFunctionName"
  - AfterAllowTestTraffic: "AfterAllowTestTrafficHookFunctionName"
  - BeforeAllowTraffic: "BeforeAllowTrafficHookFunctionName"
  - AfterAllowTraffic: "AfterAllowTrafficHookFunctionName"

Mit JSON:

"Hooks": [
		{
			"BeforeInstall": "BeforeInstallHookFunctionName"
		},
		{
			"AfterInstall": "AfterInstallHookFunctionName"
		},
		{
			"AfterAllowTestTraffic": "AfterAllowTestTrafficHookFunctionName"
		},
		{
			"BeforeAllowTraffic": "BeforeAllowTrafficHookFunctionName"
		},
		{
			"AfterAllowTraffic": "AfterAllowTrafficHookFunctionName"
		}
	]
}

Beispiel für die Lambda-Funktion „Hooks“

Verwenden Sie den 'hooks' Abschnitt, um eine Lambda-Funktion anzugeben, die aufgerufen CodeDeploy werden kann, um eine Amazon ECS-Bereitstellung zu validieren. Sie können dieselbe oder eine andere Funktion für die Ereignisse im Lebenszyklus der AfterAllowTraffic Bereitstellung BeforeInstall AfterInstallAfterAllowTestTraffic,BeforeAllowTraffic,, und verwenden. Nach Abschluss der Validierungstests ruft die AfterAllowTraffic Lambda-Funktion zurück CodeDeploy und liefert das Ergebnis Succeeded oderFailed.

Wichtig

Die Bereitstellung gilt als fehlgeschlagen, wenn sie nicht innerhalb einer Stunde von der Lambda-Validierungsfunktion benachrichtigt CodeDeploy wird.

Vor dem Aufrufen einer Lambda-Hook-Funktion muss der Server mithilfe des Befehls über die Bereitstellungs-ID und die Ausführungs-ID des Lifecycle-Event-Hooks informiert werden. putLifecycleEventHookExecutionStatus

Im Folgenden finden Sie ein Beispiel für eine Lambda-Hook-Funktion, die in Node.js geschrieben wurde. 

'use strict';

const aws = require('aws-sdk');
const codedeploy = new aws.CodeDeploy({apiVersion: '2014-10-06'});

exports.handler = (event, context, callback) => {
    //Read the DeploymentId from the event payload.
    var deploymentId = event.DeploymentId;

    //Read the LifecycleEventHookExecutionId from the event payload
    var lifecycleEventHookExecutionId = event.LifecycleEventHookExecutionId;

    /*
     Enter validation tests here.
    */

    // Prepare the validation test results with the deploymentId and
    // the lifecycleEventHookExecutionId for CodeDeploy.
    var params = {
        deploymentId: deploymentId,
        lifecycleEventHookExecutionId: lifecycleEventHookExecutionId,
        status: 'Succeeded' // status can be 'Succeeded' or 'Failed'
    };
    
    // Pass CodeDeploy the prepared validation test results.
    codedeploy.putLifecycleEventHookExecutionStatus(params, function(err, data) {
        if (err) {
            // Validation failed.
            callback('Validation test failed');
        } else {
            // Validation succeeded.
            callback(null, 'Validation test succeeded');
        }
    });
};

AppSpec Abschnitt „Hooks“ für eine AWS Lambda-Bereitstellung

Liste der Lifecycle-Event-Hooks für eine AWS Lambda-Bereitstellung

Ein AWS Lambda-Hook ist eine Lambda-Funktion, die mit einer Zeichenfolge in einer neuen Zeile nach dem Namen des Lebenszyklusereignisses angegeben wird. Jeder Hook wird einmal pro Bereitstellung ausgeführt. Im Folgenden finden Sie Beschreibungen der Hooks, die in Ihrer AppSpec Datei verwendet werden können.

  • BeforeAllowTraffic— Wird verwendet, um Aufgaben auszuführen, bevor der Datenverkehr auf die bereitgestellte Lambda-Funktionsversion umgestellt wird.

  • AfterAllowTraffic— Wird verwendet, um Aufgaben auszuführen, nachdem der gesamte Datenverkehr auf die bereitgestellte Lambda-Funktionsversion umgestellt wurde.

Reihenfolge der Hooks in einer Bereitstellung einer Lambda-Funktionsversion ausführen

In einer serverlosen Bereitstellung einer Lambda-Funktionsversion werden Event-Hooks in der folgenden Reihenfolge ausgeführt:

Die Reihenfolge der Event-Hooks in einer Lambda-Bereitstellung.
Anmerkung

Für die Start AllowTraffic- und Endereignisse in der Bereitstellung kann kein Skript erstellt werden, weshalb sie in diesem Diagramm grau dargestellt werden.

Struktur des Abschnitts „Hooks“

Die folgenden Beispiele veranschaulichen die Struktur des 'hooks'-Abschnitts .

Mit YAML:

hooks:
   - BeforeAllowTraffic: BeforeAllowTrafficHookFunctionName
   - AfterAllowTraffic: AfterAllowTrafficHookFunctionName

Mit JSON:

"hooks": [{
    "BeforeAllowTraffic": "BeforeAllowTrafficHookFunctionName"
    },
    {
    "AfterAllowTraffic": "AfterAllowTrafficHookFunctionName"
}]

Beispiel für die Lambda-Funktion „Hooks“

Verwenden Sie den Abschnitt „Hooks“, um eine Lambda-Funktion anzugeben, die aufgerufen CodeDeploy werden kann, um eine Lambda-Bereitstellung zu validieren. Sie können dieselbe oder eine andere Funktion für die Ereignisse im Lebenszyklus der BeforeAllowTraffic AfterAllowTraffic Bereitstellung verwenden. Nach Abschluss der Validierungstests ruft die Lambda-Validierungsfunktion zurück CodeDeploy und liefert ein Ergebnis von Succeeded oderFailed.

Wichtig

Die Bereitstellung gilt als fehlgeschlagen, wenn sie nicht innerhalb einer Stunde von der Lambda-Validierungsfunktion benachrichtigt CodeDeploy wird.

Vor dem Aufrufen einer Lambda-Hook-Funktion muss der Server mithilfe des Befehls über die Bereitstellungs-ID und die Ausführungs-ID des Lifecycle-Event-Hooks informiert werden. putLifecycleEventHookExecutionStatus

Im Folgenden finden Sie ein Beispiel für eine Lambda-Hook-Funktion, die in Node.js geschrieben wurde. 

'use strict';

const aws = require('aws-sdk');
const codedeploy = new aws.CodeDeploy({apiVersion: '2014-10-06'});

exports.handler = (event, context, callback) => {
    //Read the DeploymentId from the event payload.
    var deploymentId = event.DeploymentId;

    //Read the LifecycleEventHookExecutionId from the event payload
    var lifecycleEventHookExecutionId = event.LifecycleEventHookExecutionId;

    /*
     Enter validation tests here.
    */

    // Prepare the validation test results with the deploymentId and
    // the lifecycleEventHookExecutionId for CodeDeploy.
    var params = {
        deploymentId: deploymentId,
        lifecycleEventHookExecutionId: lifecycleEventHookExecutionId,
        status: 'Succeeded' // status can be 'Succeeded' or 'Failed'
    };
    
    // Pass CodeDeploy the prepared validation test results.
    codedeploy.putLifecycleEventHookExecutionStatus(params, function(err, data) {
        if (err) {
            // Validation failed.
            callback('Validation test failed');
        } else {
            // Validation succeeded.
            callback(null, 'Validation test succeeded');
        }
    });
};

AppSpec Abschnitt „Hooks“ für eine EC2/On-Premises-Bereitstellung

Liste der Lifecycle-Event-Hooks

Ein EC2/On-Premises-Bereitstellungs-Hook wird einmal pro Bereitstellung für eine Instance ausgeführt. Sie können ein oder mehrere Skripts zur Ausführung in einem Hook angeben. Jeder Hook für ein Lebenszyklusereignis wird mit einer Zeichenfolge in einer separaten Zeile angegeben. Im Folgenden finden Sie Beschreibungen der Hooks, die für die Verwendung in Ihrer Datei verfügbar sind. AppSpec

Weitere Informationen darüber, welche Lebenszyklusereignis-Hooks für welche Bereitstellungs- und Rollback-Typen gültig sind, finden Sie unter Verfügbarkeit von Hooks für Lebenszyklus-Ereignisse.

  • ApplicationStop— Dieses Ereignis im Bereitstellungszyklus tritt auf, noch bevor die Anwendungsversion heruntergeladen wird. Sie können Skripts für dieses Ereignis angeben, um die Anwendung ordnungsgemäß anzuhalten, oder zur Vorbereitung einer Bereitstellung derzeit installierte Pakete entfernen. Die für dieses Ereignis im Bereitstellungslebenszyklus verwendeten AppSpec Dateien und Skripts stammen aus der vorherigen erfolgreich bereitgestellten Anwendungsversion.

    Anmerkung

    Eine AppSpec Datei ist auf einer Instanz nicht vorhanden, bevor Sie sie auf ihr bereitstellen. Aus diesem Grund wird der ApplicationStop-Hook beim ersten Bereitstellen auf der Instance nicht ausgeführt. Sie können den ApplicationStop-Hook bei der zweiten Bereitstellung für eine Instance verwenden.

    Um den Speicherort der letzten erfolgreich bereitgestellten Anwendungsrevision zu ermitteln, sucht der CodeDeploy Agent nach dem in der deployment-group-id_last_successful_install Datei aufgeführten Speicherort. Diese Datei befindet sich unter:

    /opt/codedeploy-agent/deployment-root/deployment-instructionsOrdner auf Amazon Linux-, Ubuntu Server- und RHEL Amazon EC2 EC2-Instances.

    C:\ProgramData\Amazon\CodeDeploy\deployment-instructionsOrdner auf Windows Server Amazon EC2 EC2-Instances.

    Informationen zur Problembehebung für eine Bereitstellung, die während des Bereitstellungslebenszyklusereignisses ApplicationStop fehlschlägt, finden Sie unter Behebung eines Fehlers oder eines ApplicationStop BeforeBlockTraffic Ereignisses im Lebenszyklus einer AfterBlockTraffic Bereitstellung.

  • DownloadBundle— Während dieses Bereitstellungslebenszyklus kopiert der CodeDeploy Agent die Revisionsdateien der Anwendung an einen temporären Speicherort:

    /opt/codedeploy-agent/deployment-root/deployment-group-id/deployment-id/deployment-archiveOrdner auf Amazon Linux-, Ubuntu Server- und RHEL Amazon EC2 EC2-Instances.

    C:\ProgramData\Amazon\CodeDeploy\deployment-group-id\deployment-id\deployment-archiveOrdner auf Windows Server Amazon EC2 EC2-Instances.

    Dieses Ereignis ist für den CodeDeploy Agenten reserviert und kann nicht zum Ausführen von Skripten verwendet werden.

    Informationen zur Problembehebung für eine Bereitstellung, die während des Bereitstellungslebenszyklusereignisses DownloadBundle fehlschlägt, finden Sie unter Behebung eines fehlgeschlagenen DownloadBundle Deployment-Lifecycle-Ereignisses mit UnknownError: nicht zum Lesen geöffnet.

  • BeforeInstall— Sie können dieses Ereignis im Bereitstellungslebenszyklus für Aufgaben vor der Installation verwenden, z. B. für das Entschlüsseln von Dateien und das Erstellen einer Sicherungskopie der aktuellen Version.

  • Install— Während dieses Bereitstellungslebenszyklus kopiert der CodeDeploy Agent die Revisionsdateien vom temporären Speicherort in den endgültigen Zielordner. Dieses Ereignis ist für den CodeDeploy Agenten reserviert und kann nicht zum Ausführen von Skripten verwendet werden.

  • AfterInstall— Sie können dieses Ereignis im Bereitstellungslebenszyklus für Aufgaben wie die Konfiguration Ihrer Anwendung oder das Ändern von Dateiberechtigungen verwenden.

  • ApplicationStart— In der Regel verwenden Sie dieses Ereignis im Bereitstellungslebenszyklus, um Dienste neu zu starten, die währenddessen gestoppt wurdenApplicationStop.

  • ValidateService— Dies ist das letzte Ereignis im Bereitstellungslebenszyklus. Es wird verwendet, um zu überprüfen, ob die Bereitstellung erfolgreich abgeschlossen wurde.

  • BeforeBlockTraffic— Sie können dieses Ereignis im Bereitstellungslebenszyklus verwenden, um Aufgaben auf Instances auszuführen, bevor diese bei einem Load Balancer deregistriert werden.

    Informationen zur Problembehebung für eine Bereitstellung, die während des Bereitstellungslebenszyklusereignisses BeforeBlockTraffic fehlschlägt, finden Sie unter Behebung eines Fehlers oder eines ApplicationStop BeforeBlockTraffic Ereignisses im Lebenszyklus einer AfterBlockTraffic Bereitstellung.

  • BlockTraffic— Während dieses Bereitstellungslebenszyklus-Ereignisses wird der Internetverkehr daran gehindert, auf Instances zuzugreifen, die derzeit Datenverkehr bereitstellen. Dieses Ereignis ist für den CodeDeploy Agenten reserviert und kann nicht zur Ausführung von Skripten verwendet werden.

  • AfterBlockTraffic— Sie können dieses Ereignis im Bereitstellungslebenszyklus verwenden, um Aufgaben auf Instances auszuführen, nachdem diese bei ihrem jeweiligen Load Balancer abgemeldet wurden.

    Informationen zur Problembehebung für eine Bereitstellung, die während des Bereitstellungslebenszyklusereignisses AfterBlockTraffic fehlschlägt, finden Sie unter Behebung eines Fehlers oder eines ApplicationStop BeforeBlockTraffic Ereignisses im Lebenszyklus einer AfterBlockTraffic Bereitstellung.

  • BeforeAllowTraffic— Sie können dieses Deployment-Lifecycle-Ereignis verwenden, um Aufgaben auf Instances auszuführen, bevor diese bei einem Load Balancer registriert wurden.

  • AllowTraffic— Während dieses Bereitstellungslebenszyklus darf Internet-Traffic nach einer Bereitstellung auf Instances zugreifen. Dieses Ereignis ist für den CodeDeploy Agenten reserviert und kann nicht zur Ausführung von Skripten verwendet werden.

  • AfterAllowTraffic— Sie können dieses Deployment-Lifecycle-Ereignis verwenden, um Aufgaben auf Instances auszuführen, nachdem diese bei einem Load Balancer registriert wurden.

Verfügbarkeit von Hooks für Lebenszyklus-Ereignisse

In der folgenden Tabelle finden Sie die Lebenszyklusereignis-Hooks für die einzelnen Bereitstellungs- und Rollback-Szenarien.

Name des Lebenszyklusereignis Bereitstellung von Auto Scaling Scaling-Start¹ Bereitstellung von Auto Scaling-Termination¹ Bereitstellung vor Ort² Blau/Grün-Bereitstellung: Original-Instances Blau/Grün-Bereitstellung: Ersatz-Instances Blau/Grün-Bereitstellungs-Rollback: Original-Instances Blau/Grün-Bereitstellungs-Rollback: Ersatz-Instances
ApplicationStop ✓ ✓ ✓ ✓
DownloadBundle³ ✓ ✓ ✓
BeforeInstall ✓ ✓ ✓
³ installieren ✓ ✓ ✓
AfterInstall ✓ ✓ ✓
ApplicationStart ✓ ✓ ✓
ValidateService ✓ ✓ ✓
BeforeBlockTraffic ✓ ✓ ✓ ✓
BlockTraffic³ ✓ ✓ ✓ ✓
AfterBlockTraffic ✓ ✓ ✓ ✓
BeforeAllowTraffic ✓ ✓ ✓ ✓
AllowTraffic³ ✓ ✓ ✓ ✓
AfterAllowTraffic ✓ ✓ ✓ ✓

¹ Informationen zu Amazon EC2 Auto Scaling Scaling-Bereitstellungen finden Sie unter. So funktioniert Amazon EC2 Auto Scaling mit CodeDeploy

² Gilt auch für das Rollback einer In-Place-Bereitstellung.

³ Für den Betrieb reserviert CodeDeploy . Kann nicht für die Ausführung von Skripts verwendet werden.

Führt die Reihenfolge der Hooks in einem Deployment aus

Auto Scaling Scaling-Startbereitstellungen

CodeDeploy Führt während einer Auto Scaling Scaling-Startbereitstellung Event-Hooks in der folgenden Reihenfolge aus.

Weitere Informationen zu Auto Scaling Scaling-Startbereitstellungen finden Sie unterSo funktioniert Amazon EC2 Auto Scaling mit CodeDeploy.

Die Reihenfolge der Event-Hooks während einer Auto Scaling Scaling-Startbereitstellung.
Anmerkung

Für die Start - DownloadBundleAllowTraffic, Installations - und Endereignisse in der Bereitstellung kann kein Skript erstellt werden, weshalb sie in diesem Diagramm grau dargestellt werden. Sie können den 'files' Abschnitt der AppSpec Datei jedoch bearbeiten, um anzugeben, was während des Installationsereignisses installiert wird.

Bereitstellungen zur Kündigung von Auto Scaling

CodeDeploy Führt während einer Auto Scaling-Terminierungsbereitstellung Event-Hooks in der folgenden Reihenfolge aus.

Weitere Informationen zu Auto Scaling-Terminierungsbereitstellungen finden Sie unterAktivierung von Terminierungsbereitstellungen bei Auto Scaling-Scale-In-Ereignissen.

Die Reihenfolge der Event-Hooks während einer Auto Scaling-Terminierungsbereitstellung.
Anmerkung

Für die Start BlockTraffic- und Endereignisse in der Bereitstellung kann kein Skript erstellt werden, weshalb sie in diesem Diagramm grau dargestellt werden.

In-Situ-Bereitstellungen

In einer In-Situ-Bereitstellung, einschließlich des Rollbacks einer In-Situ-Bereitstellung, werden Ereignis-Hooks in der folgenden Reihenfolge ausgeführt:

Anmerkung

Bei In-Place-Bereitstellungen gelten die sechs Hooks, die sich auf das Blockieren und Zulassen von Traffic beziehen, nur, wenn Sie in der Bereitstellungsgruppe einen Classic Load Balancer, Application Load Balancer oder Network Load Balancer von Elastic Load Balancing angeben.

Die Reihenfolge der Event-Hooks beim Rollback einer In-Place-Bereitstellung.
Anmerkung

Für die Start - DownloadBundle, Installations - und Endereignisse in der Bereitstellung kann kein Skript erstellt werden, weshalb sie in diesem Diagramm grau dargestellt werden. Sie können den 'files' Abschnitt der AppSpec Datei jedoch bearbeiten, um anzugeben, was während des Installationsereignisses installiert wird.

Blau/Grün-Bereitstellungen

In einer Blau/Grün-Bereitstellung werden Ereignis-Hooks in der folgenden Reihenfolge ausgeführt:

Die Reihenfolge der Event-Hooks in einer blauen/grünen Bereitstellung.
Anmerkung

Für die Ereignisse Start DownloadBundle, Install BlockTrafficAllowTraffic, und End in der Bereitstellung kann kein Skript erstellt werden, weshalb sie in diesem Diagramm grau dargestellt werden. Sie können jedoch den Abschnitt „Dateien“ der AppSpec Datei bearbeiten, um anzugeben, was während des Installationsereignisses installiert werden soll.

Struktur des Abschnitts „Hooks“

Der 'hooks'-Abschnitt weist die folgende Struktur auf:

hooks:
   deployment-lifecycle-event-name:
     - location: script-location
       timeout: timeout-in-seconds
       runas: user-name

Sie können die folgenden Elemente nach dem Namen des Bereitstellungslebenszyklusereignisses in einen Hook-Eintrag einschließen:

location

Erforderlich Die Position im Paket der Skriptdatei für die Revision. Der Speicherort der Skripts, die Sie in hooks diesem Abschnitt angeben, bezieht sich auf das Stammverzeichnis des Revisionspakets der Anwendung. Weitere Informationen finden Sie unter Planen Sie eine Überarbeitung für CodeDeploy.

timeout

Optional. Die Anzahl der Sekunden, die das Skript ausgeführt wird, bevor es als fehlgeschlagen gilt. Der Standard ist 3 600 Sekunden (1 Stunde).

Anmerkung

Für jedes Bereitstellungslebenszyklusereignis sind maximal 3 600 Sekunden (1 Stunde) für die Ausführung von Skripts zulässig. Wenn Skripts dieses Limit überschreiten, wird die Bereitstellung angehalten und die Bereitstellung auf der Instance schlägt fehl. Stellen Sie sicher, dass die für timeout angegebene Gesamtanzahl der Sekunden für alle Skripts in jedem Bereitstellungslebenszyklusereignis dieses Limit nicht überschreitet.

runas

Optional. Der Benutzer, der vorgetäuscht werden soll, wenn das Skript ausgeführt wird. Standardmäßig ist dies der CodeDeploy Agent, der auf der Instanz ausgeführt wird. CodeDeploy speichert keine Passwörter, sodass der Benutzer nicht imitiert werden kann, wenn der Runas-Benutzer ein Passwort benötigt. Dieses Element gilt nur für Amazon Linux- und Ubuntu Server-Instances.

Referenzieren von Dateien in Ihren Hook-Skripten

Wenn Sie ein Skript mit einem CodeDeploy Lebenszyklusereignis verknüpfen, wie unter beschriebenAppSpec Abschnitt „Hooks“, und Sie in Ihrem Skript auf eine Datei verweisen möchten (z. B.helper.sh), müssen Sie Folgendes angebenhelper.sh:

Absolute Pfade verwenden

Um mit ihrem absoluten Pfad auf eine Datei zu verweisen, können Sie entweder:

Speicherort des Bereitstellungsarchivs

Während des DownloadBundleLebenszyklusereignisses extrahiert der CodeDeploy Agent die Version für die Bereitstellung in ein Verzeichnis, das das folgende Format hat:

root-directory/deployment-group-id/deployment-id/deployment-archive

Der Stammverzeichnis-Teil des Pfads ist immer entweder auf den in der folgenden Tabelle angegebenen Standard festgelegt oder wird durch die :root_dir Konfigurationseinstellung gesteuert. Weitere Informationen zu den Konfigurationseinstellungen finden Sie unter. CodeDeploy Referenz zur Agentenkonfiguration

Agentenplattform Standard-Stammverzeichnis
Linux — alle RPM-Distributionen /opt/codedeploy-agent/deployment-root
Ubuntu Server — alle Deb-Distributionen /opt/codedeploy-agent/deployment-root
Windows Server %ProgramData%\Amazon\CodeDeploy

Von Ihren Hook-Skripten aus könnten Sie über den Stammverzeichnispfad und die DEPLOYMENT_GROUP_ID Umgebungsvariablen auf das DEPLOYMENT_ID aktuelle Deployment-Archiv zugreifen. Weitere Hinweise zu Variablen, die Sie verwenden können, finden Sie unterVerfügbarkeit von Umgebungsvariablen für Hooks.

So könnten Sie beispielsweise auf eine data.json Datei zugreifen, die sich im Stammverzeichnis Ihrer Revision unter Linux befindet:

#!/bin/bash

rootDirectory="/opt/codedeploy-agent/deployment-root" # note: this will be different if you
                                                      # customize the :root_dir configuration
dataFile="$rootDirectory/$DEPLOYMENT_GROUP_ID/$DEPLOYMENT_ID/deployment-archive/data.json"
data=$(cat dataFile)

Als weiteres Beispiel können Sie mit Powershell unter Windows auf eine data.json Datei zugreifen, die sich im Stammverzeichnis Ihrer Revision befindet:

$rootDirectory="$env:ProgramData\Amazon\CodeDeploy" # note: this will be different if you
                                                    # customize the :root_dir configuration
$dataFile="$rootDirectory\$env:DEPLOYMENT_GROUP_ID\$env:DEPLOYMENT_ID\deployment-archive\data.json"
$data=(Get-Content $dataFile)

Verwenden relativer Pfade

Um mit ihrem relativen Pfad auf eine Datei zu verweisen, müssen Sie das Arbeitsverzeichnis des CodeDeploy Agenten kennen. Dateipfade sind relativ zu diesem Verzeichnis.

Die folgende Tabelle zeigt das Arbeitsverzeichnis für jede unterstützte Plattform des CodeDeploy Agenten.

Agenten-Plattform Methode zur Prozessverwaltung Arbeitsverzeichnis für Lebenszyklusereignisskripte
Linux — alle RPM-Distributionen systemd (Standard) /
init.d — Erfahre mehr /opt/codedeploy-agent
Ubuntu Server — alle Debian-Distributionen all /opt/codedeploy-agent
Windows Server n.v. C:\Windows\System32

Verfügbarkeit von Umgebungsvariablen für Hooks

Während jedes Bereitstellungslebenszyklusereignisses können Hook-Skripts auf die folgenden Umgebungsvariablen zugreifen:

APPLICATION_NAME

Der Name der Anwendung CodeDeploy , die Teil der aktuellen Bereitstellung ist (z. B.WordPress_App).

DEPLOYMENT_ID

Die ID, die der aktuellen Bereitstellung zugewiesen CodeDeploy wurde (z. B.d-AB1CDEF23).

DEPLOYMENT_GROUP_NAME

Der Name der Bereitstellungsgruppe CodeDeploy , die Teil der aktuellen Bereitstellung ist (z. B.WordPress_DepGroup).

DEPLOYMENT_GROUP_ID

Die ID der Bereitstellungsgruppe CodeDeploy , die Teil der aktuellen Bereitstellung ist (z. B.b1a2189b-dd90-4ef5-8f40-4c1c5EXAMPLE).

LIFECYCLE_EVENT

Der Name des aktuellen Bereitstellungslebenszyklusereignisses (z. B. AfterInstall).

Es handelt sich um lokale Umgebungsvariablen für die einzelnen Bereitstellungslebenszyklusereignisse.

Abhängig von der Quelle des Bereitstellungspakets stehen zusätzliche Umgebungsvariablen für Hook-Skripte zur Verfügung:

Paket von Amazon S3

  • BUNDLE_BUCKET

    Der Name des Amazon S3 S3-Buckets, aus dem das Bereitstellungspaket heruntergeladen wurde (z. B.my-s3-bucket).

  • BUNDLE_KEY

    Der Objektschlüssel für das heruntergeladene Paket innerhalb des Amazon S3 S3-Buckets (z. B.WordPress_App.zip).

  • BUNDLE_VERSION

    Die Objektversion für das Bundle (zum Beispiel). 3sL4kqtJlcpXroDTDmJ+rmSpXd3dIbrHY+MTRCxf3vjVBH40Nr8X8gdRQBpUMLUo Diese Variable wird nur gesetzt, wenn für den Amazon S3 S3-Bucket die Objektversionierung aktiviert ist.

  • BUNDLE_ETAG

    Das Objekt-Etag für das Bundle (zum Beispiel). b10a8db164e0754105b7a99be72e3fe5-4

Paket von GitHub

  • BUNDLE_COMMIT

    Der SHA256-Commit-Hash des von Git generierten Bundles (zum Beispield2a84f4b8b650937ec8f73cd8be2c74add5a911ba64df27458ed8229da804a26).

Das folgende Skript ändert den Überwachungsport auf einem Apache HTTP-Server von 80 auf 9090, wenn der Wert von DEPLOYMENT_GROUP_NAME gleich Staging ist. Dieses Skript muss während des Bereitstellungslebenszyklusereignisses BeforeInstall aufgerufen werden:

if [ "$DEPLOYMENT_GROUP_NAME" == "Staging" ]
then
    sed -i -e 's/Listen 80/Listen 9090/g' /etc/httpd/conf/httpd.conf
fi

Das folgende Skriptbeispiel ändert die Ausführlichkeitsstufe der Nachrichten, die im Fehlerprotokoll aufgezeichnet werden, von Warnung zu Debug-Nachricht, wenn der Wert der Umgebungsvariablen DEPLOYMENT_GROUP_NAME gleich Staging ist. Dieses Skript muss während des Bereitstellungslebenszyklusereignisses BeforeInstall aufgerufen werden:

if [ "$DEPLOYMENT_GROUP_NAME" == "Staging" ]
then
    sed -i -e 's/LogLevel warn/LogLevel debug/g' /etc/httpd/conf/httpd.conf
fi

Das folgende Skriptbeispiel ersetzt den Text auf der angegebenen Webseite mit Text, der den Wert dieser Umgebungsvariablen anzeigt. Dieses Skript muss während des Bereitstellungslebenszyklusereignisses AfterInstall aufgerufen werden:

#!/usr/bin/python

import os
 
strToSearch="<h2>This application was deployed using CodeDeploy.</h2>"
strToReplace="<h2>This page for "+os.environ['APPLICATION_NAME']+" application and "+os.environ['DEPLOYMENT_GROUP_NAME']+" deployment group with "+os.environ['DEPLOYMENT_GROUP_ID']+" deployment group ID was generated by a "+os.environ['LIFECYCLE_EVENT']+" script during "+os.environ['DEPLOYMENT_ID']+" deployment.</h2>"
 
fp=open("/var/www/html/index.html","r")
buffer=fp.read()
fp.close()
 
fp=open("/var/www/html/index.html","w")
fp.write(buffer.replace(strToSearch,strToReplace))
fp.close()

Beispiel für Hooks

Hier finden Sie ein Beispiel für einen hooks-Eintrag, der zwei Hooks für das AfterInstall-Lebenszyklusereignis angibt:

hooks:
   AfterInstall:
     - location: Scripts/RunResourceTests.sh
       timeout: 180
     - location: Scripts/PostDeploy.sh
       timeout: 180

Das Skript Scripts/RunResourceTests.sh wird während der Stufe AfterInstall des Bereitstellungsvorgangs ausgeführt. Die Implementierung schlägt fehl, wenn die Ausführung des Skripts mehr als 180 Sekunden (3 Minuten) dauert.

Der Speicherort von Skripts, den Sie im Abschnitt „Hooks“ angeben, ist relativ zum Stamm des Anwendungsrevisionspakets. Im obigen Beispiel befindet sich eine Datei mit dem Namen RunResourceTests.sh in einem Verzeichnis mit dem Namen Scripts. Das Verzeichnis Scripts befindet sich auf der Stammebene des Pakets. Weitere Informationen finden Sie unter Planen Sie eine Überarbeitung für CodeDeploy.