Now to get our hands dirty,
attached to find a very simple web application,
a very simple Node.js application
which just has two end points,
a get request to /nothing and one to /error
which will then crash this node application
with this code line.
I'll come back to that later.
And let's deploy this to our kubernetes cluster.
Now there's one super important thing
which is easy to forget now
with all that new kubernetes knowledge.
We still need to use Docker
to create an image based on this application
because kubernetes is all about containers.
And in order to run containers, it needs an image, right?
That does not change.
So while you'll learn about images
and containers still applies.
The only difference with kubernetes will be
that you don't run your containers on your own anymore
but we still need to create the images
which we want to run as containers.
So that's why I also added a Dockerfile to this project.
A very simple Node.js app Dockerfile
as we saw it many times throughout this course.
Setting a base image and the working directory,
installing dependencies, copying over the source code,
exposing port 8080
because that is the port we're listening on here.
And then running this app.js file with the node executable
when the container starts.
Now, we could absolutely run this application locally
but of course, I now want to run this on my cluster.
And for this I'll open up the terminal here in my IDE.
And first of all, build this image with docker build
and give it a name of maybe kub-first-app.
That's my name.
And of course you can pick any name you want.
This will now build this as an image
and for me it's super fast
because I already built it off screen before.
But there's nothing fancy about it,
we just built this image as we did it multiple times
throughout the course.
Now, once the image is built,
we kind of wanna send it to the Kubernetes cluster
but of course not like this, but instead as part of a pod
or actually as we learned as part of a deployment,
which will then create the pod
and they offered a container running into pod for us,
and it will also manage it for us.
And to do that,
to send this instruction to the Kubernetes cluster,
we first of all need to ensure
that this cluster is up and running.
Now, if you followed along in the last lectures,
that should be the case,
but you can run minikube status
to check whether it is up and running.
And you should see a bunch of running here,
which means this cluster is up and running.
If it's not,
you can restart it with minikube start --driver=docker
and then set the driver to virtual box if you installed that
or give docker a try,
which is actually pretty inception like,
because we would then use docker
to create a virtual environment,
a containerized environment in this case for the cluster,
which we simulate on our local machine
to then test Kubernetes which again is all about containers.
Boom, head explosion, but it should also work as a driver
so that is a virtual cluster,
this cluster in a virtual machine
is created with help of docker instead of virtual box.
And on windows 10 pro,
you should also be able to use hyper-V.
Now I already got the cluster up and running.
So with that, we can now send our image
or send the instruction to create a deployment
to that cluster.
And we do this with this kubectl, this kubectl command.
Remember that we also installed this tool
over the last lectures.
This is the command
which you always execute on your local machine.
So this will not change once we move to the cloud.
This always executes on the local machine
because this is the command we use to send instructions
to our kubernetes cluster.
So to master node and to control plane
in that cluster so to say.
So this is the command we need.
And now this actually supports a broad variety
of things we can do.
If you just type kubectl help,
you get a long list of commands you can execute.
So there's a lot you can do, and this can be overwhelming
but we actually only need a fraction of these things here.
Now, of course, you can always dive
in the official kubernetes docs if you wanna learn more
but I will also show you the most important things
throughout this and the next modules.
So here we wanna use the kubectl command
to create a new deployment object.
Because as I mentioned, you work with these objects,
which are then picked up by the Kubernetes cluster
to then do something.
And you create objects with the kubectl create command.
Now, if you just hit enter like this,
you actually get help for this command.
And you can see what you can create there,
basically these things.
And for the moment we need to create a deployment object.
And this is one of the most common objects you will create.
As a side note at the moment, by using this create command,
we are using this imperative approach of creating objects.
Later, I will also show you the declarative approach.
But for the moment we run create
and we run create deployment,
to create a new deployment object.
And this object is then also automatically sent
to the Kubernetes cluster.
So we don't need to run a separate command for this.
Now this deployment should get a name
and we could name it first-app,
but of course, this name is totally up to you.
And then we need to specify one important thing here.
We need to pass one important option.
And that's the --image option, where we wanna specify
which image should be used for the container
of the pod created by this deployment.
And this is --image=.
Now here, you could of course think that you simply use
that local image we just created, kub-first-app.
That's the image I just built locally.
But this actually won't work
as you will see if you hit enter.
You actually get a success message here.
But if we now run another command, kubectl get deployments,
we can see how many deployments we have in our cluster
to which we connected here.
By the way, kubectl was configured by minikube
to automatically connect to minikube
so we don't need to tell the command
that we wanna interact with minikube here.
So if I now run gets deployments,
I see all the deployments in my minikube demo cluster
and we see the deployment we just made.
But we also see this.
We have one deployment and zero of them are ready.
Which means one deployment of one deployment failed
which is not the best ratio to put it like that.
Now to get or insights, we can run kubectl get pods
and we'll now see all it's created by our deployments.
And we see one part created by the first-app deployment
but we see that here, one pod should be created.
This is the target states so to say,
but we don't have one pod created.
And here we see the reason it's an ImagePull error
and it should be pretty clear what's causing this.
When we created deployment
with this create deployment command
the image which we specify here
is not taken from the local machine
and sent to the virtual machine.
Instead, this command is sent to the Kubernetes cluster
and then the cluster will look for this image.
And since the cluster runs in a virtual machine,
which I guess technically of course,
is running on our local machine
but which actually acts like a totally separate machine.
This image, which only exists on our local machine,
but not in the Kubernetes cluster of course isn't found.
So instead of sending or specifying a local image here,
we should specify an image
which is part of a image registry like Docker Hub.
So they affirmed let's for the moment,
delete this first-app deployment.
So run Kubectl delete deployment first-app,
so that we remove that again.
Thereafter you'll have no pods anymore.
And let's now push this image from our local machine
to Docker Hub.
For that on your Docker Hub account,
create a new repository and I'll name mine kub-first-app.
And therefore it can later be found
under your account named slash this name,
create it, and then you learned how that works.
Let's re-tag our local kub-first-app image
as your Docker Hub account named slash
and then your repository name.
So in my case, I tag it like this
and thereafter we can run docker push
and then this repository image name.
And now it does this being pushed to Docker hub,
and that means that now it can be accessed
from anywhere in the world, including our cluster machine.
So with that if we now run this again,
the create deployment command
but now we point at this remote image.
So this image on Docker Hub,
and hence we adjust the image name here.
If we tried this now,
you will see that if you now get your deployments,
you will eventually have one over one ready deployments.
Initially, whilst it's starting up,
you could still see zero over one here,
but eventually you will have one over one here.
And therefore, if you run get pods,
you will also have one over one ready pod here
with a status of running.
So this is looking good now,
our application is up and running.
Of course at the moment, we can't really reach it though.
So that's something we're going to work on,
but to see at least something, we can run minikube dashboard
which you might remember is this web dashboard
which we can open up.
This now is a process which needs to stay up and running
at least as long as you wanna visit that dashboard.
And it should open up the dashboard
and the new browser window automatically
if not, simply use that link, which you get here.
And this is now our cluster.
And here you should see your deployment
the first-app deployment
and also all the pods which are up and running.
You'll also see that this pod has a label
which is basically some metadata attached to it,
which identifies the application
and the deployment that belongs to.
And you can also look into these things
and you'll see more information about the deployment
it's status and so on.
And if you look into your pod,
you also can learn more about that.
For example, you can also find an IP address here
but this will only be the internal IP address
inside of the cluster.
So if you try using that in your browser to reach that pod,
this won't work,
even if you use the port exposed by the container.
So for the moment this won't work
but we'll see how we can reach this pod
and this container later.
So that is all working, now I wanna take a brief look
behind the scenes of what happened here
before we then ensure
that we can actually see and visit this webpage,
which was created by the container,
which has part off that pod we deployed.