-: In the last section, we learned how to temporarily
reconfigure a single terminal window
to access our Docker server
running inside the virtual machine.
I want to remind you again,
you have to rerun that command every single time
that you open up a new terminal window.
All right, so I'm gonna very quickly paste this
inside of here just to make sure it's really clear
that I'm going to reconfigure
my current terminal window right here.
Now I wanna talk to you a little bit about
why we would want to do this at all.
Why would we want to reach into the virtual machine
and take a look at the Docker server
and all the containers that are running inside there?
Well, I put together a couple of reasons that I think
you might want to do this,
this is not an exhaustive list by any means.
So I just want you to have an additional tool
in your little toolkit for working with Kubernetes
so that you can understand how to kind of get a better idea
of how to play around with all this stuff.
All right, so a couple of reasons that you might want to
mess around with Docker inside of our node.
The first reason is that you can use
all the same debugging techniques
that we had learned much earlier in this course
to inspect containers and get logs from them
and do all that kind of stuff
when you connect to the copy of Docker
running inside the node.
So for example, remember right here again
I just reconfigured my shell
so I'm gonna do a docker ps,
and when I do so I can scroll all the way back up to the top
and get the ID of my multi-client container right here.
So I'm gonna copy that ID.
Now, I can get logs outta that container
by doing a very classic docker logs,
and then the ID of the container.
Remember, this is something we covered way long ago
at the very start of the course.
Now in this case, our container has not emitted any logs,
so I get nothing back here
but I could do other commands as well,
such as, say, executing an arbitrary program,
or a secondary program inside the container.
So for example, if I want to start up a shell
inside of that container,
I could do a docker exec -it, then the container id,
and then I'll start up shell inside there.
And so when I do that, I can very simply get a shell
and I can start to poke around and get a better idea
of the state of my container if I want to.
Now, the one kind of caveat to this,
the one thing I want to mention,
is that a lot of these different debugging commands
are actually available through kubectl as well.
So for example, I can still pull logs using kubectl
from a very specific container,
and I can start up a shell and slide of a specific container
using kubectl as well.
As a very quick example of that,
I'll do a kubectl get pods.
I'm gonna copy the name of my pod right here,
and then I'll do a kubectl logs,
and I'll paste the name of the pod.
And again, I don't get anything back
because the container has not emitted any logs
but it definitely would retrieve logs
if any had been emitted.
I can also do a kubectl exec -it,
and then the pod name,
and then -sh on the very end to start up a shell.
And so the same thing right here,
yeah, I'm starting at a shell using kubectl as well.
So again, you can use all the knowledge
that you have of Docker to do a lot of debugging.
However, a lot of that stuff is already available
with kubectl.
So I'm gonna kind of leave it up to you
if you want to figure out how to do this stuff
through kubectl,
or if you want you to stick with your knowledge
that you've already gained of Docker,
and use those same techniques as well.
Now, the next reason that we might want to mess around
with Docker inside of our node
is so that we can do exactly what I did a little bit ago
inside the course,
where I manually deleted a container
and then we were able to observe that,
oh, hey it was restarted automatically.
So essentially, you can test Kubernetes' ability
to self-heal or restart crashed containers
or whatever it might be,
by reaching into there and deleting a container manually.
Now, that's not a great reason to do this,
but I just wanna say it's something
that you could possibly do if you felt like it.
Now, the other reason you might do this
is that if you're for some reason having a really tough time
figuring out why images are being cached
inside of your node, talking about Docker images here,
and if for some reason it feels like
you're not able to update the image
that a particular container is using,
you can always reach into the container,
access the copy of Docker inside there,
and say, hey, delete your image cache
and just blow away all the cached images that you have.
And so to do that, we could run the same command
that we had learned way long ago.
We can do a Docker system prune -a
and this will remove all stopped containers,
all unused networks, and all build cache,
and all images that are not being used at this point.
So I could just blow away everything inside there
if for some reason I felt like there was a big caching issue
with what was going on inside of my node.
Okay, so that's it, that's a couple of reasons
on why you would want to mess around with Docker
in the node.
Now, I just give these to you as like possibilities.
Again, I'm rather convinced that you can think of
some better reasons than what I've listed here
of messing around with Docker inside the node.
But again, I just wanted to give you a couple examples
to kind of get your brain going
and give you a reason to look into this feature
a little bit more.
All right, so let's take a pause right here,
and we'll continue in the next section.