In this video we're gonna start to set up a routing rules for all the other micro services inside of
our cluster.
I'm inside of our ingress SRB file inside of our infra K Cade's directory.
Right now we only have a route mapping for slashed posts which means in theory we can only attempt to
fetch or retrieve posts is that is the only thing we're doing with our post cluster IP service.
So we need to add in some additional parts to this thing to make sure we map of all the different incoming
requests that might come in.
Now I went through all of our different micro services and the react application and put together a
quick diagram to help you remember all the different routes that we need to service.
All right.
So in this diagram we have some number of requests coming in from our ReACT application.
These are all the different requests we expect to receive.
So we're going to get a post to slash post if that occurs it should go to the post pod.
We're also gonna have a post to slash post slashed ideas slash comments.
That request should go to the common service a get to slash post should go to query and then finally
a get to just slashed by itself is attempting to load up the react application.
So we need to make sure that gets sent to the reactor.
So we need to write out all these different routing rules inside that ingress config file.
Now I got some bad news.
This is something that I knew about ahead of time and I wanted you to have to go through this as well
because I've had to deal with this on a real project too.
The bad news here is that we have two routes right now of slash posts.
If a request comes in with a method of post then that should go to the postal service.
Otherwise if it is a get issue go to query.
The bad news here is that our ingress engine X module can not do routing based upon the method of the
request.
So all the methods I have list on here the ingress controller has no idea that these methods exist.
So the only thing we can really root on effectively is a route early a path so for all these things
it really goes down to just this.
This is all we get.
This is what we have to route based on.
Now the reason this is bad is that now when we look at this you'll notice that if we have a request
coming into a slash posts we're saying it should go to this post pod but there's another one down here
that says if a request comes in to slash post it should go to the query pod.
We can no longer differentiate on the method of the incoming request.
So now we don't have enough information with these requests to figure out whether or not one should
go to the post pod or query so that's the bad news here.
To fix this we need to make sure that we have some unique path or request that should go to posts and
a unique path for one it should go to query.
In other words we really just need to change the name of one of these parts.
So maybe this right here instead of being slash post it should be something like those slash create
or something like that.
If we put that in now we can distinguish between requests that's going to go to the post pod and the
query pod that actually make this reality.
Well we need to make sure that we not only update our ReACT application to make a request to slash create
we need to make sure we also update the post pod itself so that it should expect requests to come in
to slash post slash create.
So in other words we need to change two different images right now just to solve this image or this
issue that we are running into.
Let's take care of that right now because we're going to have to edit those two code bases and then
rebuild the images and post them back up to Docker Hub.
So I can first get started inside of by react application.
I'm going to find my post create file that is where we are making a post request to slash post so I'm
gonna change that route to post slash create again so that we can differentiate between a request that
is supposed to go to the post pod versus the query pod.
There's the change right there.
I can save this file then after that I'm gonna go to my post project find the next J S file inside there.
Here's the post request handler so post flash.
Create you will recall that we do have a getter or a get request handler for Slash post right here.
That was in the previous initial version of our application before we implemented that query.
So this thing is technically unused right now and we don't really care about that handler at all.
We can actually delete it if we want to.
I only left it in here so we could test out our post end point once we initially set up all that ingress
engine X stuff okay.
So I'll say this file as well and I'll go back to my terminal I'm gonna go to my client folder and I'll
do a docker build client Dot.
There we go.
And a docker push.
There we go and we're going to repeat that same process for post as well.
Now this one time you're probably sitting there saying wait a minute Steven wait wait wait wait.
We have to rebuild the image manually and push it up to Docker Hub every single time we make a change
or a code Hey wait a minute that seems a really really awkward.
I know it is really awkward.
This is something else we're gonna fix up very quickly.
I really just want us to have to go through this problem distinctly one more time because very quickly
like in the next come coming videos we're gonna take a look at a tool that's going to automate all this
change process for us and so I just want to give you a quick reminder that yeah.
Sound right now they want to make a change to our code we have to rebuild image push it and then update
the deployment manually.
All very painful.
All right.
Well the client is all done.
I'm going to restart that deployment.
They'll do a cube C.T. El.
What is it rollout restart deployment client Client dash devil.
There we go.
That will restart our client deployment and we're going to go through all those same steps for our postal
service as well.
So I will go back to post I'll do a docker Bill dash t even greater post dot.
I'll do a docker push even greater post
and then once this is all done we'll go ahead and restart the post deployment as well
quick upload.
Come on come on it this apple it always takes slightly longer than you hope I'll.
There you go so we'll do a cube GTL rollout restart deployment those dash double OK.
So we've now got that new version of code or posts and for the rack client.
So now we've got unique routes that we're going to access each of our different pods.
So now quick pause right here.
When come back the next video we can start to actually write out the routing configuration that we need.