Docker images, Dockerfiles and containers are considered as "Three musketeers" in a Docker operation, work hand in hand in a Docker setup. Here is a brief introduction to these components in view of a comparative study.
It is often a confounding affair for IT professionals to understand Containers and images since they are very akin in concepts. It is also crystal clear that the Docker image and container are playing different roles and distinctively different components. Let's understand a Docker image.
Docker image
A Docker image as a compendium of instructions decides what should go on inside a container. Most container images of course are not created out of scratch. The IT professionals set out with an existing image as the foundation, then makeover it for a given project.
A Docker image keenly specifies:
1. If the container image is not written from scratch, it decides the kind of external image to use as the basis for the container.
2. When the container starts, it helps to pick up the required commands.
3. It directs to set up the file system within the container.
4. It also specifies the additional instructions relating to ports to open on the container and to import data from the host system.
Only one image can lead to Multiple containers. This image also offers a blueprint for the developer to deploy an executable container.
Docker images and Dockerfiles
Generally, the specifications mentioned above are written in a Dockerfile. The docker built command, asks Docker to create a container image out of this file.
Docker container
A container image leads one to build container based on it. A retinue of instructions is made operable in a runtime environment because of Docker containers.
Containers continue to function until it is stopped. Interestingly, it never allows any change in the image on which it is based, irrespective of its run time. Since the containers are not designed to update during operation, it needs to be stopped for any update.
Docker images vs. containers
We can draw a conspicuous analogy between a cake making process and Docker's image- container story. Let us imagine Docker image as the recipe for a cake, and a container as a cake, the final output.
The image directs the nature of ingredients that should go into the cake. One should not stop in between, since he won't have the taste of a cake unless the whole process is completed.
Likewise, one must follow assiduously the instructions in the Docker image to create a container that rooms the software or service to run.
Again, one can have as many cakes as he wants based on a single recipe. One can modify the taste of the cake by bringing changes in the recipe which will yield in a new set of cakes. And the existing set of cakes will remain the same. Similarly, the updating of a container image means a new container you different from the containers that are already running.
Conclusion
This flexibility in Docker has made it widely acceptable to the developers. These characteristics also have paved the ways for its high portability. This self-evolving possibility has made docker a long sustainable software platform.
