AppSpec Datei-Beispiel - 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 Datei-Beispiel

AppSpec Beispieldateien für eineAWSLambda und eine EC2/lokalen Bereitstellung.

Beispiel für eine AppSpec File (Beispiel für eine Amazon ECS-Bereitstellung)

Hier finden Sie ein Beispiel für eine AppSpec -Datei, die in YAML für die Bereitstellung eines Amazon ECS-Diensts 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 finden Sie eine Version des obigen Beispiels in JSON.

{ "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 Amazon ECS-Anwendung auf dem neuen Aufgabensatz installiert wird, wird die Lambda -Funktion namensLambdaFunctionToValidateBeforeInstallFührt aus.

  2. Wenn die aktualisierte Amazon ECS-Anwendung auf dem neuen Aufgabensatz installiert ist, aber bevor irgendwelcher Datenverkehr an sie weitergeleitet wird, wird die Lambda Funktion namensLambdaFunctionToValidateAfterInstallFührt aus.

  3. Wenn die Amazon ECS-Anwendung auf dem neuen Aufgabensatz Datenverkehr vom Test-Listener empfängt, wird die Lambda Funktion namensLambdaFunctionToValidateAfterTestTrafficStartsFührt aus. 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. Nach allen Validierungstests in derAfterAllowTestTrafficBevor Produktionsdatenverkehr an die aktualisierte Amazon ECS-Anwendung geleitet wird, wird die Lambda -Funktion namensLambdaFunctionToValidateBeforeAllowingProductionTrafficFührt aus.

  5. Wenn Produktionsdatenverkehr an die aktualisierte Amazon ECS-Anwendung auf dem neuen Aufgabensatz geleitet wurde, wird die Lambda -Funktion namensLambdaFunctionToValidateAfterAllowingProductionTrafficFührt aus.

Die Lambda -Funktionen, die während beliebiger Hooks ausgeführt werden, können Validierungstests durchführen oder Datenverkehrsmetriken erfassen.

AppSpec File Beispiel für eineAWSBereitstellung von Lambda

Hier finden Sie ein Beispiel für eine AppSpec -Datei, die in 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 finden Sie eine Version des obigen Beispiels in 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. Vor dem Verschieben des Datenverkehrs von Version 1 einer Lambda Funktion namensmyLambdaFunctionauf Version 2, führen Sie eine Lambda Funktion namensLambdaFunctionToValidateBeforeTrafficShift, die überprüft, ob die Bereitstellung bereit ist, den Datenverkehr zu verschieben.

  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. Nach der Verschiebung des Datenverkehrs von Version 1 einer Lambda Funktion namensmyLambdaFunctionauf Version 2 abgeschlossen ist, führen Sie eine Lambda Funktion namensLambdaFunctionToValidateAfterTrafficShiftDie Validierung der Bereitstellung wurde erfolgreich abgeschlossen.

AppSpec File — Beispiel für eine EC2/lokalen Bereitstellung

Hier finden Sie ein Beispiel für eine AppSpec -Datei für eine In-Situ-Bereitstellung auf einer Amazon Linux-, Ubuntu-Server- oder RHEL-Instance.

Anmerkung

Bereitstellungen für Windows Server-Instanzen unterstützen dierunas-Element. Wenn Sie die Bereitstellung auf Windows Server-Instanzen durchführen, sollten Sie sie nicht in die AppSpec -Datei aufnehmen.

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

Ändern Sie für eine Windows Server -Instanceos: linuxaufos: 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.