- [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.