WEBVTT 00:00.260 --> 00:03.830 Okay, so our last step is to create a service for reservations. 00:03.830 --> 00:08.810 And this is the most important one because it's going to be what our users are going to use to actually 00:08.810 --> 00:15.080 enter our system and make calls to create reservations and trigger our whole application. 00:15.080 --> 00:20.450 In this sense, it's acting like the API gateway and this service is what we're going to need to actually 00:20.450 --> 00:22.250 expose externally. 00:22.460 --> 00:28.150 Now, when we run this service in Google Cloud, we're actually going to provision a load balancer. 00:28.160 --> 00:33.230 However, when we're running locally, we just want to configure it as a node port service so that we 00:33.230 --> 00:36.020 can communicate it via local host. 00:36.050 --> 00:38.000 Let's go ahead and set this up. 00:38.000 --> 00:44.240 We'll CD into the Template's directory, into reservations, and we can run our usual command to create 00:44.240 --> 00:46.040 a service to change the service type. 00:46.040 --> 00:46.310 Here. 00:46.310 --> 00:52.880 Now to be Node port, we'll still specify a TCP IP and expose it on 3004. 00:52.910 --> 00:57.050 We can set dry run equal to client output Yaml. 00:57.050 --> 01:02.790 And of course don't forget the name of the service as well, which we'll call reservations and we'll 01:02.790 --> 01:06.270 go ahead and pipe this out to a service dot yaml as usual. 01:06.270 --> 01:12.330 So now in the reservations folder we can see our service and we'll remove the load balancer and the 01:12.330 --> 01:14.250 creation timestamp as usual. 01:14.250 --> 01:19.920 So one last improvement we're going to make to make our services a bit cleaner is to actually update 01:19.920 --> 01:20.310 the name. 01:20.310 --> 01:23.520 So if it's a microservice, we'll leave the name as TCP. 01:23.910 --> 01:26.820 Otherwise we'll call the name Http. 01:27.180 --> 01:31.650 So let's go ahead and update our services and payments and payments. 01:31.650 --> 01:38.010 We know this is a TCP microservice port, we'll call it TCP and notifications. 01:38.010 --> 01:39.570 We'll go ahead and do the same. 01:39.570 --> 01:42.390 It's TCP and most importantly, an auth. 01:42.390 --> 01:44.340 This is where it'll be most clear. 01:44.340 --> 01:50.490 The TCP port is at 3002 and at 3003 this is Http. 01:50.670 --> 01:56.670 So now we can run helm upgrade Sleeper and if we run kubectl get service, we can see we have a new 01:56.670 --> 02:03.540 reservation service created on a node port and it will be on exposed externally at this port here, 02:03.540 --> 02:07.950 which means we can actually communicate with this service using local host. 02:07.950 --> 02:09.870 So let's go ahead and try that next. 02:09.870 --> 02:16.020 So back in Postman, we can now actually communicate with our cluster and entering in the node port 02:16.020 --> 02:19.290 that you just found on the reservation service case. 02:19.290 --> 02:26.040 It's 305 zero zero and we can go ahead and send a request at this and we get the response that we can't 02:26.040 --> 02:26.790 find a root. 02:26.790 --> 02:32.730 So we can go ahead and send a request at slash reservations to go ahead and post a new reservation. 02:32.730 --> 02:38.040 And of course, we get a forbidden resource because we have not authenticated in our auth service. 02:38.040 --> 02:43.050 So as you know, we need to go ahead and create a user and authenticate with that user first. 02:43.050 --> 02:48.780 However, we don't have a node port set up for our authentication service yet, so we can't communicate 02:48.780 --> 02:49.350 with it. 02:49.350 --> 02:51.060 Let's go ahead and address that next. 02:51.060 --> 02:58.770 So back in the folder, in the auth service, we actually want to create two separate services. 02:58.770 --> 03:06.450 One that will be a cluster IP service and only expose the microservice port here and another one that 03:06.450 --> 03:10.980 will be a node port service and expose our Http port. 03:10.980 --> 03:18.390 So let's go ahead and rename this service dash, TCP dot Yaml and we'll go ahead and create a new file 03:18.390 --> 03:21.990 called service dash http dot Yaml. 03:22.200 --> 03:28.680 Then I'll go ahead and copy and paste the whole service we have already and paste it into the Http one. 03:28.920 --> 03:36.120 And now I'll remove the TCP port only keep the Http one and then change the type to a node port. 03:36.120 --> 03:42.180 Similarly, back in the TCP service, I'll go ahead and remove the Http port altogether. 03:42.180 --> 03:46.230 We're also going to need to change the name of the services here so they don't conflict. 03:46.230 --> 03:53.250 So I'll call this one auth Http and I'll call this one auth TCP. 03:53.520 --> 03:58.200 However, they're both still going to be targeting the auth app based off of our selector. 03:58.230 --> 04:03.480 Now since we're changing the name of our service, also need to update the services that actually rely 04:03.480 --> 04:07.080 on auth, which is just going to be the reservations deployment. 04:07.080 --> 04:09.390 So let's go ahead and update reservations. 04:09.390 --> 04:17.730 We're going to change the auth host to auth dash TCP and the port will still say stay the same at 3002. 04:17.730 --> 04:24.390 So now we can run helm upgrade Sleeper again and if we run Kubectl get service, we can see the auth. 04:24.390 --> 04:32.850 TCP service is still a cluster IP at 3002 and the auth Http is a node port that's being exposed here 04:32.880 --> 04:34.650 on 31554. 04:34.680 --> 04:34.980 Okay. 04:34.980 --> 04:41.130 So lastly, we need to provide the environment variables that are used in the notification service to 04:41.130 --> 04:45.150 actually email users, all of our Google OAuth information. 04:45.150 --> 04:52.350 And right now, actually we are not adding this to our notifications module, Joy Validation. 04:52.350 --> 04:54.300 So let's go ahead and actually add this. 04:54.300 --> 04:59.850 Now we'll go ahead and add all of these environment variables to make sure that we're actually validating 04:59.850 --> 04:59.970 them. 05:00.500 --> 05:05.270 So make sure we add the joy auth client ID as a required string. 05:05.270 --> 05:11.300 So I've gone ahead and updated all the environment variables that are going to be required in the notification 05:11.300 --> 05:11.900 service. 05:11.900 --> 05:17.630 And thankfully since we've set up our G Cloud automated build, the next time we commit push this, 05:17.660 --> 05:20.180 it should be reflected in our application. 05:20.300 --> 05:25.610 Okay, so we're going to launch a request at our authentication service which is listening on Node port 05:25.610 --> 05:34.370 31554 slash users and I sent a payload with an email and password with a strong password of numbers 05:34.370 --> 05:35.630 and special characters. 05:35.630 --> 05:39.560 And the email is one where we know we'll actually be able to receive them from. 05:39.560 --> 05:43.610 So I've gone ahead and created this and got a 201 response back. 05:43.640 --> 05:51.950 Next we can launch a request at the same service at slash auth slash login to get our JWT cookie. 05:52.130 --> 05:59.630 And now if we go back to our reservation service listening on Node port 305 zero zero and send it a 05:59.630 --> 06:05.190 payload here to create a reservation, I should be able to send this off and make sure we're posting 06:05.190 --> 06:05.700 here. 06:05.700 --> 06:08.160 I should be able to send this off. 06:08.160 --> 06:14.610 And a new reservation has been created with a 201 response back. 06:14.610 --> 06:18.750 I can even run the get command here to get all observations. 06:18.780 --> 06:24.810 Okay, so after creating a few reservations, you can see we can query our reservations. 06:24.810 --> 06:31.860 And if we go back to Atlas and click on our database, you can see of course we have some read and write 06:31.860 --> 06:39.060 activity going on here and some increased connections and we can even click on it to view our collections 06:39.060 --> 06:40.260 on real time. 06:40.260 --> 06:47.520 So you can see all of our reservation documents here and the users that we've created here all persisted 06:47.520 --> 06:48.990 in our Atlas database. 06:48.990 --> 06:54.870 We can also verify that our payment service is working correctly by going ahead and changing the amount 06:54.870 --> 06:57.480 here to some new amount like 19. 06:57.480 --> 06:59.610 And I'll go ahead and send off this request. 06:59.640 --> 07:05.610 Now, back in the Stripe dashboard, if we go ahead and refresh the screen here, we should expect to 07:05.610 --> 07:12.750 see a payment of $19 reflected and completed in our dashboard, which shows that our payment service 07:12.750 --> 07:15.300 is working in our Kubernetes environment. 07:15.300 --> 07:22.350 Now, importantly, if you don't see an email coming in based from our notification service run Kubectl 07:22.380 --> 07:27.060 get pods and you might see that the notification service has restarted. 07:27.060 --> 07:33.060 So go ahead and copy the pod and run kubectl logs dash dash previous. 07:33.060 --> 07:37.680 And we actually threw an error here that the token has been expired or revoked. 07:37.680 --> 07:42.510 So if this happens, it means we need to update our refresh token. 07:42.510 --> 07:47.220 So to update our refresh token, go back to the Google OAuth two playground. 07:47.220 --> 07:54.120 And as we've done before, use our own OAuth credentials here and enter your client ID and secret. 07:54.120 --> 08:00.540 I'll go ahead and take these from the existing notifications.mv as we did before. 08:00.570 --> 08:06.750 We'll open up the Gmail API V1 here and authorize the mail Google API. 08:06.780 --> 08:15.180 Go ahead and connect your account and exchange authorization code for tokens and copy this new refresh 08:15.180 --> 08:15.510 token. 08:15.510 --> 08:22.020 Here now to update our existing refresh token secret, we're going to run Echo Dash n Enter the new 08:22.020 --> 08:26.760 refresh token with quotes and pipe this to base 64. 08:26.790 --> 08:33.600 Go ahead and copy this new base, 64 encoded secret and then we'll go ahead and run Kubectl edit secret 08:33.600 --> 08:43.440 Google and go ahead and replace the existing refresh token secret here with our new value and go ahead 08:43.440 --> 08:44.730 and save. 08:44.760 --> 08:52.740 Additionally, go ahead and run Kubectl rollout Restart deployment notifications so we get the latest 08:52.770 --> 08:58.460 notifications pod with our updated secrets and you can see it running here. 08:58.470 --> 09:05.870 So now if we send off another request to create a reservation in with our authenticated user, we should 09:05.870 --> 09:11.240 now see back in our Google account or Gmail for whatever user you've created. 09:11.270 --> 09:17.960 We can see a sleeper notification from our notification service saying our payment has completed successfully. 09:17.960 --> 09:24.890 So this means we have our application working end to end locally running in a Kubernetes cluster. 09:24.890 --> 09:28.520 Let's go ahead and see how we can easily deploy this to Google Cloud. 09:28.520 --> 09:29.420 Kubernetes.