Actionable walkthroughs on containerization, multi-stage builds, microservices orchestration, container networking, and DevOps pipelines.
A container’s network is not one thing. It is a namespace, a set of interfaces, a routing table, and a driver that constructs all three. The driver determines whether the container is isolated, shares the host’s network, or appears as a physical device on the LAN. The choice of driver is the choice of how…
Two containers on the same host cannot talk to each other by name unless they are on a user-defined network. The default bridge network, the one Docker creates automatically at installation, does not provide DNS resolution between containers. This is not a bug; it is a deliberate limitation, kept for backward compatibility with the legacy…
The host network driver removes the network namespace from the container. The container shares the host’s network stack directly, with the host’s IP address, the host’s interfaces, and the host’s ports. There is no NAT, no virtual bridge, and no port mapping. The container’s application binds to the host’s port directly, and the performance is…
A bridge network puts the container behind a NAT. The container has its own IP, but it is on a virtual subnet, and the outside world reaches it only through published ports. Some applications do not accept this. A legacy application that uses broadcast discovery, a monitoring tool that needs to see all traffic, a…
A published port is a promise. The container’s application listens on a port inside its own network namespace, and the host promises that a connection to a specific host port will reach it. The mechanism behind that promise is a set of iptables rules in the host’s NAT table, a connection-tracking system, and—for the traffic…
A running container is not necessarily a working container. The main process can be alive while the application inside it is wedged — a web server stuck in an infinite loop, a database accepting connections but unable to serve queries, a worker that has lost its connection to the queue. Docker’s HEALTHCHECK instruction exists to…
A container that exits is not always a container that should stay exited. A web server that crashes because of a transient network error should come back. A database that is killed by the OOM killer should restart. A batch job that completes successfully should stay stopped. Docker’s restart policies are the mechanism that distinguishes…
A container without resource limits is a container that can consume the entire host. A runaway process inside a container can starve every other container, exhaust the host’s memory, and trigger the kernel’s OOM killer, which may terminate processes outside the container as well. Docker’s resource allocation controls exist to prevent this. They set boundaries…
When a container reaches its memory limit, the Linux kernel does not gracefully ask it to free memory. It sends SIGKILL. The process dies immediately, without cleanup, without flushing buffers, without closing connections. The container exits with code 137 (128 + 9), and docker inspect reports OOMKilled: true. This is the cgroup OOM killer, and…
Docker Compose begins with a single file. A compose.yaml file describes an entire application stack — every service, network, volume, and configuration — in declarative YAML. Instead of running docker run commands one by one, with all the flags, environment variables, port mappings, and network connections remembered separately, Compose reads the file and creates the…