AppSpec File example - Amazon CodeDeploy
AppSpec File example for an Amazon ECS deployment AppSpec File example for an Amazon Lambda deployment AppSpec File example for an EC2/On-Premises deployment
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

AppSpec File example

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

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 called LambdaFunctionToValidateAfterInstall runs.

  3. After the Amazon ECS application on the replacement task set starts receiving traffic from the test listener, the Lambda function called LambdaFunctionToValidateAfterTestTrafficStarts 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 called LambdaFunctionToValidateBeforeAllowingProductionTraffic runs.

  5. After production traffic is served to the updated Amazon ECS application on the replacement task set, the Lambda function called LambdaFunctionToValidateAfterAllowingProductionTraffic runs.

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

AppSpec File example for an Amazon 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 called myLambdaFunction to version 2, run a Lambda function called LambdaFunctionToValidateBeforeTrafficShift 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 called myLambdaFunction to version 2 is complete, run a Lambda function called LambdaFunctionToValidateAfterTrafficShift 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 at Scripts/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 user codedeploy with a timeout of 3600 seconds (1 hour).