- [Instructor] So we can see we went from an Image
to a Running Container.
When we ran that container again,
we got the same thing we got the first time.
And that's the whole point of images,
it's they are fixed points where you know
everything's good and you can always start from there.
Now when you've got a Running Container,
you make changes to that container, you put files there,
it's very useful, when you want to be able
to actually save those.
The next step in the Docker flow is a Stopped Container.
So the container that's running is alive,
it has a process in it.
When that process exits, the container is still there,
so that file I created a moment ago,
when I exited that container, it's still there,
I can go back and find it, it didn't get deleted,
it's just that it's currently in a Stopped Container.
So I can look at the most recently exited container
with the docker ps command,
just like I do when I want to look
at the Running Containers, except Stopped Containers
don't show up by default.
To see Stopped Containers, I can specify the -a argument
to see all containers, a for all.
And if I just want to see the last container to exit,
I can do docker ps -l.
Now since I just exited a container right there,
I'm gonna say docker ps -l, because I want to look
at the last one, let me put in my format argument
to make it fit nicely on my screen.
I see I have a container, that's the container ID
from this one right up here that I just exited,
you see the image that it was started from,
the command, I had run bash, I made it five minutes ago,
and it exited with an exit code of 127,
that's just the return value of whatever process you ran.
Zero generally means success, in that case it was a shell
and I exited it so that it returned 127.
Looking at these exit codes can be a good clue
as to why a container died.
If you expected a container to be running
and you find to be stopped for some reason,
this can often give you a clue, right.
This container doesn't have any networking going on
and Docker can be newly made up a name for us.
So now I have a Stopped Container.
Alright, now say I've got a Stopped Container
that has a file in it I want to use for the future.
I started from a base image, I installed my own software,
I've got a container that has my software installed on it.
The next step is the Docker Commit command.
That takes containers and makes images out of them.
It doesn't delete the container,
the container is still there, now we have an image
with the same content that was in that container.
So Docker Run and Docker Commit
are complementary to each other.
Docker Run takes images to containers
and Docker Commit takes containers back to new images.
It doesn't overwrite the image
that the container was made from.
So now we can make a new image.
Let me go ahead and show you that.
So if I start with the Ubuntu image,
docker run
- ti
Ubuntu,
the latest tag is actually optional.
If you don't specify a tag, Docker will fill in
the word latest for you.
So I'm gonna go ahead and omit that.
Run a container, let's take a look,
totally blank, normal Ubuntu container,
and I'm gonna make a file.
My
important
file
Okay, now that I've finished editing this container,
going to exit by pressing Control + D,
you can also just type exit,
and I'm going to look at the most recently exited container.
There I see, alright.
Docker
commit,
and I'm gonna grab that container ID, copy,
paste, so I've got a container ID,
and I'm gonna make an image out of it.
Boom!
I just got an image ID out of it.
Looks very different from a container ID.
Now
I have made a new image.
The original Ubuntu image is unchanged,
I have a new image, and it just has a big number,
not very convenient.
So the last step in the Docker flow is the tag command
to give images names.
I can say
docker
tag
gonna grab this big image ID, everything after the colon,
copy,
paste it in here, and I'm gonna call this
my
image.
Alright.
If I run docker images we can see I have a new image called
My image.
I can say
docker
run
ti
my
image
and it has my important file in it.
Committing images and then tagging them
is such a common pattern that it's actually
built right into the Docker Commit command.
So you can skip the steps about copying the image name
over to a Docker tag command, and just run
Docker Commit,
the name of the container,
right, it's nice human readable name,
and then you can, as the next argument,
say the name you'd like it to be tagged as.
So I'm gonna say, let's make another image
out of that container, and I'm gonna call that image
my
image
two,
and that went ahead and did the same thing.
You can see it printed out the same container ID as before.
Docker images, and it made a new image,
I just had one extra step.
This is the format you should probably use
in all of your day to day life.
There's no reason to go through the extra step
of doing a commit, then running Docker tag,
but it is very important to understand
that that's what's happening under the hood.
And there we have the Docker flow.