Now we already learned
and saw that containers are great
and that they can make development easier.
And thus far we only focused on development.
However, containers are these independent isolated packages
full of application code and application environment
which we can ship anywhere where Docker runs.
Because they are standardized
if we built them with Docker
and therefore Docker can run them anywhere
where Docker is installed.
And therefore, in section one of this course
already I mentioned that containers
can help us with problems we might be facing
when shipping applications
because without containers
we often end up with different development
and production environments
which means that code which might work locally
on our machine all of a sudden fails
once we deployed the application
onto a remote host, onto a server.
And the idea for also already mentioned in section one
that Docker and containers can help us with that.
We can get the exact same environment
on our development machine
as we later have it on our remote machine
where we wanna run the application
and that is the case because the environment
is inside of the container.
We don't have to configure the machine itself.
We don't have to install tools
like Node.js on the machine,
neither on our local development
nor on the production remote hosting machine.
Instead, we have everything our application needs
inside of the container.
So therefore, with containers and Docker
we benefit from this isolated standalone environment
both during development
which we saw in all the sections up to this point,
as well as in production.
And that is why I had so many sections
on our local development environment
because everything you'll learn there
will also help you in production
because you ship the same containers
you worked on locally on your local host machine
to remote machines that should run your containers.
And that is what we're going to see in this module
because with these containers and with Docker
we got these reproducible environments
which are easy to share and use
and that will help us for moving our application
from our local host machine
where it is inside of an image in the end
to a remote machine where it's then should be served
to all our application users.
And therefore, we ensure when using Docker and containers
that we don't face any unwanted surprises.
What works on our local machine in a container
will also work after deployment on a remote machine.
That's the idea behind Docker.
That's what I mentioned
multiple times throughout this course
and what we already used locally on our local machine
when we learned about all these Docker basics
and that's also what we're going to use now
when we deploy the application
and therefore move our container
from the localhost machine to our remote host.
So to some other computer
running somewhere in the cloud,
in the internet not on our local machine.
Now in this module,
we are going to dive into deploying containers.
Which means bringing them to remote machines.
And there are a couple of things you should be aware of
when it comes to deploying containers.
A couple of things you should watch out for
and a couple of things you will see
throughout this module therefore.
One of the most important things which can be strange
when you first see it is that during development
we use bind mounts a lot.
In production we shouldn't really use them.
You shouldn't really use bind mounts
when you move your container
from your local machine to production.
And I will come back to why that's the case in a second.
Another important thing to watch out for
is that your containerized apps
might need different setups for development
and for production
which sounds strange at first
after all the idea with containers
was that we have one at the same environment.
That's true but some applications
like React apps for example
simply need a build step
where the code is converted and optimized
and that builds step happens after development
before you deploy the application.
But even though we need this build step in this module
you will all learn how you can still ensure
that you ship containers
which have reproducible environments
and where to code that work locally
will also work once you deployed it.
The same by the way will be true for bind mounts
even though we may use them during development
and we shouldn't use them in production.
You will still learn in this section
how does won't contradict the idea behind containers
and how does won't lead to containers that are different
during development and production.
You will see how that all still works
even though we might have differences.
In addition one other thing we'll see
throughout this module
is related to multi-container projects.
In such projects it heavily depends on the project
and on the containers whether you might need to
or maybe might want to split your containers
across multiple hosts
so across multiple remote machines.
So whilst you might be able to test everything
let's say with Docker compose locally on one host machine
for deployment you might consider splitting it
across multiple servers or multiple host machines
and I will come back that as well.
And last but not least,
throughout this module,
there will be a couple of points, a couple of lectures
where we actually make a trade off
and where we may be go for a solution
where we have less control over the deployment platform.
For example, over a remote host
but we also therefore have less responsibility
and that might be worth it
as you will see throughout this module.
Because it turns out that
if you have to manage a remote host on your own.
If you have to set everything up on some remote machine
that also brings a lot of responsibility.
Where you have to ensure that that machine is secure
and so on.
And therefore will have a couple of lectures in this module
where we will actually go for less control
but also less responsibilities solution
so that ultimately we as a developer have an easier time.