WEBVTT 00:00.500 --> 00:01.580 Welcome back everyone. 00:01.580 --> 00:08.420 This section is very exciting because we are going to connect all of these applications to databases. 00:08.420 --> 00:11.240 Before we start, go to containers. 00:11.240 --> 00:13.760 Delete every container that you may already have running. 00:13.760 --> 00:18.140 Delete every single image that you may already have in your local cache. 00:18.140 --> 00:18.650 Delete. 00:18.650 --> 00:22.670 Delete every single volume as well that you may have. 00:22.670 --> 00:27.500 And once you're sure that you're off to a clean slate, let's begin. 00:28.070 --> 00:32.370 Now, the first task I'm going to give you, you're going to probably hate me for it because it's a 00:32.370 --> 00:40.380 bit tedious, and that is to build an image out of each Docker file inside of oh five starter projects. 00:40.410 --> 00:42.810 Why are we rebuilding the images? 00:42.840 --> 00:49.500 Well, because the source code for each API here is very different from the source code in oh three 00:49.500 --> 00:50.760 starter projects. 00:50.760 --> 00:55.840 All of these applications are now designed to connect to a database. 00:56.020 --> 01:04.360 So when you're creating your images, uh, name each one according to your Docker Hub username, followed 01:04.360 --> 01:09.070 by the service name, and tag each one as version 2.0.0. 01:09.280 --> 01:10.390 All right. 01:10.390 --> 01:17.420 The e-commerce UI code doesn't really change from section three, so you can just leave the tag as latest. 01:17.420 --> 01:20.390 Pause the video until you have that set up. 01:23.540 --> 01:24.500 All right. 01:24.500 --> 01:27.590 Once you do, we're ready to begin. 01:27.710 --> 01:33.920 So all of these applications except for the e-commerce UI, the e-commerce UI is stateless. 01:33.950 --> 01:36.020 It's not connected to a database. 01:36.050 --> 01:44.940 All it does is it communicates with all of these APIs which do persist data to databases, which means 01:44.940 --> 01:48.600 that for each API, we need to create a volume. 01:48.600 --> 01:52.590 Well, let me start by specifying a version of three. 01:52.920 --> 01:56.730 Um, we'll specify a mapping for services. 01:56.730 --> 02:06.760 But first we're going to define we're going to define 123456 named volumes one volume for each service. 02:06.760 --> 02:10.180 So four of these services use MongoDB. 02:10.180 --> 02:14.260 So we're going to define four MongoDB volumes. 02:14.260 --> 02:18.280 The first one is going to be called MongoDB product catalog data. 02:18.280 --> 02:24.790 Because if you look inside the product catalog API it relies on MongoDB. 02:25.480 --> 02:33.440 Uh, so do the contact support API, as well as the shipping API and the order Management API. 02:33.470 --> 02:39.860 So we're going to say MongoDB contact uh support data. 02:41.420 --> 02:43.310 That's another volume we're going to create. 02:43.310 --> 02:55.620 Another volume will create is MongoDB uh shipping data and MongoDB order management data. 02:57.090 --> 02:57.960 All right. 03:03.390 --> 03:07.920 Now we need to create two more volumes. 03:08.160 --> 03:11.910 Um, the profile management API. 03:11.910 --> 03:16.110 If you were to look into it it relies on MySQL. 03:16.170 --> 03:25.450 So we're going to create a named volume called MySQL Profile Management. 03:27.040 --> 03:31.120 And that's going to store all the MySQL data for profile management. 03:31.120 --> 03:32.710 Why do I have a colon here. 03:35.680 --> 03:41.120 And the last service uh I believe it's product inventory. 03:41.120 --> 03:43.640 This one relies on PostgreSQL. 03:43.640 --> 03:44.750 It does. 03:44.780 --> 03:55.340 So here we'll define a named volume called Postgres Product Inventory data. 03:55.880 --> 03:56.270 All right. 03:56.270 --> 04:04.610 So all of these named volumes, named volumes are going to take up actual space inside of my computer. 04:04.640 --> 04:12.630 The reason these are important is because when each database container persists its data, once we destroy 04:12.630 --> 04:15.480 that container, we don't want that data to be erased. 04:15.510 --> 04:20.400 We want it to be redirected to these volumes where they are more durable. 04:20.430 --> 04:21.450 Okay. 04:22.500 --> 04:25.710 Um, I want to start with MySQL. 04:25.710 --> 04:32.770 So let's go ahead by creating a MySQL container for the Profile Management API. 04:32.890 --> 04:34.330 What should I call the container? 04:34.330 --> 04:35.500 I'm thinking of a name. 04:35.530 --> 04:37.540 How about, um. 04:37.540 --> 04:46.150 Well, under services we create a container called MySQL Profile Management. 04:46.840 --> 04:48.490 That's going to be the name of the container. 04:48.490 --> 04:54.610 The image from which we're going to create the container is MySQL version 8.0. 04:54.610 --> 05:00.700 So if you were to look inside of Docker Hub, this is the official repo for the MySQL image. 05:00.700 --> 05:03.070 You can find various versions of this image. 05:03.070 --> 05:07.570 The one we're going to pull is specifically tagged 8.0. 05:07.600 --> 05:09.040 This one right over here. 05:10.510 --> 05:18.140 So let's pull MySQL version eight, the container name we're going to explicitly specify to be MySQL 05:18.140 --> 05:19.910 profile management. 05:20.270 --> 05:21.680 All right. 05:22.220 --> 05:28.580 And um, now we're going to set up some environment variables. 05:28.610 --> 05:29.150 Okay. 05:29.150 --> 05:36.170 So when the MySQL container starts up and launches the MySQL app, it needs to give the MySQL instance 05:36.170 --> 05:42.310 running inside of it the environment variables that it needs to properly initialize one of them. 05:43.660 --> 05:48.340 Let's go to the environment variables section to see what we can pass into the app, so that it can 05:48.340 --> 05:49.870 do what we want it to do. 05:49.930 --> 05:52.600 One of them is MySQL database. 05:52.630 --> 05:59.590 This variable is optional, but it allows us to specify the name of the database that we want MySQL 05:59.620 --> 06:01.840 to create when it starts up. 06:01.840 --> 06:07.990 So when the MySQL instance starts up within the container, we want the container to give it an environment 06:07.990 --> 06:10.630 variable named MySQL database. 06:10.630 --> 06:17.050 And that's going to tell the MySQL instance to start up a database called profile management. 06:17.200 --> 06:18.400 All right. 06:19.420 --> 06:26.680 The next environment variable we want to give the MySQL instance when it starts up is MySQL user and 06:26.680 --> 06:28.120 MySQL password. 06:28.120 --> 06:36.050 This basically tells MySQL the credentials that are needed in order to access the MySQL database that 06:36.050 --> 06:47.960 we initialized in this step, so only users named profile user with a certain MySQL password equal to 06:47.960 --> 06:53.250 a profile password are allowed to access the profile management database. 06:53.250 --> 06:57.780 Now there's one more environment variable we need to pass in to the MySQL instance from the container 06:57.780 --> 07:00.960 that runs it, and that's the MySQL root password. 07:00.960 --> 07:04.170 The only reason I'm doing that is because this variable is mandatory. 07:04.170 --> 07:08.760 We need to specify a password for the root superuser account. 07:08.760 --> 07:10.470 So let's just go ahead and do it. 07:10.470 --> 07:11.700 Get it out of the way. 07:11.700 --> 07:14.490 We're just going to say root password. 07:14.490 --> 07:14.760 All right. 07:14.760 --> 07:19.760 We're not actually going to end up using the root uh user, the root super user. 07:19.760 --> 07:26.120 But whatever we need to do this and I think no, we're not done yet. 07:26.810 --> 07:34.820 The last thing we got to do is remember that, um, well, there's nothing to remember because I haven't 07:34.820 --> 07:36.050 explained anything yet. 07:36.140 --> 07:43.010 Uh, MySQL by default persists its data to slash var lib slash MySQL. 07:43.010 --> 07:50.690 So this is the directory within the container where the MySQL instance is going to persist all the data. 07:50.720 --> 07:59.900 By default, what we want to do is redirect any data that gets saved to slash var lib slash MySQL to 07:59.900 --> 08:01.940 the named volume. 08:02.510 --> 08:03.320 Um. 08:03.320 --> 08:06.090 MySQL profile management data. 08:06.090 --> 08:11.790 That way, if we ever destroy the container, all of the data that was saved here within the container 08:11.790 --> 08:15.570 was redirected to the more durable named volume. 08:15.570 --> 08:20.790 That's that is taking up actual space inside of our host machine. 08:20.970 --> 08:22.290 All right. 08:22.290 --> 08:26.250 Now finally, this is just information that we need for later. 08:26.250 --> 08:30.370 MySQL by default runs on port 3306. 08:30.370 --> 08:40.090 So uh, MySQL here, I can comment and say we'll run on container port 3306. 08:40.090 --> 08:43.420 Do we want to map this container port to a host machine port? 08:43.450 --> 08:51.010 No, because I don't anticipate that I'm going to be connecting to this MySQL app from my host machine. 08:51.010 --> 08:58.310 The profile Management API is going to connect to it directly through the Docker network and use the 08:58.310 --> 08:59.750 container port. 08:59.750 --> 09:00.590 All right. 09:00.590 --> 09:04.910 There's no reason to expose a host machine port if we don't need it. 09:05.420 --> 09:06.890 Um, okay. 09:06.890 --> 09:08.000 That's pretty much it. 09:08.000 --> 09:13.850 Now we're ready to set up the, uh, profile management container. 09:13.850 --> 09:24.120 What I want to do is copy the setup from this docker compose YAML, but instead of pulling version one 09:24.120 --> 09:31.620 that we have pushed to Docker Hub, we're going to pull version two that we have stored locally in our 09:31.620 --> 09:33.510 local Docker cache. 09:33.810 --> 09:39.270 So this container is going to be created from the image that we just built, the image that's inside 09:39.270 --> 09:40.710 of our local Docker cache. 09:40.710 --> 09:42.700 We don't have this on Docker Hub yet. 09:42.700 --> 09:43.840 We will later. 09:44.560 --> 09:52.150 Um, everything here is fine, but now we need to provide, uh, the Profile Management API version 09:52.150 --> 09:59.320 two with the environment variables that it needs in order to connect to MySQL. 09:59.350 --> 10:03.850 Let's just copy this over into our Docker compose YAML. 10:07.370 --> 10:10.340 And specify the environment variables. 10:10.340 --> 10:12.440 We start with the host okay. 10:12.440 --> 10:16.550 We're going to set this equal to the container MySQL profile management. 10:16.550 --> 10:23.060 So the host environment variable is going to tell the profile management API where the application is 10:23.060 --> 10:23.630 running. 10:23.630 --> 10:31.320 Once we help it locate where the application is running then we need to tell it the port where the application 10:31.320 --> 10:32.760 is serving requests. 10:32.760 --> 10:36.870 The MySQL app runs on the container port 3306. 10:36.870 --> 10:40.650 So at this point it found the container where the app is running. 10:40.650 --> 10:44.760 It found the port where the application is serving requests. 10:44.760 --> 10:49.440 And now the MySQL instance contains a profile management database. 10:49.440 --> 10:57.010 That's the database that we need to connect to from our profile management application. 11:00.850 --> 11:02.170 All right. 11:02.170 --> 11:10.930 And the credentials needed to connect to that database are where set to be profile user. 11:15.700 --> 11:18.050 And profile password. 11:21.590 --> 11:22.370 Okay. 11:22.370 --> 11:31.430 So now our authentication API has all the information that it needs to locate the MySQL instance, locate 11:31.430 --> 11:38.600 which port it's serving requests on, authenticate against the database where we want to write and read 11:38.600 --> 11:39.470 data. 11:39.470 --> 11:44.430 And it's going to use all of this information to connect to my SQL. 11:44.430 --> 11:50.130 This should work because both containers are running inside of the same network. 11:50.130 --> 11:51.570 Let's try it out. 11:51.990 --> 11:54.750 We're going to say docker compose up. 12:03.570 --> 12:04.260 And you know what? 12:04.260 --> 12:08.920 One other thing I could do is say depends on the profile management container. 12:08.920 --> 12:13.480 Depends on the MySQL profile management container. 12:14.410 --> 12:15.430 All right. 12:16.150 --> 12:16.900 Um. 12:20.890 --> 12:26.980 So after MySQL profile management is done initializing the database and all that, then the profile 12:26.980 --> 12:30.080 management application is able to connect to it. 12:30.080 --> 12:31.190 It tries to do so. 12:31.190 --> 12:35.000 At first it fails, but I programmed the application to be resilient. 12:35.000 --> 12:37.010 It connects to it eventually. 12:37.760 --> 12:39.380 All right. 12:40.820 --> 12:46.400 Now we're going to do the same thing for the PostgreSQL database. 12:47.480 --> 12:53.410 So the application that's going to try to connect to a PostgreSQL database is product inventory which 12:53.410 --> 13:00.100 means what I'm going to do is set up a container called Postgres Product Inventory. 13:00.610 --> 13:06.430 And the image from which we're going to create this container. 13:08.110 --> 13:08.980 Um. 13:11.830 --> 13:12.730 You know what? 13:12.730 --> 13:15.130 Let's just say Postgres latest. 13:15.130 --> 13:16.060 Why not? 13:18.010 --> 13:18.580 All right. 13:18.580 --> 13:20.710 I don't have a specific version in mind. 13:20.740 --> 13:22.270 Container name. 13:22.660 --> 13:25.270 Postgres product inventory. 13:25.960 --> 13:27.220 All right. 13:27.490 --> 13:33.880 And now we need to specify the environment variables that the container needs to pass into its underlying 13:33.880 --> 13:39.940 Postgres application so that it can initialize a database and also set up the credentials needed to 13:39.940 --> 13:45.240 authenticate against that database by whatever service tries to connect to it. 13:46.050 --> 13:50.580 Okay, so, uh, obviously I'm not a magician. 13:50.580 --> 13:53.370 I can't predict what these environment variables are. 13:53.370 --> 13:55.980 I need to go to the documentation just like you. 13:55.980 --> 13:58.320 So let's go to the environment variables. 13:58.500 --> 14:08.420 Um, one of these here we see Postgres user Postgres uh db and postgrespassword. 14:08.420 --> 14:11.600 We've got all the information we need to start setting this up. 14:11.600 --> 14:19.730 So back inside of my Postgres product inventory container, I'm going to pass uh, three environment 14:19.730 --> 14:24.050 variables into uh, the underlying app. 14:24.050 --> 14:28.070 So Postgres db let me just copy it over. 14:30.810 --> 14:38.520 We want, uh, the Postgres instance to initialize a database called product inventory. 14:39.750 --> 14:40.770 All right. 14:42.930 --> 14:54.490 And the credentials needed to authenticate against that database, the Postgres user will be inventory 14:54.490 --> 14:55.180 user. 14:55.180 --> 15:01.120 So anyone that has a user of inventory user and a password. 15:03.190 --> 15:08.260 Of inventory password will be able to access the database successfully. 15:09.100 --> 15:09.940 All right. 15:09.940 --> 15:20.600 Now we need to redirect, um, the path in the container where the data is saved to a named volume. 15:20.600 --> 15:29.780 So if I go here and say slash var the default path where data is going to be saved within the container. 15:29.780 --> 15:32.240 Within the Postgres container is the following. 15:33.470 --> 15:39.560 For durability, we need to redirect the data that gets saved here to the named volume. 15:39.560 --> 15:42.760 Postgres product inventory data. 15:43.480 --> 15:44.680 All right. 15:44.680 --> 15:52.450 And now, by default, uh, PostgreSQL runs on the port to seven something. 15:55.030 --> 15:57.850 Um, PostgreSQL port. 15:57.850 --> 15:59.620 We're going to need this information. 15:59.620 --> 16:00.400 Never mind. 16:00.400 --> 16:02.620 It's port 5432. 16:02.830 --> 16:09.940 So PostgreSQL is going to run on port 5432. 16:15.190 --> 16:15.610 All right. 16:15.610 --> 16:22.690 So now what I can do is set up the service that will actually interact with this with this database. 16:22.840 --> 16:27.850 And that's going to be uh product inventory. 16:27.850 --> 16:30.440 So let's go to this docker-compose.yaml. 16:30.560 --> 16:38.660 Copy over the following again make sure the spacing is consistent. 16:38.660 --> 16:41.300 So this should be at the level of services. 16:41.300 --> 16:41.810 All right. 16:41.810 --> 16:47.720 We want to pull product inventory version 2.0.0. 16:47.750 --> 16:52.160 The image that we just built that's in our local Docker cache. 16:52.340 --> 16:59.820 And we want to give the updated product inventory version two with a bunch of environment variables. 16:59.820 --> 17:01.290 What will these variables be? 17:01.290 --> 17:01.980 The following. 17:01.980 --> 17:07.950 These are the variables that our application is going to rely on in order to establish connection with 17:07.950 --> 17:09.960 a PostgreSQL database. 17:10.890 --> 17:18.490 So let's go ahead and temporarily copy these variables over here for reference. 17:19.420 --> 17:20.230 Um. 17:22.810 --> 17:25.930 The first variable is Postgres host the host. 17:25.930 --> 17:32.770 Once we pass it into the underlying app, it's going to help it locate the container where PostgreSQL 17:32.770 --> 17:33.730 is running. 17:33.730 --> 17:37.330 That container is called Postgres product inventory. 17:37.330 --> 17:44.780 All right, the port tells our Product inventory API. 17:44.780 --> 17:48.290 Once it locates the container that the app is running in. 17:48.290 --> 17:53.840 Now, it needs to know the port in the container where Postgres is serving requests. 17:53.840 --> 17:56.270 That's port 5432. 17:56.300 --> 17:59.210 I was able to determine that by googling it. 17:59.720 --> 18:08.910 Um, next we specify the database that we want to connect to within our PostgreSQL instance. 18:08.940 --> 18:12.450 That database is called product inventory. 18:12.450 --> 18:17.610 This was the database that was initialized within PostgreSQL. 18:17.640 --> 18:24.360 Now I need to specify the credentials needed to authenticate against that database, and therefore be 18:24.360 --> 18:26.040 able to save data to it. 18:26.070 --> 18:33.050 Those were set to be inventory user as well as inventory password. 18:34.310 --> 18:35.360 All right. 18:36.620 --> 18:44.540 And now I've given my product inventory application all of the information that it needs to connect 18:44.540 --> 18:52.400 to this PostgreSQL instance PostgreSQL instance and be able to authenticate against its database. 18:52.400 --> 18:56.150 So I'm going to stop the runtime. 18:57.200 --> 19:03.320 Control C then say docker compose down to make sure things get fully removed. 19:03.320 --> 19:05.090 Then I'm going to rerun. 19:05.120 --> 19:05.990 Docker. 19:05.990 --> 19:13.970 Uh, before I do that let me just say here it depends on Postgres product inventory. 19:15.110 --> 19:15.800 Okay. 19:15.800 --> 19:17.120 Let me make sure everything's good. 19:19.560 --> 19:21.360 Everything is fine. 19:22.230 --> 19:23.070 All right. 19:23.070 --> 19:24.690 Famous last words. 19:24.720 --> 19:26.520 Docker compose up. 19:35.550 --> 19:39.900 So the profile management service was able to connect to my SQL. 19:39.930 --> 19:42.130 What about the product inventory service? 19:42.160 --> 19:45.610 Was it able to connect to PostgreSQL? 19:48.250 --> 19:52.930 Um, I don't see any error messages if you do. 19:52.930 --> 19:58.330 By the way, I programmed the application to retry connecting to it every five seconds. 19:58.330 --> 20:05.600 So if you see a failed message, as long as that failed message doesn't persist or it doesn't keep printing, 20:05.600 --> 20:10.010 that means your product inventory app was successfully connected to Postgres. 20:10.010 --> 20:15.560 But if you keep saying failed, retrying retrying in five seconds, if that keeps printing, that means 20:15.560 --> 20:16.700 it didn't connect. 20:16.700 --> 20:18.410 But I don't see anything. 20:18.410 --> 20:20.090 So we're good. 20:21.020 --> 20:24.530 As the programmer of this application, I think we're all good. 20:24.530 --> 20:28.460 Profile management struggled a bit at first, but then it was able to connect. 20:28.460 --> 20:29.640 All right. 20:30.930 --> 20:38.010 And now what I'm going to do is do all of these applications at once. 20:38.010 --> 20:41.010 Product catalog support, shipping and order management. 20:41.040 --> 20:42.060 Okay. 20:42.630 --> 20:54.260 I'm going to go ahead and start by creating the MongoDB instance that will be responsible for storing 20:54.260 --> 21:00.470 data for the order management microservice that's going to this container is going to be created from 21:00.470 --> 21:01.760 the image Mongo. 21:01.790 --> 21:03.500 I won't specify a version. 21:03.500 --> 21:10.610 Let's just use the latest one container name Mongo DB order management. 21:12.050 --> 21:13.370 All right. 21:14.540 --> 21:16.520 Um, I don't want to specify. 21:16.550 --> 21:22.850 I don't want to map the container port to a host machine port, but just know that the MongoDB instance 21:22.850 --> 21:27.050 that's going to be running within this container will use. 21:30.500 --> 21:32.390 Container port 21:32.600 --> 21:38.450 27017, I believe. 21:39.260 --> 21:41.610 Um, let me just validate this. 21:42.900 --> 21:43.620 Yep. 21:45.540 --> 21:46.710 All right. 21:48.570 --> 21:51.120 And here we can just say volumes. 21:51.120 --> 21:54.840 We're not going to need to set any environment variables in Mongo. 21:54.870 --> 22:00.870 Our apps are going to be able to connect to it fairly seamlessly by virtue of just providing a host 22:00.870 --> 22:02.010 and a port. 22:02.280 --> 22:06.910 We could set up authentication and all that within Mongo, but since we're not obliged, we're not going 22:06.910 --> 22:07.390 to do it. 22:07.390 --> 22:14.350 So anyways, in, uh, Mongo by default is going to save its data to slash data slash DB. 22:14.350 --> 22:23.230 We're just going to redirect all that data to, um, this named volume mongo DB order management data. 22:23.230 --> 22:25.120 Let me make sure I got it correctly. 22:26.200 --> 22:27.070 I did. 22:28.300 --> 22:28.900 All right. 22:28.930 --> 22:38.720 Now we connect the order management application to this to, uh, the MongoDB instance running inside 22:38.720 --> 22:39.620 of this container. 22:39.620 --> 22:44.150 So we'll go back to the docker-compose.yaml over here. 22:45.050 --> 22:46.640 Copy the following. 22:48.530 --> 22:53.790 But make sure that we're pulling version two that we just recently built in this video. 22:54.180 --> 23:00.420 And now if you were to look inside the Order Management API, uh, the only other, the only environment 23:00.420 --> 23:07.710 variables that it needs, the only environment variable that it needs in order to connect to, uh, 23:07.710 --> 23:10.080 MongoDB is the following. 23:10.350 --> 23:20.500 But what we're going to have to do is set this equal to the scheme MongoDB followed by slash slash the 23:20.500 --> 23:22.870 container name MongoDB order management. 23:22.870 --> 23:28.480 So the host is always the container name because that's where the app is running. 23:28.480 --> 23:31.840 The host allows you to find where the app is running. 23:31.840 --> 23:39.130 The port where the app is serving requests within this container is 27017. 23:39.130 --> 23:41.050 And then we say slash. 23:41.350 --> 23:48.310 That's going to be order management basically telling it connect to a database called order management. 23:48.310 --> 23:49.210 All right. 23:49.210 --> 23:56.140 And finally here we say depends on the MongoDB order management service. 23:57.670 --> 23:58.990 All right. 23:59.380 --> 24:04.330 Um I think we're good for order management. 24:04.330 --> 24:05.930 Let's go ahead and try it out. 24:06.080 --> 24:08.300 Docker compose down. 24:17.210 --> 24:19.250 Docker compose up. 24:41.310 --> 24:52.500 Oh, um, I think the image for order management is doesn't actually install the dependencies inside 24:52.500 --> 24:55.510 the image, so it does it during the runtime. 24:56.410 --> 24:57.700 Um, whatever. 24:57.700 --> 24:58.180 It's okay. 24:58.180 --> 25:00.160 We can wait a little bit. 25:03.940 --> 25:10.570 But our Spring Boot app, as you can see, is able to connect to the MongoDB application. 25:10.570 --> 25:15.490 This environment variable here overrode the following property. 25:15.490 --> 25:22.400 We set this property equal to the following connection, which means our Spring Boot app is able to 25:22.400 --> 25:29.780 connect to the Mongo application inside this container at that port, and will read and write to a database 25:29.780 --> 25:31.910 called Order Management. 25:31.910 --> 25:33.170 Beautiful. 25:33.170 --> 25:35.030 Did we do the product catalog yet? 25:35.030 --> 25:36.350 We didn't. 25:36.530 --> 25:37.280 Okay. 25:37.280 --> 25:38.450 What I'm going to do. 25:40.550 --> 25:45.000 Is set up a MongoDB container for the product catalog. 25:45.060 --> 25:46.380 So. 25:51.690 --> 25:56.670 We'll say MongoDB product catalog. 25:58.260 --> 26:05.860 This container will be created from the Mongo image that's going to run a mongo application. 26:05.860 --> 26:09.730 The container that will run the application is MongoDB product catalog. 26:10.210 --> 26:12.700 Um, the volume. 26:15.310 --> 26:20.680 Is MongoDB product catalog data. 26:23.020 --> 26:33.740 And what that's going to do is, Um, so all the data from Mongo is going to be saved to this path in 26:33.740 --> 26:34.220 the container. 26:34.220 --> 26:39.320 We want to redirect it to the named volume MongoDB product catalog data. 26:39.530 --> 26:40.220 All right. 26:40.220 --> 26:49.850 And if we look at the product catalog itself, it expects two environment variables. 26:49.850 --> 26:54.760 So it expects a MongoDB host and a MongoDB port. 26:54.760 --> 27:01.270 So depending on the application and how it expects to receive the environment variables, you need to 27:01.270 --> 27:03.430 modify your docker-compose.yaml. 27:03.430 --> 27:10.030 So for the Spring Boot app, it expected an environment variable that has the entire URL. 27:10.030 --> 27:15.820 In this application it expects two environment variables a host and a port, and it's going to embed 27:15.820 --> 27:19.250 those into its URL that it already made. 27:19.250 --> 27:25.760 But regardless of the application, the URL is always the same MongoDB followed by a host followed by 27:25.760 --> 27:26.510 a port. 27:26.510 --> 27:32.390 And it also expects the database name that it will read and write data to. 27:32.660 --> 27:33.620 All right. 27:34.040 --> 27:39.770 Um, so here what we can do is say, um, well, we're going to copy over. 27:42.530 --> 27:49.250 The product catalog container definition from the previous Docker compose file. 27:49.250 --> 27:56.210 Make sure to, uh, fix the spacing so that this is at the level of services we want to pull, version 27:56.210 --> 27:58.400 two, the one we just built. 27:58.640 --> 28:04.820 And then we provide the environment variables that the app needs in order to connect. 28:07.540 --> 28:08.800 To Mongo. 28:09.490 --> 28:10.720 So these are the variables. 28:10.720 --> 28:13.270 Let's just copy them over here for reference. 28:13.540 --> 28:21.070 So it relies on a variable called Mongo host, which is going to be the container where Mongo is running. 28:21.070 --> 28:29.050 Once the app is able to locate the container where the Mongo app is running, then we give it the port 28:29.050 --> 28:33.700 within that container where it's going to be serving requests. 28:33.700 --> 28:40.210 Mongo by default serves requests on the container port to 7017. 28:43.840 --> 28:52.330 And then the MongoDB database that we're going to try connecting to, we can actually create any database 28:52.330 --> 28:53.020 that we want. 28:53.020 --> 28:58.080 And the JavaScript application is going to use that information to connect to a database. 28:58.080 --> 29:00.630 Let's just call it product catalog. 29:00.630 --> 29:07.440 So MongoDB is flexible enough to create this database if it doesn't already exist, if the app tries 29:07.440 --> 29:08.400 accessing it. 29:10.800 --> 29:12.180 All right. 29:12.810 --> 29:15.960 Um, that's the last one I'm going to do the last. 29:15.990 --> 29:18.300 The rest I'm going to leave up to you. 29:18.300 --> 29:21.150 But I will show you what the code should look like. 29:22.740 --> 29:24.060 Docker compose down. 29:24.060 --> 29:25.560 Docker compose up. 29:31.530 --> 29:35.130 I really wish this image. 29:37.560 --> 29:38.190 Um. 29:40.050 --> 29:47.470 Pulled the dependencies during the image building phase, not during container runtime, but whatever. 29:49.240 --> 29:50.230 It's the last lesson. 29:50.230 --> 29:51.160 It doesn't matter. 29:51.160 --> 29:52.270 We can wait a bit. 29:52.600 --> 29:59.260 It seems like everything was able to successfully connect to their respective databases. 29:59.260 --> 30:02.590 Let me make sure the product catalog one did as well. 30:03.250 --> 30:05.590 Product catalog connected to MongoDB. 30:05.690 --> 30:06.800 Perfect. 30:07.010 --> 30:14.300 All right, so I believe there are two more databases you need to create alongside two applications 30:14.300 --> 30:16.430 that need to connect to those databases. 30:16.430 --> 30:18.200 So your task. 30:18.350 --> 30:21.110 This is actually good for you to challenge yourself. 30:21.110 --> 30:26.900 Your task is going to be to create those two MongoDB containers. 30:26.900 --> 30:27.770 All right. 30:27.770 --> 30:34.650 And then you're going to look inside of the two applications that need to connect to the MongoDB containers. 30:34.650 --> 30:41.610 Look at the environment variables that the applications rely on so that it connects to a certain database. 30:41.850 --> 30:43.350 Uh, set that up. 30:43.350 --> 30:44.520 Pause the video. 30:44.520 --> 30:45.870 Once you're done. 30:46.260 --> 30:48.120 Um, I'll show you the solution. 30:48.120 --> 30:48.990 Okay. 30:52.530 --> 30:53.070 All right. 30:53.070 --> 30:55.180 So here is what I came up with. 30:55.240 --> 31:01.030 Um, contact support relied on three environment variables. 31:01.030 --> 31:08.170 If you were to look inside the application and then shipping and handling only relied on one environment. 31:08.170 --> 31:12.220 Variables that defines the scheme, the host and the port. 31:12.220 --> 31:19.440 You'll notice if you went inside the code that it already defines that it wants to connect to or create 31:19.440 --> 31:22.380 in this case, upon connecting to Mongo. 31:22.380 --> 31:25.470 So you only need it to define the host and the port. 31:25.470 --> 31:31.560 That database was already hard coded, so it's just extra practice for you to actually look inside the 31:31.560 --> 31:36.450 code base and make sense of what it needs and what you need to provide from your container. 31:36.450 --> 31:41.370 So that's it for shipping and handling MongoDB shipping. 31:41.370 --> 31:47.700 We have all of our applications connected to the databases that they need to connect to. 31:47.730 --> 31:51.720 We have everything being backed up into volumes. 31:52.260 --> 31:58.500 Uh, the last service that remains unchanged is the e-commerce UI. 31:59.190 --> 32:01.350 So let's put that over here. 32:04.140 --> 32:05.310 And that's it. 32:06.610 --> 32:10.660 We should now be ready to. 32:13.000 --> 32:14.260 I think we're done, guys. 32:17.950 --> 32:23.860 Uh, product catalog depends on MongoDB product catalog. 32:25.870 --> 32:28.270 Order management depends on MongoDB. 32:28.270 --> 32:29.140 Order management. 32:29.140 --> 32:32.420 Product inventory depends on the following. 32:34.910 --> 32:37.130 All right, let's do it. 32:40.070 --> 32:49.970 Docker compose down ecommerce UI depends on an undefined service contact support team. 32:50.930 --> 32:53.570 So this is contact support team. 32:53.570 --> 32:55.520 This is contact support. 32:55.610 --> 32:57.020 My apologies. 32:59.810 --> 33:02.570 Like I said things never work out from the get go. 33:02.870 --> 33:04.220 It is what it is. 33:05.180 --> 33:06.830 Make sure the volumes are right. 33:07.340 --> 33:08.030 We're good. 33:23.640 --> 33:29.610 Now that pesky spring boot up clock cluttering up all of our logs. 33:29.700 --> 33:36.420 Uh, feel free to take it upon yourself to change this Docker file so that it installs the dependencies 33:36.420 --> 33:38.490 during the image building phase. 33:38.520 --> 33:45.640 That way, the spring boot run command doesn't need to do it as the container, uh, during the containers 33:45.640 --> 33:46.390 runtime. 33:46.390 --> 33:47.230 All right. 33:48.220 --> 33:51.550 So I didn't see any errors while all of this was happening. 33:51.550 --> 33:55.720 I believe everything should have been started up correctly. 33:56.230 --> 34:03.970 There is only one way to test this, which is by going over to localhost 4000. 34:04.660 --> 34:05.230 All right. 34:05.230 --> 34:06.330 Fingers crossed. 34:06.330 --> 34:10.230 We're going to log out and we're going to create an account. 34:11.130 --> 34:12.450 We'll say Bob. 34:12.450 --> 34:21.870 Bill, address 123 private road postal code B1B b2b email bill gmail.com. 34:21.870 --> 34:22.590 Password. 34:22.590 --> 34:23.670 Love. 34:23.820 --> 34:25.020 All right. 34:25.020 --> 34:26.340 Beautiful. 34:26.340 --> 34:29.370 So authentication works. 34:29.880 --> 34:37.620 Um, if it didn't, um, if it showed a failure, that means it had a problem in connecting to its database. 34:38.130 --> 34:39.630 Um, a sign in. 34:41.910 --> 34:42.960 Product catalog. 34:42.960 --> 34:44.340 Everything works. 34:44.340 --> 34:45.210 Shipping. 34:45.210 --> 34:46.170 Everything works. 34:46.170 --> 34:47.580 Profile management. 34:47.580 --> 34:48.690 We already saw that. 34:48.690 --> 34:49.410 That worked. 34:49.410 --> 34:50.790 Subject. 34:50.790 --> 34:51.570 Um. 34:52.660 --> 34:53.980 Trouble? 34:54.100 --> 34:58.480 Trouble buying a backpack? 34:58.780 --> 34:59.770 Submit. 34:59.770 --> 35:01.180 Everything works. 35:01.180 --> 35:02.740 Inventory management. 35:02.740 --> 35:03.970 Beautiful. 35:04.270 --> 35:07.720 Uh, let's try ordering a product at the cart. 35:08.380 --> 35:09.550 Amazing. 35:10.450 --> 35:15.730 Okay, um, we're pretty much done, guys. 35:15.730 --> 35:22.460 Uh, the last thing that I want you to do Docker compose down. 35:23.000 --> 35:26.090 So we have all of these Docker images. 35:26.990 --> 35:30.950 Um, we have Mongo, MySQL and Postgres as well. 35:30.950 --> 35:31.970 Ignore these. 35:31.970 --> 35:36.950 I want you to push all of these over to Docker Hub. 35:37.070 --> 35:38.120 Okay. 35:38.120 --> 35:45.750 Once you do I want you to paste in the updated Readme to each repository. 35:45.750 --> 35:46.650 Overview. 35:46.680 --> 35:53.520 The updated Readme should include a section for the version 2.0.0 update. 35:53.550 --> 35:54.390 All right. 35:54.390 --> 36:03.990 Once you push version two, I want you to rebuild all of these images and tag them as latest, and then 36:03.990 --> 36:06.910 push those onto Docker Hub as well. 36:06.910 --> 36:14.620 So each one of your services should have a version of one where everything happens in memory. 36:14.650 --> 36:21.820 A version of two where, uh, the app is actually connected to a database, and a version of latest, 36:21.820 --> 36:24.310 which is effectively version two. 36:24.700 --> 36:34.130 Once you have all of that set up, congratulations on being able to containerize a fully loaded e-commerce 36:34.130 --> 36:40.610 application whereby each microservice is running alongside a database. 36:40.640 --> 36:46.880 We have a flask microservice, we have NodeJS microservices, we have a spring boot microservice, a 36:46.880 --> 36:54.150 go microservice, all of them connected to different types of databases Mongo, Postgres, MySQL. 36:54.180 --> 36:57.990 We've done a lot with Docker in this course. 36:57.990 --> 37:02.460 I hope you're proud of yourself, and I hope you were able to take a lot from this lesson. 37:02.460 --> 37:07.830 I should be creating a Kubernetes course in the next month or two, so look out for that. 37:07.830 --> 37:12.720 And, uh, thank you so much for taking this course and trusting me with your education. 37:12.720 --> 37:14.400 I'll see you in the next one.