Now, the approach of using the automatically generated
environment variables, works.
And of course, just to clarify this,
not just in node js applications,
any programming language supports this concept
of environment variables.
The exact code simply then depends
on the programming language.
But this approach works.
Nonetheless, there is an even more convenient one.
Because Kubernetes clusters by default,
when using a modern version of Kubernetes,
come with a built-in service called, CoreDNS.
Now CoreDNS, as the name suggests, is a domain name service,
which in the end helps with creating domain names.
And here I'm talking about cluster internal domain names
which means, not domains you could enter
into the browser, because they will not be registered
with global domain name services.
But instead, domains which are known inside of your cluster.
So just like IP addresses, known inside of your cluster,
there will be domain names, known inside of your cluster.
And this CoreDNS thing,
this service which is installed in your cluster,
automatically creates domain names
which are available and known inside of the cluster,
for all your services.
And now that only leaves one question.
Which domain names would that be?
For that I'll go to the signup request
and replace this environment variable here,
where we still use auth address.
And I wanna pass in a different value for auth address,
not the IP address, which we used before,
but instead this automatically generated domain.
Which again, will only be known inside of your cluster.
But since the code in this user's app js file runs
inside of the cluster, that will not be a problem.
And here the pattern is very simple.
It's your service name.
So if you wanna send a request to the auth-service,
which in my case has a name of, auth-service,
you can simply use auth-service here,
as a domain to send your request to.
And that's of course very similar to Docker compose.
There we could also use our service name,
a service and Docker compose
was a slightly different concept.
In the end it's a container.
But we could use that name to send our requests to.
In the Kubernetes world, now again, it's very similar,
We just use our service name.
Now actually, it's not just your service name,
instead it's your service name, then a dot
and then the namespace this service is part of.
Namespaces are a concept which we haven't talked about yet.
In the end it is a concept which allows you to assign
services and deployments and so on,
to different namespaces within one of the same cluster,
to, for example assign them to different teams
or projects or whatever.
So simply a way of differentiating and grouping
your resources, you could say.
And you can see which namespaces you've got
by running Q control, get namespaces.
And here on mini cube, we got a couple of namespaces
and it's the default namespace to which our services
and deployments are assigned.
If we don't tell Kubernetes to do it in another way,
which we're not doing here
because we don't need this slightly advanced feature here.
So therefore, we need to add dot default here.
So, service name, dot and then namespace name.
And if you don't assign it to a different namespace,
it's the default namespace.
And this is then the address which can be used inside
of the code running in your cluster to send requests
to our services of that cluster.
So, with that, we don't need to change anything
about any code.
I just changed the value for the
auth address environment variable.
And hence, we just need to apply
this updated, users, dash, deployment, dot yaml file.
And now we still should be able to send requests
to slash login.
Because there nothing changed on the login route.
I'm still using the auto generated environment variable.
But we should also be able to send requests to slash signup,
where I use my own environment variable,
which now receives this automatically generated domain name
as a value.
So if you try sending a request to signup, this also works.
We're not getting an error here.
And it works because this is automatically generated
by Kubernetes and this built-in CoreDNS feature.
And therefore, it's super easy to send requests
to other services.
Because we get these auto-generated domains
which we can use in our code to send requests around.