1
00:00:01,080 --> 00:00:03,540
We are finally all complete with that era handling stuff.

2
00:00:03,540 --> 00:00:08,520
So now it's time to move on and start to actually implement our sign up flow whenever user signs up

3
00:00:08,520 --> 00:00:12,360
to our application as you would imagine one of the first things we need to do is take that email and

4
00:00:12,360 --> 00:00:18,750
password and create some entry inside of some database to reflect that user being created we discussed

5
00:00:18,750 --> 00:00:22,620
previously when we were first talking about the architecture of this application that we're going to

6
00:00:22,620 --> 00:00:24,720
be using Mongo DB across the board.

7
00:00:25,560 --> 00:00:31,050
So in this video we're gonna start to focus on adding in Mongoose into our Express application or really

8
00:00:31,050 --> 00:00:36,690
the service and we're going to make sure that we also have a Mongo DB instance to communicate with as

9
00:00:36,690 --> 00:00:43,110
well now as a quick reminder once again every copy or every service that we are going to implement is

10
00:00:43,110 --> 00:00:45,360
going to have its own instance of Mongo DB.

11
00:00:45,480 --> 00:00:47,190
Own Private instance.

12
00:00:47,190 --> 00:00:53,610
And this goes back to that whole idea of one database per service so in this video we're going to install

13
00:00:53,610 --> 00:00:55,200
Mongoose into our project.

14
00:00:55,200 --> 00:01:00,160
We're also going to setup a new Mongo DV instance inside of our communities cluster as well.

15
00:01:01,660 --> 00:01:05,550
Let's first just install Mongoose because it's pretty easy and straightforward.

16
00:01:05,590 --> 00:01:17,800
So back at my terminal inside my off directory I will run npm install Mongoose Well yep.

17
00:01:17,810 --> 00:01:18,620
That's easy enough.

18
00:01:19,960 --> 00:01:24,820
Now that Magnus is installed into our project let's go ahead and create a new instance of Margot DV

19
00:01:25,390 --> 00:01:27,190
So how are we gonna do that.

20
00:01:27,190 --> 00:01:33,010
Well Margot DV is just like any other thing that we're trying to run inside of our Cuban 80s cluster

21
00:01:33,370 --> 00:01:36,470
we are going to be running Mongo DV inside of a pod.

22
00:01:36,550 --> 00:01:39,140
And remember we usually do not create pods directly.

23
00:01:39,160 --> 00:01:41,190
Instead we make use of deployments.

24
00:01:41,470 --> 00:01:43,680
The deployment is going to create a pod for us.

25
00:01:44,170 --> 00:01:49,090
And in order to communicate with this pod we're going to have to create a cluster I.P. service to go

26
00:01:49,090 --> 00:01:50,950
along with it as well.

27
00:01:50,950 --> 00:01:56,320
In total we're going to really just be writing out one single deployment file so a config file that's

28
00:01:56,320 --> 00:02:01,650
going to look very similar to the one we already put together for the authentication service go back

29
00:02:01,650 --> 00:02:09,000
to my editor I'm gonna find the infra K AIDS directory and inside there I'm going to make a new file

30
00:02:09,270 --> 00:02:17,220
called off dash Mongo dash devil gamble that is the general naming strategy that we're going to use

31
00:02:17,220 --> 00:02:22,520
for our different databases that we create we're gonna put in the service that owns this database the

32
00:02:22,530 --> 00:02:23,430
type of database.

33
00:02:23,460 --> 00:02:28,380
So in this case it's Mongo DV and we are creating a deployment that we're gonna bring it that simply

34
00:02:28,380 --> 00:02:31,740
as devil than inside of here.

35
00:02:31,750 --> 00:02:35,110
Once again we're gonna write out some configuration that's gonna look very similar to what we already

36
00:02:35,110 --> 00:02:37,730
have inside of our off deployment file.

37
00:02:37,860 --> 00:02:49,690
So at the very top we'll get our API version of apps V1 a kind of deployment the metadata section we'll

38
00:02:49,690 --> 00:02:54,010
give this a name of off Mongo double

39
00:02:57,820 --> 00:03:06,660
then our spec section we'll have replicas one we'll put in that selector with a match labels property

40
00:03:07,630 --> 00:03:12,190
of app off dash Mongo

41
00:03:15,320 --> 00:03:18,770
then our pod template where we will have some metadata.

42
00:03:18,770 --> 00:03:24,910
Once again with the label section that has app off dash Mongo.

43
00:03:24,940 --> 00:03:27,370
So once again we've gone over this many times now.

44
00:03:27,430 --> 00:03:30,990
Remember this is going to be a label that gets applied to the pod.

45
00:03:31,070 --> 00:03:35,170
This selector thing right here is how the deployment is going to find the pod that it actually creates

46
00:03:37,720 --> 00:03:41,500
after the metadata section will then add in a spec for the pod.

47
00:03:41,590 --> 00:03:46,030
We'll say that there's going to be one container so put in the container section with the single array

48
00:03:46,060 --> 00:03:54,240
entry we're going to give that container a name of off dash mango and we'll specify the image as simply

49
00:03:54,360 --> 00:03:56,720
mango.

50
00:03:56,750 --> 00:03:59,940
Quick reminder on where this image is coming from right here.

51
00:03:59,990 --> 00:04:01,840
Remember that on Docker Hub.

52
00:04:01,880 --> 00:04:07,370
So if you go to hub dot dot dot com inside of our browser right now there are a wide variety of different

53
00:04:07,370 --> 00:04:10,750
images hosted on Docker Hub for public use.

54
00:04:10,760 --> 00:04:17,160
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.

55
00:04:17,180 --> 00:04:23,250
This is an officially hosted image that we can run to get a mongo DB database.

56
00:04:23,270 --> 00:04:29,710
So by just putting in an image name of mango we are referring to this image right here if we ever want

57
00:04:29,710 --> 00:04:37,330
to understand how to configure this thing we can always read in the documentation on this page as well.

58
00:04:37,420 --> 00:04:38,760
So that's it for the deployment.

59
00:04:38,800 --> 00:04:43,030
But remember after creating the deployment also going to create a cluster I.P. service inside of here

60
00:04:43,060 --> 00:04:49,190
so that we can actually connect to the pods that are going to be created it's going to add in a dash

61
00:04:49,220 --> 00:04:55,490
dash dash to indicate I want to put in some configuration for a second object well then put in an API

62
00:04:55,490 --> 00:05:05,570
version of V1 a kind of service metadata with the name of art Mongo SRB

63
00:05:09,670 --> 00:05:18,780
with a selector of app off dash Mongo remember we put the selector together inside of a service that

64
00:05:18,780 --> 00:05:22,500
is telling the service which pods it is going to govern access to.

65
00:05:22,500 --> 00:05:28,630
So in this case we're saying find a set of pods or any pod with a label of app off Mongo.

66
00:05:28,680 --> 00:05:34,500
And of course that matches up to the one that we just put right there that we can list out all of the

67
00:05:34,500 --> 00:05:39,560
different ports that we want to allow access to we're only going to expose one port.

68
00:05:39,710 --> 00:05:42,380
I'm going to give it a name of simply D.B..

69
00:05:42,620 --> 00:05:47,270
Remember the name that we put here is really just for logging purposes.

70
00:05:47,300 --> 00:05:51,690
Once we start to print out information about the service if we ever do at our terminal it's going to

71
00:05:51,740 --> 00:05:53,680
give us a name of D.B. for this port.

72
00:05:53,750 --> 00:05:57,920
The name that you put there not super important actually used a different name in my notes than D.B.

73
00:05:58,040 --> 00:05:59,470
just when you're writing this config file.

74
00:05:59,480 --> 00:06:01,220
I thought a DB makes sense.

75
00:06:01,220 --> 00:06:10,690
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

76
00:06:10,690 --> 00:06:12,920
of 27 0 1 7.

77
00:06:12,940 --> 00:06:14,740
Why are we using this port right here.

78
00:06:14,740 --> 00:06:20,130
Well by default Mongo D.B. listens for incoming traffic on 20 7 0 1 7.

79
00:06:20,140 --> 00:06:22,300
That is the default port for Mongo.

80
00:06:22,300 --> 00:06:24,120
So that's why I put it in here.

81
00:06:24,250 --> 00:06:29,140
You would normally have to do a little bit of research to figure out what port a given database or a

82
00:06:29,140 --> 00:06:31,950
given application is going to be listening on.

83
00:06:32,200 --> 00:06:35,030
To do so you would look up some information about the image itself.

84
00:06:35,350 --> 00:06:41,320
So I could go back over to that Docker Hub page over here and chances are I should be able to do a search

85
00:06:41,320 --> 00:06:47,350
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

86
00:06:47,350 --> 00:06:49,600
be listening on or 20 7 0 1 7

87
00:06:52,500 --> 00:06:52,870
all right.

88
00:06:52,900 --> 00:06:54,300
That's it for our service.

89
00:06:54,310 --> 00:07:01,750
That is it for our deployment now to create this database and the service will just do yet another either

90
00:07:02,120 --> 00:07:09,250
UCL apply or a better way of handling this would be to just make use of scaffold as remember scaffold

91
00:07:09,250 --> 00:07:14,620
is going to try to deploy all the different files we list out inside this directory sometimes scaffold

92
00:07:14,620 --> 00:07:17,520
does not actually see when we create new files however.

93
00:07:17,570 --> 00:07:20,470
I to go back over to the window that is running scaffold.

94
00:07:20,470 --> 00:07:26,590
It looks like in my case scaffold did see that I created that new file and so I see right here that

95
00:07:26,590 --> 00:07:32,020
scaffold has gone ahead applied that file and my deployment has been created and the service has been

96
00:07:32,020 --> 00:07:38,180
created as well in your terminal window running scaffold if for some reason you do not see this information

97
00:07:38,450 --> 00:07:43,750
then all you have to do is it control C and restart scaffold by running scaffold Dev.

98
00:07:43,760 --> 00:07:52,940
Once again once everything gets applied we should then be able to do a cube Seitel get pods I'm connected

99
00:07:52,940 --> 00:07:55,740
to the wrong cluster right now.

100
00:07:55,910 --> 00:07:56,550
They fix that up

101
00:07:59,810 --> 00:08:00,540
that's better.

102
00:08:00,620 --> 00:08:08,580
We should go to do a cube CDL get pods and see our authentication Mongo deployment that looks good.

103
00:08:08,590 --> 00:08:14,260
So now in theory we are running a copy of Mongo DV for our off service.

104
00:08:14,260 --> 00:08:15,400
So let's take a quick pause right here.

105
00:08:15,400 --> 00:08:19,930
When we come back the next video we're gonna make sure that our actual service has some code inside

106
00:08:19,930 --> 00:08:24,250
of it to reach out and connect to the Mongo instance running inside this pod.