So far, you have specified the AWS resources supporting the deployment (deployment group) and also instructed CodeDeploy on how to deploy the new application release and how to shift traffic to it (deployment configuration). There is one major element left to define, and that’s the application specification to let CodeDeploy know what to deploy. This information is passed to CodeDeploy through an application specification file (or AppSpec file), written either in Yet Another Markup Language (YAML) for deployments on EC2/on-premises, ECS, and Lambda, or JavaScript Object Notation (JSON) for ECS and Lambda deployments only.
The AppSpec file contains details about the application to be deployed. In the case of deployments on EC2/on-premises instances, it provides a mapping between source files in the new application release and their destination on the target instances. It also defines permissions to apply to the deployed files. Furthermore, it can additionally specify a set of scripts to perform validation tests during the deployment process.
In the case of ECS and Lambda, the AppSpec file provides, respectively, the name of the ECS service as well as the container name and port used to direct traffic to the new task set, and the Lambda function version to deploy. It can also specify a set of Lambda functions to be used to perform validation tests at various stages of the deployment process.
The validation scripts or functions, which are defined in the Hooks section of the AppSpec file, will be executed when the corresponding deployment lifecycle event is triggered, such as “before install” or “after install” events. Lifecycle events vary sensibly according to the target compute platform. Although ECS and Lambda share the same set of deployment lifecycle events, deployment on EC2/on-premises instances provides a totally different set. For more details on the available lifecycle events, please consult the CodeDeploy documentation at https://packt.link/NJhbu.
Here is an example of an AppSpec file to deploy a Lambda function:
version: 0.0
Resources:
– myAwsomeLambdaFunction:
Type: AWS::Lambda::Function
Properties:
Name: “myAwsomeLambdaFunction”
Alias: “myAwsomeLambdaFunctionAlias”
CurrentVersion: “1”
TargetVersion: “2”
Hooks:
– BeforeAllowTraffic: “LambdaFunctionToValidateBeforeTrafficShift”
– AfterAllowTraffic: “LambdaFunctionToValidateAfterTrafficShift”
As you can see, the content of the file is self-explanatory. It is composed of three sections: version, resources, and hooks. The version section is reserved for CodeDeploy for future use and must be set to 0.0 for now. The Resources section describes the Lambda function to be deployed, while the Hooks section lists the optional lifecycle events to handle and the associated test functions.
CodeDeploy really shines when used in combination with other members of the AWS Code family (such as CodePipeline) and/or third-party solutions, such as source code repositories or configuration management tools. It also handles automatic rollback on your behalf if a deployment fails or if a specific monitoring alarm is triggered (provided that you have defined such an alarm with CloudWatch). So, it is an extremely helpful tool for your delivery process when you deploy software to EC2/on-premises instances, ECS, or Lambda.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
