Docker Containers Explained

Docker containers are one of the most important building blocks of modern application development, DevOps, CI/CD, cloud computing, and Kubernetes.

A container allows an application and its required runtime environment to be packaged into a standardized unit that can run consistently across different environments.

But a container is not simply a lightweight virtual machine.

A better way to understand Docker is:

A Docker container is an isolated process running on a host system, with its own filesystem view, networking context, and process space, while sharing the host operating system kernel.

Docker's documentation describes containers as isolated processes. A container gets its filesystem and configuration from an image, and Docker provides mechanisms for networking, storage, and process isolation.

Consider a Python application.

A developer may have:

• Python 3.12
• Flask 3.x
• PostgreSQL client libraries
• specific operating-system packages
• environment variables
• application dependencies

The application works perfectly on the developer's laptop.

> Then another developer runs it and gets:

ModuleNotFoundError

The application is moved to a test server.

> Now another problem appears: Python version mismatch

The application reaches production.

> A different library version causes: Application failed to start

This is the classic: "It works on my machine."

Problem.

Containers address this by packaging the application and its required runtime dependencies into a standardized image.

The same image can then be used to create containers in development, testing, CI/CD, and production.

At a high level:

Docker Container
    =
Application Process
+
Application Dependencies
+
Filesystem View
+
Network Isolation
+
Process Isolation
+
Runtime Configuration

Docker's documentation defines a container as an isolated process. For example, a web application, API, and database can each run in their own containers.

# Suppose we have:

Frontend
Backend API
PostgreSQL
Redis

Instead of installing everything directly on the host:

Linux Host
│
├── Node.js
├── Python
├── PostgreSQL
├── Redis
└── Application

we can separate them:

Linux Host
│
├── Frontend Container
│
├── Backend Container
│
├── PostgreSQL Container
│
└── Redis Container

Each container has its own isolated process environment.

One of the most common Docker interview questions is:

What is the difference between a container and a virtual machine?

The key architectural difference is the operating-system boundary.

A traditional virtual machine includes a guest operating system:

Physical Server
│
├── Hypervisor
│
├── VM 1
│   ├── Guest OS
│   └── Application
│
├── VM 2
│   ├── Guest OS
│   └── Application
│
└── VM 3
    ├── Guest OS
    └── Application

Containers work differently:

Physical / Virtual Server
│
├── Docker Engine
│
├── Container 1
│   └── Application
│
├── Container 2
│   └── Application
│
├── Container 3
│   └── Application
│
└── Host Linux Kernel

Containers share the host kernel, while each VM normally has its own guest OS kernel.

This difference generally makes containers much lighter in terms of startup and operating-system overhead, although containers and VMs solve somewhat different isolation and infrastructure problems.

This distinction is fundamental.

Docker Image : An image is a packaged, immutable template containing the files, binaries, libraries, and configuration required to run a container. Docker images are composed of layers.

For example:

python:3.12 could provide a Python runtime environment.

We can build an application image:

my-python-api:1.0

Docker Container

A container is a running or stopped instance created from an image.

Think of it this way:

Image
  │
  ├── Container 1
  ├── Container 2
  └── Container 3

One image can therefore be used to create multiple containers.

For example:

docker run ngnix
creates a container from the nginx image.

Running the command again creates another container:

docker run nginx

Now:

nginx Image
     │
     ├── nginx Container 1
     │
     └── nginx Container 2

The containers can have different runtime configuration even though they originate from the same image.

Docker uses a client-server architecture.

The Docker client communicates with the Docker daemon, which manages Docker objects such as images, containers, networks, and volumes. The communication occurs through the Docker API.

The main components are:

Developer
    │
    ▼
Docker CLI
    │
    │ Docker API
    ▼
Docker Daemon
(dockerd)
    │
    ├── Images
    ├── Containers
    ├── Networks
    └── Volumes

Internally, Docker Engine uses containerd for container lifecycle management and, by default, containerd uses runc as the runtime.

Important components

Consider:

docker run ngnix
This simple command triggers several operations.

Conceptually:

docker run nginx
       │
       ▼
Docker CLI
       │
       ▼
Docker Daemon
       │
       ├── Is nginx image available?
       │
       ├── If not → Pull image
       │
       ├── Create container
       │
       ├── Configure filesystem
       │
       ├── Configure networking
       │
       └── Start container process
                    │
                    ▼
                nginx

Docker's documentation explains that when docker run is executed, Docker can pull the image if necessary, create the container, allocate its writable filesystem layer, configure networking, and start the requested process.