- Now let us review an introduction to
Amazon Elastic Container Service, or ECS.
With ECS, we have the ability to manage containers.
So, ECS is ultimately a container management service or
essentially a scheduler. And it is, uh, it does support
Docker containers And it's basically analogous to
Kubernetes if you are already familiar with containers.
If you've done any deployments with containers,
then you are probably familiar with schedulers like
Kubernetes, or Docker Swarm, uh, or Mesos.
And so Elastic Container Service, is essentially
the same thing. It's, it's fulfilling that same need,
in that we have a collection of hosts,
perhaps EC2 Instances, and we want to deploy
containers to that cluster of hosts.
And so we need something that can track the state
of those Instances of those hosts, track the available,
uh, resources, such as CPU and memory and DiskIO,
uh, or, or, NetworkIo. And, help us keep track of what, in-,
what containers are running on what Instances,
and help us help us to handle all of the low-level,
um, minusha of getting, uh, in a, a container running
on a particular Instance within that cluster.
So that's what a scheduler does.
That's what ECS does.
And so, we can use this to essentially schedule,
uh, or ensure that containers are running for,
perhaps long-running applications.
So if you are deploying micro-services for an API,
services that need to run for a long period of time,
listening for incoming connections.
Those are well-suited for containers,
as are other applications like batch jobs,
right? So you can have one cluster of, of Instances
that run all kinds of different applications
side-by-side. And the, the isolation between those
processes is achieved through containers.
So again, long-running applications for API's,
batch jobs, um, all kinds of different things we can
use containers for.
ECS does integrate very well with Elastic Load Balancing,
with Elastic Block Store, with, uh, Amazon VPC,
and with the Identity and Access Management Service.
And so, I suppose that that would be the nice thing,
the great thing about ECS, as oppose to running Docker Swarm
or Kubernetes on EC2, is that we have a native
inherent integration with other native Amazon services.
Now when we take a look at this diagram,
a few things I want to point out here,
would be one, you notice that we have, here,
an auto-scaled fleet of EC2 Instances.
And of course we will talk about auto-scaling,
uh, in more detail later on.
But for now the idea here is that if any one of these
Instances were to fail, for whatever reason,
become unhealthy,
or unusable,
then auto-scaling could simply replace it.
And if we needed to add more machines
then we could do that with auto-scaling as well.
Now up here, we have the cluster. And a cluster,
in this regard, is within ECS,
a logical grouping
of EC2 Instances or hosts that allow us to deploy
a grouping of services.
So, a cluster is a collection of EC2 Instances
that are being managed,
and it is also a collection of services that we deploy,
uh, to that cluster. And so, we create the cluster
as it's own sort of resource within ECS,
and then as these EC2 Instances come to life,
using custom Amazon machine images using
user data bootstrapping scripts.
These Instances can then
communicate to the ECS service in order to join the cluster
and then be managed by
as, as essentially a single pool
of resources, right?
And so now that all of these machines are essentially
a part of the same cluster, we can now use ECS
to manage those machines in deploy containers
to those machines.
So taking a closer look at, or perhaps a different
look at this diagram, you can see here that we have
our, we have our cluster in, in that cluster
is essentially managing, in this example
a couple of EC2 Instances.
And within those Instances, we have containers
that are running, right?
So each one of these is a container.
And
those containers are deployed by the ECS service.
The ECS service is able to create
those containers by pulling container images
from ECR, the Elastic Container Register.
So very much like virtual machines,
containers are also based on an image.
The primary difference being: that a container image
does not need the operating system.
All of these containers that are running on a, on a host,
they all share the same underlying operating system.
And so the benefit of containers, is that, as,
if we are deploying containers as our deployment artifact,
then the container image, in many cases I've seen
many container images, be far less than 100 meg.
Whereas virtual machine images could be
upwards of 8 gigs or more, right?
So that's, uh, that's a pretty good difference,
a very noticeable difference between the size
of the actual artifact.
And so by having small artifacts, it means that
they can upload faster, they can download faster,
uh, and they can deploy faster. So
again we have our, our registry where we
would publish our container images.
We have the ECS service, and so in our deployments
we essentially tell ECS:
"Hey I want this particular
image to be used
for this particular service".
So, ECS will pull the image
from the container registry.
ECS will then instruct this cluster, it will choose
a particular Instance to launch that container on.
Now, when we launch what we call a service,
we may say that we want uh, a certain number of
containers to be replicated.
Meaning that we will take the same image,
and replicate it some number of times across
a different number of containers for the sake
of fault-tolerance and high availability.
If one container fails, we still have another
two or three, or however many containers we need.
And so,
again ECS is responsible for ensuring
tracking the state of, of the EC2 Instances that
are within this cluster. And knowing how much CPU,
and memory, and disc, and NetworkIo are available.
So that when we go to deploy more containers,
it knows where those containers can be placed.
Where the um, resource requirements can be fulfilled.
Another thing that we can do with ECS that's
really powerful, especially for microservices,
is that if we wanted to create, you know, microservices
and offer, you know, different services at different URL's,
we can leverage the application load-balancer.
So here we have a forum of the Elastic Load-Balancer
called the Application Load-Balancer.
And what we can do with this is both host name,
and path-based routing. We could say if
we had uh, a series of microservices, we might say that,
um, perhaps this container, this container,
and this container, belonged to a particular service.
And that a certain URL, should be routed
to
those particular, uh, containers like so.
In order to satisfy the routing for a particular service.
And, and, so we could, we could group,
containers
um, essentially container replicas for a particular
service. We can group them as what we call "targets"
within target groups. And so, again, we can use,
use path-based routing from the Application Load-Balancer
to get us to the containers for a particular service.
And so in this example, we may have, you know,
three containers, running for a microservice available
through the load-balancer. We may have several other
containers doing some type of background processing,
or batch processing.
Either way, the deployment, the underlying, um,
you know, all of the steps it takes to get that container
running on those Instances, is all managed by ECS.
And we will take a closer look at that and
how that all works, in an upcoming lesson.