We need the IP address,
which has generated for this auth-service.
Because as I mentioned,
with services, you get stable IP addresses.
And one service has it's own IP address,
and that IP address will not change,
and through that IP address,
the pods that are controlled by that service,
can be reached.
So that means we need to find out which IP address
this service has.
Now one way of doing that, is of course,
to go into our kubernetes folder,
and to apply the -f=auth-dash-service.yaml file.
And also maybe already the -f=auth-deployment.yaml file.
Apply that and with that of course,
we got a brand new deployment
and a brand new service.
And hence, if we run kubectl get services,
we see that new service here.
It's this auth-service.
And it's this IP address,
which is now available inside of the cluster.
So you will not be able to use that IP address
on your local machine.
It's only available inside of the cluster.
And we could use this IP address here,
as a value instead of local host.
So let's do that.
Let's insert this IP address here,
as a value for AUTH-ADDRESS.
And therefore let's now apply that changed.
f=users-deployment.yaml file,
which uses this new IP address.
And if you now get your pods,
you see the old two container pod is terminating,
and we got two different pods with one container
each up and running.
Because we also got these two deployments.
So that's working.
And if we now try to send
this login request it still succeeds,
the same as true for the signup request,
because we're using this IP address,
which we found for the service we created,
this IP address.
But of course manually getting this IP address,
is a bit annoying.
The good news is that it's stable,
it won't change all the time, so we could do that.
But still as I just said it is a bit annoying.
There is a more convenient way.
Kubernetes will give you automatically generated
environment variables.
In your programs, with information about all the services,
which are running in your cluster.
So here we got the auth and users-service
up and running basically,
and we automatically get environment variables.
In our code, by kubernetes, if we got these services.
And through these environment variables,
kubernetes will automatically give us information,
like the IP addresses of the different services.
So here in users-api, we could, for example,
take advantage of the automatically generated,
environment variables by accessing process.env
here in node js to use an environment variable,
but by using a different name,
a name automatically generated by kubernetes.
And that is your service name,
all caps with dashes replaced by underscores.
So in my case, since I wanna reach out to the auth-service
here,
it would be auth-service transformed to AUTH_SERVICE
all caps,
and then _SERVICE_HOST.
And this pattern, environment variables of this pattern,
are created for all your services.
So the AUTH would be a USERS_SERVICE_SERVICE_HOST
variable here,
because we've got this users-service up and running as well.
But of course we don't need that here,
we need the auth-service environment variable.
And this is automatically generated
and configured by kubernetes.
And this will hold the IP address,
which was automatically assigned for this service,
for this AUTH_SERVICE and this case.
Now, of course,
this kind of hurts us when we try to run
this with docker-compose,
we simply would have to make sure
that we use the same environment variable name here,
but ultimately of course, that's a problem we can solve.
but we then have the advantage
of getting the generated IP address automatically.
And here I will only replace it in the login route,
and not in the signup route so that we see both in action.
Our manual environment variable with the manually set value,
this one here.
And the automatically generated environment variable,
generated by kubernetes.
Again, to make sure that this runs with docker,
you would have to add this kubernetes
generated environment variable,
to your environment variables here,
in the docker-compose file.
Because of course in the docker-compose world,
this is not generated automatically.
With that though, if we redeploy our updated users image,
and then restart our deployment in the end,
it should again work
but now with the auto-generated environment variable.
Hence here, I'll switch into the users-api folder,
and rebuild the image
with the name of academind/kub-demo-users in my case.
And of course I should give that name with the -t flag.
And once this was built, we push it,
using the latest tag like this,
and now this updated code will be pushed.
And now if we go out of this into the kubernetes folder,
we can run kubctl apply -f=users-deployment.yaml file,
and to ensure that this happens here,
I will simply delete my currently running deployment,
and then apply it again.
Because otherwise this deployment wouldn't do anything,
because the file didn't change
and then kubernetes will not re-pull the image.
For that you would have to use a different tag,
which we change all the time.
But with that, I'm also recreating this.
The old pod is terminating and the new one is up
and running.
And now we should be able to still send both the login
and the signup request.
Though, of course, you should keep in mind,
that for the login request,
we are using this auto-generated environment variable,
which holds the automatically assigned IP address
for this AUTH_SERVICE.
So a signup, of course, it still works.
But if we now test login, that also still works.
Which proves that this auto-generated IP address
does its job.
And that's of course a very useful feature,
since it makes this whole gets the IP address process.
Very, very dynamic.