And with that, that is really it
for this module, this was a huge module.
We started by understanding that Docker containers
always work the same and can help us both locally
on our machine during development, as well as in production.
And throughout this module, you saw in great depth,
how we can build images, and then launch containers
based on these images locally on our machine.
I guess you saw that through the entire course already,
but also again in this module,
but then especially in this module,
you also saw how you can take these same containers
and deploy them, for example to AWS,
either by installing Docker on your own there,
or by using a managed service like ECS,
I highlighted a couple of important aspects
you should keep in mind,
like the fact that bind mounts are primarily a thing
during development to mirror our life code
into a running container.
I showed you multistage builds and Docker files.
For example, for applications that require a build step,
like the React app, we had a look at in the last lectures.
This is a powerful feature for ensuring
that you can use Docker to not just to run code locally,
but to also then deploy applications,
which wouldn't work without an extra build step,
we saw how we can deploy multiple containers
within the same task, the same host, you could say,
but also split across multiple hosts,
and therefore running on different URLs.
And I also talked about the trade-offs between having
more control and responsibility and having less of both.
And therefore throughout this module,
you saw two main ways of deploying containers,
you learned how you could connect to a remote machine,
install Docker on it, and then use the Docker installation
on that machine to pull images deployed to Docker Hub
and run them on there.
And you could also use Docker compose there, of course,
it's your machine, you install the tools
you can do whatever you want there.
But because of that extra responsibility
that comes with that, this might not be the best solution
for all applications you might be building,
because you can make errors there,
you can build insecure setups.
And therefore you might wanna go for a managed approach,
for example, with AWS ECS.
And hence, I also introduced you to that in great depth
throughout this module.
And you learned how ECS works
that you work with tasks there,
which contain your containers,
and that you then start these tasks as services,
you learned how you can have one or multiple containers
in the same task or across multiple tasks.
And we also had a look at our AWS resources,
like the elastic file system service,
to add a file system to our containers
to then also add a volume to our containers
to ensure that data is not lost
if a container is redeployed or simply deleted.
We also talked about the special role of databases.
And that there, again, we have this trade-off,
we can deploy our own database containers,
but then we also have to manage them.
And there are aspects like performance, scaling,
availability, but also backups and security,
which can be challenging.
That's why I also recommended that you at least consider
moving to a managed database service
for this specific use case.
And that therefore maybe don't use Docker for that,
but instead, keep Docker focused on your application code
on the node REST API in this example,
on the React single page application,
and move that database responsibility
to some other hosting provider,
which takes care of all the heavy lifting for you.
And therefore, throughout this module,
we did not just move from EC2, our own host machine
with Docker installed on it.
And this fully self managed approach to ECS.
But we also managed from this ECS setup with node
and MongoDB containers being deployed in one task
to this set up where we also then added MongoDB Atlas,
on to this setup, which turned out that it didn't work
because we weren't able to launch two web servers
in the same ECS task
and therefore on the same machine in the end.
So did we finally arrived at this setup
where we had multiple containers running on different tasks,
so different hosting machines, you could say on AWS.
And we therefore had a setup where we finally were able
to run everything the way we want it to run it
now fully deployed to the cloud.
Now there's always more you can learn,
there are always things you could dive in deeper.
Especially when it comes to AWS,
we only scratched the surface here,
because this is no AWS course.
So there is some more you can configure here more settings
you can find you and and there's way more you should learn
about AWS and the services you're using there.
If you plan on using this in your own apps in production,
I really wanna emphasize that this was an example,
I wanted to show you certain challenges you might be facing
and how to think about managed services.
Whereas this manual installation of Docker
on a remote machine you own.
The primary focus of this course was and is Docker,
and you learned about many important features
throughout this module.
You again learned how containers
really can run in different environments,
and that they only need Docker for that.
You learned about multistage builds,
multistage Docker files a very useful feature,
you saw environment variables in action.
And in general, now, you should have a good understanding
of Docker but also of how to use Docker locally
with Docker compose for example,
and what it means to deploy Docker to a remote host.
And of course, if you decide to use Docker only locally
on your machine during development,
that would be totally fine as well.
I just want to give you the big picture,
I want to give you the full tool set
so that you can use Docker containers wherever you want,
on your machine, on a remote machine, everywhere.