For pod-internal communication
so when two containers run in the same pod,
and that's important, only then,
kubernetes allows you to send a request
to the localhost address and then using the pod
which is exposed by that other container.
So localhost is the magic address
you can use inside of a pod.
So if you have one container running in a pod,
which executes some code
which also runs on the server side so to say,
ends up the pod, and that code needs an address
you can use a localhost as an address
if you wanna send the request
to another container running in the same pod.
Therefore here, in the users-deployment,
for our users container, we wanna add the env field
to provide a value for that
AUTH_ADDRESS environment variable, in that users container
and then as you learned in the last core section
for env, we can have multiple environment variables.
And for every environment variable
created with such a dash here, we provide a name
which is the name of the environment variable.
So in my case AUTH_ADDRESS
and then we also have a value
and we could get that from a file
as shown in the last section
but here, I will just hard-code it
into debt's deployment file and use localhost,
and this should do the trick.
Now we provide auth as an address
in the docker-compose world using that other services name
and we use local hosts in the kubernetes world
which should work since that is the special address
that can be used inside of one and the same pod,
if two containers running in that same pod
wanna communicate with each other.
So, if we now save this,
we can go out of that users API folder
into the kubernetes folder and apply
the updated users-deployment.yaml file.
This updates, the deployment
hence if we now run get pods,
we see that one pod is being created now
and the containers are being created there.
And once that finished
we see the old pod is being terminated
and the new pod is up and running
and there we got two containers in the pod.
That's what this 2/2 means two containers
and both are up and running.
So that's looking good we got two containers up and running.
Now let's see whether that really all works.
Our service IP and the service address exposed by minikube
didn't change in the meantime
changing the deployment does not change the service
and therefore we should be able to send
that same sign up request again, in postman.
So a POST request to that minikube exposed
IP address and port
two slash signup with some raw JSON data attached
an email address and a password
and if I click send, this is looking good.
This is looking good because if something would fail
about sending that request here, when we sign up
sending that request to the off service,
if something would fail about that,
we should not get back 'User created' as a response,
instead, if this would throw some kind of error,
because the address isn't found or anything like that,
we should actually get back an error response
and we are not which proves that it works.
Now let's try sending the same request data
to the slash login service.
and we get back token 'abc',
which again, proves that it works
because that token value, is actually not created
in the users service file here
but in the auth-app.js file.
Is here where this token is being generated
and where this value of 'abc' is being sent back.
So that again proves, that it works
because we're using localhost as an address name here
since we got two containers running in the same pod,
and then for the pod-internal communication,
we can use localhost.