If you're just starting out with Docker, it's super easy to follow the examples, get started and run a few things. However, moving to the next step, making your own Dockerfiles, can be a bit confusing. One of the more common points of confusion seems to be:

Where are my Docker images stored?

- Everyone

Open your Docker-enabled command line and use the Docker pull address to download the image. This loads the SAP HANA, express edition image. If the file is to be stored locally, store it in the /data/ directory you created earlier. Create the json file: vi.json. Docker Machine on Mac. Step 3: Run a Multi-Service App. Easily connect multiple services together. Docker Compose is a tool for defining and running multi-container Docker applications. With Compose, you use a YAML file to configure your application’s services. Then, with a single command, you create and start all the services from your configuration.

I know this certainly left me scratching my head a bit. Even worse, as a n00b, the last thing you want to do is publish your tinkering on the public Docker Index.

Checkout my awesome new Docker image thoward/i_have_no_idea_what_im_doing.

Yeah. Not really what I want to do.

Even worse, for quite a while there was no way to delete something that you had published, so your shamefully awkward learning process was up there for good. Luckily, deleting published Docker repositories is now quite easy.

So let me start with this small assurance; Nothing you do will become public especially if:

You haven't made an account on the public index.
You haven't run docker login to authenticate via the command-line client.
You don't run docker push, to push an image up to the index.

Vocabulary

One of the things that contributes to much of the confusion around Docker is the language that's used. There's a lot of terminology which seem to overlap, or is a bit ambiguous, used somewhat incorrectly, or has a well-established meaning that is different from how Docker uses it.

I'll try to clear those up here, in a quick vocabulary lesson.

Image vs Dockerfile

This one is the least confusing, but it's an important distinction. Docker uses images to run your code, not the Dockerfile. The Dockerfile is used to build the image when you run docker build.

If you go browsing around on the Docker Index, you'll see lots of images listed there, but weirdly, you can't see the Dockerfile that built them. The image is an opaque asset that is compiled from the Dockerfile.

When you run docker push to publish an image, it's not publishing your source code, it's publishing the image that was built from your source code.

Registry vs Index

The next weird thing is the idea of a Registry and an _Index_, and how these are separate things.

An index manages user accounts, permissions, search, tagging, and all that nice stuff that's in the public web interface.

A registry stores and serves up the actual image assets, and it delegates authentication to the index.

When you run docker search, it's searching the index_, not the _registry. In fact, it might be searching multiple registries that the index is aware of.

When you run docker push or docker pull, the index determines if you are allowed to access or modify the image, but the registry is the piece that stores it or sends it down the wire to you after the index approves the operation. Also, the index figures out which registry that particular image lives in and forwards the request appropriately.

Beyond that, when you're working locally and running commands like docker images, you're interacting with something that is neither an index or a registry, but a little of both.

Repository

Docker's use of this word is similar to its use at Github, and other source control systems, but also, kind of not.

Three common head-scratching questions are:

What's the difference between a repository and a registry?
What's the difference between a repository and an image?
What's the difference between a repository and an index username?

In fact, this is a problem, because a repository is all of those things and not really any of them either. Further, when you run docker images you get output like this:

So, the list of images seems to be a list of repositories? Huh? Actually the images are the GUIDs, but that's not how you interact with them.

Let's start over with this.

When you run docker build or docker commit, you can specify a name for the image. The name is usually in the format of username/image_name, but it doesn't have to be. It could be anything, and it could even be the same as something well known and published.

However, when the time comes to docker push, the index will look at the name, and will check to see if it has a matching repository. If it does, it will check to see if you have access to that repository_, and if so, allow you to push the new version of the _image to it. So, a registry holds a collection of named repositories_, which themselves are a _collection of images tracked by GUIDs. This is also where tags come in. You can tag an image, and store multiple versions of that image with different GUIDs in a single named _repository_, access different tagged versions of an image with a special syntax like username/image_name:tag.

If we look at the output from docker images again, now it makes a little more sense. We have five different versions of the image named ubuntu, each one tagged slightly differently. The repository holds all of those under that name ubuntu. So, while it may seem like ubuntu is an image name, it's actually a repository name, indicating where it came from, or where it should go during a push.

Further, the repository name has a specific schema to it. An index can parse out the username from first part, and figure out where it is.

So, this the confusing part: Suppose there's a Docker image called thoward/scooby_snacks.

The official 'repository name' is thoward/scooby_snacks, even though we would normally think of the repository as just being scooby_snacks (eg, in GitHub, or elsewhere).

In fact, when the Docker documentation refers to a _repository_, it sometimes means the whole thing, username included, and sometimes only means the part after the username.

That's because some repositories don't have usernames (like ubuntu). The username is very important to handle separately, because it's used for authentication by the _index_, so that part of the repository name has its own semantics separate from the name, when it's there.

Local Storage on the Docker Host

So far I've been explaining the intricacies of remote storage, and how that relates to the confusing vocabulary, but running docker images shows you only what is local to your machine.

Where is this stuff? The first place to look is in /var/lib/docker/.

Open up the file repositories to find a JSON list of the repositories on your host:

Hey, that matches the output from docker images!

Checkout what's in /var/lib/docker/graph/:

Docker Mac Download

Not terribly friendly, but we can see how Docker is keeping track of these, based on the repositoriesJSON file which holds a mapping of repository names and tags, to the underlying image GUIDs.

We have two images from the ubuntu repository, with the tags 12.04, precise, and latest all corresponding to the image with id 8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c (or 8dbd9e392a96 for short).

So what's actually stored there?

The entries here are:

Docker Pull Image From Url

json - hold

Docker Pull Download Image Stored Mac