WEBVTT

00:00.170 --> 00:01.910
How about we start with great submission portal.

00:01.910 --> 00:06.920
So go to the directory ten starter code and then go to Great Submission Portal.

00:07.760 --> 00:10.070
And let's begin okay.

00:10.070 --> 00:16.550
So the purpose of this lesson is we need to basically rebuild images from our grid submission API and

00:16.550 --> 00:17.810
our grid submission portal.

00:17.810 --> 00:19.490
You might be wondering why.

00:19.490 --> 00:24.620
And the reason is we've been using the traditional Docker build command to build images.

00:24.620 --> 00:30.680
And the reason why this command is limited is because it only builds the image for a single architecture.

00:31.100 --> 00:36.830
So to give you an example, I'm using Mac with Apple Silicon, and by using the docker build command

00:36.830 --> 00:43.850
on it, Docker is going to default to binding this image for the ARM architecture ARM, let's call it.

00:43.850 --> 00:49.010
And most cloud providers like AWS or Heroku in this case, which is what we're going to use.

00:49.010 --> 00:53.030
They currently run on the x86 64 architecture.

00:53.030 --> 00:58.160
So the container that I build for ARM may not run on these providers.

00:58.280 --> 01:00.840
If you build the same Docker image on windows.

01:00.870 --> 01:07.080
Docker will default to binding this image for the x86 64 architecture, which should be compatible with

01:07.080 --> 01:09.030
most cloud providers that support it.

01:09.030 --> 01:15.270
The take home message is that because the Docker build command only builds images for a single architecture,

01:15.270 --> 01:21.090
it kind of limits the compatibility of our container with cloud providers that support different architectures.

01:21.090 --> 01:26.430
And so to ensure maximum compatibility and portability, which is what we love about Docker, we can

01:26.430 --> 01:30.690
use the command Docker build X build.

01:30.690 --> 01:35.730
So this is an enhanced build command because it allows you to build images for multiple architectures

01:35.730 --> 01:38.640
using a single command, which is really, really cool.

01:39.000 --> 01:44.940
So by building these Multi-architecture images, you can deploy your containers to a wider range of

01:44.940 --> 01:49.470
cloud providers and environments without having to worry about the underlying architecture that they

01:49.470 --> 01:50.280
support.

01:50.400 --> 01:57.750
Okay, so before we actually use Docker build X, what we need to do is set up a builder.

01:57.750 --> 01:59.980
So Docker build x create dash dash.

01:59.980 --> 02:01.900
Name my builder.

02:02.950 --> 02:03.520
Okay.

02:03.520 --> 02:04.900
And then I'm going to use this builder.

02:04.900 --> 02:08.410
So docker build x use my builder.

02:08.650 --> 02:09.430
Cool.

02:09.460 --> 02:15.130
Now that I've got that set up I can say docker build x build.

02:15.130 --> 02:22.840
We're going to build an image that's compatible with the platform Linux slash amd64.

02:22.960 --> 02:30.070
So amd64 refers to the x86 64 architecture which is the most common architecture for Linux based systems.

02:30.070 --> 02:35.740
And it is widely supported by cloud platforms like AWS or in this case, Heroku, which is what we're

02:35.740 --> 02:37.120
going to use in this course.

02:37.120 --> 02:44.080
To keep the deployment process straightforward, we're going to make the image compatible with ARM 64.

02:44.830 --> 02:51.190
This refers to the ARM 64 architecture, which is the most commonly used in ARM based servers and cloud

02:51.190 --> 02:52.030
instances.

02:52.060 --> 02:56.140
We're also going to make it compatible with Linux Armv7.

02:56.170 --> 03:04.790
This armv7 architecture is commonly used in some older ARM based services or devices, I should say,

03:04.790 --> 03:10.790
but it's good to ensure that whatever image we build is compatible with as many platforms as it needs

03:10.790 --> 03:12.020
to be.

03:12.530 --> 03:14.150
All right.

03:14.150 --> 03:18.800
And now we can build an image so we can say dash t.

03:18.920 --> 03:24.080
We can build an image called we're going to call it our slim 087.

03:24.080 --> 03:34.700
So your Docker Hub username followed by grade submission API multi arc and actually not API portal because

03:34.700 --> 03:36.860
we're at the great submission portal directory.

03:36.890 --> 03:39.800
Great submission portal multi arc.

03:39.980 --> 03:40.700
All right.

03:40.700 --> 03:48.200
And upon building an image from the docker file at the current directory we're going to say dash dash

03:48.200 --> 03:48.470
push.

03:48.470 --> 03:54.230
So this is really cool because as we're building the image it's going to automatically push it to Docker

03:54.260 --> 03:54.710
Hub.

03:54.710 --> 03:58.500
If the build process is successful, then I'm going to say dot.

03:58.500 --> 04:02.370
So build an image from the docker file at the current directory.

04:02.370 --> 04:06.120
I think everything here should be fine and enough talk.

04:06.120 --> 04:07.050
Let's just do it.

04:07.890 --> 04:16.110
This should take quite some time, because we're building this image and repeating everything so that

04:16.110 --> 04:19.710
it is compatible with many different platforms.

04:20.130 --> 04:23.700
Should take about 5 to 7 minutes, I should say.

04:24.390 --> 04:27.390
So I might see you in a bit.

04:36.000 --> 04:37.470
All right, let's clear the output.

04:37.470 --> 04:45.450
And, um, over here we're not going to use environment variables because the location of our MongoDB

04:45.450 --> 04:47.490
instance is pretty fixed.

04:47.490 --> 04:55.330
So I'm just going to paste the connection URL right over here Okay.

04:55.600 --> 05:03.340
Now upon this application connecting to the MongoDB cluster, anything that we save, any data that

05:03.340 --> 05:09.220
we save is going to be saved to a default database that is going to be created for us.

05:09.220 --> 05:18.010
Instead of a default database being used, we can set our own database name so we can have every record

05:18.040 --> 05:21.250
saved to a database called grades DB.

05:21.460 --> 05:22.120
All right.

05:22.120 --> 05:25.090
If you don't want to specify a database name, that's fine.

05:25.090 --> 05:28.450
Everything that we save will just be saved to a default database created for us.

05:28.450 --> 05:32.710
But I want a specific database name and that's it.

05:32.740 --> 05:39.820
We're going to use the same command that we used to build the grade submission portal image to build

05:39.820 --> 05:42.340
the grade submission API image.

05:42.370 --> 05:43.510
All right.

05:43.870 --> 05:47.800
Um, pretty sure we've got everything covered.

05:50.110 --> 05:50.980
Let's do it

05:53.510 --> 05:56.000
So this should take quite a long time.

05:56.300 --> 06:02.150
Really make sure that your connection URL is good, because you don't want to realize you've made a

06:02.150 --> 06:02.690
mistake.

06:02.690 --> 06:04.790
After building this image.

06:04.790 --> 06:09.140
It's going to take like ten minutes to run this one from experience.

06:09.410 --> 06:12.230
So I'll see you in ten minutes.

06:13.790 --> 06:14.240
All right.

06:14.240 --> 06:17.600
I just came back, made a cup of coffee, and it's still going.

06:18.350 --> 06:20.060
It looks like it's done.

06:20.480 --> 06:24.230
Uh, building the image now.

06:24.230 --> 06:26.390
It's just pushing it over to Docker Hub.

06:26.420 --> 06:27.110
Okay.

06:27.140 --> 06:28.070
Not bad.

06:28.580 --> 06:31.220
That shouldn't take more than 20s.

06:31.250 --> 06:31.760
All right.

06:31.760 --> 06:33.200
Yeah, both of them are pushed.

06:33.230 --> 06:34.370
Let me refresh.

06:37.460 --> 06:38.480
Sweet.

06:39.080 --> 06:42.770
All right, so pause the video until yours have been built and pushed.

06:42.800 --> 06:45.650
Now I'm just gonna clear the output.

06:46.880 --> 06:52.010
And what I want to do is test the connection between the great submission API that's going to be running

06:52.010 --> 06:58.440
inside of a container, and the MongoDB cluster that's hosted by a database service.

06:58.440 --> 07:03.600
We need to make sure that connection works before we can deploy this container over to the cloud.

07:04.350 --> 07:05.460
Um, okay.

07:05.460 --> 07:12.870
So docker uh, run dash dash m dash dash name.

07:12.870 --> 07:15.000
We'll call it grade submission API.

07:16.680 --> 07:28.380
Um, we're going to create a container from the image are slim 087 slash grade submission API multi

07:28.380 --> 07:28.950
arc.

07:28.980 --> 07:30.450
Let me just copy this.

07:31.410 --> 07:34.020
Don't feel like making any typos.

07:35.130 --> 07:37.980
I'm really hoping this works because that took like 20 minutes.

07:38.970 --> 07:39.510
All right.

07:39.540 --> 07:40.470
That should be it.

07:45.600 --> 07:48.450
Did I misspell the password I love you underscore 52.

07:48.480 --> 07:48.660
No.

07:48.660 --> 07:53.950
We're good, we're good Fingers crossed.

07:55.180 --> 07:56.140
Sweet.

07:56.170 --> 07:59.440
So if all you get is great, service is running on port 3000.

07:59.470 --> 08:01.570
That means it was able to connect successfully.

08:01.570 --> 08:05.860
Now, before we move on to the next video where we deploy everything to the cloud, I want to test this

08:05.860 --> 08:06.220
out.

08:06.220 --> 08:10.900
So there's no point creating a Docker compose file, because we're just going to be testing this out

08:10.900 --> 08:11.320
once.

08:11.320 --> 08:13.060
Let's say Docker network.

08:13.060 --> 08:14.740
Create my network.

08:15.820 --> 08:16.480
All right.

08:16.480 --> 08:22.540
And let's run this container on the network.

08:23.770 --> 08:25.000
My network.

08:27.790 --> 08:29.260
We have to remove it.

08:29.320 --> 08:33.160
Um, for some reason the dash dash RM didn't do anything.

08:33.160 --> 08:39.790
In this case, whatever, uh, cannot remove, we'll say dash f to force it.

08:39.910 --> 08:40.300
Okay.

08:40.330 --> 08:41.050
Now we're good.

08:41.050 --> 08:42.040
We'll try this again.

08:42.040 --> 08:44.020
Run it on this network.

08:46.360 --> 08:49.840
All right, so taking note of the container name.

08:49.840 --> 08:51.230
Great grade submission API.

08:51.260 --> 08:55.070
We can create another container for the grade submission portal.

08:55.070 --> 09:01.490
So docker run network my network dash dash dash dash name.

09:01.490 --> 09:03.740
We'll call it grade submission portal.

09:04.610 --> 09:11.570
We'll say dash E, so it expects an environment variable from its container in order to connect to the

09:11.570 --> 09:14.150
grade submission API running on the same network.

09:14.240 --> 09:21.620
So dash e um, so the grade submission API in this case is going to be the full URL.

09:21.710 --> 09:24.020
So that's going to equal HTTP.

09:25.610 --> 09:30.560
The host is going to be the container name where the grade submission API is running.

09:30.560 --> 09:31.310
So that's great.

09:31.310 --> 09:32.450
Submission API.

09:32.480 --> 09:37.190
The port is where the application is going to be serving requests within the container.

09:37.190 --> 09:41.510
So it's going to be serving requests on container port.

09:41.900 --> 09:45.500
The API is going to be serving requests on container port 3000.

09:47.090 --> 09:52.530
And we needed the slash grades path, remember, because that's a path where it's serving requests and

09:52.530 --> 09:53.430
endpoint.

09:53.430 --> 10:03.450
And now we can create a container out of our Docker image or a slim 087 slash to create submission portal

10:03.450 --> 10:04.860
Multiarch.

10:09.240 --> 10:11.040
Let's do a port mapping.

10:11.040 --> 10:18.150
So after setting the environment variable we'll say dash p 5001 5001.

10:18.150 --> 10:22.830
Because I'm pretty sure that app dot Pi is serving requests on container port 5001.

10:22.860 --> 10:23.580
All right.

10:23.610 --> 10:24.720
Let's try it out now.

10:27.720 --> 10:31.650
Okay I'm excited localhost 5001.

10:31.950 --> 10:37.830
We'll say Harry we'll give him a 94 in potions.

10:37.920 --> 10:45.030
So we've got two containers talking to each other and one container communicating with an external database.

10:45.060 --> 10:45.960
All right.

10:45.990 --> 10:49.630
Now it seems to have worked beautifully.

10:49.630 --> 11:00.700
If I go to my cluster and I go to browse collections, I can see that Harry potions 94 was saved to

11:00.730 --> 11:01.780
MongoDB.

11:02.170 --> 11:03.160
Beautiful.

11:03.160 --> 11:08.320
So now I've got my database hosted using a database service.

11:08.320 --> 11:12.340
I've got my two containers that are able to talk to each other seamlessly.

11:12.340 --> 11:15.460
One of the containers is able to communicate with this database.

11:15.460 --> 11:21.040
I've got everything I need to deploy these two containers over to Heroku.

11:21.070 --> 11:27.340
Now, the beauty about Docker containers is that no matter where you deploy them, the underlying application

11:27.340 --> 11:33.250
we know is going to run reliably, because what's inside the container is just the application and only

11:33.250 --> 11:36.190
the resources that the app needs in order to run.

11:36.370 --> 11:41.680
In the next video, you're going to see firsthand just how easy it is to deploy containers to the cloud.

11:41.710 --> 11:43.090
All right, we're done.

11:43.090 --> 11:43.720
The hard part.

11:43.750 --> 11:45.610
Now it's on to the fun part