Working with Docker images

In the previous chapter, we demonstrated the typical Hello World! example by using a busybox image. Now there is a need for a close observation of the output of the docker pull subcommand, which is a standard command for downloading the Docker images. You would have noticed the presence of the busybox:latest text in the output text, and we will explain this mystery in a detailed manner by bringing in a small twist to the docker pull subcommand by adding the -a option, as shown here:

$ sudo docker pull -a busybox

Surprisingly, you will observe that the Docker engine downloads a few more images with the -a option. You can easily check the images that are available on the Docker host by running the docker images subcommand, which comes in handy, and it reveals more details with respect to :latest and the additional images that are downloaded by running this command. Let us run this command:

$ sudo docker images

You will get the list of images, as follows:

REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
busybox ubuntu-14.04 f6169d24347d 3 months ago 5.609 MB
busybox ubuntu-12.04 492dad4279ba 3 months ago 5.455 MB
busybox buildroot-2014.02 4986bf8c1536 3 months ago 2.433 MB
busybox latest 4986bf8c1536 3 months ago 2.433 MB
busybox buildroot-2013.08.1 2aed48a4e41d 3 months ago 2.489 MB

Evidently, we have five items in the preceding list, and to gain a better understanding of those, we need to comprehend the information that is printed out by the Docker images subcommand. Here is a list of the possible categories:

• REPOSITORY: This is the name of the repository or image. In the preceding example, the repository name is busybox.
• TAG: This is the tag associated with the image, for example buildroot-2014.02, ubuntu-14.04, latest. One or more tags can be associated with one image.

  Note

  The ubuntu-* tagged images are built by using the busybox-static Ubuntu package and the buildroot-* tagged images are built from scratch by using the buildroot tool-chain.

• IMAGE ID: Every image is associated with a unique ID. The image ID is represented by using a 64 Hex digit long random number. By default, the Docker images subcommand will only show 12 Hex digits. You can display all the 64 Hex digits by using the --no-trunc flag (for example: sudo docker images --no-trunc).
• CREATED: Indicates the time when the image was created.
• VIRTUAL SIZE: Highlights the virtual size of the image.

You might be wondering how, in the preceding example, a single pull command with the -a option was able to download five images, even though we had only specified one image by the name of busybox. This happened because each Docker image repository can have multiple variants of the same image and the -a option downloads all the variants that are associated with that image. In the preceding example, the variants are tagged as buildroot-2013.08.1, ubuntu-14.04, ubuntu-12.04, buildroot-2014.02 and latest. A closer observation of the image IDs will reveal that both buildroot-2014.02 and latest share the image ID 4986bf8c1536.

By default, Docker always uses the image that is tagged as latest. Each image variant can be directly identified by qualifying it with its tag. An image can be tag-qualified by appending the tag to the repository name with a : that is added between the tag and the repository name (<repository>:<tag>). For instance, you can launch a container with the busybox:ubuntu-14.04 tag, as shown here:

$ sudo docker run -t -i busybox:ubuntu-14.04

The docker pull subcommand will always download the image variant that has the latest tag in that repository. However, if you choose to download an image variant other than the latest, then you can do so by qualifying your image with the tag name by using the following command:

$ sudo docker pull busybox:ubuntu-14.04

Docker Hub Registry

In the previous section, when you ran the docker pull subcommand, the busybox image got downloaded mysteriously. In this section, let's unravel the mystery around the docker pull subcommand and how the Docker Hub immensely contributed toward this unintended success.

The good folks in the Docker community have built a repository of images and they have made it publicly available at a default location, index.docker.io. This default location is called the Docker index. The docker pull subcommand is programmed to look for the images at this location. Therefore, when you pull a busybox image, it is effortlessly downloaded from the default registry. This mechanism helps in speeding up the spinning of the Docker containers. The Docker Index is the official repository that contains all the painstakingly curated images that are created and deposited by the worldwide Docker development community.

This so-called cure is enacted to ensure that all the images stored in the Docker index are secure and safe through a host of quarantine tasks. There are proven verification and validation methods for cleaning up any knowingly or unknowingly introduced malware, adware, viruses, and so on, from these Docker images. The digital signature is a prominent mechanism of the utmost integrity of the Docker images. Nonetheless, if the official image has been either corrupted, or tampered with, then the Docker engine will issue a warning and then continue to run the image.

In addition to the official repository, the Docker Hub Registry also provides a platform for the third-party developers and providers for sharing their images for general consumption. The third-party images are prefixed by the user ID of their developers or depositors. For example, thedockerbook/helloworld is a third-party image, wherein thedockerbook is the user ID and helloworld is the image repository name. You can download any third-party image by using the docker pull subcommand, as shown here:

$ sudo docker pull thedockerbook/helloworld

Apart from the preceding repository, the Docker ecosystem also provides a mechanism for leveraging the images from any third-party repository hub other than the Docker Hub Registry, and it provides the images hosted by the local repository hubs. As mentioned earlier, the Docker engine has been programmed to look for images in index.docker.io by default, whereas in the case of the third-party or the local repository hub, we must manually specify the path from where the image should be pulled. A manual repository path is similar to a URL without a protocol specifier, such as https://, http:// and ftp://. Following is an example of pulling an image from a third party repository hub:

$ sudo docker pull registry.example.com/myapp

Searching Docker images

As we discussed in the previous section, the Docker Hub repository typically hosts both the official images as well as the images that have been contributed by the third-party Docker enthusiasts. At the time of writing this book, more than 14,000 images (also called the Dockerized application) were available for the users. These images can be used either as is, or as a building block for the user-specific applications.

You can search for the Docker images in the Docker Hub Registry by using the docker search subcommand, as shown in this example:

$ sudo docker search mysql

The search on mysql will list 400 odd images, as follows:

NAME DESCRIPTION STARS OFFICIAL AUTOMATED
mysql MySQL is the... 147 [OK]
tutum/mysql MySQL Server.. 60 [OK]
orchardup/mysql 34 [OK]
. . . OUTPUT TRUNCATED . . .

As you can see in the preceding search output excerpts, the images are ordered based on their star rating. The search result also indicates whether or not the image is official. In order to stay in focus, in this example, we will show only two images. Here, you can see the official version of mysql, which pulls a 147 star rating image as its first result. The second result shows that this version of the mysql image was published by the user tutum. The Docker containers are fast becoming the standard for the building blocks of the distributed applications. A dynamic repository of the Docker images will be realized with the help of the enthusiastic contribution of several community members across the globe. The Repository-based software engineering will make it easier for users and programmers to quickly code and assemble their projects. The official repositories can be freely downloaded from the Docker Hub Registry, and these are curated images. They represent a community effort that is focused on providing a great base of images for applications, so that the developers and the system administrators can focus on building new features and functionalities, while minimizing their repetitive work on commodity scaffolding and plumbing.

Based on the search queries in the Docker Hub Registry and the discussions with many of the developer community members, the Docker company, which spearheaded the Docker movement so powerfully and passionately, came to the conclusion that the developer community wanted pre-built stacks of their favorite programming languages. Specifically, the developers wanted to get to work as quickly as possible writing code without wasting time wrestling with environments, scaffolding, and dependencies.