How about we start with great submission portal.
So go to the directory ten starter code and then go to Great Submission Portal.
And let's begin okay.
So the purpose of this lesson is we need to basically rebuild images from our grid submission API and
our grid submission portal.
You might be wondering why.
And the reason is we've been using the traditional Docker build command to build images.
And the reason why this command is limited is because it only builds the image for a single architecture.
So to give you an example, I'm using Mac with Apple Silicon, and by using the docker build command
on it, Docker is going to default to binding this image for the ARM architecture ARM, let's call it.
And most cloud providers like AWS or Heroku in this case, which is what we're going to use.
They currently run on the x86 64 architecture.
So the container that I build for ARM may not run on these providers.
If you build the same Docker image on windows.
Docker will default to binding this image for the x86 64 architecture, which should be compatible with
most cloud providers that support it.
The take home message is that because the Docker build command only builds images for a single architecture,
it kind of limits the compatibility of our container with cloud providers that support different architectures.
And so to ensure maximum compatibility and portability, which is what we love about Docker, we can
use the command Docker build X build.
So this is an enhanced build command because it allows you to build images for multiple architectures
using a single command, which is really, really cool.
So by building these Multi-architecture images, you can deploy your containers to a wider range of
cloud providers and environments without having to worry about the underlying architecture that they
support.
Okay, so before we actually use Docker build X, what we need to do is set up a builder.
So Docker build x create dash dash.
Name my builder.
Okay.
And then I'm going to use this builder.
So docker build x use my builder.
Cool.
Now that I've got that set up I can say docker build x build.
We're going to build an image that's compatible with the platform Linux slash amd64.
So amd64 refers to the x86 64 architecture which is the most common architecture for Linux based systems.
And it is widely supported by cloud platforms like AWS or in this case, Heroku, which is what we're
going to use in this course.
To keep the deployment process straightforward, we're going to make the image compatible with ARM 64.
This refers to the ARM 64 architecture, which is the most commonly used in ARM based servers and cloud
instances.
We're also going to make it compatible with Linux Armv7.
This armv7 architecture is commonly used in some older ARM based services or devices, I should say,
but it's good to ensure that whatever image we build is compatible with as many platforms as it needs
to be.
All right.
And now we can build an image so we can say dash t.
We can build an image called we're going to call it our slim 087.
So your Docker Hub username followed by grade submission API multi arc and actually not API portal because
we're at the great submission portal directory.
Great submission portal multi arc.
All right.
And upon building an image from the docker file at the current directory we're going to say dash dash
push.
So this is really cool because as we're building the image it's going to automatically push it to Docker
Hub.
If the build process is successful, then I'm going to say dot.
So build an image from the docker file at the current directory.
I think everything here should be fine and enough talk.
Let's just do it.
This should take quite some time, because we're building this image and repeating everything so that
it is compatible with many different platforms.
Should take about 5 to 7 minutes, I should say.
So I might see you in a bit.
All right, let's clear the output.
And, um, over here we're not going to use environment variables because the location of our MongoDB
instance is pretty fixed.
So I'm just going to paste the connection URL right over here Okay.
Now upon this application connecting to the MongoDB cluster, anything that we save, any data that
we save is going to be saved to a default database that is going to be created for us.
Instead of a default database being used, we can set our own database name so we can have every record
saved to a database called grades DB.
All right.
If you don't want to specify a database name, that's fine.
Everything that we save will just be saved to a default database created for us.
But I want a specific database name and that's it.
We're going to use the same command that we used to build the grade submission portal image to build
the grade submission API image.
All right.
Um, pretty sure we've got everything covered.
Let's do it
So this should take quite a long time.
Really make sure that your connection URL is good, because you don't want to realize you've made a
mistake.
After building this image.
It's going to take like ten minutes to run this one from experience.
So I'll see you in ten minutes.
All right.
I just came back, made a cup of coffee, and it's still going.
It looks like it's done.
Uh, building the image now.
It's just pushing it over to Docker Hub.
Okay.
Not bad.
That shouldn't take more than 20s.
All right.
Yeah, both of them are pushed.
Let me refresh.
Sweet.
All right, so pause the video until yours have been built and pushed.
Now I'm just gonna clear the output.
And what I want to do is test the connection between the great submission API that's going to be running
inside of a container, and the MongoDB cluster that's hosted by a database service.
We need to make sure that connection works before we can deploy this container over to the cloud.
Um, okay.
So docker uh, run dash dash m dash dash name.
We'll call it grade submission API.
Um, we're going to create a container from the image are slim 087 slash grade submission API multi
arc.
Let me just copy this.
Don't feel like making any typos.
I'm really hoping this works because that took like 20 minutes.
All right.
That should be it.
Did I misspell the password I love you underscore 52.
No.
We're good, we're good Fingers crossed.
Sweet.
So if all you get is great, service is running on port 3000.
That means it was able to connect successfully.
Now, before we move on to the next video where we deploy everything to the cloud, I want to test this
out.
So there's no point creating a Docker compose file, because we're just going to be testing this out
once.
Let's say Docker network.
Create my network.
All right.
And let's run this container on the network.
My network.
We have to remove it.
Um, for some reason the dash dash RM didn't do anything.
In this case, whatever, uh, cannot remove, we'll say dash f to force it.
Okay.
Now we're good.
We'll try this again.
Run it on this network.
All right, so taking note of the container name.
Great grade submission API.
We can create another container for the grade submission portal.
So docker run network my network dash dash dash dash name.
We'll call it grade submission portal.
We'll say dash E, so it expects an environment variable from its container in order to connect to the
grade submission API running on the same network.
So dash e um, so the grade submission API in this case is going to be the full URL.
So that's going to equal HTTP.
The host is going to be the container name where the grade submission API is running.
So that's great.
Submission API.
The port is where the application is going to be serving requests within the container.
So it's going to be serving requests on container port.
The API is going to be serving requests on container port 3000.
And we needed the slash grades path, remember, because that's a path where it's serving requests and
endpoint.
And now we can create a container out of our Docker image or a slim 087 slash to create submission portal
Multiarch.
Let's do a port mapping.
So after setting the environment variable we'll say dash p 5001 5001.
Because I'm pretty sure that app dot Pi is serving requests on container port 5001.
All right.
Let's try it out now.
Okay I'm excited localhost 5001.
We'll say Harry we'll give him a 94 in potions.
So we've got two containers talking to each other and one container communicating with an external database.
All right.
Now it seems to have worked beautifully.
If I go to my cluster and I go to browse collections, I can see that Harry potions 94 was saved to
MongoDB.
Beautiful.
So now I've got my database hosted using a database service.
I've got my two containers that are able to talk to each other seamlessly.
One of the containers is able to communicate with this database.
I've got everything I need to deploy these two containers over to Heroku.
Now, the beauty about Docker containers is that no matter where you deploy them, the underlying application
we know is going to run reliably, because what's inside the container is just the application and only
the resources that the app needs in order to run.
In the next video, you're going to see firsthand just how easy it is to deploy containers to the cloud.
All right, we're done.
The hard part.
Now it's on to the fun part