So updating isn't too hard.
Now let's try something which will fail.
If I try this set image command again,
but I use a tag, which doesn't exist, actually,
it will still try to update this, but it will fail.
And you can tell that it will fail
by running another command,
which allows you to inspect the progress of your rollouts.
That's the kubectl rollout status deployment/
your deployment name command.
This actually tells you,
what's currently going on for this deployment.
And for example, here you see
that we're waiting for a deployment to finish.
And at the moment, the old replica,
so the currently running port is shutting down,
you could say, and please note that I can't execute more
commands here at the moment.
Because this rollout status command
enters an interactive session,
where we keep on listening to what's going on,
you can always get out of that with Control + C.
Now if we have a look at our dashboard here, under pods,
we see that we're facing some problems.
This old replica is not terminating,
because the new pod is not starting up successfully.
And it has issues with pulling the image,
you see it fails to pull the image.
So it's pretty good that
because of that rolling update strategy Kubernetes uses,
it doesn't shut down the old pod
before the new pod is up and running.
So that's good to have.
But of course, here,
our update will never finish therefore,
because the new pod never starts.
Because in this case, I had a typo in my image tag.
So what does this mean?
It means that we want to roll back this update,
so that we don't want Kubernetes to continue with it.
Now, first of all, let's quickly get our pods here
to see the pod which is stuck,
where it tried to pull an image which it doesn't find,
so that it eventually stopped trying this.
And let's now roll back this problematic deployment,
which clearly won't complete here.
To roll back, we can run
kubectl rollout undo deployment/first-app.
And this will undo the latest deployment.
So if we now check our pods again,
this problematic pod is gone.
And if we have a look at our status,
we see here we're back to successful.
And our application, of course,
still is up and running here.
So this is how we can roll back a deployment.
Now if you wanna go back to an even older deployment,
so not just to the previous one, we can first of all
have a look at the deployment history
with kubectl rollout history for our deployment
with the name first app.
And we see the different deployments we made.
We can also have details about a deployment,
by adding --revision here.
And then using one of these revision identifiers,
let's say three.
And we see which image was he was here,
so that for example is the image which broke.
And a couple of other things here.
Not too useful to us here, though.
But if I, for example, have a look at the revision one,
we see that this is our original deployment,
which use that latest tag on our image.
Now let's say we wanted to go back
to that original deployment.
Instead of just running kubectl rollout undo like this,
we can add the --to-revision option
to specify a specific revision,
we wanna go back to it, in this case, one.
And if we do that, you will see the old code here
because we're going back to that first deployment,
which was based on the original image,
and therefore on the original source code.
So here, if I reload, I'm back to my old output.
So is that we actually already
took a little bit of a deeper dive into Kubernetes, I guess.
But I find it quite interesting to see
what you can do with Kubernetes and with deployments,
and I find it super important
that you see what Kubernetes does for you.
And this pod management,
automatic creation and removal
and restarting pods and containers,
and the rollback of deployments and so on.
These are all super useful features,
which of course can make your life way easier
if you're deploying big applications
to production ready clusters.
With it however, we played around
with these commands enough.
Now I wanna switch from that imperative approach
which we used this far
by executing all these commands to a declarative approach,
which will make working with Kubernetes, even more fun.
Now to switch, let's first of all
delete our service first-app
by running kubectl delete service first-app.
Let's delete the deployment
by running kubectl delete deployment first-app,
so that we ensure that all these resources are removed.
Therefore, of course now,
you can't visit the application anymore.
And the deployment and pods will disappear here in the end.
But with that, let's now move on.