So let's now move on
to letting the users-api communicate with the auth-api.
For that we first of all, need to dive back
into the users-app.js file and edit to code again,
because there we replaced some code with dummy code.
For example,
here in this signup route function,
the hashedPassword which is a dummy text,
that should now be reverted
to making that access request again.
And the same for the login route there,
this dummy response
should be replaced
with the actual response
which we get from sending a axios request.
Now please note that these axois requests
are sent to this domain
or this address,
which is just auth.
I have this code here
because this was set up for docker-compose
and there you learned earlier in the course
that it creates a network for you automatically.
And these service names here
can then be used internally, in that network
in the code that runs in the containers
to send requests to each other.
Hence I'm using the auth-service name here
to send requests to that auth-service.
Now that works for docker-compose
but it will actually not do the trick
like this, at least for kubernetes.
So again, to stay flexible here,
what I will do is I will actually replace this
with an environment variable
so that the exact address which can be used
can be changed depending on the environment
on which we're running.
And for this, we should replace this string here
with the string created with back ticks,
instead of single quotes.
So that's a different character on your keyboard,
which still creates a string.
But in JavaScript,
which we're using here
allows us to inject a dynamic value into the string
with this dollar sign calibrates syntax.
And here we could then expect an environment variable
which is the AUTH_ADDRESS, let's say.
So I'm going to copy that and not just do it up here
but all's is a little bit further below, here.
Use back ticks instead of single quotes here,
and replace auth with this injected environment variable.
Using that we can go to docker-compose,
and then here on the users-service,
we can add the environment key,
and then simply add our AUTH_ADDRESS environment variable,
which we just injected here in the end
and give this a value of auth here,
in this case, in the docker-compose world,
sort of this service name.
And then use a different value
when we create and launch this with kubernetes.
Now I will come back
to which address we need to use there, in a second.
Before we start this users-api
with a new value for AUTH_ADDRESS though,
let's make sure
that we do have a running auth-api container as well.
And for that of course
we need to build this image and push it to dockerhub.
Hence, let's go
into the
auth-api folder
and then run docker built dot and give it a name,
which of course should be a repository
you have on dockerhub.
Hence I will first of all create a new repository,
with Create Repository
and name it, kub-demo-auth.
So that's my repository name, click create.
And then as always, use this as a name for the image.
So here I'll insert this,
and build this image.
And then once it will be built,
we of course wanna push it, just like before.
So docker push and then this repository image,
name to push it to dockerhub.
And once it is pushed
we can use that image to create containers
inside of our kubernetes pods.
So let's wait for this pushing to finish.
And now that it finished,
we can deploy this container.
Now we could create a new deployment,
but keep in mind that at least for the moment,
I wanna have that auth-api
in the same pod as the users-api.
So it should not be in a separate pod.
If we would create a new deployment file,
we would also create a new kind of pod.
Yes, a deployment is able
to create and manage multiple pods,
that's the idea behind the deployment,
but only one kind of pod.
And then when we talk about multiple pods,
we're just talking about the replicas.
So we're not going to create a new deployment,
instead in the existing users-deployment here,
we'll add a new container.
A container which we can give a name of auth,
and which then should use this image name
we just pushed as an image.
That's what I wanna do here.
I'll also add the latest tag after both images,
because as you also learned earlier in this course,
when using the latest tag,
by default kubernetes
always refetches and re-evaluates the image
when something changes about our deployment configuration.
So that will ensure
that we always use the latest source code,
because of course we'll also need
to repush the users-api image soon,
because we also changed something there in the code.
We switched back to sending a real request
using this environment variable,
but that will be a next step.
For the moment let's go back to our deployment file
and make sure you added your auth container here.
Now I don't edit my service file there though,
because whilst my auth-api does listen on a different port,
it listens on port 80.
I don't wanna expose that port to the outside world,
after all the requests should be made Pod-internal.
So the users-api should be reachable from the outside world
but the auth-api should actually not.
So therefore in the service,
I don't wanna expose the auth-app,
the auth container port for the moment.
Instead in this service,
only one port should be exposed
which points at the users-port,
which will only be handled by the users-api,
which is part of the users-port.
The port exposed by the auth-api
is not exposed by this service.
So it shouldn't be reachable through the service.
I hope that makes sense.
So with that we've got both containers in one port
in one deployment.
Now of course we need to make sure
that all of that can be applied.
And for that we need to push the updated users-api image,
and we of course also need to make sure
that in the kubernetes world,
we provide a value for the AUTH_ADDRESS.
Now first things first,
let's first of all,
cd into the users-api folder
and rebuild the image there
with that tag of kub-demo-users,
which was the image name I used before,
and which is the image name being used here
in the deployment yaml file.
And then of course, push it again
so that we have that latest version of that image
with the updated source code,
pushed to dockerhub,
and then let's apply our changes.
And for that, of course, let's ensure
that we provide a value for AUTH_ADDRESS.
And the big question now is,
which value should be provided here
in the kubernetes cluster world?
What's the correct address for that users-api,
to be able to talk to that auth-api,
which lives in the same port,
but in a different container?