The Docker images are the fundamental building blocks of containers. These images could be very basic operating environments, such as busybox or ubuntu, as we found while experimenting with Docker in the previous chapters. Alternatively, the images could craft advanced application stacks for the enterprise and cloud IT environments. As we discussed in the previous chapter, we could craft an image manually by launching a container from a base image, install all the required applications, make the necessary configuration file changes, and then commit the
As a better alternative, we could resort to the automated approach of crafting the images by using Dockerfile. Dockerfile is a text-based build script that contains special instructions in a sequence for building the right and relevant images from the base images. The sequential instructions inside the Dockerfile can include the base image selection, installing the required application, adding the configuration and the data files, and automatically running the services as well as exposing those services to the external world. Thus the Dockerfile-based automated build system has simplified the image-building process. It also offers a great deal of flexibility in the way in which the build instructions are organized and in the way in which they visualize the complete build process.
The Docker engine tightly integrates this build process with the help of the docker build subcommand. In the client-server paradigm of Docker, the Docker server (or daemon) is responsible for the complete build process and the Docker command line interface is responsible for transferring the build context, including transferring Dockerfile to the daemon.
In order to have a sneak peak into the Dockerfile integrated build system in this section, we will introduce you to a basic Dockerfile. Then we will explain the steps for converting that Dockerfile into an image, and then launching a container from that image. Our Dockerfile is made up of two instructions, as shown here:
$ cat Dockerfile FROM busybox:latest CMD echo Hello World!!
In the following, we will discuss the two instructions mentioned earlier:
• The first instruction is for choosing the base image selection. In this example, we will select the busybox:latest image
• The second instruction is for carrying out the command CMD, which instructs the container to echo Hello World!!.
Now, let's proceed towards generating a Docker image by using the preceding Dockerfile by calling docker build along with the path of Dockerfile. In our example, we will invoke the docker build subcommand from the directory where we have stored Dockerfile, and the path will be specified by the following command:
$ sudo docker build .
After issuing the preceding command, the build process will begin by sending build context to the daemon and then display the text shown here:
Sending build context to Docker daemon 3.072 kB Sending build context to Docker daemon
Step 0 : from busybox:latest
The build process would continue and, after completing itself, it will display the following:
Successfully built 0a2abe57c325
In the preceding example, the image was built by the IMAGE ID0a2abe57c325. Let's use this image to launch a container by using the docker run subcommand as follows:
$ sudo docker run 0a2abe57c325 Hello World!!
Cool, isn't it? With very little effort, we have been able to craft an image with busybox as the base image, and we have been able to extend that image to produce Hello World!!. This is a simple application, but the enterprise-scale images can also be realized by using the same technology.
Now let's look at the image details by using the docker images subcommand, as shown here:
$ sudo docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
<none> <none> 0a2abe57c325 2 hours ago 2.433 MB
Here, you may be surprised to see that the IMAGE (REPOSITORY) and TAG name have been listed as <none>. This is because we did not specify any image or any TAG name when we built this image. You could specify an IMAGE name and optionally a TAG name by using the docker tag subcommand, as shown here:
$ sudo docker tag 0a2abe57c325 busyboxplus
The alternative approach is to build the image with an image name during the build time by using the -t option for the docker build subcommand, as shown here:
$ sudo docker build -t busyboxplus .
Since there is no change in the instructions in Dockerfile, the Docker engine will efficiently reuse the old image that has ID0a2abe57c325 and update the image name to busyboxplus. By default, the build system would apply latest as the TAG name.
This behavior can be modified by specifying the TAG name after the IMAGE name by having a : separator placed between them. That is, <image name>:<tag name> is the correct syntax for modifying behaviors, where <image name> is the name of the image and <tag name> is the name of the tag.
Once again, let's look at the image details by using the docker images subcommand, and you will notice that the image (Repository) name is busyboxplus and the tag name is latest:
$ sudo docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE busyboxplus latest 0a2abe57c325 2 hours ago 2.433 MB Building images with an image name is always recommended as the best practice.
Having experienced the magic of Dockerfile, in the subsequent sections we will introduce you to the syntax or the format of Dockerfile and explain a dozen Dockerfile instructions.
The latest Docker release (1.5) has incorporated an additional option (-f) in the docker build subcommand, and it is used for specifying a Dockerfile with an alternative name.