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 earlier chapters. Alternatively, the images can craft advanced application stacks for the enterprise and cloud IT environments. As we discussed in the previous chapter, we can 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 container as an image.

As a better alternative, we can resort to the automated approach of crafting the images using Dockerfile, which is a text-based build script that contains special instructions in a sequence for building the correct and relevant images from the base images. The sequential instructions inside Dockerfile can include selecting the base image, 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 remarkably. It also offers a great deal of flexibility in organizing the build instructions and in visualizing 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, we will introduce you to a basic Dockerfile in this section. Then, we will explain the steps for converting that Dockerfile into an image, and then launch 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!!  

We will discuss these two instructions as follows:

• The first instruction is for choosing the base image selection. In this example, we select the busybox:latest image.
• The second instruction is for carrying out the CMD command, which instructs the container to execute echo Hello World!!.

Now, let's proceed towards generating a Docker image 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 the build context to the daemon and then display the text shown here:

Sending build context to Docker daemon 2.048 kB
Step 1 : FROM busybox:latest  

The build process will continue and after completing itself, will display the following:

Successfully built 0a2abe57c325  

In the preceding example, the image was built with the 0a2abe57c325 image ID. Let's use this image to launch a container 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 using the same technology.

Now, let's look at the image details using the docker images subcommand, as shown here:

$ sudo docker images
REPOSITORY     TAG         IMAGE ID      CREATED       SIZE
<none>       <none>        0a2abe57c325  2 hours ago   1.11 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 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 using the -t option for the docker build subcommand, as shown here:

$ sudo docker build -t busyboxplus .  

Since there is no change to the instructions in Dockerfile, the Docker Engine will efficiently reuse the old image that has the 0a2abe57c325 ID and update the image name to busyboxplus. By default, the build system applies 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. This means that, <image name>:<tag name> is the correct syntax for modifying behaviors, wherein <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 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, we will introduce you to the syntax or the format of Dockerfile and explain a dozen Dockerfile instructions in the subsequent sections.