- [Alana] Hello, and welcome back. Our development team is
getting to the end of a sprint. Some exciting new features
are coming to the application. Now, we have to start thinking
about how we are going to deploy the application to get those features in
front of our customers. We've spoken about different
deployment strategies for the application, and the
team has decided they want to use the service, AWS CodeDeploy, to take our build artifact,
getting built by CodeBuild, and deploy this to our
application instances. CodeDeploy supports
deploys to EC2 instances, on-premises physical servers, AWS Lambda, and Amazon ECS. Our application is
hosted on EC2 instances. To get started with CodeDeploy, we will need to create an application, and one or more deployment groups. Let's go through what each of these means. An application defines
the compute platform we are deploying to. This is a choice of the
supported platforms: EC2/on-premises, Lambda, and ECS. I'm deploying to EC2 instances, so I would use the
EC2/On-premises compute platform. An application can have
multiple deployment groups. For an EC2 server deployments, the deployment group
needs to know information about several things, like: The IAM role that CodeDeploy will use to authenticate to other services. The deployment style, whether
it's in-place or blue/green. In-place will replace the
application on our instances, and blue/green will
create new green instances to deploy the application. Then, we have to specify the
deployment configuration. For an EC2 deploy, this controls the number or percentage of healthy hosts we want
available during a deployment. We also have to specify
how to find our instances by tags, Auto Scaling group, or even on-premises tagged instances. For a blue/green deploy, we can configure an Auto Scaling group that CodeDeploy will copy to
provision the green instances. Specifically for a blue/green deploy, you have control over
when to route the traffic to the green instances. It can be automatic or the
deploy can wait for you to continue the deployments
when you're happy to go ahead. You also control how long the original, or blue, instances are kept
after successful deploy. Optionally, you can also
select a load balancer, so CodeDeploy knows where to register and deregister instances
during the deployment. We can also associate CloudWatch alarms. A deployment can be halted if any of the configured
CloudWatch alarms go into an alarm state. And finally, auto rollback. If we want to automatically rollback on a deployment failure, a rollback is just going to redeploy the last
successful deployment for you. With an application and
deployment group in place, I'm ready to create a deployment. A deployment for EC2 just
needs to know my application, the deployment group, and the
revision of my application. The revision is the
artifact we want to deploy. This will contain all the
files and instructions run on each host during the deployments. These instructions are
configured in an AppSpec file. We will go into a lot more
detail on the AppSpec file, and the hooks you have
to run your commands during a deployment, later. How exactly are these commands
run on my instances, though? Well, this is the job
of the CodeDeploy agent. We need to have the agent installed and running on all of the instances where we plan to deploy the application. The link on your screen
goes to more details on how to install the CodeDeploy agent. I'll also include this link
in the course readings. An EC2 deployments from CodeDeploy
can pick up this artifact from S3 or from a GitHub commit. When CodeDeploy is added as part of an AWS CodePipeline action, the revision can be
picked up from the output of another CodePipeline action, for example, the artifacts created from a pipeline build phase. Here's Russ to show you more
about this in the console. - [Russ] Let's jump into the console, and see how all of this works
with a simple deployment. From inside the console, I can create a CodeDeploy application. This is just the application name, and the compute platform we are
deploying to, EC2 instances. Now, I create the deployment group. We give it a name. I choose the service role. This is the role it
will use to authenticate to other AWS services. Our deployment type, let's start simple with
an in-place deployment. CodeDeploy needs to know which instances that we want to deploy to, so I'm going to give it
an EC2 instance name tag. We are given an option to
install the CodeDeploy agent on our instances. I don't need to do this because
I already have this set up. For deployment settings,
let's do all at once. This will mean an outage
for our application, but I'm deploying to a dev environment and I want to deploy as fast as I can. I have a load balancer set up, so I can tell CodeDeploy about my load balancer target group, here. I now have an application and
a deployment group set up. I have everything I need
to create a deployment. This will send an application revision to the deployment group we just created. Let me show you what a
simple revision looks like. I have a revision open in an editor here. The revision contains
a simple AppSpec file, the scripts I have specified
to run with each of the hooks, and a single source file I
want to deploy on my instances. Back in the CodeBuild console, from my deployment group, I
can choose Create deployment. All I need to supply here is
the location of my revision. I have zipped up the
contents of my revision and copied this to an S3 bucket. I can enter the S3
location of my revision. I can override some deployment
group settings, here. I'll just keep this set to all at once, and then choose Create deployment. My deploy completed in
about a minute and a half. If I choose View events here
for one of my instances, I see the sequence of events
that happen during the deploy. BlockTraffic is the event
that deregistered the instance from the load balancer. AllowTraffic is the event
that registered it back. ApplicationStop and
BeforeInstall are the two steps where my revision scripts ran. These events all ran
simultaneously on my instances, where you're using the all-at-a-time
deployment configuration, for this deployment. If we were to use one at a time for the deployment configuration, one instance would be selected, all of the events we
see here would complete. Only then would CodeDeploy
move to the next instance. That was a pretty quick
introduction to CodeDeploy. We have spoken about
CodeDeploy's application, deployment group,
deployments, and revisions. We saw the deployment run
against my five instances, where the CodeDeploy agent
followed the instructions in my AppSpec file to get
my applications installed.