AppSpec Abschnitt „hooks“ - AWS CodeDeploy

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 im'hooks'Der Abschnitt der AppSpec -Datei variiert abhängig von der Datenverarbeitungsplattform für Ihre Bereitstellung. Die'hooks'Der Abschnitt einer EC2/lokalen Bereitstellung enthält Zuordnungen, die Bereitstellungslebenszyklusereignis-Hooks mit einem oder mehreren Skripts verknüpfen. Die'hooks'Der Abschnitt einer Lambda - oder Amazon ECS-Bereitstellung gibt Lambda-Validierungsfunktionen an, die während eines Bereitstellungs-Lebenszyklusereignisses 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 Skripts oder Lambda -Validierungsfunktionen als Teil der Bereitstellung ausführen.

AppSpec „hooks“ -Abschnitt von einer Amazon ECS-Bereitstellung

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

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

  • BeforeInstall— Für die Ausführung von Aufgaben auf Instances verwenden, bevor der neue Aufgabensatz erstellt ist. 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.

  • AfterInstallZur Ausführung von Aufgaben, wenn der neue Aufgabensatz erstellt wurde und ihm eine der Zielgruppen zugeordnet ist. 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— Für die Ausführung von Aufgaben auf Instances verwenden, nachdem der Test-Listener Datenverkehr an den neuen Aufgabensatz sendet. Die Ergebnisse einer hook-Funktion können zu diesem Zeitpunkt einen Rollback auslösen.

  • BeforeAllowTraffic— Wird zur Ausführung von Aufgaben verwendet, wenn die zweite Zielgruppe dem neuen Aufgabensatz zugeordnet ist, aber bevor Datenverkehr an den neuen Aufgabensatz umgeleitet wurde. Die Ergebnisse einer hook-Funktion bei diesem Lebenszyklus-Ereignis können einen Rollback auslösen.

  • AfterAllowTrafficZur Ausführung von Aufgaben, wenn die zweite Zielgruppe Datenverkehr an den neuen Aufgabensatz sendet. 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.

Ausführen von Hook-Aufträgen in einer Amazon ECS-Bereitstellung

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

Anmerkung

Die Ereignisse Start, Install, TestTraffic, AllowTraffic und End in der Bereitstellung können nicht mithilfe von Skripts erledigt werden, weshalb sie in diesem Diagramm ausgegraut sind.

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 eine Lambda -Funktion

Verwenden der'hooks'Eine Lambda -Funktion angeben, die CodeDeploy aufrufen kann, um eine Lambda -Bereitstellung zu validieren. Sie können dieselbe Funktion oder eine andere für die Bereitstellungs-Lebenszyklusereignisse BeforeInstall, AfterInstall, AfterAllowTestTraffic, BeforeAllowTraffic und AfterAllowTraffic verwenden. Nach Abschluss der Validierungstests wurde der LambdaAfterAllowTrafficFunktion ruft CodeDeploy zurück und liefert ein Ergebnis vonSucceededoder .Failed.

Wichtig

Wenn CodeDeploy nicht innerhalb einer Stunde von der Lambda -Validierungsfunktion benachrichtigt wird, gilt die Bereitstellung als fehlgeschlagen.

Bevor eine Lambda Hook-Funktion aufgerufen wird, muss der Server mit der Bereitstellungs-ID und der Ausführungs-ID des Lebenszyklusereignis-Hooks informiert werden.putLifecycleEventHookExecutionStatus-Befehl.

Nachfolgend finden Sie ein Beispiel für eine Lambda Hook-Funktion, die in Node.js geschrieben ist.

'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 „hooks“ -Abschnitt für eineAWSBereitstellung von Lambda

Liste der Lifecycle-Ereignis-Hooks für eineAWSBereitstellung von Lambda

EinAWSLambda -Hook ist eine Lambda -Funktion, die nach dem Namen des Lebenszyklusereignisses mit einer Zeichenfolge in einer neuen Zeile angegeben wird. Jeder Hook wird einmal pro Bereitstellung ausgeführt. Hier finden Sie Beschreibungen der Hooks, die für die Verwendung in Ihrer AppSpec-Datei verfügbar sind.

  • BeforeAllowTraffic— Für die Ausführung von Aufgaben auf Instances verwenden, bevor Datenverkehr an die bereitgestellte Lambda Funktionsversion verschoben wird.

  • AfterAllowTraffic— Für die Ausführung von Aufgaben auf Instances verwenden, nachdem der gesamte Datenverkehr an die bereitgestellte Lambda Funktionsversion verschoben wird.

Ausführen der Reihenfolge von Hooks in einer Lambda Funktionsversion

In einer serverlosen Lambda -Funktion werden Ereignis-Hooks in der folgenden Reihenfolge ausgeführt:

Anmerkung

Die Ereignisse Start, AllowTraffic und End in der Bereitstellung können nicht mithilfe von Skripts erledigt werden, weshalb sie in diesem Diagramm ausgegraut sind.

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 eine Lambda -Funktion

Verwenden Sie den 'hooks'-Abschnitt, um eine Lambda -Funktion anzugeben, die CodeDeploy zur Validierung einer Lambda-Bereitstellung aufrufen kann. Sie können dieselbe Funktion oder eine andere für die Bereitstellungslebenszyklusereignisse BeforeAllowTraffic und AfterAllowTraffic verwenden. Nach dem Abschluss der Validierungstests ruft die Lambda -Validierungsfunktion CodeDeploy zurück und liefert ein Ergebnis vonSucceededoder .Failed.

Wichtig

Wenn CodeDeploy nicht innerhalb einer Stunde von der Lambda -Validierungsfunktion benachrichtigt wird, gilt die Bereitstellung als fehlgeschlagen.

Bevor eine Lambda Hook-Funktion aufgerufen wird, muss der Server mit der Bereitstellungs-ID und der Ausführungs-ID des Lebenszyklusereignis-Hooks informiert werden.putLifecycleEventHookExecutionStatus-Befehl.

Nachfolgend finden Sie ein Beispiel für eine Lambda Hook-Funktion, die in Node.js geschrieben ist.

'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/lokalen Bereitstellung

Liste der Lebenszyklus-Ereignis-Hooks

Ein EC2/lokalen 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. Hier finden Sie Beschreibungen der Hooks, die für die Verwendung in Ihrer AppSpec-Datei verfügbar sind.

Weitere Informationen darüber, welche Lebenszyklusereignis-Hooks für welche Bereitstellungs- und Rollback-Typen gültig sind, finden Sie unter Lifecycle-Ereignis-Hook.

  • ApplicationStopDieses Bereitstellungslebenszyklusereignis erfolgt sogar noch vor dem Herunterladen der Anwendungsrevision. 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 Bereitstellungslebenszyklusereignis verwendeten AppSpec -Datei und Skripts stammen aus der zuvor erfolgreich bereitgestellten Anwendungsrevision.

    Anmerkung

    Eine AppSpec -Datei existiert erst dann auf einer Instance, wenn Sie sie auf dieser 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 bestimmen, schlägt der CodeDeploy -Agent die imdeployment-group-id_last_successful_installfile. Diese Datei befindet sich unter:

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

    C:\ProgramData\Amazon\CodeDeploy\deployment-instructionsAmazon EC2 Instances von Windows Server.

    Informationen zur Problembehebung für eine Bereitstellung, die während des Bereitstellungslebenszyklusereignisses ApplicationStop fehlschlägt, finden Sie unter Fehlerbehebung bei einem fehlgeschlagenen Bereitstellungslebenszyklusereignis ApplicationStop, BeforeBlockTraffic oder AfterBlockTra.

  • DownloadBundleWährend dieses Bereitstellungslebenszyklusereignisses kopiert der CodeDeploy -Agent die Anwendungsrevisionsdateien an einen temporären Speicherort:

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

    C:\ProgramData\Amazon\CodeDeploy\deployment-group-id\deployment-id\deployment-archiveAmazon EC2 Instances von Windows Server.

    Dieses Ereignis ist für den CodeDeploy -Agenten vorgesehen und kann nicht zur Ausführung von Skripts verwendet werden.

    Informationen zur Problembehebung für eine Bereitstellung, die während des Bereitstellungslebenszyklusereignisses DownloadBundle fehlschlägt, finden Sie unter Fehlersuche bei einem fehlgeschlagenen Bereitstellungslebenszyklusereignis DownloadBundle mit „UnknownError: not opened for reading“.

  • BeforeInstallMit dem Bereitstellungslebenszyklusereignis können Sie Aufgaben im Vorfeld der Installation durchführen, etwa das Entschlüsseln von Dateien und das Erstellen einer Sicherung der aktuellen Version.

  • Install— Während dieses Bereitstellungslebenszyklusereignisses kopiert der CodeDeploy -Agent die Revisionsdateien aus dem temporären Speicherort in den Zielortordner. Dieses Ereignis ist für den CodeDeploy -Agenten vorgesehen und kann nicht zur Ausführung von Skripts verwendet werden.

  • AfterInstallMit diesem Bereitstellungslebenszyklusereignis können Sie Aufgaben wie das Konfigurieren Ihrer Anwendung oder das Ändern von Dateiberechtigungen durchführen.

  • ApplicationStartIn der Regel verwenden Sie dieses Bereitstellungslebenszyklusereignis, um Services, die während gestoppt wurden,ApplicationStop.

  • ValidateServiceDies ist das letzte Bereitstellungslebenszyklusereignis. Es wird verwendet, um zu überprüfen, ob die Bereitstellung erfolgreich abgeschlossen wurde.

  • BeforeBlockTrafficMit diesem Bereitstellungslebenszyklusereignis können Sie Aufgaben auf Instances ausführen, bevor deren Registrierung von einem Load Balancer aufgehoben wird.

    Informationen zur Problembehebung für eine Bereitstellung, die während des Bereitstellungslebenszyklusereignisses BeforeBlockTraffic fehlschlägt, finden Sie unter Fehlerbehebung bei einem fehlgeschlagenen Bereitstellungslebenszyklusereignis ApplicationStop, BeforeBlockTraffic oder AfterBlockTra.

  • BlockTrafficWährend dieses Bereitstellungslebenszyklusereignisses wird verhindert, dass Internetdatenverkehr auf Instances zugreift, die derzeit Datenverkehr bereitstellen. Dieses Ereignis ist für den CodeDeploy -Agenten vorgesehen und kann nicht zur Ausführung von Skripts verwendet werden.

  • AfterBlockTrafficMit diesem Bereitstellungslebenszyklusereignis können Sie Aufgaben auf Instances ausführen, nachdem deren Registrierung von einem Load Balancer aufgehoben wurde.

    Informationen zur Problembehebung für eine Bereitstellung, die während des Bereitstellungslebenszyklusereignisses AfterBlockTraffic fehlschlägt, finden Sie unter Fehlerbehebung bei einem fehlgeschlagenen Bereitstellungslebenszyklusereignis ApplicationStop, BeforeBlockTraffic oder AfterBlockTra.

  • BeforeAllowTrafficMit diesem Bereitstellungslebenszyklusereignis können Sie Aufgaben auf Instances ausführen, bevor sie bei einem Load Balancer registriert werden.

  • AllowTrafficWährend dieses Bereitstellungslebenszyklusereignisses kann Internetdatenverkehr nach einer Bereitstellung auf Instances zugreifen. Dieses Ereignis ist für den CodeDeploy -Agenten vorgesehen und kann nicht zur Ausführung von Skripts verwendet werden.

  • AfterAllowTrafficMit diesem Bereitstellungslebenszyklusereignis können Sie Aufgaben auf Instances ausführen, nachdem sie bei einem Load Balancer registriert wurden.

Lifecycle-Ereignis-Hook

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

Name des Lebenszyklusereignis In-Situ-Bereitstellung¹ Blau/Grün-Bereitstellung: Original instances Blau/Grün-Bereitstellung: Ersatz-Instanzen Blau/Grün-Bereitstellungs-Rollback: Original instances Blau/Grün-Bereitstellungs-Rollback: Ersatz-Instanzen
ApplicationStop
DownloadBundle²
BeforeInstall
Installieren²
AfterInstall
ApplicationStart
ValidateService
BeforeBlockTraffic
BlockTraffic²
AfterBlockTraffic
BeforeAllowTraffic
AllowTraffic²
AfterAllowTraffic

¹ Gilt auch für das Rollback von In-Situ-Bereitstellungen.

² Reserviert für CodeDeploy Vorgänge. Kann nicht für die Ausführung von Skripts verwendet werden.

Ausführen der Reihenfolge von Hooks in einer Bereitstellung

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

Für In-Situ-Bereitstellungen gelten die sechs Hooks im Zusammenhang mit dem Blockieren und Zulassen von Datenverkehr nur, wenn Sie einen Classic Load Balancer, einen Application Load Balancer oder den Network Load Balancer von Elastic Load Balancing in der Bereitstellungsgruppe angeben.

Anmerkung

Die Ereignisse Start, DownloadBundle, Install und End in der Bereitstellung können nicht mithilfe von Skripts erledigt werden, weshalb sie in diesem Diagramm ausgegraut sind. Sie können jedoch die Option'files'In der AppSpec -Datei können Sie angeben, was während derInstallevent.

Blau/Grün-Bereitstellungen

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

Anmerkung

Die Ereignisse Start, DownloadBundle, Install, BlockTraffic, AllowTraffic und End in der Bereitstellung können nicht mithilfe von Skripts erledigt werden, weshalb sie in diesem Diagramm ausgegraut sind. Sie können jedoch den Abschnitt 'files' der AppSpec -Datei bearbeiten, um anzugeben, was während der Installation derInstallevent.

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 Skripte, die Sie in derhooksDer Abschnitt ist relativ zum Stamm des Anwendungsrevisionspakets. Weitere Informationen finden Sie unter Planen einer Revision 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 Instance ausgeführt wird. CodeDeploy speichert keine Passwörter, sodass der Benutzer nicht vorgetäuscht werden kann, wenn derrunas-Benutzer ein Kennwort benötigt. Dieses Element gilt nur für Amazon Linux- und Ubuntu Server-Instances.

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 in CodeDeploy, die Teil der aktuellen Bereitstellung ist (z. B.WordPress_App) enthalten.

DEPLOYMENT_ID

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

DEPLOYMENT_GROUP_NAME

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

DEPLOYMENT_GROUP_ID

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

LIFECYCLE_EVENT

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

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

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 einer Revision für CodeDeploy.