Docker Images vs Containers Explained

Quick take: When you first encounter Docker, one of the most critical concepts to understand is the relationship between Docker images and containers.

Docker Images vs Containers Explained: A Complete Guide for DevOps Engineers

When you first encounter Docker, one of the most critical concepts to understand is the relationship between Docker images and containers. Many beginners treat these terms interchangeably, but this fundamental misunderstanding can lead to confusion in your DevOps journey. In this comprehensive guide, we will explore every aspect of Docker images and containers, their differences, how they work together, and practical examples you can implement immediately.

Docker has revolutionized the way applications are deployed and managed in modern infrastructure. At its core, Docker relies on two essential components: images and containers. Think of a Docker image as a blueprint or template, while a container is the actual running instance of that blueprint. This article will give you the deep understanding you need to work effectively with Docker in production environments.

Understanding Docker Images

What is a Docker Image?

A Docker image is a lightweight, standalone, executable package that contains everything needed to run an application. This includes the application code, runtime environment, system tools, libraries, and settings. An image is essentially a snapshot or template that defines exactly how an application should run.

Docker images are immutable, meaning once created, they cannot be changed. If you need to modify an image, you must create a new version. This immutability ensures consistency and reproducibility across different environments. Every time you create a container from the same image, you get an identical execution environment.

Images are built in layers, each layer representing a set of file changes. These layers are stacked on top of each other, and Docker uses a copy-on-write mechanism to manage them efficiently. This layered approach is crucial for understanding how images work and why they are so efficient in terms of storage and build time.

Docker Image Components

A Docker image consists of several important components working together:

• Base layer: The foundational operating system or runtime environment
• Application layers: Your application code and dependencies
• Configuration layers: Environment variables, exposed ports, and default commands
• Metadata: Information about the image including architecture, creation time, and author

When you pull a Docker image from a registry like Docker Hub, you are actually downloading all these layers. Docker stores each layer separately and reuses them across images. For example, if multiple images use Ubuntu 22.04 as their base, Docker downloads it only once and references it in each image that needs it.

How Docker Images Are Built

Docker images are built using a Dockerfile, a text file containing a series of instructions. Each instruction in a Dockerfile creates a new layer in the image. Let's examine a practical example:

FROM ubuntu:22.04
RUN apt-get update && apt-get install -y python3 python3-pip
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
EXPOSE 5000
CMD ["python3", "app.py"]

In this Dockerfile:

• FROM ubuntu:22.04 creates the base layer using Ubuntu 22.04
• RUN apt-get update... creates a layer that installs Python and pip
• WORKDIR /app sets the working directory
• COPY requirements.txt . copies the requirements file into the container
• RUN pip install... creates another layer by installing Python dependencies
• COPY . . copies the entire application into the container
• EXPOSE 5000 documents which port the application listens on
• CMD ["python3", "app.py"] sets the default command to run the application

When you build this image with docker build -t myapp:1.0 ., Docker executes each instruction sequentially and creates a new layer for each RUN, COPY, and ADD command. The resulting image is a stack of these layers.

Image Layers and Caching

Docker's layering system provides significant efficiency benefits. When you rebuild an image after making changes, Docker uses cached layers for unchanged instructions. For example, if you only modify your application code but keep the base image and dependencies the same, Docker reuses the cached layers for the base system and dependencies, rebuilding only the layers that changed.

This is why the order of instructions in a Dockerfile matters. Instructions that change frequently should come near the end, while stable instructions should come early. This optimization technique can reduce build times from minutes to seconds.

Docker Image Size and Storage

Each image has a size that includes all its layers. You can view image sizes using:

docker images --format "{{.Repository}}:{{.Tag}}\t{{.Size}}"

Example output:

myapp:1.0           256MB
ubuntu:22.04        77MB
python:3.11-slim    125MB

The size matters because images need to be pushed to registries, pulled to machines, and stored locally. Optimizing image size is a critical concern in production DevOps environments. Using minimal base images like Alpine Linux or Python slim variants can significantly reduce size.

Understanding Docker Containers

What is a Docker Container?

A Docker container is a running instance of a Docker image. While an image is static and immutable, a container is dynamic and mutable. When you run a container, Docker creates a writable layer on top of the image's read-only layers. Any changes made during the container's execution are written to this writable layer, not to the image itself.

Think of it this way: if a Docker image is like a class definition in programming, then a container is like an instance of that class. Multiple containers can run from the same image simultaneously, and each maintains its own isolated state.

Container Isolation and Namespaces

Containers achieve isolation through Linux namespaces and control groups (cgroups). Namespaces provide process isolation, network isolation, and filesystem isolation. Each container has its own:

• Process namespace (isolated process tree with its own PID 1)
• Network namespace (isolated network interfaces and routing tables)
• Mount namespace (isolated filesystem view)
• IPC namespace (isolated inter-process communication)
• UTS namespace (isolated hostname and domain name)
• User namespace (isolated user and group IDs)

Control groups limit resources allocated to each container, including CPU, memory, I/O, and network bandwidth. This ensures that one misbehaving container cannot consume all system resources and crash other containers.

Container Lifecycle

A container goes through several states during its lifetime:

1. Created: The container exists but has not started
2. Running: The container is actively executing
3. Paused: The container is suspended but can be resumed
4. Stopped: The container has exited but still exists and can be restarted
5. Removed: The container has been deleted and no longer exists

You can manage container states with these commands:

docker create --name mycontainer myimage:latest
docker start mycontainer
docker pause mycontainer
docker unpause mycontainer
docker stop mycontainer
docker restart mycontainer
docker rm mycontainer

Container Storage and Writable Layer

When a container runs, Docker creates a thin writable layer on top of the image layers. This layer stores all changes made during the container's execution. The filesystem uses copy-on-write semantics, meaning unchanged files are referenced from image layers, while modified or new files are stored in the writable layer.

This approach provides several benefits:

• Multiple containers from the same image share the image layers, saving disk space
• Containers do not modify the original image
• Containers can be quickly created and destroyed
• Storage is efficient even with many running containers

However, container storage is temporary. When a container is removed, its writable layer is deleted, and all changes are lost. This is why you should never rely on persistent storage within containers for data that matters. Instead, use Docker volumes for persistent data.

Key Differences Between Images and Containers

Immutability vs Mutability

Docker images are immutable. Once built, an image cannot be modified. If you need changes, you rebuild the image, creating a new version. This immutability ensures consistency, reproducibility, and makes images safe to share and distribute.

Containers are mutable. You can modify files, install software, change configurations, and make any changes you want while a container is running. However, these changes are lost when the container stops unless they are written to a volume or committed to a new image.

Persistence and Lifespan

Images persist until you explicitly delete them. An image remains on your system and can be used to create containers indefinitely.

Containers have a temporary existence. By default, they persist on disk after stopping but are removed when you execute docker rm. The data inside a container is lost unless stored in volumes or committed to a new image.

Resource Usage

Images consume disk storage and cannot directly use CPU or memory. However, the size of the image affects how much disk space is used and how long it takes to push, pull, and start containers from that image.

Containers actively consume system resources including CPU, memory, disk I/O, and network bandwidth. The resource consumption depends on the container's workload and the limits you set with cgroups.

Portability and Distribution

Images are highly portable and distributable. You build an image once and run it anywhere Docker is installed. Images are pushed to registries and pulled by other developers or deployment systems, ensuring identical execution environments across different machines.

Containers themselves are not directly portable because they are stateful and tied to a specific host. However, the image they are created from is portable. To move a workload, you push the image to a registry and pull it on another machine.

Practical Examples: Working with Images and Containers

Building and Running a Web Application

Let's create a practical example with a Node.js web application. First, create your application files:

mkdir nodeapp && cd nodeapp
cat > package.json << 'EOF'
{
  "name": "nodeapp",
  "version": "1.0.0",
  "main": "server.js",
  "dependencies": {
    "express": "^4.18.2"
  }
}
EOF

Create the application server:

cat > server.js << 'EOF'
const express = require('express');
const app = express();

app.get('/', (req, res) => {
  res.send('Hello from Docker Container!');
});

app.listen(3000, () => {
  console.log('Server running on port 3000');
});
EOF

Create a Dockerfile to build the image:

cat > Dockerfile << 'EOF'
FROM node:18-alpine
WORKDIR /app
COPY package.json .
RUN npm install
COPY server.js .
EXPOSE 3000
CMD ["node", "server.js"]
EOF

Build the image:

docker build -t nodeapp:1.0 .

Verify the image was created:

docker images | grep nodeapp

Run a container from this image:

docker run -d -p 8080:3000 --name myserver nodeapp:1.0

Verify the container is running:

docker ps

Access the application:

curl http://localhost:8080

This example demonstrates the complete workflow: you build an image once, then run multiple containers from that image. Each container is isolated and can be started, stopped, and removed independently.

Running Multiple Containers from the Same Image

Create multiple containers from the same image:

docker run -d -p 8081:3000 --name server1 nodeapp:1.0
docker run -d -p 8082:3000 --name server2 nodeapp:1.0
docker run -d -p 8083:3000 --name server3 nodeapp:1.0

Verify all containers are running:

docker ps

Access each container via different ports:

curl http://localhost:8081
curl http://localhost:8082
curl http://localhost:8083

All three containers run independently, but they share the same image layers, making efficient use of storage. If you need to update the application, you rebuild the image and create new containers from the updated version.

Making Changes in a Container

To demonstrate container mutability, execute a command inside a running container:

docker exec -it myserver sh

Inside the container, make changes:

echo "Modified content" > /app/changes.txt
exit

Verify the change exists:

docker exec myserver cat /app/changes.txt

Stop and remove the container:

docker stop myserver
docker rm myserver

The changes are lost because they were stored in the container's writable layer. If you want to persist changes, you must either use volumes or commit the container to a new image.

Committing Changes to a New Image

You can create a new image from a modified container. First, make modifications to a running container:

docker run -d --name basecontainer nodeapp:1.0
docker exec basecontainer npm install lodash

Commit the container to a new image:

docker commit basecontainer nodeapp:2.0

Verify the new image was created:

docker images | grep nodeapp

The new image includes the changes made to the container. However, this approach is generally discouraged in production because it makes images less reproducible. Instead, modify the Dockerfile and rebuild the image.

Docker Image Management

Pulling Images from Registries

Docker images are typically stored in registries. Docker Hub is the default registry, but you can use private registries as well. Pull an image with:

docker pull ubuntu:22.04

This downloads all layers of the image from the registry. If you pull the same image again, Docker only downloads layers that don't already exist locally, making subsequent pulls faster.

Pull from a different registry:

docker pull gcr.io/my-project/myapp:latest

Tagging Images

Tags are mutable references to images that make them easier to identify and version. When you build an image, tag it immediately:

docker build -t myapp:1.0 -t myapp:latest .

This creates two tags pointing to the same image. You can also add tags to existing images:

docker tag myapp:1.0 myregistry.azurecr.io/myapp:1.0

This is useful when pushing to different registries. Best practices recommend including a registry prefix and version tag.

Pushing Images to Registries

Push an image to a registry for sharing:

docker login
docker push myregistry.azurecr.io/myapp:1.0

This uploads all image layers to the registry. Subsequent pushes only upload layers that have changed, making updates efficient.

Inspecting Images

View detailed information about an image:

docker inspect myapp:1.0

This returns a JSON object with extensive metadata. You can also view just the layers:

docker history myapp:1.0

This shows each layer, its size, creation time, and the command that created it. This information helps optimize image size and understand what is included.

Docker Container Management

Running Containers with Options

The docker run command has many options for configuring container behavior:

docker run -d \
  --name webserver \
  -p 80:8080 \
  -e NODE_ENV=production \
  -v /host/data:/container/data \
  --cpus="1.5" \
  --memory="512m" \
  --restart always \
  nodeapp:1.0

Breaking down these options:

• -d runs the container in detached mode (background)
• --name webserver names the container for easy reference
• -p 80:8080 maps port 80 on the host to port 8080 in the container
• -e NODE_ENV=production sets environment variables
• -v /host/data:/container/data mounts a volume for persistent storage
• --cpus="1.5" limits CPU usage to 1.5 cores
• --memory="512m" limits memory to 512MB
• --restart always automatically restarts the container if it crashes

Monitoring Container Resources

Monitor real-time resource usage of running containers:

docker stats

This shows CPU, memory, network I/O, and block I/O for all containers. For a specific container:

docker stats myserver

View container logs:

docker logs myserver

Follow logs in real-time:

docker logs -f myserver

Executing Commands in Running Containers

Run commands in a running container without stopping it:

docker exec myserver ps aux

Interactive shell access:

docker exec -it myserver /bin/bash

This is useful for debugging, checking logs, and investigating container state without rebuilding or restarting.

Advanced Concepts: Image Layers and Optimization

Understanding Layer Caching and Build Optimization

Docker caches layers during builds, which speeds up rebuilds when nothing has changed. However, a single change invalidates all subsequent layers. Consider this Dockerfile:

FROM python:3.11-slim
RUN apt-get update && apt-get install -y curl
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "app.py"]

If you change your application code in the COPY command, Docker rebuilds from that point onward. But if you change requirements.txt, Docker only rebuilds from the pip install step. This is why you should copy dependency files before application code.

Optimize builds further by minimizing layer creation:

FROM python:3.11-slim
RUN apt-get update && \
    apt-get install -y curl && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/*
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "app.py"]

Combining RUN commands with && reduces the number of layers and image size. The clean-up commands remove package manager cache, further reducing size.

Multi-Stage Builds

Multi-stage builds create images more efficiently by using intermediate stages. This is particularly useful for compiled languages:

FROM golang:1.20 AS builder
WORKDIR /src
COPY . .
RUN go build -o myapp

FROM alpine:latest
COPY --from=builder /src/myapp /usr/local/bin/
CMD ["myapp"]

The first stage builds the Go application with all build tools. The second stage copies only the compiled binary into a minimal Alpine image. The final image is much smaller because it doesn't include the Go compiler and build dependencies.

Common Workflows and Best Practices

Development Workflow

In development, you frequently rebuild images and run containers:

docker build -t myapp:dev .
docker run -it -v $(pwd):/app myapp:dev

The volume mount allows you to edit code on your host and see changes immediately in the container without rebuilding. However, for production deployments, always rebuild the image with your changes to ensure consistency.

Production Deployment Workflow

In production, follow these steps:

1. Build the image: docker build -t myapp:1.0.0 .
2. Tag for registry: docker tag myapp:1.0.0 myregistry.com/myapp:1.0.0
3. Push to registry: docker push myregistry.com/myapp:1.0.0
4. Deploy from registry: docker run myregistry.com/myapp:1.0.0

Use semantic versioning for tags, never rely on latest in production, and scan images for vulnerabilities before deployment.

Clean Up and Maintenance

Regularly clean up unused images and containers:

docker container prune
docker image prune

Remove dangling images that are not tagged:

docker image prune -a

View image usage and identify large images:

docker images --format "{{.Size}}\t{{.Repository}}:{{.Tag}}" | sort -h

Conclusion

Understanding the distinction between Docker images and containers is fundamental to becoming a proficient DevOps engineer. Docker images are immutable blueprints that package everything needed to run an application, while containers are the dynamic, isolated runtime instances created from images. Images are shared, versioned, and distributed through registries, while containers are ephemeral execution environments that can be created and destroyed as needed. This article has covered the complete spectrum of Docker images and containers, from basic concepts to advanced optimization techniques and production workflows. By mastering these concepts, you are now prepared to use Docker effectively in your infrastructure. This article is part of the Docker Complete Course available on learnwithirfan.com, where you will find additional resources to deepen your containerization expertise and advance your DevOps career.

Final Thoughts

Docker Images vs Containers Explained is worth reviewing with a practical lens: understand the risk or opportunity, map it to your environment, and take clear next steps instead of reacting to headlines.