AppSpec Beispiel für eine Datei - 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 Beispiel für eine Datei

Dieses Thema enthält AppSpec Beispieldateien für eine AWS Lambda- und eine EC2 /On-Premises-Bereitstellung.

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:

  1. Bevor die aktualisierte ECS Amazon-Anwendung auf dem Ersatz-Task-Set installiert wird, wird die Lambda-Funktion namens LambdaFunctionToValidateBeforeInstall ausgeführt.

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

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

  4. 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 Namen LambdaFunctionToValidateBeforeAllowingProductionTraffic ausgeführt.

  5. 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:

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

  2. Wenn LambdaFunctionToValidateBeforeTrafficShift den Exit-Code 0 (Erfolg) zurückgibt, fangen Sie an, Datenverkehr in Version 2 von myLambdaFunction zu verschieben. Die Bereitstellungskonfiguration für diese Bereitstellung bestimmt die Geschwindigkeit, in der der Datenverkehr verschoben wird.

  3. 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:

  1. Führen Sie das Skript unter Scripts/UnzipResourceBundle.sh aus.

  2. Wenn das vorherige Skript einen Beendigungscode von 0 (Erfolg) wiedergegeben hat, führen Sie das Skript unter Scripts/UnzipDataBundle.sh aus.

  3. Kopieren Sie den Dateipfad von Config/config.txt zum Pfad /webapps/Config/config.txt.

  4. Kopieren Sie rekursiv alle Dateien im Verzeichnis source in das Verzeichnis /webapps/myApp.

  5. Führen Sie das Skript unter Scripts/RunResourceTests.sh mit einem Timeout von 180 Sekunden (3 Minuten) aus.

  6. Führen Sie das Skript unter Scripts/RunFunctionalTests.sh mit einem Timeout von 3 600 Sekunden (1 Stunde) aus.

  7. Führen Sie das Skript unter Scripts/MonitorService.sh als Benutzer codedeploy mit einem Timeout von 3 600 Sekunden (1 Stunde) aus.