So let's get started by dockerizing this app.
And as so often, of course, feel free to pause the video
at this point and try dockerizing this on your own.
It's basically the same, what we already did
in the last lectures and modules.
After a short pause which would give you to pause the video,
we're going to do that together.
So, let's now dockerize this app together.
And for this, I'm again going to create a Dockerfile here.
Now in this Dockerfile, I wanna dockerize this app.
It's a Node app and they are for my base image,
pulled in with the from instruction, will be node.
And I'll go for a version 14 here,
but you could also go for 12, but I'll take 14.
Next, I will set my working directory
and I will again, set it to app,
but as I mentioned before, of course, this is up to you.
Now that this is set, we can copy the package.json file,
which contains the dependencies of this application,
into our working directory, with copy packaged.json.
or again, repeating the working directory,
but since it's already set,
we can always just use a dot here.
With that done, we can run the npm install command,
to install all dependencies
that are mentioned in package.json.
And once this is set up, we can copy over the remaining code
with dot pointing at the entire folder here
in which the Dockerfile lives
and the second dot which refers to the working directory.
We also should expose a port
and this application listens on port 80.
So that's the port I'll expose here.
And now last but not least,
we can specify the command which we want to execute,
when a container is started based on this image.
And here, I wanna use the Node executable
to execute server.js.
So that's my Dockerfile here.
Nothing too fancy, basically just again, what we did before
and therefore now, we can open up a terminal,
and run Docker build, to build this as an image.
And I'll give this image attack with the -t flag,
and I will name it feedback-node.
Since it's a feedback application
taking in some user feedback and based on Node.js.
We could also add a tag with a colon thereafter,
but I'll go for the default tag of latest,
which is assigned automatically
if you don't assign your own tag.
So with that, we created this image with all the steps,
and now we can start a container based on that image.
For that, we can use docker run on our feedback-node image,
which we just created.
Again, you can point at a specific tag,
but since we only got one tag here the latest tag,
we can also just go with the name.
But of course, I also wanna publish the port.
Let's say, I wanna publish the internal port 80,
on port 3000 on my machine here.
A launched is in detached mode,
so that we can use the terminal right
after launching this container.
And I'll give the container a name of Feedback App.
We can also add --rm to ensure that this container
is automatically removed whenever we stop it.
If we now enter this starts this container,
with docker ps we can see it.
And if you now visit local host 3000,
you will see your application there.
And if I add a little feedback here
with the title of awesome, this is awesome,
I can click save, and this should work.
As a side note, this is a very simple application
and the title which you enter here, is used as a filename.
The only transformation I do to this title
is that I transform it to be all lowercase.
So if you enter a lot of special characters here,
saving might not work.
So therefore, keep this title simple for this demo,
it's best If you use one word titles,
without any special characters.
I kept this example simple since it's about Docker
and not Node.js.
Now, with that saved and I chose awesome as a name,
in this app, we can actually also visit,
/feedback/awesome.txt to view this stored file.
This is not a bug but this is actually,
something I am enabling my code here.
You can access the feedback folder.
As a user of this web app you are allowed
to look into files stored in that folder.
Now, as a side note,
if you look into the feedback folder on your local machine,
you will not see this file there.
It only exists inside of the Docker container
which is why we can view it there, but not here.
And the reason for that is that, in the Dockerfile,
we copy our local folder into the image
and the container is then based on that image.
But that means that the image
and therefore also the container
has its own file system,
based on our local folder here,
because we copy it in, but they're after
there is no connection between our local folder
and this image internal file system.
And that's how it's intended to work.
The containers should be isolated after all.
It would be pretty bad,
if files would be created inside of the container
and suddenly would end up somewhere on our hard drive,
on our host machine.
That's not the idea behind Docker at all.
And that's by the way, the same thing as earlier
in this course when we changed something
in our source code locally on our host machine
and the change wasn't reflected
in the running Docker container.
You might remember that we had to rebuild the image,
to copy in the changed code, create a new image based on it,
and then containers running based on that changed image
would have our code changes.
For the same reason, we copy code into an image,
it then is in a special file system inside of the image,
it's locked in, there is no connection to the host folder
or to the host machine and the container,
therefore also has this isolated file system
where only this snapshot was copied in
when we built the image;
this snapshot of our local folder in this case.
That's all something we covered already
but it is important to always keep this in mind,
there is no connection between your container
or your image and your local file system.
You just initialized his image once,
you can copy in a snapshot of your local folders and files,
but there after, that's it.
There is no connection,
and that's why we don't see the text file
in the feedback folder here on our hosting machine,
in this folder.
We only have it available inside
of the running Docker container.
There we can access it, there it exists.
So, that's how this application works.
Let me go back here,
and if I now would submit the same feedback again,
so with the same title I mean,
I would actually see this, 'Exists already page',
and the file would not be stored in the feedback folder.
If I visit awesome.txt we still see the old text in there,
so it was not overwritten.
And it is not overwritten because in the Node code,
I have the logic for creating a temporary file first
and only copying it into the final folder,
into the feedback folder,
if the file doesn't exist there yet.
that's the logic I have here in my Node app.
So that's why we're not overwriting existing files.