Now last but not least,
over the last sections,
we did learn all these fundamentals,
but of course, we also did
deploy our a containerized application.
And if that is something which is interesting to you,
I want you to keep a couple of key considerations in mind,
for example, that you typically don't use bind mounts
when you deploy your application,
instead use a regular volume
or just a copy instruction to make sure that everything
that should be in the container is inside of it.
Bind mounts are really primarily a tool
for local development to mirror your source code
or some configuration which you might wanna change
from time to time into the running container.
Don't use them for production.
In addition, it's also worth pointing out
that of course, multi-container projects
or even ambitious single container projects
might need multiple hosts.
Locally, everything happens on just one hosting machine
but that's not necessarily true
once you move to the web,
once you deploy your application.
One machine might not have enough power
and therefore you might need multiple machines.
That's where this (mumbles) den can get a bit more complex
and where then just docker run
and just docker-compose might not be enough anymore.
I wanna highlight of course though,
that you can run
multiple containers on the same host as well.
It really depends on your application,
on your hardware requirements,
incoming traffic
and all of these aspects.
Now, when it comes to deployment,
there is a key feature which I showed you,
multi-stage builds,
which can be very helpful.
This allows you build containers which
might require a build step to get the final output
which you wanna deploy.
And you typically have that for front-end applications
like react single-page applications
as shown in the last sections.
Multi-stage builds then make deploying such containers
way easier because you can include
that build step in the image
and then have a container which has the finished output
when it's being started.
So multi-stage builds are a feature to keep in mind.
Now when it comes to the concrete deployment process,
there is one key trade-off you should always be aware of.
And that is the control which you have over the environment,
versus the ease-of-use.
And security also is involved in that trade-off.
You can bring up your own server,
your own EC2 instance on AWS for example,
install Docker
and any other software which might be needed on it,
and then run your containers on that remote machine.
That is possible.
You then have full control
because it's effectively your computer
which you control there.
But that also means that you have to do everything.
You are responsible for its security
and you are responsible for keeping the tools updated,
for monitoring your running applications.
All of that.
You can instead also use a managed service
to make that easier for you.
Then all of that is managed for you
and you don't have to bring up
and configure your own servers
and install your own software.
That means less control,
but all the less responsibility
and less knowledge which is required.
It's easier to use
and if you're just a developer,
I strongly recommend
that you consider such managed services.
Of course, if you are a longterm administrator
and you know everything about servers,
then being able to manage everything on your own
might be worth a lot to you.
And that is it for this summary.
These are all things we learned,
It was just a summary.
And these are all things
and concepts which should be clear to you by now,
because in the next core section,
we are going to start with Kubernetes,
which is a brand new thing
still related to docker at containers of course,
but a brand new concept
or a collection of concepts,
which will help us with deploying containers
and managing more complex
applications possibly, multi-container applications
running on multiple hosts.
So let's dive into that.
If something about this summary was not clear,
I strongly recommend
that you go back to the respective module
to make sure we're all on the same page again.