-: In the last section
we started investigating the life cycle of a container
by using the docker create and docker start commands.
We're now gonna start to investigate the status
of some of those containers that we've already
started up on our machine,
but have closed down for some particular reason.
So we can print those all out with dockerps--all.
You'll notice that I have just one container
listed as exited now,
whereas before I had like 30.
The reason for that is that I ran a command
between the last video and this one
to kind of par down that list.
And of course I will show you that command
in just a second as well.
So at this point, the only stopped or exited container
that I have on my machine, is this one right here.
Let's try creating and running and then stopping
one more container just to make sure
that we're kind of on level footing.
So I'm going to execute docker run BusyBox echo hi there.
If I then do dockerps--all again,
and then zoom out so I can see this a little bit better,
there we go,
I'll see the ID of that container.
I'll see the echo hi there, and I can definitely verify
that its status is definitely exited right now.
When a container is exited, we can still start it back up.
So just because a container's stopped,
doesn't mean that it's like dead or cannot be used again.
We can very easily stop and then start containers again
at some point in the future.
To start a container back up,
we can take its ID and then execute docker start
and paste that ID in.
Remember that if we use docker start without the -a flag,
however, we won't see any output from it.
And so it might be a little bit more useful
to do docker start -a and then the ID.
And when I do that, you'll notice that it
printed out hi there again,
which is kind of interesting.
Let's take a look at a diagram to really understand
this entire series of commands that we just issued.
All right, here we go.
So we've got our BusyBox image, and at some point in time
we definitely ran docker create or docker run,
that took our file system snapshot
and essentially got a reference to it inside the container.
We then provided that override command of echo hi there.
So that was the primary running command
inside the container.
That command ran, it then completed,
the container exited it naturally,
and we then ran the docker start command a second time.
What happened was the running process
or this primary command,
was issued a second time inside the container.
When you have a container that's already been created,
we cannot replace that default command.
As soon as you start it up with the default command,
that's it, the default command is then in place.
So we cannot do something like say docker start -a the ID,
and then try to replace the default command.
I can't do something like echo bye there.
So in theory, this would be us trying to replace
the default command.
Again, can't do that.
And if we try to run it,
it's going to misinterpret the command that we just issued.
It's thinking that we're trying to start up
multiple containers at the same time.
So, once we have started up a container, and let it exit,
we can start it back up again,
which is going to reissue the default command
that was used when the container was first created.
All right, now it might seem like
going over all this life cycle stuff is kind of unimportant.
It might seem like I'm going
really far into the weeds with it,
but trust me, having a solid understanding
of the life cycle of a container
is gonna be so incredibly useful later on,
when it really comes down to figuring out
how to troubleshoot these things
and debug a running container.
So I think we got a better idea
on the the life cycle of a container.
So let's take another quick break,
and continue in the next section.