AppSpec File example - AWS CodeDeploy (original) (raw)

This topic provides example AppSpec files for an AWS Lambda and an EC2/On-Premises deployment.

Topics

AppSpec File example for an Amazon ECS deployment

Here is an example of an AppSpec file written in YAML for deploying an Amazon ECS service. 

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"

Here is a version of the preceding example written 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"
        }
    ]
}

Here is the sequence of events during deployment:

  1. Before the updated Amazon ECS application is installed on the replacement task set, the Lambda function called LambdaFunctionToValidateBeforeInstall runs.
  2. After the updated Amazon ECS application is installed on the replacement task set, but before it receives any traffic, the Lambda function calledLambdaFunctionToValidateAfterInstall runs.
  3. After the Amazon ECS application on the replacement task set starts receiving traffic from the test listener, the Lambda function calledLambdaFunctionToValidateAfterTestTrafficStarts runs. This function likely runs validation tests to determine if the deployment continues. If you do not specify a test listener in your deployment group, this hook is ignored.
  4. After any validation tests in the AfterAllowTestTraffic hook are completed, and before production traffic is served to the updated Amazon ECS application, the Lambda function calledLambdaFunctionToValidateBeforeAllowingProductionTraffic runs.
  5. After production traffic is served to the updated Amazon ECS application on the replacement task set, the Lambda function calledLambdaFunctionToValidateAfterAllowingProductionTraffic runs.

The Lambda functions that run during any hook can perform validation tests or gather traffic metrics.

AppSpec File example for an AWS Lambda deployment

Here is an example of an AppSpec file written in YAML for deploying a Lambda function version. 

version: 0.0
Resources:
  - myLambdaFunction:
      Type: AWS::Lambda::Function
      Properties:
        Name: "myLambdaFunction"
        Alias: "myLambdaFunctionAlias"
        CurrentVersion: "1"
        TargetVersion: "2"
Hooks:
  - BeforeAllowTraffic: "LambdaFunctionToValidateBeforeTrafficShift"
  - AfterAllowTraffic: "LambdaFunctionToValidateAfterTrafficShift"

Here is a version of the preceding example written 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"
         }
     ]
 }

Here is the sequence of events during deployment:

  1. Before shifting traffic from version 1 of a Lambda function calledmyLambdaFunction to version 2, run a Lambda function calledLambdaFunctionToValidateBeforeTrafficShift that validates the deployment is ready to start traffic shifting.
  2. If LambdaFunctionToValidateBeforeTrafficShift returned an exit code of 0 (success), begin shifting traffic to version 2 of myLambdaFunction. The deployment configuration for this deployment determines the rate at which traffic is shifted.
  3. After the shifting of traffic from version 1 of a Lambda function calledmyLambdaFunction to version 2 is complete, run a Lambda function calledLambdaFunctionToValidateAfterTrafficShift that validates the deployment was completed successfully.

AppSpec File example for an EC2/On-Premises deployment

Here is an example of an AppSpec file for an in-place deployment to an Amazon Linux, Ubuntu Server, or RHEL instance.

Note

Deployments to Windows Server instances do not support the runas element. If you are deploying to Windows Server instances, do not include it in your AppSpec file.

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

For a Windows Server instance, change os: linux to os: windows. Also, you must fully qualify the destination paths (for example,c:\temp\webapps\Config and c:\temp\webapps\myApp). Do not include the runas element.

Here is the sequence of events during deployment:

  1. Run the script located atScripts/UnzipResourceBundle.sh.
  2. If the previous script returned an exit code of 0 (success), run the script located at Scripts/UnzipDataBundle.sh.
  3. Copy the file from the path of Config/config.txt to the path/webapps/Config/config.txt.
  4. Recursively copy all the files in the source directory to the/webapps/myApp directory.
  5. Run the script located at Scripts/RunResourceTests.sh with a timeout of 180 seconds (3 minutes).
  6. Run the script located at Scripts/RunFunctionalTests.sh with a timeout of 3600 seconds (1 hour).
  7. Run the script located at Scripts/MonitorService.sh as the usercodedeploy with a timeout of 3600 seconds (1 hour).