‫So now let's talk about AWS code deploy.
‫So as the name indicates, it is a deployment service that will automate application deployment.
‫What does that mean?
‫Well, that means you have a version, one of an application running and somehow you want to upgrade
‫it to version two.
‫Now, where can we deploy version one and version two?
‫Well, these application versions can be deployed either to EC2 instances on premises, servers or lambda
‫functions or services.
‫So three different kinds of targets because EC2 instances and on premises servers have the same methodology
‫on top of it.
‫Code deploy can allow you to update an application but also rollback.
‫So in case your deployment is not working as expected, it is failing or there is an alarm that gets
‫triggered, then we can automatically initiate a rollback that makes it a very safe automated deployment.
‫On top of it, we can control how fast we want to deploy our application.
‫We will see this later on, but we can say one instance at a time or all at a time or half at a time
‫or bluegreen.
‫Finally, to control how code deploy works, there is a file named app spec YAML that can help define
‫how the deployment will happen.
‫So now let's talk about the EC2 on premises platform.
‫So this allows you to deploy to EC2 instances and on premises, servers, your application and your
‫code and you can perform two kinds of deployments either in place deployments or bluegreen deployments.
‫We'll see them both To understand the difference and to work, we must first deploy the code, deploy
‫agent onto the target instances because the agent is the thing that will be performing the instance.
‫The updates on the instances, we can define the deployment speed.
‫So as I said, we can have a gradual deployment.
‫For example, we can do all at once, which will update all the instances at once, but will give us
‫the most amount of downtime because we will be down half at a time, for example, to reduce capacity
‫by 50% or one at a time, which is going to be the slowest because we take down one instance at a time
‫and update it.
‫But of course it's going to give us the lowest availability impact because only one instance will be
‫down at a time.
‫Or you can define your own custom deployment speed if you wanted to.
‫So let's have a look at how, for example, in place deployment works for half at a time setting.
‫So here we have the V1 running on four EC2 instances because we're in a half at a time setting an in
‫place deployment.
‫Two instances are going to be taken down for maintenance so the agent will stop the application on two
‫instances, which then are going to be upgraded again by the agent to version two.
‫And once it is done, then the other half is going to be taken down for install and then upgraded to
‫version two.
‫And so this is the process of in place deployment for half at a time setting.
‫What about blue Green?
‫Well, blue, green is the idea that you have, for example, an application load balancer pointing
‫to version one and all your instances are in auto scaling group.
‫What's going to happen is that we're going to create a new autoscaling group so this can be done either
‫manually or automatically by code deploy and code deploy is going to create as many EC2 instances in
‫this new auto scaling group.
‫So we have V one and v two now running in parallel, and the load balancer through some process is going
‫to be pointing now to the V two auto scaling group and the V one will be taken down.
‫So this is a simplified version, but at least you see the process and it's called blue green because
‫new instances are taken up and the old ones are terminated.
‫So this code deploy agent I've been telling you about, it must be installed on the EC2 instances as
‫a prerequisite.
‫So we have the EC2 instance and we install the code deploy agent.
‫Now you can install it directly using some Linux commands to install any software or if you wanted to
‫have some kind of automation.
‫If your EC2 instances are managed using systems manager, then you can automate the install of code
‫deploy agent using systems manager.
‫Now this EC2 instance with the code deploy agent will need sufficient IAM permissions to access Amazon
‫S3.
‫Why?
‫Well, because in Amazon S3 will be stored the application revision.
‫So when we want to update from version one to version two, then the code deploy agent with the proper
‫IAM permissions attached to the ec2 instance will download the application revision from the S3 bucket
‫and now you know enough for code deploy and EC2 instances.
‫Now let's see how code deploy works with the lambda platform.
‫So code deploy can help you automate traffic shift for lambda aliases.
‫And the idea is that you can shift from V1 to V2 under and prod alias.
‫I'll show you this in a second.
‫Now this feature is fully integrated within the SAM framework that you will see soon.
‫And so that allows us to just use the same framework and internally use code deploy.
‫So how does that work for the traffic shifting function?
‫We'll say we have a prod alias.
‫Okay.
‫And we have V one that we've deployed before and v two that we've deployed after and we want to shift
‫the traffic between the V one version and the v two version under the prod alias.
‫So the way it works is that code deploy is going to mix this x vary until x equals 100%.
‫So at first x will be zero.
‫So that means that all the prod alias points to the v one function and then x will gradually increase
‫until it reaches 100%.
‫So that's all the traffic on the prod alias is redirecting to the v two function.
‫Now we have several strategies to make X evolve so we have linear where we grow the traffic every n
‫minutes until 100%.
‫So in this example, Lambda linear 10% every three minutes, that means that every three minutes 10%
‫will be added.
‫So we'll have ten and then 20 and then 30% after nine minutes and so on until we reach 100%.
‫And so you have different strategies, for example, 10% every ten minutes and so on.
‫So this is linear.
‫Then we have canary, which is to have a small amount of traffic on the V two function and then ramp
‫up to 100%.
‫So here we have Lambda Canary 10%, five minutes.
‫So that means that for five minutes the new V two function is going to receive 10% of the traffic.
‫And then if everything goes well, then all of a sudden we switch to 100% of the traffic.
‫That's why it's called canary.
‫So we have, for example, the 10%, five minutes or the 10% 30 minutes strategy and finally all at
‫once, which immediately jumps from v one, two, v two.
‫But we don't have the time to test it if it's working.
‫Now could deploy for the platform is actually similar.
‫So we can automate the deployment of a new ECS task definition.
‫And this only works for blue green deployments.
‫So let's take an example.
‫So we have an application load balancer and it's related to a target group where our ECS task are running
‫under an ECS cluster and we'll use code deploy to do a blue green deployment.
‫So very similarly to EC2 instances, there will be a new target group with the V2 version of our application,
‫and this V2 version comes from the new ECS task definition that will be run with the same capacity as
‫before and then can deploy is going to affect the load balancer and so it's going to redirect the traffic
‫from the V1 target group, the blue target group into the V2 target group, the green target group.
‫And what's going to happen here is that we're going to shift traffic again between the first one and
‫the second one with similar strategies as before.
‫So we have the linear strategy and this is just like before we gradually increase until we reach 100%,
‫we have the canary strategy to test a small amount of traffic on the new target group and then all of
‫a sudden we switch everything to the new target group or we have the all at once to immediately switch
‫from the blue to the green target group.
‫So that's it for an overview of code deploy.
‫I hope you liked it and I will see you in the next lecture.