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 Beispiel für eine Datei
Dieses Thema enthält AppSpec Beispieldateien für eine AWS Lambda- und eine EC2 /On-Premises-Bereitstellung.
Themen
AppSpec Dateibeispiel für eine ECS Amazon-Bereitstellung
Hier ist ein Beispiel für eine AppSpec Datei, die YAML für die Bereitstellung eines ECS Amazon-Service geschrieben wurde.
version: 0.0 Resources: - TargetService: Type: AWS::ECS::Service Properties: TaskDefinition: "arn:aws:ecs:us-east-1:111222333444:task-definition/my-task-definition-family-name:1" LoadBalancerInfo: ContainerName: "SampleApplicationName" ContainerPort: 80 # Optional properties PlatformVersion: "LATEST" NetworkConfiguration: AwsvpcConfiguration: Subnets: ["subnet-1234abcd","subnet-5678abcd"] SecurityGroups: ["sg-12345678"] AssignPublicIp: "ENABLED" CapacityProviderStrategy: - Base: 1 CapacityProvider: "FARGATE_SPOT" Weight: 2 - Base: 0 CapacityProvider: "FARGATE" Weight: 1 Hooks: - BeforeInstall: "LambdaFunctionToValidateBeforeInstall" - AfterInstall: "LambdaFunctionToValidateAfterInstall" - AfterAllowTestTraffic: "LambdaFunctionToValidateAfterTestTrafficStarts" - BeforeAllowTraffic: "LambdaFunctionToValidateBeforeAllowingProductionTraffic" - AfterAllowTraffic: "LambdaFunctionToValidateAfterAllowingProductionTraffic"
Hier ist eine Version des vorherigen Beispiels geschriebenJSON.
{ "version": 0.0, "Resources": [ { "TargetService": { "Type": "AWS::ECS::Service", "Properties": { "TaskDefinition": "arn:aws:ecs:us-east-1:111222333444:task-definition/my-task-definition-family-name:1", "LoadBalancerInfo": { "ContainerName": "SampleApplicationName", "ContainerPort": 80 }, "PlatformVersion": "LATEST", "NetworkConfiguration": { "AwsvpcConfiguration": { "Subnets": [ "subnet-1234abcd", "subnet-5678abcd" ], "SecurityGroups": [ "sg-12345678" ], "AssignPublicIp": "ENABLED" } }, "CapacityProviderStrategy": [ { "Base" : 1, "CapacityProvider" : "FARGATE_SPOT", "Weight" : 2 }, { "Base" : 0, "CapacityProvider" : "FARGATE", "Weight" : 1 } ] } } } ], "Hooks": [ { "BeforeInstall": "LambdaFunctionToValidateBeforeInstall" }, { "AfterInstall": "LambdaFunctionToValidateAfterInstall" }, { "AfterAllowTestTraffic": "LambdaFunctionToValidateAfterTestTrafficStarts" }, { "BeforeAllowTraffic": "LambdaFunctionToValidateBeforeAllowingProductionTraffic" }, { "AfterAllowTraffic": "LambdaFunctionToValidateAfterAllowingProductionTraffic" } ] }
Hier finden Sie die Ereignisabfolge während der Bereitstellung:
-
Bevor die aktualisierte ECS Amazon-Anwendung auf dem Ersatz-Task-Set installiert wird, wird die Lambda-Funktion namens
LambdaFunctionToValidateBeforeInstall
ausgeführt. -
Nachdem die aktualisierte ECS Amazon-Anwendung auf dem Ersatzaufgabensatz installiert wurde, aber bevor sie Datenverkehr empfängt, wird die Lambda-Funktion namens Lambda-Funktion
LambdaFunctionToValidateAfterInstall
ausgeführt. -
Nachdem die ECS Amazon-Anwendung auf dem Ersatzaufgabensatz anfängt, Datenverkehr vom Test-Listener zu empfangen, wird die Lambda-Funktion namens
LambdaFunctionToValidateAfterTestTrafficStarts
Lambda-Funktion ausgeführt. Diese Funktion führt wahrscheinlich Validierungstests durch, um zu bestimmen, ob die Bereitstellung fortgesetzt wird. Wenn Sie keinen Test-Listener in Ihrer Bereitstellungsgruppe angeben, wird dieser Hook ignoriert. -
Nachdem alle Validierungstests im
AfterAllowTestTraffic
Hook abgeschlossen sind und bevor der Produktionsdatenverkehr an die aktualisierte ECS Amazon-Anwendung weitergeleitet wird, wird die Lambda-Funktion mit dem NamenLambdaFunctionToValidateBeforeAllowingProductionTraffic
ausgeführt. -
Nachdem der Produktionsdatenverkehr für die aktualisierte ECS Amazon-Anwendung auf dem Ersatz-Tasksatz bereitgestellt wurde, wird die Lambda-Funktion namens Lambda-Funktion
LambdaFunctionToValidateAfterAllowingProductionTraffic
ausgeführt.
Die Lambda-Funktionen, die während eines beliebigen Hooks ausgeführt werden, können Validierungstests durchführen oder Verkehrsmetriken sammeln.
AppSpec Dateibeispiel für eine AWS Lambda-Bereitstellung
Hier ist ein Beispiel für eine AppSpec Datei, in die YAML für die Bereitstellung einer Lambda-Funktionsversion geschrieben wurde.
version: 0.0 Resources: - myLambdaFunction: Type: AWS::Lambda::Function Properties: Name: "myLambdaFunction" Alias: "myLambdaFunctionAlias" CurrentVersion: "1" TargetVersion: "2" Hooks: - BeforeAllowTraffic: "LambdaFunctionToValidateBeforeTrafficShift" - AfterAllowTraffic: "LambdaFunctionToValidateAfterTrafficShift"
Hier ist eine Version des vorherigen Beispiels geschrieben. JSON
{ "version": 0.0, "Resources": [{ "myLambdaFunction": { "Type": "AWS::Lambda::Function", "Properties": { "Name": "myLambdaFunction", "Alias": "myLambdaFunctionAlias", "CurrentVersion": "1", "TargetVersion": "2" } } }], "Hooks": [{ "BeforeAllowTraffic": "LambdaFunctionToValidateBeforeTrafficShift" }, { "AfterAllowTraffic": "LambdaFunctionToValidateAfterTrafficShift" } ] }
Hier finden Sie die Ereignisabfolge während der Bereitstellung:
-
Bevor Sie den Datenverkehr von Version 1 einer aufgerufenen Lambda-Funktion
myLambdaFunction
auf Version 2 verlagern, führen Sie eine Lambda-Funktion namens aus,LambdaFunctionToValidateBeforeTrafficShift
die bestätigt, dass die Bereitstellung bereit ist, mit der Verkehrsverlagerung zu beginnen. -
Wenn
LambdaFunctionToValidateBeforeTrafficShift
den Exit-Code 0 (Erfolg) zurückgibt, fangen Sie an, Datenverkehr in Version 2 vonmyLambdaFunction
zu verschieben. Die Bereitstellungskonfiguration für diese Bereitstellung bestimmt die Geschwindigkeit, in der der Datenverkehr verschoben wird. -
Nachdem die Übertragung des Datenverkehrs von Version 1 einer aufgerufenen Lambda-Funktion
myLambdaFunction
auf Version 2 abgeschlossen ist, führen Sie eine aufgerufene Lambda-Funktion aus,LambdaFunctionToValidateAfterTrafficShift
die bestätigt, dass die Bereitstellung erfolgreich abgeschlossen wurde.
AppSpec Dateibeispiel für eine /On-Premises-Bereitstellung EC2
Hier ist ein Beispiel für eine AppSpec Datei für eine direkte Bereitstellung auf einem Amazon Linux-, Ubuntu-Server oder einer RHEL Instance.
Anmerkung
Bereitstellungen auf Windows Server-Instances unterstützen das runas
Element nicht. Wenn Sie es auf Windows Server-Instanzen bereitstellen, nehmen Sie es nicht in Ihre AppSpec Datei auf.
version: 0.0 os: linux files: - source: Config/config.txt destination: /webapps/Config - source: source destination: /webapps/myApp hooks: BeforeInstall: - location: Scripts/UnzipResourceBundle.sh - location: Scripts/UnzipDataBundle.sh AfterInstall: - location: Scripts/RunResourceTests.sh timeout: 180 ApplicationStart: - location: Scripts/RunFunctionalTests.sh timeout: 3600 ValidateService: - location: Scripts/MonitorService.sh timeout: 3600 runas: codedeployuser
Wechseln Sie für eine Windows Server-Instanz os: linux
zuos: windows
. Außerdem müssen Sie die destination
-Pfade vollständig qualifizieren (z. B. c:\temp\webapps\Config
und c:\temp\webapps\myApp
). Beziehen Sie das Element runas
nicht mit ein.
Hier finden Sie die Ereignisabfolge während der Bereitstellung:
-
Führen Sie das Skript unter
Scripts/UnzipResourceBundle.sh
aus. -
Wenn das vorherige Skript einen Beendigungscode von 0 (Erfolg) wiedergegeben hat, führen Sie das Skript unter
Scripts/UnzipDataBundle.sh
aus. -
Kopieren Sie den Dateipfad von
Config/config.txt
zum Pfad/webapps/Config/config.txt
. -
Kopieren Sie rekursiv alle Dateien im Verzeichnis
source
in das Verzeichnis/webapps/myApp
. -
Führen Sie das Skript unter
Scripts/RunResourceTests.sh
mit einem Timeout von 180 Sekunden (3 Minuten) aus. -
Führen Sie das Skript unter
Scripts/RunFunctionalTests.sh
mit einem Timeout von 3 600 Sekunden (1 Stunde) aus. -
Führen Sie das Skript unter
Scripts/MonitorService.sh
als Benutzercodedeploy
mit einem Timeout von 3 600 Sekunden (1 Stunde) aus.