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 Managing Virtual Containers
Related Q&A from Chris Tozzi
Red Hat OpenShift and Kubernetes share a lot of similarities -- including the same underlying container orchestration technology. So how are they ... Continue Reading
How can you approach container orchestration on AWS? Learn the basics about ECS, EKS, DIY Kubernetes and Fargate before you choose an application ... Continue Reading
AIOps tools can reduce overhead for IT staff, but first, enterprises must decide how they will use the tool to know which features to budget for. Continue Reading