Maksim Kabakou - Fotolia
Containers and images are closely related concepts, which can be confusing to IT organizations new to Docker and containerizing applications. A Docker image and a Docker container are distinct components that play different roles in deploying a workload.
What is a Docker image?
A Docker image is a set of instructions that defines what should run inside a container. Most container images are not built from scratch. Instead, an IT organization starts with an existing image as the foundation, then modifies it for the given project.
A Docker image typically specifies:
- Which external image to use as the basis for the container, unless the container image is written from scratch;
- Commands to run when the container starts;
- How to set up the file system within the container; and
- Additional instructions, such as which ports to open on the container, and how to import data from the host system.
This image provides a blueprint for the the organization to deploy an executable container. Multiple containers can spin up from one image.
Docker images and Dockerfiles
In most cases, the information described above is written in a Dockerfile. Use the docker build command to tell Docker to generate a container image based on this file.
There are alternative, more complex methods to build a Docker image without a Dockerfile, such as Red Hat Ansible playbooks. Stick to the Dockerfile unless you want to avoid Docker's command-line interface tools for some reason.
What is a Docker container?
Once you have a container image, you can start a container based on it. Docker containers are the way to execute that package of instructions in a runtime environment. Start a container using the docker run command.
Containers run until they fail and crash, or are told to stop. No matter how long the container runs, it does not change the image on which it is based. If you update a container image, you need to stop, remove and restart the containers based on it. Containers are not designed to update during operation.
There are several reasons to run multiple containers based on one image. For example, duplicate containers increase application availability: If one container fails, others that are based on the same image will keep the application up and running. Multiple instances also scale up an application or service when demand increases.
Docker images vs. containers
For a simple analogy, think of a Docker image as the recipe for a cake, and a container as a cake you baked from it.
The image spells out what ingredients should go into the cake. You cannot eat if you stop there.
The container is the cake. You must follow the recipe to get something you can eat. In the same way, you must follow the instructions in the Docker image to start a container that can execute whatever software or service it runs.
You can make as many cakes as you want based on a single recipe, but if you decide to modify your recipe, your existing cakes won't change. Only new cakes will follow the updated recipe. Similarly, if you update a container image, you won't change the containers that are already running.
Dig Deeper on Containers and virtualization
Related Q&A from Chris Tozzi
Looking for an efficient, user-friendly alternative to traditional Kubernetes? Compare the popular lightweight distributions K3s and MicroK8s to ... Continue Reading
Fully automated NoOps workflows might not be possible, but there's always room to further automate existing processes. An expert explains two ... Continue Reading
Scaling Kubernetes clusters has always been a challenge -- but eBPF makes the process smoother with service-specific monitors and a lack of special ... Continue Reading