So now that we saw how we can deploy a single container
to AWS ECS, and use this more managed environment,
let's do the same for multiple containers.
And for that, again attached,
you will find a project which I prepared for you.
It's actually part of the project we used
in a Docker compose section.
The only thing which is missing at this point
is the front end.
Instead, here we have our backend API,
which is this goals API
where you can add and get and delete goals.
And therefore the Docker compose yami file
also just sets up Mongo DB.
And then also this backend.
So again, the front end is missing.
Nonetheless, we got all of that.
And therefore here,
we got a project that utilizes two containers,
the Mongo DB container,
and this backend container.
And now I wanna deploy these two containers
to AWS ECS,
to show you how that would work as well.
For that, first of all,
I will delete the existing resources
we got here on AWS ECS.
And that starts in my cluster,
I got one service here,
you might have a different one,
I created this one off screen.
But still I have one service here,
which I don't want,
so you can check it, click Delete,
and then Enter, delete me here.
And once the service is deleted,
also delete the overall cluster
by clicking on Delete cluster,
and Enter delete me here as well.
Now, this can take a couple of minutes, actually,
until the cluster is deleted.
So I will leave that like that.
And already switch back to the code.
Because here I got a couple of important points.
And one of the most important things
I wanna emphasize here is that we're not going
to use Docker compose for deployment.
And Docker compose is a great tool
for running configurations to find four containers
in a Docker compose file,
possibly also for multiple containers
on your local machine.
But it's not really a great tool for deployment right now.
And that makes sense by the way,
if we keep in mind that with Docker compose,
we can easily run multiple containers
on our local host machine.
Even containers that listen on different ports
and therefore we could have our backend,
our database and our front end container
running all on the same machine with Docker compose.
Now, if you deploy something,
if you move it to a remote machine,
things get more complex,
you might need to define how much CPU capacity
you should be provided for a given service.
All of a sudden certain things start to matter,
which play no role locally on your machine.
And of course, it's depends heavily
on the hosting provider you're using,
which kind of extra information might be needed.
So for example, AWS needs some extra information.
Other cloud providers like Microsoft Azure
might need other kinds of extra data,
which would not be part of the Compose file.
So that's why a compose file can be great for managing
and running multiple containers on one at the same machine.
But as soon as you start moving that into the cloud,
where potentially you also got multiple
different machines working together,
it reaches its limits.
But that's no problem,
you will see that deploying these individual containers
will still be super easy.
And that we can use this compose file as an inspiration.
To understand which deployment settings
we need to set in this case when using AWS.
So therefore, we'll just use this as
you could say an inspiration of what we need to do
and manually deploy these individual containers,
these services to AWS ECS.
Since that is the example a hosting provider
we're using this module.
And I will start with the backend here.
For this we first of all need
to create a backend image
which we can then push to Docker Hub,
so that we can use
this Docker Hub backend image in AWS ECS later,
so therefore, we can open up the terminal
or Command Prompt on our local host machine
and this project folder
and run Docker build to build our backend image.
However, there is another important note
we have to be aware of before we built this image.
Unfortunately for AWS ECS
we will not be able to use this automatic
find the container IP by container name feature
which works so nice locally
in app JS when I connect to Mongo DB,
I did refer to Mongo DB as my domain address so to say.
And since my container,
my service here was named Mongo DB,
Docker compose set up a network
where Docker was able to replace
this placeholder name in this connection string
with the actual IP of the Mongo DB container.
Unfortunately, this won't work like that on AWS ECS.
Now, you might wonder why we can't use
this container name and Docker networks
when deploying our dockerized app.
The reason for that is rather simple.
When you run Docker locally on your local machine,
then everything of course happens
on just one machine, right?
Your local machine,
and Docker runs to different containers there.
And when you create a Docker network
with the Docker network command
or with Docker compose,
then all these containers can be put into the same network
on your local machine.
Now, as soon as you deploy something, for example,
here to AWS ECS,
it'll not be that simple anymore,
your containers and the different instances
of your containers will be executed
and managed by this cloud provider.
And they don't necessarily always run on the same machine.
Of course, after all, there's a huge data center out there
managed by AWS, actually multiple data centers,
with the thousands and 10s of thousands
of machines and servers.
And therefore, it's not guaranteed,
and it's indeed very unlikely
that your containers will always run
on the exact same machine all the time.
That's why this Docker network approach won't work anymore.
Now, still there is an exception though,
if your containers are added in the same task
in AWS ECS case,
which is exactly what we're going to do,
then they are guaranteed to run on the same machine.
Still then AWS ECS will not create a Docker network
for them instead it allows you to use localhost
as an address inside of your container application code.
So we can use localhost instead of Mongo DB here
when deploying this with AWS ECS,
because these two containers,
which we wanna connect the node app container
and Mongo DB will be part of the same task,
and therefore will be guaranteed to run
on the same machine.
And then AWS ECS gives us access to the network
on that machine and to the other containers,
which are part of the task,
through the local host address.
That's how this works here.
So here unfortunately,
we have to adjust our code to work with AWS ECS,
which of course is a bit against the idea
of having the same environment locally and in production.
Nonetheless, we can fix this
and ensure that we have the same environment again,
by leveraging environment variables here.
So here, we could expect a process.env MongoDB URL,
or something like that variable.
And then we just need to make sure that
we provide this variable in the backend env file.
And this could be MongoDB here locally,
so the name of the container to which you want to connect.
And when we then run this container through AWS ECS,
we could provide a different value here,
so that this again is flexible and works
in both our local development environment,
as well as in production.
It's a little adjustment we have to make here.
With that, however we can build this image.
And since I'm currently in the main project folder,
not in the backend folder,
I will build./backend,
which means I will build the Docker file
which can be found in the backend folder.
I also wanna give my image a name
with the -t flag,
and I will name it node goals
or maybe goals node and hit Enter
and this creates the image
and with the image created,
we now have to push it to Docker Hub.
So for that on Docker Hub,
I'll create a new repository and name this gold stash node,
just like my local image,
but this will now be a repository
so it will be named academind/goals node.
Created as a public repository here.
And then use this name here
as a name for my image locally.
So I can retag my goals node image here
to academind/ Gold's node
with the Docker tag command.
And then we can Docker push academind/goals node
to push this locally built image to Docker Hub.
And one thing I want to emphasize here is
that we're really just pushing the image right now.
So things like the environment variables
are not getting used at the moment.
These are being fed in when we run containers
based on the images.
That's also what we did with Docker compose
There we also just pointed at the end file,
which then was only used when the images were executed.
Now with that this image was pushed to Docker Hub,
and now we can use it on ECS.
Once the deletion of all these resources is done,