So now, we're going to repeat
the deployment example from before,
but now not with AWS EC2,
where we need to manage on our own,
but with another service, which we can find by clicking
on that service's dropdown here,
and then searching for ECS,
which is this Elastic Container Service.
That's what we're going to use now.
And now, I have one important disclaimer here.
Where EC2, the way we used it at least,
was covered by that free tier,
the services we're using now and over the next lectures
might not be covered.
So if you wanna avoid any costs,
you definitely should follow along passively here
and/or check the AWS pricing pages
to find out which costs you might incur.
Now, we're only going to use the minimal set of features,
so potential costs shouldn't be high,
but I still wanna emphasize it here
so that you don't blame me if your credit card gets charged.
It's a cloud service provider.
They earn money by selling services,
and therefore, of course, not everything is free.
That's just a disclaimer here.
And just to also make this clear,
we would have the same problem
with basically any provider
because ultimately some services will cost money.
So with that out of the way,
let's dive in and use that service though.
And here, you should see some getting started screen,
which might look slightly different after some time,
but in the end, you should have some getting started screen
with a get started button.
Press that button, and you should see something like this.
That's the wizard you will see
when you launch your first container with ECS.
Now, the container we are going to launch
is that node-example-1 container,
which I pushed to Docker Hub before
in the last lectures.
So if you skipped these lectures,
make sure you take the example project you find attached,
build an image from that project,
and push that image to your Docker Hub account,
and then use that image
because this specific image on my Docker Hub account
will not be available anymore when you're watching this.
For me, right now, it is available though,
and that's the image which we'll now deploy
with help of ECS.
So how does this work then?
AWS ECS thinks in four categories,
clusters, containers, tasks, and services.
Now, it should be clear what containers are,
and that's what we're going to start with.
Initially in that wizard,
we pick the container we wanna deploy.
Now, there are some examples here,
but we're going to go with our own custom container.
So we should click on Configure here,
and this opens up this side drawer
where we can now define our own custom container.
Now, we should give this container a name,
and I'll choose node-demo here,
and then we have to define the image
on which this container should be based.
And before we do that,
I have one important note about this side drawer.
In the end here, we just specify
how ECS should later execute docker run.
You will see plenty of options here,
which you could also just plug into your docker run command.
For example, --name for the container name.
And the image is, of course, also the required
for docker run, so we also need to define it here.
In here, you should take your repository name.
In my case, it's academind/node-example-1.
And if your image is on Docker Hub,
you just need to enter this repository name,
and ECS will automatically look on Docker Hub.
If you're using some other container registry,
you need to have the full registry hosting domain here,
and then the repository name.
But for Docker Hub, just the repository name is enough.
Now, if it should be a private repository,
you can specify your login information here,
but it's not a private repository here.
You can leave the default for the memory limits,
but of course we wanna map some ports.
Again, in the end here, in this overlay,
we just define how docker run should be executed later.
And if you run it locally, you also might specify a name,
but we then, for this project, which listens on port 80,
would definitely also publish port 80
on the host machine with the -p flag.
And that's just what we define here with port mappings.
We want to expose port 80.
Now, you don't need to specify two numbers here
because the container internal port will always be mapped
to the same port outside of the container.
So this is automatically mapping
the container internal port 80 to the outside port 80.
Now, you can also configure advanced container options.
Now, we can ignore the healthcheck for now.
That's some AWS-specific setting
which allows AWS to run a specific command
to check whether the container is running successfully.
We can ignore this here.
But for the environment, we can, for example,
override the default entry point or command
that should be executed for this container when it starts.
Again, that's also something you can do with docker run.
You saw that in the utility containers section, for example.
You can run a container
and specify your own command that should be executed
instead of the command specified in the Dockerfile.
Here, however, I wanna go
with the Dockerfile internal command,
so I will not specify my own command.
You could also override the working directory.
And, again, even though that is nothing
we've done thus far in the course,
you indeed would have an option on docker run to do that.
If we run docker run --help, we see all available options.
And there, you see there is a workdir option
which would allow you to override the working directory
for this container when it's being started.
And that's what you can set up here.
Now, I wanna do none of that.
I just wanna explain what you're configuring here.
Now, if your container would be using environment variables,
you probably would want to pass them in
when the container runs.
And locally, we did that with docker run --env.
Now here, we can define
our environment variable key value pairs
simply here in this part of that AWS console.
Now, we can also define container timeouts,
so basically telling AWS when it should stop trying
to launch this container.
We can set up network settings,
and I'll come back to that later
once we have more than one container being deployed.
For the moment, we can ignore all of that.
By default, our container will be reachable from the web.
I can tell you that.
Unless you disable networking, of course,
which we don't wanna do here.
We wanna keep it enabled.
Under storage and logging,
you can define mount points and volumes.
Again, that's not something we use right now,
but I will come back to that later as well.
And, of course, that is the equivalent to the -v option
on docker run.
Then, you can configure logging if you want to.
And, with Auto-configure CloudWatch Logs,
you automatically use another AWS service called CloudWatch
to manage and store the logs generated by this container,
which could be useful, so I'll do that here,
but you don't have to check it.
And that is basically it.
Now with that, we can click Update here,
and now we configured our container
that should be launched here.
Now, in case you're wondering
how you could launch multiple containers,
I'll come back to that.
For the moment,
let's stick to this single container example.
Now, in the next section, we can define our task
for this container.
And the task is basically, as it says here,
the blueprint for your application.
Here, you can tell AWS how it should launch your container.
So not how it should execute docker run,
but how the server on which it runs this
should be configured, you could say.
And therefore a task actually also can include
more than one container, and you will also see that later
when we add multiple containers to one and the same task.
So you can think of the task as one remote server,
one remote machine, which runs one or more containers.
So a bit like the EC2 instances you saw before,
which we managed ourself.
Now, we're not managing it ourself,
but we're still telling AWS
how it should execute our containers,
and which environment it should generally set up for them.
And that's what a task is.
And here, we're using FARGATE by default.
That's a specific way of launching your container,
which in the end launches it in a so-called serverless mode,
which means AWS does not really create an EC2 instance
on which it runs your container,
but instead it stores your container and your run settings,
and whenever there is a request
that requires the container to do something,
it starts the container up, handles that request,
and then stops it again,
which is, of course, very cost effective
because you only pay
for the time your container is executing
and not for the time where it's just sitting around idle.
So that's why we're using FARGATE here,
this serverless container launching mode.
And then, we can click Next.
Now here, we define our service.
And a service, in the end, now controls how this task,
so this configured application and the container
that belongs to it, should be executed.
And it's here where you, for example,
could add a load balancer,
and it manages all the heavy lifting
of redirecting the incoming requests,
queue the up and running containers,
and all of that behind the scenes.
Now, I'm not going to use a load balancer here,
but we will add one later in this module.
To keep things simple for now, we'll start without one.
So you could say every task is executed by a service.
So you have one service per task.
And these are just the terms in which AWS thinks.
You will, of course, see all these things in action
and working together over the next lectures.
So let's click Next then.
And the last thing we need to configure is our cluster.
You could say that's the overall network
in which our services run.
Here, we have just one service
with one task with one container,
but if you had a multi-container app,
you could group multiple containers in one cluster
so that they all belong together logically,
and they all can talk to each other.
Now here, we automatically get this cluster network
created for us, and therefore the only thing
we need to do now is click Next.
This gives us this Review page,
where we can have a look whether everything
is configured the way we want,
and then I'm gonna click on Create.
AWS will set up all the things it needs
to launch that container when needed
in the way you told it to do so.
Now, this can take a couple of minutes here,
and I'll be back once setting up all of that finished.
So now, this finished, everything was set up,
and we can now click on view service.
Now, this page might look overwhelming.
Here, you can see all the details of the environment
and the configuration that was created by AWS.
Now, for us, it's probably most interesting
to see our running application.
And you can see this by clicking on Tasks,
and then click on that task which was created here.
Important, on that task ID,
not on the task definition, but on the task ID.
And here, you'll find a public IP.
Now, you could map your own domain to that public IP.
I'll just paste this public IP into the browser,
and I see my running application.
And that's how we can now run it with help of AWS ECS.
Now, this might still look overwhelming,
but the huge advantage here
is that we didn't start any custom servers or machines.
We did not install anything, and we're not responsible
for keeping anything up to date.
We just configured how AWS should execute our containers,
and that is it.
There's nothing else to it.
So now, let me also show you
how we could update our container or our image
on which this container is based
and reflect those changes on this running cluster
before we then thereafter also have a look
at multi-container applications.