Let's have a look at the tasks-API,
there we got one JavaScript file.
and in the end here,
we're also sending a request to the auth-service.
At the moment, I still got auth hard-coded in the code
because in the past it only had to work with docker-compose
and dare using the service name like this, did work.
Now we only got one line of code
where we are sending a request to Naver service,
and that is this one line
so we don't need to worry about the rest of the code here.
Nonetheless, of course, we need to adjust this
and to make this flexible,
I will replace it with an environment variable
so that this again works with both Kubernetes
but also with docker-compose.
So I'll use a similar approach as before,
and now here, we got two options.
We can use the automatically generated environment variable
for the auth-service,
since that's the service we wanna talk to here
or we of course use our own environment variable
and pass in the service name in the docker-compose world
and the service domain name in the Kubernetes world
and I'm going to do that.
I'm going to name it AUTH-ADDRESS here as well,
though this environment variable name is totally up to you
and I'm going to save this file
in the docker-compose yaml file,
just to ensure that this also works again.
I will therefore add AUTH-ADDRESS
and set this to auth,
which is my service name here in the docker-compose file.
But now more important than that
we can of course create a new tasks-deployment dot yaml file
and a new tasks-service dot yaml file.
We need a task-service
because this tasks container
and the Pod in which it is running
should be reachable from outside
through Postman, for example.
So let's start with the tasks-deployment
and here we can really use the users-deployment code.
Copy that into the tasks-deployment yaml file
and just change the name here to tasks dash deployment
to selector, and this label here to app tasks
and to container of course,
I'll label this or I'll name this container tasks as well.
And we'll need to push our image
and I expect to get an image here,
which has a name of kub dash demo dash tasks.
We also need the AUTH-ADDRESS environment variable,
at least that's the name I just chose
a couple of seconds ago.
So I wanna provide this here
and of course I wanna use the domain name
for my auth-service.
So this also doesn't change here
and that's the task-deployment configured already.
Now for the task-service,
it's very similar to the users-service,
so we can copy that as well,
but of course rename it
and select our ports with an app label auth tasks
and set the type to LoadBalancer
and that's important.
It's not clusterIP
because tasks should be reachable from outside the cluster.
Hence, we typically use LoadBalancer
since this gives us a great way of exposing a stable IP
to the outside world.
Now for the ports that should be mapped,
we can take a look at the dockerfile
and we see that it listens on port 8,000.
So that's the port I wanna use here in my tasks-service
and with that, the services declared
that the deployment is declared.
Now we need to create the image and push it.
So for this on docker hub,
we create a new repository of course,
and name it, kub-demo dash tasks
and of course, make sure you're using the name here,
which you defined in your tasks-deployment file
and create this repository.
And then let's go into that tasks-API folder,
and build that image with a tag of your
docker hub account names slash kub dash demo dash tasks.
So that this image is built
and once it is built,
we of course wanna push it
just as we did it multiple times before
for the other images like this.
So this will now be pushed
and once it is pushed,
we can apply our deployment and our service here
and everything should work thereafter.
So let's wait for that to be pushed.
Let's then go out of this folder
into the Kubernetes folder here.
We don't need to stop our existing deployments
these can continue running.
I just, in addition,
wanna apply my tasks-service yaml file
and my tasks-deployment dot yaml file,
so these two new files we added.
This creates the new service and the new deployment
and hence here with get deployments,
we see that this new deployment is coming up with get pods.
We see that it's trying to launch this,
but we also see something is wrong here,
something is not working.
So what could be the issue here?
What's failing about this file?
Why is it not starting?
Well because there's a little trick here.
This file actually uses more than one environment variable,
you see that in the docker-compose yaml file.
We also provide the folder name
in which the tasks text files should be stored
through the TASKS-FOLDER environment variable.
So of course, we still have to provide that
when using Kubernetes.
Hence, in the tasks-deployment yaml file,
we wanna add an additional environment variable
for the tasks container
with the name of TASKS-FOLDER,
which simply is the environment variable name expected here
in the tasks-app JavaScript file.
And then we wanna provide a value here auth-tasks,
because that is the folder name I'm using here.
That is the folder I pre-created as an empty folder
and therefore that is the folder name we wanna use
in the Kubernetes world as well.
So with that fixed,
we can apply the updated tasks-deployment dot yaml file,
which now does provide this environment variable.
And now if we get our deployments,
we see the tasks-deployment is also up and running
and ready.
Of course, if we get our pods,
we also see all the pods are up and running.
And with that now,
we just need to ensure that we can send the request
to the new task-service.
So if we get our services,
of course, we see
we got this new task-service here,
it's of type LoadBalancer
and just as with the users-service
to get the externally awaitable IP address here,
when using minikube,
we need to run minikube service and then the service name.
So in this case tasks-service,
and this gives us a new URL,
which we can use to send requests to this tasks-service.
The URL of the user-service,
to which we for example, sends to signup request
does not change,
but we now can use this new URL
to send the request to slash tasks.
A simple get request to get our tasks.
Now, if you try sending this like this,
you should get a no token provided error.
So make sure that here in Postman,
you add headers,
and then you add authorization key here
simply by typing it and making sure it's checked
and then add bearer white space,
and then abc,
which is a valid token in this dummy application.
Now, initially you'll get a loading
the tasks failed error back here
because we have no tasks initially.
So make sure you send a post request
to the same minikube exposed URL slash tasks.
Make sure under headers,
you add that authorization header
with a value of bearer white space abc
and under body, add a raw body of type JSON
with curly braces
and then text and title between double quotes
and then separated with colons,
the values for these fields,
like a first task and do this too,
also between double quotes.
And if you tried this and you sent this request,
you should get back task stored.
And if you then try to get request again,
you should get back task loaded.
And if you will enter an invalid token, like just ab,
you should get back a request failed with status code
for or one error.
Which proves that
sending this request to the auth-service works
and validating the dummy token there works.
And that of course shows that this tasks-app here
was deployed correctly
and that it is able to interact with the auth-service
and the outside world
because of its own service of type LoadBalancer,
and with the auth-service,
because of that domain name,
the automatically generated cluster internal domain name,
which we're using here.