We are finally all complete with that era handling stuff.
So now it's time to move on and start to actually implement our sign up flow whenever user signs up
to our application as you would imagine one of the first things we need to do is take that email and
password and create some entry inside of some database to reflect that user being created we discussed
previously when we were first talking about the architecture of this application that we're going to
be using Mongo DB across the board.
So in this video we're gonna start to focus on adding in Mongoose into our Express application or really
the service and we're going to make sure that we also have a Mongo DB instance to communicate with as
well now as a quick reminder once again every copy or every service that we are going to implement is
going to have its own instance of Mongo DB.
Own Private instance.
And this goes back to that whole idea of one database per service so in this video we're going to install
Mongoose into our project.
We're also going to setup a new Mongo DV instance inside of our communities cluster as well.
Let's first just install Mongoose because it's pretty easy and straightforward.
So back at my terminal inside my off directory I will run npm install Mongoose Well yep.
That's easy enough.
Now that Magnus is installed into our project let's go ahead and create a new instance of Margot DV
So how are we gonna do that.
Well Margot DV is just like any other thing that we're trying to run inside of our Cuban 80s cluster
we are going to be running Mongo DV inside of a pod.
And remember we usually do not create pods directly.
Instead we make use of deployments.
The deployment is going to create a pod for us.
And in order to communicate with this pod we're going to have to create a cluster I.P. service to go
along with it as well.
In total we're going to really just be writing out one single deployment file so a config file that's
going to look very similar to the one we already put together for the authentication service go back
to my editor I'm gonna find the infra K AIDS directory and inside there I'm going to make a new file
called off dash Mongo dash devil gamble that is the general naming strategy that we're going to use
for our different databases that we create we're gonna put in the service that owns this database the
type of database.
So in this case it's Mongo DV and we are creating a deployment that we're gonna bring it that simply
as devil than inside of here.
Once again we're gonna write out some configuration that's gonna look very similar to what we already
have inside of our off deployment file.
So at the very top we'll get our API version of apps V1 a kind of deployment the metadata section we'll
give this a name of off Mongo double
then our spec section we'll have replicas one we'll put in that selector with a match labels property
of app off dash Mongo
then our pod template where we will have some metadata.
Once again with the label section that has app off dash Mongo.
So once again we've gone over this many times now.
Remember this is going to be a label that gets applied to the pod.
This selector thing right here is how the deployment is going to find the pod that it actually creates
after the metadata section will then add in a spec for the pod.
We'll say that there's going to be one container so put in the container section with the single array
entry we're going to give that container a name of off dash mango and we'll specify the image as simply
mango.
Quick reminder on where this image is coming from right here.
Remember that on Docker Hub.
So if you go to hub dot dot dot com inside of our browser right now there are a wide variety of different
images hosted on Docker Hub for public use.
So if I do a search at the very top or simply mango I'll see that there is in fact a image called Mango.
This is an officially hosted image that we can run to get a mongo DB database.
So by just putting in an image name of mango we are referring to this image right here if we ever want
to understand how to configure this thing we can always read in the documentation on this page as well.
So that's it for the deployment.
But remember after creating the deployment also going to create a cluster I.P. service inside of here
so that we can actually connect to the pods that are going to be created it's going to add in a dash
dash dash to indicate I want to put in some configuration for a second object well then put in an API
version of V1 a kind of service metadata with the name of art Mongo SRB
with a selector of app off dash Mongo remember we put the selector together inside of a service that
is telling the service which pods it is going to govern access to.
So in this case we're saying find a set of pods or any pod with a label of app off Mongo.
And of course that matches up to the one that we just put right there that we can list out all of the
different ports that we want to allow access to we're only going to expose one port.
I'm going to give it a name of simply D.B..
Remember the name that we put here is really just for logging purposes.
Once we start to print out information about the service if we ever do at our terminal it's going to
give us a name of D.B. for this port.
The name that you put there not super important actually used a different name in my notes than D.B.
just when you're writing this config file.
I thought a DB makes sense.
Let's just use that instead will list a protocol of DCP and then a port of 27 0 1 7 and a target port
of 27 0 1 7.
Why are we using this port right here.
Well by default Mongo D.B. listens for incoming traffic on 20 7 0 1 7.
That is the default port for Mongo.
So that's why I put it in here.
You would normally have to do a little bit of research to figure out what port a given database or a
given application is going to be listening on.
To do so you would look up some information about the image itself.
So I could go back over to that Docker Hub page over here and chances are I should be able to do a search
on this page for 20 7 0 1 7 and sure enough yep that does say hey to connect this thing it's going to
be listening on or 20 7 0 1 7
all right.
That's it for our service.
That is it for our deployment now to create this database and the service will just do yet another either
UCL apply or a better way of handling this would be to just make use of scaffold as remember scaffold
is going to try to deploy all the different files we list out inside this directory sometimes scaffold
does not actually see when we create new files however.
I to go back over to the window that is running scaffold.
It looks like in my case scaffold did see that I created that new file and so I see right here that
scaffold has gone ahead applied that file and my deployment has been created and the service has been
created as well in your terminal window running scaffold if for some reason you do not see this information
then all you have to do is it control C and restart scaffold by running scaffold Dev.
Once again once everything gets applied we should then be able to do a cube Seitel get pods I'm connected
to the wrong cluster right now.
They fix that up
that's better.
We should go to do a cube CDL get pods and see our authentication Mongo deployment that looks good.
So now in theory we are running a copy of Mongo DV for our off service.
So let's take a quick pause right here.
When we come back the next video we're gonna make sure that our actual service has some code inside
of it to reach out and connect to the Mongo instance running inside this pod.