- [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.
- Installing Docker on Mac, Windows, and Linux
- Understanding the Docker flow
- Running processes in containers
- Managing, networking, and linking containers
- Working with Docker images, volumes, and registries
- Building Dockerfiles
- Managing networking and namespaces with Docker
- Building entire systems with Docker