My name is Seb, and welcome to 'Back to Basics'.
I've been playing with code
ever since my dad bought me my first computer at the age of nine.
However, later in life, when working on complex codes
I noticed that it doesn't always behave the same way on my laptop
as it is on the production servers, and I couldn't understand why.
Thankfully, with the invention of containers,
it is now easy to have your code behave the same way on your laptop
as it is on the production server.
In this episode, let's explore some architectural patterns
on how to deploy your code on the AWS platform.
So, where should we start?
When I first discovered the power of containers,
I rushed to move my latest website into my first Docker container.
I have installed the Docker application on my EC2 instance.
I built my container there and then, and launched it.
This actually worked just fine at the beginning,
but I quickly realized the limitations of this approach.
What happens when my container breaks?
Or I need a hundred of them to handle more users on my website?
I could have built all the orchestration around it myself.
However, there are better tools to do this job for us.
This is why I choose to host my containers on Amazon Elastic Container Service, or ECS.
Amazon ECS takes care of all the undifferentiated heavy lifting of managing the containers.
So, I can focus on building features in my application instead.
I just first need to push my container image to Amazon Elastic Container Registry, or ECR,
and from there, it can be deployed to ECS easily.
There are two ways of running containers on ECS,
either as a task, or as a service.
Tasks are great when you need to process a specific event whenever it occurs.
For example, a new image gets uploaded to S3,
and you want to create a thumbnail of that image.
However, my web application needs to be always on,
and I may need multiple copies of my container
when more users visit my website.
Running my container inside the service will allow me to achieve that,
and ECS will take care of adding more copies of the container, when they're needed.
I also need to decide if I want ECS to launch the container on EC2 instances that I own
or through Fargate, which is a serverless way of running containers.
And I don't really want to spend time looking after the EC2 instance,
worrying if it's healthy, or too busy, and that everything's up-to-date.
With Fargate, there is no underlying server to worry about.
I can simply ask Fargate to start my container,
and AWS will take care of the rest for me.
To distribute my users between my containers
I'm going to require an AWS Elastic Load Balancer,
which tightly integrates with Amazon ECS servers
to automatically send traffic to all my containers.
And if one of my containers becomes unhealthy,
the logons will stop sending any traffic to it,
and ECS will restart the broken container and attempt to resolve the problem.
Okay. Now we have our container running on ECS,
and our application is running reliably now.
But how do we go about automating these deployments?
To do this, we need a containers' deployment pipeline.
First, I have started by pushing my source code.
as well as the container build instructions
which are held in the special file called Docker file,
into a Git repository.
We now need to turn this Docker file into a container image.
I could try to do this on an EC2 instance.
However, by doing this, I risk something going wrong with my scripts,
and the build failing.
The best way to do that is to use AWS CodeBuild,
which is designed to build a software package from source code files.
Once the AWS CodeBuild creates the container image,
it will push it to Amazon ECR.
The next step is to deploy the container image onto Amazon ECS.
This is something I could do within, for example, a Lambda function.
However, all the complicated logic required to handle this operation is on me to create,
and I'm risking making mistakes, which will cause my application to break.
AWS CodeDeploy can do this for me instead.
Due to its tight integration with Amazon ECS,
within a few clicks of a button I have my deployment drop ready to execute.
AWS CodeDeploy also allows us to automate at testing
to make sure our change actually worked,
and automate the rollback to a previous version, in case it doesn't work.
And I really want this whole process to trigger automatically
every time I make a code change.
With AWS CodePipeline I'm able to create a continuous integration
and deployment pipeline
which starts every time a change is made in source code,
and it coordinates the execution of steps required
to complete the deployment of the new version of my container.
So, there you have it.
We now have our web application deployed on the container,
and our code is behaving exactly the same way on the laptop,
as well as in production.
And with the continuous deployment pipeline,
every time we make a change to that code, it is automatically deployed.
Check out the links below for more details.
Thank you for watching 'Back to Basics'.
Happy building, folks, and see you next time.