For this one.
The great Submission API code is different because now it uses Mongo DB, and it relies on three environment
variables in order for it to connect to Mongo db and set up a database inside of it.
Okay, so the environment variables that the API now relies on are db host, db port and db name.
It relies on the environment that it's running in, in this case a Docker container to provide it with
these environment variables.
Which means now what we're going to do.
Is set up a Docker compose file that has three containers.
One container is going to be running the flask app.
The flask app is going to have one environment variable that tells it the host name that it needs to
connect to this container.
The node application running inside of this Docker container is going to need environment variables
that allow it to connect to the database that's running inside of this container.
This container is going to need environment variables that tells it how it's supposed to configure the
database.
All right.
So let's just go ahead and start by saying Docker system prune dash A.
That should remove all the images that we pulled from Docker Hub docker images docker PS dash a.
Notice how easy things are to clean up once you use docker compose.
It was very easy to remove the images because no running containers were relying on them.
There were no loose networks that we needed to manage ourselves.
So now, uh, what we need to do is go inside or go outside of oh eight starter code, go inside of
oh nine starter code.
Uh, we're going to go inside of the grade submission API, and then we're going to rebuild this image
to include the updated code that relies on MongoDB.
So Docker build t r a slim 087.
Use your username of course great submission API.
And we're going to tag this to 0.00.0.
You want to update this number when there are breaking changes in your application.
In this case, having this app interact with a NoSQL database is a pretty major change.
Dot.
All right.
And now we're going to push this
Over to Docker Hub.
Then we're going to rebuild this image to be latest and push that over to Docker Hub.
Let's just make sure everything is good.
Wonderful.
We've got version one, version two and version two is the latest one.
So if you go to the Docker file over here, we've got this one using the latest great submission portal
image.
We've got this one using great submission API version two.
We can just say latest for each one and the interest of consistency.
And now what we need to do is set up a container that runs MongoDB.
All right.
Under the services field we're going to specify another container called Mongo.
The image from which we're going to create a mongo container is called Mongo.
Now think of how annoying it can be to set up MongoDB on your local machine.
In this case, all you got to do is create a container out of a preconfigured image that's already uploaded
to Docker Hub.
I don't know about you, but I think that's really, really cool.
Okay, I'm actually out of breath now because I just told the construction workers upstairs to take
it easy on the noise, but I will catch my breath.
Don't worry.
So we're creating a container from the image Mongo that's going to run an instance of MongoDB inside
of the same docker compose environment as Great submission API, which means we can.
Seamlessly connect our great submission API to our MongoDB database.
All right.
And then we're going to specify.
Volumes.
All right.
So our MongoDB instance is going.
To be running inside of a Docker container.
When we destroy that container.
Everything inside of it is going to be destroyed as well.
So what we need to do is determine where MongoDB saves its data within the Docker container file system.
It's automatically it's automatically configured to save its data to a folder.
Slash data dash DB.
What we can do is connect, uh, whatever data is saved here to a persistent volume in our host machine,
a named volume, if you will We're going to give that volume a particular name.
And what that accomplishes is when we destroy this container, the data lives inside of this persistent
volume.
For as long as you keep that volume and you don't delete it, when you restart this container, the
data will live.
All right.
So that is why we use volumes in Docker.
So the data is automatically going to be saved to the directory slash data slash DB within the containers
file system.
And now here what I can do is say volumes.
And I'm going to specify a volume called Mongo data.
This is how you specify a named volume.
So now what I'm going to do is connect the directory where data is being saved inside of the mongo container
to the persistent space within my host machine.
So now any data that gets saved to slash data dash.
DB will take up space inside of my host machine itself.
When we destroy the container, the data will live here.
If I don't do this, any data that gets saved to Mongo is just going to disappear.
Okay, but we're not done yet.
Now, if I go to the Mongo, uh, official image repo, remember, nothing I do here is magic.
I looked at the documentation beforehand.
Um, there's a specific environment variable I want to show you.
Mongo init.
Mongo init db database.
This variable allows you to specify the name of a database to be used for creation So, Um, whenever
we create a mongo container, I want it to create a database.
So our Mongo application that lives inside of a mongo container, it accepts an environment variable
Mongo init db database.
And if that environment variable is provided, it's going to create a database, uh, based on whatever
we call it.
So as before we can specify environment variables okay.
The environment variable we're going to pass in to from the Mongo container to the Mongo application
itself.
Running inside of it is going to be called how about grade DB.
Because ultimately the node server is going to be persisting applications to a grade database.
All right.
And now we're not going to set up any authentication for the Mongo application.
We could by passing in the right environment variables from the container into the app.
We're not going to do it.
We're just going to keep things simple.
And then here I'm going to set up environment variables.
That allows my node server API to find the Mongo instance that's running inside of the Mongo container.
So this is typically how you would connect from a JavaScript application to a MongoDB database.
You start with the scheme MongoDB, followed by the host, the port and the database name that you want
to connect to.
The host allows our Node.js application to find which container the application is running in.
They're both running inside of the same network, so if I specify a DB host.
Equal to Mongo, it's going to be able to find the Mongo container and therefore connect to the application
that's running inside of it.
The Mongo application that's running inside of it is serving requests well.
By default, the Mongo application serves requests on two seven something.
This is just something you would find in the documentation.
I'm not making this up.
So once the node server API finds the container that the app is running in, that app is serving requests
on the container port 27017.
So we specify a DB port environment variable equal to 27017.
All right.
Uh, what other environment variables does our great submission API rely on?
The DB name.
So db what was it DB name.
Is equal to grade DB.
This is something you would have found in the documentation that we gave our API.
All right.
Uh, the Great Submission API integrates with a mongo database for persistent storage.
For great submissions, the following env variables are required for the database connection.
A hostname or IP address of the MongoDB container so that we can connect to the application running
inside of that container.
The port number where the MongoDB application is accepting requests, and once we're able to connect
to that host at a particular port, we can give it the database name that we want to connect to.
All right.
I'm pretty sure that's it.
Let us run.
Sorry, I need to CD out of the great submission API.
And then call Docker compose up.
All right.
We were able to run a MongoDB application running inside of a particular container, serving requests
on a particular port.
Through the usage of environment variables, we were able to give the Node.js application the information
that it needs to connect to that application, make requests to it, and everything just worked smoothly.
We didn't have to install anything into our host machine.
Everything is happening inside of a docker compose environment.
I don't know about you, but this is really cool and I can't wait to put it all to the test.
I'm going to say Harry with a score of 92 or 93 on potions, press submit.
Everything works beautifully.
Now if I say docker compose down, let me start up another terminal.
I'm going to CD into oh nine.
Uh, lesson starter projects oh nine starter code.
I'm going to say docker compose down.
That's going to destroy all the containers okay.
But the data is still going to live inside the volume that's mounted on our host machine.
So all the data so the data that we saved to Mongo went to slash data DB and was redirected to the volume
itself.
Now if I restart the containers by saying docker compose up.
And I'm going to go back to localhost 5001 slash grades.
The grade is still there.
How cool is that?
All right.
That's all I wanted to teach you for this course.
Thank you for tuning in.