Okay, so our last step is to create a service for reservations.
And this is the most important one because it's going to be what our users are going to use to actually
enter our system and make calls to create reservations and trigger our whole application.
In this sense, it's acting like the API gateway and this service is what we're going to need to actually
expose externally.
Now, when we run this service in Google Cloud, we're actually going to provision a load balancer.
However, when we're running locally, we just want to configure it as a node port service so that we
can communicate it via local host.
Let's go ahead and set this up.
We'll CD into the Template's directory, into reservations, and we can run our usual command to create
a service to change the service type.
Here.
Now to be Node port, we'll still specify a TCP IP and expose it on 3004.
We can set dry run equal to client output Yaml.
And of course don't forget the name of the service as well, which we'll call reservations and we'll
go ahead and pipe this out to a service dot yaml as usual.
So now in the reservations folder we can see our service and we'll remove the load balancer and the
creation timestamp as usual.
So one last improvement we're going to make to make our services a bit cleaner is to actually update
the name.
So if it's a microservice, we'll leave the name as TCP.
Otherwise we'll call the name Http.
So let's go ahead and update our services and payments and payments.
We know this is a TCP microservice port, we'll call it TCP and notifications.
We'll go ahead and do the same.
It's TCP and most importantly, an auth.
This is where it'll be most clear.
The TCP port is at 3002 and at 3003 this is Http.
So now we can run helm upgrade Sleeper and if we run kubectl get service, we can see we have a new
reservation service created on a node port and it will be on exposed externally at this port here,
which means we can actually communicate with this service using local host.
So let's go ahead and try that next.
So back in Postman, we can now actually communicate with our cluster and entering in the node port
that you just found on the reservation service case.
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
find a root.
So we can go ahead and send a request at slash reservations to go ahead and post a new reservation.
And of course, we get a forbidden resource because we have not authenticated in our auth service.
So as you know, we need to go ahead and create a user and authenticate with that user first.
However, we don't have a node port set up for our authentication service yet, so we can't communicate
with it.
Let's go ahead and address that next.
So back in the folder, in the auth service, we actually want to create two separate services.
One that will be a cluster IP service and only expose the microservice port here and another one that
will be a node port service and expose our Http port.
So let's go ahead and rename this service dash, TCP dot Yaml and we'll go ahead and create a new file
called service dash http dot Yaml.
Then I'll go ahead and copy and paste the whole service we have already and paste it into the Http one.
And now I'll remove the TCP port only keep the Http one and then change the type to a node port.
Similarly, back in the TCP service, I'll go ahead and remove the Http port altogether.
We're also going to need to change the name of the services here so they don't conflict.
So I'll call this one auth Http and I'll call this one auth TCP.
However, they're both still going to be targeting the auth app based off of our selector.
Now since we're changing the name of our service, also need to update the services that actually rely
on auth, which is just going to be the reservations deployment.
So let's go ahead and update reservations.
We're going to change the auth host to auth dash TCP and the port will still say stay the same at 3002.
So now we can run helm upgrade Sleeper again and if we run Kubectl get service, we can see the auth.
TCP service is still a cluster IP at 3002 and the auth Http is a node port that's being exposed here
on 31554.
Okay.
So lastly, we need to provide the environment variables that are used in the notification service to
actually email users, all of our Google OAuth information.
And right now, actually we are not adding this to our notifications module, Joy Validation.
So let's go ahead and actually add this.
Now we'll go ahead and add all of these environment variables to make sure that we're actually validating
them.
So make sure we add the joy auth client ID as a required string.
So I've gone ahead and updated all the environment variables that are going to be required in the notification
service.
And thankfully since we've set up our G Cloud automated build, the next time we commit push this,
it should be reflected in our application.
Okay, so we're going to launch a request at our authentication service which is listening on Node port
31554 slash users and I sent a payload with an email and password with a strong password of numbers
and special characters.
And the email is one where we know we'll actually be able to receive them from.
So I've gone ahead and created this and got a 201 response back.
Next we can launch a request at the same service at slash auth slash login to get our JWT cookie.
And now if we go back to our reservation service listening on Node port 305 zero zero and send it a
payload here to create a reservation, I should be able to send this off and make sure we're posting
here.
I should be able to send this off.
And a new reservation has been created with a 201 response back.
I can even run the get command here to get all observations.
Okay, so after creating a few reservations, you can see we can query our reservations.
And if we go back to Atlas and click on our database, you can see of course we have some read and write
activity going on here and some increased connections and we can even click on it to view our collections
on real time.
So you can see all of our reservation documents here and the users that we've created here all persisted
in our Atlas database.
We can also verify that our payment service is working correctly by going ahead and changing the amount
here to some new amount like 19.
And I'll go ahead and send off this request.
Now, back in the Stripe dashboard, if we go ahead and refresh the screen here, we should expect to
see a payment of $19 reflected and completed in our dashboard, which shows that our payment service
is working in our Kubernetes environment.
Now, importantly, if you don't see an email coming in based from our notification service run Kubectl
get pods and you might see that the notification service has restarted.
So go ahead and copy the pod and run kubectl logs dash dash previous.
And we actually threw an error here that the token has been expired or revoked.
So if this happens, it means we need to update our refresh token.
So to update our refresh token, go back to the Google OAuth two playground.
And as we've done before, use our own OAuth credentials here and enter your client ID and secret.
I'll go ahead and take these from the existing notifications.mv as we did before.
We'll open up the Gmail API V1 here and authorize the mail Google API.
Go ahead and connect your account and exchange authorization code for tokens and copy this new refresh
token.
Here now to update our existing refresh token secret, we're going to run Echo Dash n Enter the new
refresh token with quotes and pipe this to base 64.
Go ahead and copy this new base, 64 encoded secret and then we'll go ahead and run Kubectl edit secret
Google and go ahead and replace the existing refresh token secret here with our new value and go ahead
and save.
Additionally, go ahead and run Kubectl rollout Restart deployment notifications so we get the latest
notifications pod with our updated secrets and you can see it running here.
So now if we send off another request to create a reservation in with our authenticated user, we should
now see back in our Google account or Gmail for whatever user you've created.
We can see a sleeper notification from our notification service saying our payment has completed successfully.
So this means we have our application working end to end locally running in a Kubernetes cluster.
Let's go ahead and see how we can easily deploy this to Google Cloud.
Kubernetes.