WEBVTT 00:00.050 --> 00:00.980 For this one. 00:00.980 --> 00:10.670 The great Submission API code is different because now it uses Mongo DB, and it relies on three environment 00:10.670 --> 00:17.390 variables in order for it to connect to Mongo db and set up a database inside of it. 00:17.510 --> 00:26.900 Okay, so the environment variables that the API now relies on are db host, db port and db name. 00:26.900 --> 00:33.110 It relies on the environment that it's running in, in this case a Docker container to provide it with 00:33.110 --> 00:34.760 these environment variables. 00:34.760 --> 00:37.100 Which means now what we're going to do. 00:39.560 --> 00:44.450 Is set up a Docker compose file that has three containers. 00:44.450 --> 00:47.480 One container is going to be running the flask app. 00:47.480 --> 00:53.840 The flask app is going to have one environment variable that tells it the host name that it needs to 00:53.870 --> 00:55.760 connect to this container. 00:56.750 --> 01:03.340 The node application running inside of this Docker container is going to need environment variables 01:03.340 --> 01:09.190 that allow it to connect to the database that's running inside of this container. 01:10.360 --> 01:16.000 This container is going to need environment variables that tells it how it's supposed to configure the 01:16.000 --> 01:17.110 database. 01:17.140 --> 01:18.460 All right. 01:18.670 --> 01:27.220 So let's just go ahead and start by saying Docker system prune dash A. 01:28.210 --> 01:35.590 That should remove all the images that we pulled from Docker Hub docker images docker PS dash a. 01:35.770 --> 01:40.720 Notice how easy things are to clean up once you use docker compose. 01:40.720 --> 01:45.790 It was very easy to remove the images because no running containers were relying on them. 01:45.790 --> 01:49.810 There were no loose networks that we needed to manage ourselves. 01:50.710 --> 01:58.750 So now, uh, what we need to do is go inside or go outside of oh eight starter code, go inside of 01:58.750 --> 02:01.080 oh nine starter code. 02:03.060 --> 02:12.240 Uh, we're going to go inside of the grade submission API, and then we're going to rebuild this image 02:12.240 --> 02:16.080 to include the updated code that relies on MongoDB. 02:16.440 --> 02:21.030 So Docker build t r a slim 087. 02:21.060 --> 02:25.560 Use your username of course great submission API. 02:25.560 --> 02:29.310 And we're going to tag this to 0.00.0. 02:29.340 --> 02:34.380 You want to update this number when there are breaking changes in your application. 02:34.380 --> 02:41.100 In this case, having this app interact with a NoSQL database is a pretty major change. 02:41.610 --> 02:42.900 Dot. 02:52.350 --> 02:53.700 All right. 02:54.540 --> 02:57.330 And now we're going to push this 02:59.720 --> 03:01.310 Over to Docker Hub. 03:16.100 --> 03:26.480 Then we're going to rebuild this image to be latest and push that over to Docker Hub. 03:32.390 --> 03:34.280 Let's just make sure everything is good. 03:39.080 --> 03:39.920 Wonderful. 03:39.920 --> 03:44.690 We've got version one, version two and version two is the latest one. 03:45.140 --> 03:55.370 So if you go to the Docker file over here, we've got this one using the latest great submission portal 03:55.370 --> 03:56.360 image. 03:56.360 --> 04:01.580 We've got this one using great submission API version two. 04:01.940 --> 04:06.110 We can just say latest for each one and the interest of consistency. 04:06.500 --> 04:12.080 And now what we need to do is set up a container that runs MongoDB. 04:12.830 --> 04:13.670 All right. 04:13.700 --> 04:19.040 Under the services field we're going to specify another container called Mongo. 04:19.100 --> 04:24.110 The image from which we're going to create a mongo container is called Mongo. 04:24.140 --> 04:29.270 Now think of how annoying it can be to set up MongoDB on your local machine. 04:29.270 --> 04:34.670 In this case, all you got to do is create a container out of a preconfigured image that's already uploaded 04:34.670 --> 04:36.020 to Docker Hub. 04:36.140 --> 04:40.070 I don't know about you, but I think that's really, really cool. 04:40.880 --> 04:46.160 Okay, I'm actually out of breath now because I just told the construction workers upstairs to take 04:46.160 --> 04:48.770 it easy on the noise, but I will catch my breath. 04:48.770 --> 04:49.730 Don't worry. 04:49.970 --> 04:58.610 So we're creating a container from the image Mongo that's going to run an instance of MongoDB inside 04:58.640 --> 05:04.240 of the same docker compose environment as Great submission API, which means we can. 05:04.270 --> 05:10.660 Seamlessly connect our great submission API to our MongoDB database. 05:10.750 --> 05:11.590 All right. 05:11.590 --> 05:13.000 And then we're going to specify. 05:13.030 --> 05:14.320 Volumes. 05:14.860 --> 05:16.150 All right. 05:16.720 --> 05:19.840 So our MongoDB instance is going. 05:19.870 --> 05:22.360 To be running inside of a Docker container. 05:22.930 --> 05:25.360 When we destroy that container. 05:25.390 --> 05:28.480 Everything inside of it is going to be destroyed as well. 05:28.480 --> 05:37.480 So what we need to do is determine where MongoDB saves its data within the Docker container file system. 05:37.570 --> 05:43.060 It's automatically it's automatically configured to save its data to a folder. 05:43.090 --> 05:45.340 Slash data dash DB. 05:45.820 --> 05:55.570 What we can do is connect, uh, whatever data is saved here to a persistent volume in our host machine, 05:55.600 --> 06:01.170 a named volume, if you will We're going to give that volume a particular name. 06:01.230 --> 06:08.970 And what that accomplishes is when we destroy this container, the data lives inside of this persistent 06:08.970 --> 06:09.780 volume. 06:09.780 --> 06:16.650 For as long as you keep that volume and you don't delete it, when you restart this container, the 06:16.650 --> 06:17.730 data will live. 06:17.760 --> 06:18.270 All right. 06:18.270 --> 06:22.710 So that is why we use volumes in Docker. 06:22.950 --> 06:31.560 So the data is automatically going to be saved to the directory slash data slash DB within the containers 06:31.560 --> 06:32.610 file system. 06:32.640 --> 06:36.210 And now here what I can do is say volumes. 06:36.300 --> 06:41.940 And I'm going to specify a volume called Mongo data. 06:42.720 --> 06:45.630 This is how you specify a named volume. 06:45.630 --> 06:54.030 So now what I'm going to do is connect the directory where data is being saved inside of the mongo container 06:54.510 --> 07:00.140 to the persistent space within my host machine. 07:00.140 --> 07:03.740 So now any data that gets saved to slash data dash. 07:04.280 --> 07:08.720 DB will take up space inside of my host machine itself. 07:08.720 --> 07:11.900 When we destroy the container, the data will live here. 07:11.900 --> 07:19.520 If I don't do this, any data that gets saved to Mongo is just going to disappear. 07:19.730 --> 07:23.600 Okay, but we're not done yet. 07:23.630 --> 07:31.910 Now, if I go to the Mongo, uh, official image repo, remember, nothing I do here is magic. 07:31.910 --> 07:34.940 I looked at the documentation beforehand. 07:35.240 --> 07:40.010 Um, there's a specific environment variable I want to show you. 07:40.250 --> 07:42.890 Mongo init. 07:48.680 --> 07:51.260 Mongo init db database. 07:51.260 --> 07:59.590 This variable allows you to specify the name of a database to be used for creation So, Um, whenever 07:59.590 --> 08:06.640 we create a mongo container, I want it to create a database. 08:06.640 --> 08:13.960 So our Mongo application that lives inside of a mongo container, it accepts an environment variable 08:13.960 --> 08:16.630 Mongo init db database. 08:16.630 --> 08:23.800 And if that environment variable is provided, it's going to create a database, uh, based on whatever 08:23.800 --> 08:24.970 we call it. 08:24.970 --> 08:32.410 So as before we can specify environment variables okay. 08:32.440 --> 08:38.590 The environment variable we're going to pass in to from the Mongo container to the Mongo application 08:38.590 --> 08:38.980 itself. 08:38.980 --> 08:43.030 Running inside of it is going to be called how about grade DB. 08:43.390 --> 08:49.780 Because ultimately the node server is going to be persisting applications to a grade database. 08:49.810 --> 08:50.740 All right. 08:50.740 --> 08:55.930 And now we're not going to set up any authentication for the Mongo application. 08:55.930 --> 09:01.470 We could by passing in the right environment variables from the container into the app. 09:01.470 --> 09:02.100 We're not going to do it. 09:02.100 --> 09:03.780 We're just going to keep things simple. 09:03.870 --> 09:08.940 And then here I'm going to set up environment variables. 09:08.940 --> 09:16.650 That allows my node server API to find the Mongo instance that's running inside of the Mongo container. 09:16.650 --> 09:24.240 So this is typically how you would connect from a JavaScript application to a MongoDB database. 09:24.240 --> 09:31.950 You start with the scheme MongoDB, followed by the host, the port and the database name that you want 09:31.980 --> 09:33.270 to connect to. 09:33.300 --> 09:41.340 The host allows our Node.js application to find which container the application is running in. 09:41.370 --> 09:48.510 They're both running inside of the same network, so if I specify a DB host. 09:51.270 --> 09:59.840 Equal to Mongo, it's going to be able to find the Mongo container and therefore connect to the application 09:59.840 --> 10:01.580 that's running inside of it. 10:01.610 --> 10:08.480 The Mongo application that's running inside of it is serving requests well. 10:08.510 --> 10:13.670 By default, the Mongo application serves requests on two seven something. 10:14.870 --> 10:17.900 This is just something you would find in the documentation. 10:17.930 --> 10:19.220 I'm not making this up. 10:19.250 --> 10:29.750 So once the node server API finds the container that the app is running in, that app is serving requests 10:29.750 --> 10:34.070 on the container port 27017. 10:34.070 --> 10:43.610 So we specify a DB port environment variable equal to 27017. 10:43.640 --> 10:44.900 All right. 10:45.560 --> 10:50.300 Uh, what other environment variables does our great submission API rely on? 10:50.330 --> 10:52.400 The DB name. 10:52.820 --> 10:56.840 So db what was it DB name. 11:01.580 --> 11:03.890 Is equal to grade DB. 11:05.210 --> 11:11.210 This is something you would have found in the documentation that we gave our API. 11:11.510 --> 11:12.470 All right. 11:12.650 --> 11:16.550 Uh, the Great Submission API integrates with a mongo database for persistent storage. 11:16.550 --> 11:21.080 For great submissions, the following env variables are required for the database connection. 11:21.110 --> 11:26.900 A hostname or IP address of the MongoDB container so that we can connect to the application running 11:26.900 --> 11:28.070 inside of that container. 11:28.100 --> 11:36.350 The port number where the MongoDB application is accepting requests, and once we're able to connect 11:36.350 --> 11:43.070 to that host at a particular port, we can give it the database name that we want to connect to. 11:43.490 --> 11:44.660 All right. 11:44.660 --> 11:47.600 I'm pretty sure that's it. 11:47.630 --> 11:49.250 Let us run. 11:50.090 --> 11:53.990 Sorry, I need to CD out of the great submission API. 11:55.820 --> 11:59.320 And then call Docker compose up. 12:04.210 --> 12:04.960 All right. 12:04.960 --> 12:12.370 We were able to run a MongoDB application running inside of a particular container, serving requests 12:12.370 --> 12:13.810 on a particular port. 12:13.840 --> 12:20.590 Through the usage of environment variables, we were able to give the Node.js application the information 12:20.590 --> 12:28.270 that it needs to connect to that application, make requests to it, and everything just worked smoothly. 12:28.270 --> 12:32.530 We didn't have to install anything into our host machine. 12:32.530 --> 12:37.990 Everything is happening inside of a docker compose environment. 12:38.080 --> 12:43.270 I don't know about you, but this is really cool and I can't wait to put it all to the test. 12:44.560 --> 12:53.500 I'm going to say Harry with a score of 92 or 93 on potions, press submit. 12:53.500 --> 12:56.110 Everything works beautifully. 12:56.140 --> 13:02.520 Now if I say docker compose down, let me start up another terminal. 13:02.520 --> 13:06.540 I'm going to CD into oh nine. 13:06.570 --> 13:10.470 Uh, lesson starter projects oh nine starter code. 13:11.820 --> 13:14.430 I'm going to say docker compose down. 13:14.730 --> 13:17.280 That's going to destroy all the containers okay. 13:17.280 --> 13:23.430 But the data is still going to live inside the volume that's mounted on our host machine. 13:24.960 --> 13:32.430 So all the data so the data that we saved to Mongo went to slash data DB and was redirected to the volume 13:32.430 --> 13:33.390 itself. 13:34.500 --> 13:39.510 Now if I restart the containers by saying docker compose up. 13:44.220 --> 13:48.510 And I'm going to go back to localhost 5001 slash grades. 13:48.570 --> 13:50.520 The grade is still there. 13:50.520 --> 13:51.690 How cool is that? 13:52.260 --> 13:52.800 All right. 13:52.800 --> 13:54.690 That's all I wanted to teach you for this course. 13:54.690 --> 13:56.460 Thank you for tuning in.