- [Instructor] Looking at the container output
of a container that's already finished is
something that can be very frustrating.
You start up your container, it didn't work,
you want to find out what went wrong.
The docker logs command is key for this.
Docker keeps the output of the container available.
It keeps it around as long as you keep the container around.
And you can use docker logs container_name
to look at what the output was.
I'm gonna start a container to do
some very important work here.
I'm gonna say, docker run.
And I'm gonna give this container a name, example,
so that I can find it easily afterwards.
And I'm gonna run this as a detached container.
I just want it to run in the background.
I don't want to actually look at it,
I just want it to go and do its thing.
I'll run it in the ubuntu image
and I'm gonna give it a process, bash,
and I want that to run a command line.
And I'm gonna sell it to run less /etc/password
so that I have a terminal running,
looking at the password file.
But I've got a typo right there,
I typed lose the password file.
So this isn't gonna work, it's totally gonna crash.
So later, when I notice that it isn't running,
I can go and look what went wrong
with docker logs example.
Oh, lose: command not found, and then I go fix it.
Don't let the output of your docker containers get
really, really huge, this is one
of those side effects of convenience.
It's very convenient, being able to go back and look at it.
And if you are writing tons and tons of data to the output
of the process in your docker container,
you can really bog down docker to the point
where your whole system becomes unresponsive.
Stopping and removing containers, so,
you can kill a running container.
And when you've killed it, it goes to the stopped state.
And when you're done with a container
in the stopped state, you remove it.
So kill container_name makes it stop,
and rm makes it be gone.
So I'm gonna run a container here.
The same example we've seen several times.
Okay, we got a container there.
Over here, I'm gonna look at my running containers.
There's my running container.
Now, let's say I want this container gone,
docker kill, container name.
You can also kill it by the ID if you want.
All right, look, I just got kicked out of there.
Now, if I run docker ps again and give it the -l
for the last container to exit, I can see
there's my container, it exited 16 seconds ago.
So let's go ahead and clean that up.
When you're using containers with fixed names,
if you later want to start another container
with the same name, you'll very often get an error saying
that container already exists, you can't use that name.
And it's because you need to go
through an rm to remove the old container.
Stopped containers still exist
until you explicitly remove them.
One of the big features
of docker is the ability to enforce limits
on how many resources a container's gonna use.
You can limit it to a fixed amount of memory.
You can say docker run --memory maximum-allowed-memory
and that prevents runaway containers
from clobbering the rest of the system.
You can equally limit the CPU time.
You can limit relative, you can say give
this container half of the total CPU time,
and the other one the other half,
so that if one's not busy, the other can use more CPU,
but then it will enforce that they have equal access.
You can also give them hard limits.
You can say this container only gets to use 10%
of the CPU total ever, even if 90% of the CPU time is idle.
Most of the orchestration systems that are covered
in a later chapter generally require you
to state the limits of a particular task or container.
Now, a few lessons from my bad experiences and my good.
Lesson one, don't let your containers fetch
their dependencies when they start.
If you're using things like Node.js
and you have your node starts up and then
when the container starts it fetches its dependencies.
Then, some day, somebody's gonna remove some library
out from the node repos, and all of a sudden,
all your containers just stop
throughout your whole system, it's terrible.
Fetch make your containers include their dependencies
inside the container themselves, saves a lot of pain.
Also, from a sort of different perspective,
a little security hat here, don't leave important things
in unnamed stopped containers.
Don't do a week's worth of work and just leave it sitting
in a stopped container on your laptop
because you'll inevitably come along
and say, my disk is full, ah,
I gotta clean up some stopped containers.
And then delete the seemingly unimportant container
and then your important stuff is gone.
So be careful what you leave sitting
around in unnamed containers.