So, were you successful?
Let's add it together.
And for that, I'll add a tasks.yaml file
which will hold all the resources
this tasks deployment needs.
And actually, here, we got two resources we wanna add,
a deployment and a service.
So I'll start with the deployment,
and here the apiVersion should be apps/v1,
and the kind of course is deployment.
Now we add metadata and give it a name,
just as we provide a name to all the resources
we create with Kubernetes,
and I'll name it tasks-deployment.
Next we add the specification for this deployment
and here, we therefore specify the number of replicas,
and I'll go with one here, you could of course go with more.
And I will also define the template for the ports
that should be added to this deployment.
And actually, I will already add a selector here
with the matchLabels key
and match by the app label with a value of task.
And then, here, in the template for this deployment,
so the template for the parts of this deployment,
I will add the metadata field and add the labels here,
and here add this task label
so app is the label name, task is the value
so that this selector is able to match these parts
created by this deployment.
Now, besides the metadata, just as in the other deployments,
like here, the users.yaml file,
we of course also need to add a spec here
to the template for the ports, so let's do that.
And now define how the port should be configured.
Now it's here where we wanted
to find the containers we plan on using.
So nested below spec in the template part,
I will add containers,
and then give every container a name like task.
So just as we did it before for the users-api,
actually to be in line I will therefore name it, tasks-api.
Then define the image which I have yet to create and push,
but I will name it kub-dep-tasks like this
on my academind repository.
And then I got some environment variables
and actually, we can grab the environment variables
from users.yaml because I will use
exactly the same environment variables
with exactly the same values here for this tasks setup.
So therefore, here, below image on the same level as image,
we add the environment variables for this container,
and there I got the MONGODB_CONNECTION_URI
environment variable and the AUTH_API_ADDRESS
environment variable.
Again, just as we had it in the users.yaml file.
And that's the configuration for this deployment.
Next, let's add the service,
maybe here above the deployment.
And here we got a apiVersion of just v1,
set the kind to Service, and of course,
give that service a name by adding a metadata here
and giving it a name of tasks-service,
and then add the specification for this service.
And here, as always, we need to select which parts
should be managed by this service.
We need to set up the type of service if we don't wanna go
with the default, which would be cluster IP,
and we of course, also needs to, well,
provide some information about the ports
which should be exposed by the service.
So let's start with the selector
and here, I'll of course select by the app key here
and look for a value of tasks, actually singular task.
Then, set the type here to LoadBalancer
because this service should be reachable
from the outside world, just like the user's service.
Because this will be a service I wanna
send requests to with postman.
And then for the ports,
just like on users.yaml, I wanna add one port.
So add one dash here with a protocol of TCP
and set the port for the outside world to 80, maybe,
but set the port that is targeted in the container
to the port I'm listening on.
So in the tasks-app.js file, I'm listening on port 3000,
so therefore, that's my target port here.
And that's the service and the deployment.
Now we don't need to add anything else here for the tasks
because in the code here,
I'm not doing anything which would require a volume,
and therefore, we should be good like that.
Hence, now I need to build and push this image
so that we can then launch the deployment
which of course needs that image.
So go into that tasks-api folder and build the image
and give it a tag, in my case, academind/kub-dep-tasks
and then, also make sure you create a repository
on docker hub, so there, create a new repository
and give it that same name you just gave
to your image which you built so in my case, kub-dep-tasks,
create that repository on docker hub,
and then, of course, push the image you just built
to docker hub, like this.
Now, let's wait until this is pushed
and once it is, we can of course try
using our brand new tasks.yaml file
and try applying it to our EKS cluster.
So here we go, now, navigate into the Kubernetes folder,
like this and there, run kubectl apply-f=tasks.yaml
and that should create the new deployment
and the new service.
And therefore, also automatically here on AWS,
a brand new LoadBalancer for that service.
Actually, as I mentioned, I also did tweak the source code
in the other folders auth-api and users-api,
so therefore, definitely also make sure
you rebuilt all these images,
therefore, I will actually go into these folders as well
and rebuild the images in these folders,
as well as the other image.
So all the rebuilt the kub-dep-auth image
based on the auth-api folder
and then of course also push that image,
and once that is pushed, I'll do the same for the users-api
because the code in there changed,
and of course, all the latest code should be on docker hub,
so that our deployments on EKS
pick up the latest image versions.
Let's go into the users-api folder
and build the image there as well,
with the appropriate tag, of course, like this
and now that it was built, also push it like this
and now, once that is pushed,
I will reapply the auth and the users.yaml file
and delete the existing deployments first,
so that the new images are picked up.
So let's go into the Kubernetes folder,
and run kubectl delete deployment users-deployment,
and then do the same for the auth-deployment
so that these deployments and ports are cleared
and then, also apply these files again,
so users.yaml and the auth.yaml file.
And with that, we will have applied all these changes.
If we now get our deployments,
we should have three deployments
and eventually, the user's deployment
should also be up and running.
Yes, here it is, and we got our various
ports up and running here as well.
Old ports are still shutting down,
and with that, we can now give this a try again.
And for that, I'll first of all get my services again,
to get all these external IP addresses.
And now we got two services with an external IP
because the tasks-service was also launched
with type LoadBalancer.
And therefore, on AWS, a new LoadBalancer
was created for it.
So let's give this a try now.
For this, I'll grab this address
of the new tasks service LoadBalancer,
and I'll head over to Postman and here on Postman,
I now try to get my tasks
by sending a get request to this URL,
so the URL I just grabbed slash tasks.
And for the moment, I'll not add anything else,
no extra header, no body, just a get request to this URL.
If we try this, we should get back a response,
which is good, but the response tells us
that we could not authenticate that user.
And that makes sense because actually this
is a request which requires authentication.
It needs token attached to the outgoing request
so that the API is able to verify whether
this request comes from a logged in user.
Now to get such a token, we need to send a log in request
to the other load balancers address
so the users services address, so this address here,
we send the request to that address, slash login,
and add a body with a email and password field
in JSON format and if we do that, with a valid password,
we actually get back such a token,
we can then grab this token, and of course for that,
by the way, you need that user, if you don't have that user,
send a signup request first with some user data
but once you have that, once you had did login,
grab that token, and then go back to the GET requests
from before to slash tasks, and add a header authorization,
and for the header, a value of bearer whitespace
and then that token, just copy and paste it in
and make sure this header is added
to the outgoing GET request and if you send this now,
you should get back a response with an empty list of tasks.
Now to change that, and to make that not empty anymore,
you can send a POST request to that URL/tasks.
So the URL for the tasks service with that
authorization header added as well, so that same header,
we added with the same value, on the get request
so authorization with bearer whitespace and then that token,
and since it's a POST requests, add a body,
which should be JSON data,
where you can add a title like learn Docker,
and then a text field for the title, learn it in depth.
So make sure you add this JSON data to
this post request, click Send,
and this task will be created.
And here you get the task which was sent back.
And if you now send the get request, again,
with the same token attached, you should see that task here.
If you log in with a different user, so here, for example,
with the test two user, which I also created,
you get a new token, and if you use that token
on the get request, as a value after bearer,
you will see that you get an empty list of tasks,
because this is a different user
and this user has no tasks yet.
Now we can also delete a task, and for this,
we need the ID of the task, which you for example,
got back when you created that task.
And then you can send a delete request here to this URL.
So the load balancer URL/tasks.
Also add your authorization header there
with that bearer token value.
So make sure you add that here as well on the Delete request
and then in the URL after slash tasks,
also add the ID of the task you wanna delete, for example,
this task here, which we just created and if you sent this,
you will get back that you're not authorized
if you're sending this from the wrong user.
But if I do log in with the first user, again,
who is the user that created the task,
and I use this user's token, like this,
and add this here, as a value for the bearer token,
then you will see that the task is deleted
and therefore, if I try to get my task again for that user,
I also get an empty list here.
And that is the challenge solved.
Now we got three main API's deployed
in our Kubernetes cluster, we got the auth-api,
which is cluster internal,
and we got two public facing API's
because their services use the load balancer type.
And all these services and ports are managed by Kubernetes.
And with help of EKS, this AWS service,
which gave us this Kubernetes cluster,
they can talk to each other we got a volume,
and therefore we applied everything we learned
over the last core section, in a real example,
on a real cluster, on a real cloud provider.