Containers - what are they?

A container is a running instance of a Docker image. While an image is a static, read-only snapshot that includes the application code, dependencies, and environment setup, a container brings that image to life by running it with an added writable layer on top. This writable layer allows the container to create, modify, and delete files during runtime without altering the underlying image.

Multiple containers can be launched from the same image, each operating independently with its own isolated writable layer. This allows developers to scale applications, run tests, or isolate environments without needing to duplicate the image itself. In essence, the image provides the blueprint, and the container is the live, editable instance built from that blueprint.

Image vs. Container

A Docker image is the read-only template used to create containers. It contains the application code and all its dependencies. When you run an image, Docker creates a container from it — essentially a running instance of that image. While the image stays the same, the container can change (e.g., temporary files, logs, different environment variables etc.), making it a writable and isolated environment.

Lifecycle of a Container

The typical lifecycle of a Docker container includes several stages: it is created, then started, and can later be stopped, restarted, or deleted. Containers are meant to be ephemeral — short-lived and disposable. It’s common practice to destroy and recreate containers rather than update them, especially when deploying new versions of applications.

Isolation and Portability

Containers provide process and filesystem isolation. Each container has its own file system, network interface, and process tree. This ensures that the application runs in the same way, regardless of the underlying system. This isolation, combined with portability, is a major reason why containers are ideal for microservices architectures and DevOps workflows.

Foreground vs Detached Mode

By default, when you run a container using docker run, it runs in the foreground, meaning it attaches to your terminal session and streams logs/output directly. This is useful for monitoring, debugging, or interacting with applications that produce console output. However, this also means your terminal is tied up until the container stops or you interrupt it with Ctrl+C.

To run a container in the background, you use the -d or --detach flag. This is known as detached mode. In this mode, Docker starts the container and immediately returns control to your terminal, printing the container ID. This is ideal for services, background tasks, or when you want to run containers without keeping the terminal busy.

Interactive and TTY Mode (-it)

When you want to interact with a container — for example, to run a shell session — you use the -it flags. This is a combination of:

• -i (interactive): Keeps STDIN open, so you can send input.
• -t (TTY): Allocates a pseudo-terminal, so the session behaves like a real terminal.

This is commonly used with containers like Alpine or Ubuntu to get an interactive shell.

Networking

Containers can handle network routing by allowing flexible port mappings at runtime. While a Docker image may define a specific port to be exposed — for example, port 3000 — the container instances created from that image can each be configured to publish a different host (system) port. This means one container might map host port 8080 to internal port 3000, while another maps 9090 to the same internal port, all using the same image. Docker securely routes incoming traffic from the host to the correct internal container port, enabling multiple containers to run the same service on a single machine without conflicts.