Post

AWS - CodeDevelop - CodeDeploy

Posted
By Grace L
26 min read

CodeDeploy

  • a deployment service
  • CodeDeploy makes it easier to:
    • Rapidly release new features
    • Update AWS Lambda function versions
    • Avoid downtime during application deployment
    • avoid risks associated with manual deployments
      • CodeDeploy handle the complexity of updating the applications

2 deployment approaches type options:

  • In-place / rolling update deployment
    • The application is stopped on each instance in the deployment group, and the new version is installed.
    • roll back: re-deploy, time consume
  • Blue/Green deployment

    more save

    • new release is installed on the new instances.
    • blue: active deployment
    • green: new release
    • roll back, easy switch, registered and deregistered to the load balancer

deployment approaches

can deploy nearly unlimited variety of application content, including:

  • Code
    • Serverless AWS Lambda functions
      • do not need to make changes to your existing code before you can use CodeDeploy.
  • Web and configuration files
  • Executables
  • Packages
  • Scripts
  • Multimedia files

Benefits of AWS CodeDeploy

CodeDeploy offers these benefits:

  1. Server, serverless, and container applications
    • deploy both
      • traditional applications on servers (EC2 instances, on-premises instances)
      • and applications that deploy a serverless AWS Lambda function version or an Amazon ECS application.
    • CodeDeploy works with various systems for configuration management, source control, continuous integration, continuous delivery, and continuous deployment
  2. Automated application deployments
    • fully automates the application deployments across the development, test, and production environments
    • Repeatable deployments
      • easily repeat an application deployment across different groups of instances with AWS CodeDeploy.
      • CodeDeploy uses a file and command-based install model, which enables it to deploy any application and reuse existing setup code.
      • The same setup code can be used to consistently deploy and test updates across your deployment, test, and production release stages for Amazon EC2 instances.
      • Eliminate manual steps from deployments increases the speed and reliability of software delivery process.
    • Automatic scaling
      • scales with your infrastructure to deploy to one instance or thousands.
      • integrate software deployment and scaling activities in order to keep your application up-to-date in a dynamic production environment.
      • For Amazon EC2 instances, CodeDeploy integrates with Auto Scaling. Auto Scaling allows you to scale EC2 capacity according to conditions you define such as spikes in traffic. CodeDeploy is notified whenever a new instance launches into an Auto Scaling group and will automatically perform an application deployment on the new instance before it is added to an Elastic Load Balancing load balancer.
    • On-premises deployments
      • use AWS CodeDeploy to automate software deployments across the development, test, and production environments running on any instance
        • including instances in your own data centers (instances need to connect to AWS public endpoints).
      • enables you to use a single service to consistently deploy applications across hybrid architectures.
  3. Minimize downtime

    • no require downtime when upgraded to a new revision

    • in-place / rolling update
      • for EC2/On-Premises compute platform
      • maximize the application availability.
      • CodeDeploy performs a rolling update across Amazon EC2 instances
      • specify the number of instances to be taken offline at a time for updates.
    • blue/green deployment update
      • the latest application revision is installed on replacement instances.
      • new version of application is launched alongside the old version.
      • Once the new revision is tested and declared ready, CodeDeploy shift the traffic from your prior version to new version according to the specifications.
      • Traffic is rerouted to these instances when you choose, Canary, Linear, all-at-once
    • deployment health tracking
      • For both deployment types, CodeDeploy tracks application health according to rules you configure.
      • works in conjunction with rolling updates to keep applications highly available during deployments.
      • Unexpected downtime can occur if bad updates are deployed.
      • AWS CodeDeploy monitors your deployment and will stop a deployment if there are too many failed updates.
  4. Stop and roll back
    • stop an application deployment that is in process at any time using the AWS Management Console, the AWS CLI, or any of the AWS SDKs.
      • can automatically or manually stop and roll back deployments if there are errors.
      • re-deploy that revision if you want to continue the stopped deployment at a later time.
      • or immediately rollback by redeploying the previous revision.
  5. Centralized control

    • receive a report that lists when each application revision was deployed and to which Amazon EC2 instances.

    • Monitoring and control
      • launch, control, and monitor deployments of the software directly from the AWS Management Console or by using the AWS CLI, SDKs, or APIs.
      • In the case of a failure, you can
        • pinpoint the script experiencing failure.
        • set push notifications to monitor the status of the deployments via SMS or email through Amazon Simple Notification Service.
    • Deployment groups
      • One application can be deployed to multiple deployment groups.
      • Deployment groups are used to match configurations to specific environments, such as a staging or production environments.
      • You can test a revision in staging and then deploy that same code with the same deployment instructions to production once you are satisfied.
    • Deployment history
      • tracks and stores the recent history of the deployments.
      • view which application versions are currently deployed to each of your target deployment groups.
      • inspect the change history and success rates of past deployments to specific deployment groups.
      • investigate a timeline of past deployments for a detailed view of the deployment successes and errors.
    • quickly search for resources
      • such as repositories, build projects, deployment applications, and pipelines.
      • Go to resource or press the / key > type the name of the resource.
      • Any matches appear in the list.
      • Searches are case insensitive.
      • only see resources that you have permissions to view.
  6. Easy to adopt
    • platform and language agnostic and works with any application.
    • easily reuse the setup code
      • AWS CodeDeploy uses a file and command-based install model
        • single AppSpec configuration file to run actions, tests, or verifications at each lifecycle event (phase of deployment).
        • The commands can be any code, such as a shell script, a custom program, or even a configuration management tool.
      • enables it to deploy any application and reuse existing setup code.
    • Tool chain integration
      • easy to integrate application deployments with your existing software delivery toolchain by using the AWS CodeDeploy APIs.
      • AWS CodePipeline, AWS CodeStar, and some AWS partners provide pre-built CodeDeploy integrations for continuous integration and continuous delivery services, making it simple to automatically deploy your updated application.
      • can deploy application content that runs on a server and is stored in S3 buckets, GitHub repositories, or Bitbucket repositories
  7. 同时地 Concurrent deployments.
    • have more than one application that uses the EC2/On-Premises compute platform, CodeDeploy can deploy them concurrently to the same set of instances.
  8. Receive Notifications
    • Review defined events
      • create notifications for events impacting the deployments.
      • Notifications will come in the form of Amazon SNS notifications.
      • Each notification includes a status message as well as a link to the resources whose event generated that notification.

Overview of CodeDeploy compute platforms

CodeDeploy is able to deploy applications to three compute platforms:

1. EC2/On-Premises compute platform

  • Deployments that use physical servers like Amazon EC2 cloud instances, on-premises servers, or both.
  • Applications created using the EC2/On-Premises compute platform can be composed of executable files, configuration files, images, and more.
  • manage the way in which traffic is directed to instances by using:
    • in-place deployment type
    • or blue/green deployment type

2. AWS Lambda

  • deploy applications that consist of an updated version of a Lambda function.
  • AWS Lambda manages the Lambda function in a serverless compute environment made up of a high-availability compute structure. All administration of the compute resources is performed by AWS Lambda
  • manage the way in which traffic is shifted to the updated Lambda function versions during a deployment by choosing:
    • canary, linear, or all-at-once configuration

3. Amazon ECS

  • deploy an Amazon ECS containerized application as a task set.
  • CodeDeploy performs a blue/green deployment by installing an updated version of the application as a new replacement task set.
  • CodeDeploy reroutes production traffic from the original application task set to the replacement task set.
  • The original task set is terminated after a successful deployment.
  • manage the way in which traffic is shifted to the updated task set during a deployment by choosing
    • canary, linear, or all-at-once configuration
    • Amazon ECS blue/green deployments are supported using both CodeDeploy and AWS CloudFormation.
CodeDeploy componentEC2/On-PremisesAWS LambdaAmazon ECS
Deployment groupDeploys a revision to a set of instances.Deploys a new version of a serverless Lambda function on a high-availability compute infrastructure.Specifies the Amazon ECS service with the containerized application to deploy as a task set, a production and optional test listener used to serve traffic to the deployed application, when to reroute traffic and terminate the deployed application’s original task set, and optional trigger, alarm, and rollback settings.
DeploymentDeploys a new revision that consists of an application and AppSpec file. The AppSpec specifies how to deploy the application to the instances in a deployment group Shifts production traffic from one version of a Lambda function to a new version of the same function. The AppSpec file specifies which Lambda function version to deploy Deploys an updated version of an Amazon ECS containerized application as a new, replacement task set. CodeDeploy reroutes production traffic from the task set with the original version to the new replacement task set with the updated version. When the deployment completes, the original task set is terminated.
Deployment configurationSettings that determine the deployment speed and the minimum number of instances that must be healthy at any point during a deployment.Settings that determine how traffic is shifted to the updated Lambda function versions.Settings that determine how traffic is shifted to the updated Amazon ECS task set.
RevisionA combination of an AppSpec file and application files, such as executables, configuration files, and so on.An AppSpec file that specifies which Lambda function to deploy and Lambda functions that can run validation tests during deployment lifecycle event hooks.An AppSpec file that specifies:
- The Amazon ECS task definition for the Amazon ECS service with the containerized application to deploy.
- The container where your updated application is deployed.
- A port for the container where production traffic is rerouted.
- Optional network configuration settings and Lambda functions that can run validation tests during deployment lifecycle event hooks.
ApplicationA collection of deployment groups and revisions.
An EC2/On-Premises application uses the EC2/On-Premises compute platform.		A collection of deployment groups and revisions.
An application used for an AWS Lambda deployment uses the serverless AWS Lambda compute platform.		A collection of deployment groups and revisions.
An application used for an Amazon ECS deployment uses the Amazon ECS compute platform.

CodeDeploy deployment approaches types

CodeDeploy provides two deployment approaches type options:

  • In-place deployment
    • hook: de-registering, installation, re-registering
  • Blue/Green deployment

blue/green deployment vs in-place deployment

A blue/green deployment offers a number of advantages over an in-place deployment:

  • install and test an application in the new replacement environment and deploy it to production simply by rerouting traffic

  • the EC2/On-Premises compute platform, switching back to the most recent version of an application is faster and more reliable
    • traffic can be routed back to the original instances as long as they have not been terminated.
    • With an in-place deployment, versions must be rolled back by redeploying the previous version of the application.

  • EC2/On-Premises compute platform, new instances are provisioned for a blue/green deployment and reflect the most up-to-date server configurations. This helps you avoid the types of problems that sometimes occur on long-running instances.

  • AWS Lambda compute platform, you control how traffic is shifted from your original AWS Lambda function version to your new AWS Lambda function version.

  • Amazon ECS compute platform, you control how traffic is shifted from your original task set to your new task set.

In-place deployment

In-place deployment:

  • rolling update
  • The application on each instance in the deployment group is stopped
    • the instance is offline
  • the latest/new application revision is installed
    • the new version of the application is started and validated.

The AppSpec file

  • unique to CodeDeploy
  • It defines the deployment actions you want CodeDeploy to execute.

You can use a load balancer so that each instance is deregistered during its deployment and then restored to service after the deployment is complete.

Only deployments that use the EC2/On-Premises compute platform can use in-place deployments. AWS Lambda and Amazon ECS deployments cannot use an in-place deployment type.

sds_architecture

Here’s how it works:

  1. local development machine:
    • bundle deployable content + Application specification file (AppSpec file) into an archive file (an application revision)
    • and then upload it to an Amazon S3 bucket or a GitHub repository.
  2. provide CodeDeploy with information about your deployment
    • such as
      • which Amazon S3 bucket or GitHub repository to pull the revision from
      • to which set of Amazon EC2 instances to deploy its contents.
    • deployment group
      • CodeDeploy calls a set of Amazon EC2 instances a deployment group.
      • A deployment group contains
        • individually tagged Amazon EC2 instances
        • Amazon EC2 instances in Amazon EC2 Auto Scaling groups
        • or both.
    • Each time successfully upload a new application revision to deploy to the deployment group, that bundle is set as the target revision for the deployment group.
    • In other words, the application revision that is currently targeted for deployment is the target revision.
    • This is also the revision that is pulled for automatic deployments.
  3. CodeDeploy agent

    on each instance

    • polls CodeDeploy to determine what and when to pull from the specified Amazon S3 bucket or GitHub repository.
    • pulls the target revision from the Amazon S3 bucket or GitHub repository
    • using the instructions in the AppSpec file, deploys the contents to the instance.

Screen Shot 2021-01-18 at 16.07.37

Screen Shot 2021-01-18 at 16.08.10

Screen Shot 2021-01-18 at 16.08.23

Blue/Green deployment

One of the challenges of automating deployment is the cutover,

  • take software from the final stage of testing to live production

Blue/Green deployment

  1. test new hardware or applications without going fully into production

  2. update the applications while minimizing interruptions caused by the changes of a new application version.

  3. CodeDeploy provisions your new application version alongside the old version before rerouting your production traffic
    • After the green deployment is complete and functional, begin to shut down or upgrade the blue deployment.
  4. rapid roll back
    • switching back to blue deployment if the green environment is not working properly.

blue/green deployment is highly desirable

  • the live production environment is “blue”
  • the matching environment is “green”

Blue/green deployment on different compute platform

Blue/green deployment: The behavior of your deployment depends on which compute platform you use:

  1. AWS Lambda

    :

    • Traffic is shifted from one version of a Lambda function to a new version of the same Lambda function
    • specify Lambda functions that perform validation tests and choose the way in which the traffic shifting occurs.
  2. Amazon ECS

    :

    • Traffic is shifted from a task set in your Amazon ECS service to an updated, replacement task set in the same Amazon ECS service
    • can set the traffic shifting to linear or canary through the deployment configuration.
    • The protocol and port of a specified load balancer listener is used to reroute production traffic.
    • During a deployment, a test listener can be used to serve traffic to the replacement task set while validation tests are run.
  3. EC2/On-Premises

    :

    • Traffic is shifted from one set of instances in the original environment to a replacement/different set of instances
    • the original environment -> the replacement environment
      • Instances are provisioned for the replacement environment.
      • The latest application revision is installed on the replacement instances.
      • An optional wait time occurs for activities such as application testing and system verification.
    • Elastic Load Balancing load balancer
      • Instances in the replacement environment

        are registered with an Elastic Load Balancing load balancer , causing traffic to be rerouted to them.

      • Instances in the original environment

        are deregistered and can be terminated or kept running for other uses.

  4. AWS CloudFormation

    :

    • Traffic is shifted from your current resources to your updated resources as part of an AWS CloudFormation stack update.

    • Currently, only Amazon ECS blue/green deployments are supported.

    • AWS CloudFormation templates for deployments:
      • configure deployments with AWS CloudFormation templates
      • deployments are triggered by AWS CloudFormation updates.
      • change a resource and upload a template change, a stack update in AWS CloudFormation initiates the new deployment
    • Blue/green deployments through AWS CloudFormation: use AWS CloudFormation to manage your blue/green deployments through stack updates.
      • define both your blue and green resources, in addition to specifying the traffic routing and stabilization settings, within the stack template.
      • if update selected resources during a stack update, AWS CloudFormation generates all the necessary green resources, shifts the traffic based on the specified traffic routing parameters, and deletes the blue resources.

overall

  • All AWS Lambda and Amazon ECS deployments are blue/green. For this reason, do not need to specify a deployment type.
  • An EC2/On-Premises deployment can be in-place or blue/green.
    • blue/green deployments work with Amazon EC2 instances only.

Blue/Green deployment through lambda and ECS

If using the AWS Lambda compute platform, must choose the deployment configuration types specify how traffic is shifted from the original AWS Lambda function version to the new AWS Lambda function version

If you’re using the Amazon ECS compute platform, you must choose one of the following deployment configuration types to specify how traffic is shifted from the original Amazon ECS task set to the new Amazon ECS task set:

  • Canary 金丝雀 :
    • split traffic
    • sending a small percentage

      of the traffic to the new version of your application

    • Traffic is shifted in two increments
    • predefined canary options
      • specify the percentage of traffic shifted

        to the updated Lambda function version in the first increment

      • and the interval, in minutes, before the remaining traffic is shifted in the second increment.
  • Linear:
    • Traffic is shifted in equal increments with an equal number of minutes between each increment.
    • predefined linear options
      • specify the percentage of traffic shifted in each increment
      • and the number of minutes between each increment.
  • All-at-once:
    • All traffic is shifted from the original Lambda function to the updated Lambda function version all at once.

Blue/Green deployment on an EC2/on-premises compute platform

must use Amazon EC2 instances for blue/green deployments on the EC2/On-Premises compute platform. On-premises instances are not supported for the blue/green deployment type.

to use the EC2/On-Premises compute platform, the following applies:

  • must have one or more Amazon EC2 instances with identifying Amazon EC2 tags or an Amazon EC2 Auto Scaling group.
  • The instances must meet these additional requirements:
    • Each Amazon EC2 instance must have the correct IAM instance profile attached.
    • The CodeDeploy agent must be installed and running on each instance.

You typically also have an application revision running on the instances in your original environment, but this is not a requirement for a blue/green deployment.

  • create a deployment group

    that is used in blue/green deployments, choose how your replacement environment is specified

    • Copy an existing Amazon EC2 Auto Scaling group
      • During the blue/green deployment, CodeDeploy creates the instances for your replacement environment during the deployment.
      • CodeDeploy uses the Amazon EC2 Auto Scaling group you specify as a template for the replacement environment, including the same number of running instances and many other configuration options.
    • Choose instances manually
      • specify the instances to be the replacement using Amazon EC2 instance tags, Amazon EC2 Auto Scaling group names, or both
      • do not need to specify the instances for the replacement environment until you create a deployment.

Here’s how it works:

  1. have instances or an Amazon EC2 Auto Scaling group serves as the original environment.
    • The first time you run a blue/green deployment, you typically use instances that were already used in an in-place deployment.
  2. In an existing CodeDeploy application
    • create a blue/green deployment group
    • in addition to the options required for an in-place deployment, specify the following :
      • The load balancer: routes traffic from original environment to replacement environment during the blue/green deployment process.
      • Whether to reroute traffic to the replacement environment immediately or wait to reroute it manually.
      • The rate at which traffic is routed to the replacement instances.
      • Whether the instances that are replaced are terminated or kept running.
  3. create a deployment for this deployment group during which the following occur:
    • chose to copy an Amazon EC2 Auto Scaling group,
      • instances are provisioned for your replacement environment.
      • The application revision you specify for the deployment is installed on the replacement instances.
    • specified a wait time in the deployment group settings, the deployment is paused.
      • This is the time when you can run tests and verifications in your replacement environment.
      • If you don’t manually reroute the traffic before the end of the wait period, the deployment is stopped.
    • replacement environment Instances are registered with an Elastic Load Balancing load balancer

      and traffic starts being routed to them.

    • original environment Instances are deregistered

      and handled according to your specification in the deployment group, either terminated or kept running.

Blue/Green deployment through AWS CloudFormation

manage CodeDeploy blue/green deployments by model the blue/green resources with an AWS CloudFormation template.

  1. create a stack update in AWS CloudFormation that updates your task set.
  2. Production traffic shifts from your service’s original task set to a replacement task set
    • either all at once,
    • with linear deployments and bake times,
    • or with canary deployments.
  3. The stack update initiates a deployment in CodeDeploy.

You can view the deployment status and history in CodeDeploy but you do not otherwise create or manage CodeDeploy resources outside of the AWS CloudFormation template. For blue/green deployments through AWS CloudFormation, you don’t create a CodeDeploy application or deployment group.

This method supports Amazon ECS blue/green deployments only.

AppSpec File - Application Specification File

a YAML-formatted or JSON-formatted file used by CodeDeploy to manage a deployment.

defines the parameters

to be used during a CodeDeploy deployment

1
2
3
4

appspec.yml  // must be in the root
/Scripts
/Config
/Source

Screen Shot 2020-12-28 at 22.39.43

Hooks: Lifycycle event hooks have a very specific run order

  1. create a completed AppSpec file

  2. bundle it with the content to deploy, into an archive file (zip, tar, or compressed tar).

    The tar and compressed tar archive file formats (.tar and .tar.gz) are not supported for Windows Server instances.

  3. upload it to an Amazon S3 bucket or Git repository.

  4. use CodeDeploy to deploy the revision.

AppSpec files on an Amazon ECS compute platform

the AppSpec file is used by CodeDeploy to determine:

  • the Amazon ECS task definition file

    . This is specified with its ARN in the TaskDefinition instruction in the AppSpec file.

  • The container and port in replacement task set

    where your Application Load Balancer or Network Load Balancer reroutes traffic during a deployment. This is specified with the LoadBalancerInfo instruction in the AppSpec file.

  • Optional information about your Amazon ECS service, such the platform version on which it runs, its subnets, and its security groups.

  • Optional Lambda functions to run during hooks that correspond with lifecycle events during an Amazon ECS deployment.

AppSpec files on an AWS Lambda compute platform

the AppSpec file is used by CodeDeploy to determine:

  • Which Lambda function version to deploy.

  • Which Lambda functions to use as validation tests.

An AppSpec file can be YAML-formatted or JSON-formatted.

  • can also enter the contents of an AppSpec file directly into CodeDeploy console when you create a deployment.

AppSpec files on an EC2/on-premises compute platform

the AppSpec file

  • YAML only, named appspec.yml.
  • must be placed in the root of the directory structure of an application’s source code. Otherwise, deployments fail.

It is used by CodeDeploy to determine:

  • What it should install onto your instances from your application revision in Amazon S3 or GitHub.
  • Which lifecycle event hooks to run in response to deployment lifecycle events.

AppSpec File spacing

The following is the correct format for AppSpec file spacing. The numbers in square brackets indicate the number of spaces that must occur between items.

CodeDeploy raises an error that might be difficult to debug if the locations and number of spaces in an AppSpec file are not correct.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99

version:[1]version-number                      # version: 0.0
os:[1]operating-system-name                    # os: linux OR windows
files:                                         # files:
[2]-[1]source:[1]source-files-location         #  - source: /
[4]destination:[1]destination-files-location   #    destination: /var/www/html/WordPress
permissions:                                   # permissions:
[2]-[1]object:[1]object-specification
[4]pattern:[1]pattern-specification
[4]except:[1]exception-specification
[4]owner:[1]owner-account-name
[4]group:[1]group-name
[4]mode:[1]mode-specification
[4]acls:                                       # [4]acls:
[6]-[1]acls-specification
[4]context:
[6]user:[1]user-specification
[6]type:[1]type-specification
[6]range:[1]range-specification
[4]type:
[6]-[1]object-type
hooks:                                         # hooks:
[2]deployment-lifecycle-event-name:            #   BeforeInstall:
[4]-[1]location:[1]script-location             #     - location: scripts/install_dependencies.sh
[6]timeout:[1]timeout-in-seconds               #       timeout: 300
[6]runas:[1]user-name                          #       runas: root
                                               #   AfterInstall:
                                               #     - location: scripts/change_permissions.sh
                                               #       timeout: 300
                                               #       runas: root
                                               #   ApplicationStart:
                                               #     - location: scripts/start_server.sh
                                               #     - location: scripts/create_test_db.sh
                                               #       timeout: 300
                                               #       runas: root
                                               #   ApplicationStop:
                                               #     - location: scripts/stop_server.sh
                                               #       timeout: 300
                                               #       runas: root

# example of a correctly spaced AppSpec file:
version: 0.0
os: linux
files:
  - source: /
    destination: /var/www/html/WordPress
hooks:
  BeforeInstall:
    - location: scripts/install_dependencies.sh
      timeout: 300
      runas: root
  AfterInstall:
    - location: scripts/change_permissions.sh
      timeout: 300
      runas: root
  ApplicationStart:
    - location: scripts/start_server.sh
    - location: scripts/create_test_db.sh
      timeout: 300
      runas: root
  ApplicationStop:
    - location: scripts/stop_server.sh
      timeout: 300
      runas: root


# example of a correctly spaced AppSpec file:
version: 0.0
os: linux
files:
  - source: Config/config.txt
    destination: /webapps/Config
  - source: Source
    destination: /webapps/Config
hooks:
  BeforeInstall:
    - location: scripts/install_dependencies.sh
    - location: scripts/UnzipResourceBundle.sh
      location: scripts/UnzipDataBundle.sh
      timeout: 300
      runas: root
  AfterInstall:
    - location: scripts/change_permissions.sh
    - location: scripts/RunResourceTests.sh
      timeout: 300
      runas: root
  ApplicationStart:
    - location: scripts/start_server.sh
    - location: scripts/create_test_db.sh
    - location: scripts/RunFunctionTests.sh
      timeout: 300
      runas: root
  ValidataService:
    - location: scripts/MonitorService.sh
      timeout: 3600
      runas: CodeDeployuser
ApplicationStop:
    - location: scripts/stop_server.sh
      timeout: 300
      runas: root

CodeDeploy Lifecycle Event Hooks

Screen Shot 2020-12-28 at 22.52.25

Screen Shot 2020-12-28 at 22.59.32

Screen Shot 2020-12-28 at 22.59.18

Screen Shot 2020-12-28 at 23.00.21

Lifecycle event nameIn-place deploymentBlue/green deployment   
Lifecycle event nameIn-place deploymentBlue/green deployment: Original instancesBlue/green deployment: Replacement instancesBlue/green deployment rollback: Original instancesBlue/green deployment rollback: Replacement instances
BeforeBlockTraffic✓✓  ✓
BlockTraffic✓✓  ✓
AfterBlockTraffic✓✓  ✓
ApplicationStop
gracefully stop the app 		✓ ✓  
DownloadBundle
CodeDeploy agent copy the revision files to location
✓ ✓  
BeforeInstall
pre-install, backup the current version, configurstion, decrypting files 		✓ ✓  
Install
copy application file to final location 		✓ ✓  
AfterInstall
post-install, configuration, file permissions
✓ ✓  
ApplicationStart
start servicesthat were stop during application stop
✓ ✓  
ValidateService
run tests to validate the service		✓ ✓  
BeforeAllowTraffic✓ ✓✓ 
AllowTraffic✓ ✓✓ 
AfterAllowTraffic✓ ✓✓ 

Setup an app in CodeDeploy

  1. setup ec2 role (EC2 - S3FullAcess)
  2. setup CodeDeploy role (CodeDeploy - AWSCodeDeployRole)
  3. create ec2 with ec2 role
  4. install CodeDeploy agent on ec2 instance
  5. create IAM user for local machine to CodeDeploy
  6. create application.zip
  7. create S3 bucket
  8. create application.zip and load it to CodeDeploy
  9. app should be in CodeDeploy
  10. create depolyment group
  1. setup ec2 role (EC2 - S3FullAcess)
  2. setup CodeDeploy role (CodeDeploy - AWSCodeDeployRole)
    • autoscaling, tag, sns, cloudwatch, elasticloadbalancing
  3. create ec2 with ec2 role

  4. install CodeDeploy agent on ec2 instance

    1
2
3
4
5
6
7
8
9
10

     # install CodeDeploy agent
 sudo yum update
 sudo yum install ruby
 sudo yum install wget
 cd /home.ec2-user
 # CodeDeploy agent file
 wget https://aws-CodeDeploy-eu-west-2.s3.amazonaws.com/latest/install
 chmod +x ./install
 sudo ./install auto
 sudo service CodeDeploy-agent status
  5. create IAM user for local machine to CodeDeploy
    • CodeDeploy&s3 policy
      1
2
3

       aws configure
 # add access key id
 # add secrect access key

  6. create application.zip

    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

     application.zip
 - appspec.yml
 - index.html
 - scripts/
   - install_dependencies.sh
   - start_server.sh
   - stop_server.sh

 # appspec.yml
 version: 0.0
 os: linux
 files:
   - source: /index.html
     destination: /var/www/html
 hooks:
   BeforeInstall:
     - location: scripts/install_dependencies.sh
       timeout: 300
       runas: root
     - location: scripts/start_server.sh
       timeout: 300
       runas: root
   ApplicationStop:
     - location: scripts/stop_server.sh
       timeout: 300
       runas: root

 # install_dependencies.sh
 yum install -y httpd
 # start_server.sh
 service httpd start
 # stop_server.sh
 service httpd stop

  7. create S3 bucket

  8. create application.zip and load it to CodeDeploy

    1
2
3
4

     # create application
 aws CodeDeploy create-application --application-name mywebapp
 # push app to s3
 aws CodeDeploy push --application-name mywebapp --s3-location s3://<My_Bucket_name>//webapp.zip --install

  9. app should be in CodeDep

  10. create depolyment group
    • select service role, deployment type, deployment setting (Allatonce, HalfAtATime, OneAtATime), load balancer.
  11. Create Deployment
    • select revision location (S3/Github)
    • rollback

.

01AWS, CodeDevelop
AWS
This post is licensed under CC BY 4.0 by the author.

Comments powered by Disqus.