Using Docker and containers
offers us various advantages.
We talked about this in the first course section already.
Now, up to this point,
we can see one advantage in action already.
We don't have to uninstall
and re-install local dependencies all the time.
Instead, we are already using Docker for example,
in our assignment applications,
but also in the applications we built before that,
in this module.
We're using Docker to install
the dependencies of this node app inside of the image
and container therefore,
and we therefore don't have to install node
globally on our system either.
I happen to have it installed,
but we wouldn't need that.
And the same for Python.
Thanks to Docker, which we use here.
We don't need to install Python globally on our system,
it's in the image and container instead.
And even if that would be all we're using Docker for,
that would already be great.
because it would allow us
to have multiple projects on our computer
with different dependencies and different versions,
and they could co-exist side by side
without us having to uninstall
or re-install various tools all the time.
We could have a Python 3.7 based app
next to a Python 3.9 based app
without switching python versions in between.
So that's great already.
Still, this is not the only reason
why we're typically using Docker.
We're also using it to share our images
and containers with others.
That could be team members
who are working on the same project,
or that could be servers
on which we wanna deploy our containers.
Now I'll dive into deployment later
since that involves a couple of steps,
but I wanna start with sharing images
and containers with other persons,
or even with ourselves on different machines right now.
Because there's one simple thing we have to keep in mind,
everyone who has an image,
can create containers based on that image.
So that of course also means
that we don't really share containers with anyone,
instead, we'll share images.
Because if you have an image,
you can run a container based on that image.
I mean, that's all to what we did before.
We're building up our own images
on the Python or node images.
So we're also pulling down these images
from Docker hub as I showed you earlier,
and then we're able to use them to run our own containers,
which in the end are also based on those images,
at least partly.
And when it comes to sharing images,
we've got two main ways of doing that.
We can share the Dockerfile.
If I give you that Dockerfile
and the source code that belongs to this application,
you can build your own image
and use that to run a container.
And that's actually how the various
code snapshot attachments you'll find in this course
are organized.
If you find an attachment on one of the lectures
it's a SIPP file, which contains a Dockerfile
and then the code belonging to that Dockerfile.
And then you can build that image on your own
and run container based on it.
Now that's one way of sharing an image.
I simply give you the Dockerfile
and you're good to go.
But that's, for example
not what's happening when we're basing this image
on the node image.
We're not downloading the node Dockerfile anywhere.
I never built the node image myself.
And just to make this super clear,
if you Google for GitHub node Docker,
you find the official repository for the Docker node image.
And in there, you will actually also find Dockerfiles.
For example, for the 14 tag,
let's say therefore this alpine version whatever,
there you find a Dockerfile
which in the end sets up this node image.
It's based on alpine which is a Linux distribution.
So it's the operating system for this node image so to say,
and then it has various instructions in here
obviously more complex instructions than in our basic image
which do configure this image to set up a node environment.
And this is the kind of image we are basing our image on
if we're using the from instruction.
But again, we didn't download
and built the Dockerfile,
instead, we just used this image like this.
Also earlier in this course,
when I executed docker run node,
referring to that official node image.
This also works.
It downloads the latest note image
and then just runs it as a container.
In this case, it stops automatically
since I didn't add an interactive session to the image
but that doesn't matter here.
The key takeaway is that here we didn't get a Dockerfile,
which we built on our own.
Because there always is a second way of sharing images
besides sharing a Dockerfile
and leaving it up to the recipient to build that Dockerfile,
you can also share a complete built image.
So not the Dockerfile, but the finished image.
You can share this too.
Now, when you get a Dockerfile,
you have to build it
and your therefore also need all the surrounding code
and folder structure that should go into the image.
If you get the image, you just download the image
and you can run a container instantly.
You don't need to build it
and you don't need any extra code or surrounding folders.
So there's no build step required here.
Everything is included in the image already.
And therefore that's how you typically
share images with other people.
Now, in the course I stick to these attachments
with the raw code so that you can compare
that to your code as well.
But if you share it with a team member
or also later for deployment,
you typically work with finished images
and not with raw Dockerfiles.