AppSpec Dateibeispiel

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

AppSpec Dateibeispiel für eine Amazon-ECS-Bereitstellung

Hier ist ein Beispiel für eine - AppSpec Datei, die in YAML für die Bereitstellung eines Amazon-ECS-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 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 Ersatzaufgabensatz installiert wird, wird die Lambda-Funktion namens LambdaFunctionToValidateBeforeInstall ausgeführt.

2. Nachdem die aktualisierte Amazon-ECS-Anwendung auf dem Ersatz-Aufgabensatz installiert wurde, aber bevor sie Datenverkehr empfängt, wird die aufgerufene Lambda-Funktion LambdaFunctionToValidateAfterInstall ausgeführt.

3. Nachdem die Amazon-ECS-Anwendung auf dem Ersatz-Aufgabensatz Datenverkehr vom Test-Listener empfangen hat, LambdaFunctionToValidateAfterTestTrafficStarts wird die aufgerufene 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 Amazon-ECS-Anwendung bereitgestellt wird, wird die Lambda-Funktion namens LambdaFunctionToValidateBeforeAllowingProductionTraffic ausgeführt.

5. Nachdem der Produktionsdatenverkehr an die aktualisierte Amazon-ECS-Anwendung im Ersatz-Aufgabensatz bereitgestellt wurde, wird die Lambda-Funktion namens LambdaFunctionToValidateAfterAllowingProductionTraffic ausgeführt.

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

AppSpec Dateibeispiel für eine AWS Lambda-Bereitstellung

Hier ist 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. Bevor Sie den Datenverkehr von Version 1 einer Lambda-Funktion namens myLambdaFunction auf Version 2 verlagern, führen Sie eine Lambda-Funktion namens aus, die validiertLambdaFunctionToValidateBeforeTrafficShift, 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 Verlagerung des Datenverkehrs von Version 1 einer Lambda-Funktion namens myLambdaFunction auf Version 2 abgeschlossen ist, führen Sie eine Lambda-Funktion namens aus, die bestätigt, LambdaFunctionToValidateAfterTrafficShift dass die Bereitstellung erfolgreich abgeschlossen wurde.

AppSpec Dateibeispiel für eine EC2/On-Premises-Bereitstellung

Hier ist ein Beispiel für eine - AppSpec Datei für eine direkte Bereitstellung auf einer Amazon Linux-, Ubuntu Server- oder RHEL-Instance.

Anmerkung

Bereitstellungen auf Windows Server-Instances unterstützen das -runasElement nicht. Wenn Sie auf Windows Server-Instances bereitstellen, fügen Sie sie nicht in Ihre - AppSpec Datei ein.

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-Instance os: linux zu os: 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.