30 posts tagged with "Docker"

Docker made containers mainstream, but it is no longer the only way to run them. Kubernetes dropped Docker as a runtime in version 1.24. Podman offers a daemonless, rootless alternative with Docker CLI compatibility. containerd and CRI-O power most production Kubernetes clusters. The container ecosystem has matured beyond a single tool, and understanding the options helps you make the right choice for your specific use case.

"Docker Compose is only for development." You hear this constantly, but it is not universally true. Compose is not the right choice for a 200-service microservices platform, but for a team running 5-15 services on a single server or small cluster, Compose provides everything you need: restart policies, health-based dependency ordering, resource limits, logging, and deployment configuration. The question is not whether Compose can run in production — it is whether your use case fits.

docker stats shows you what is happening right now. It does not show you what happened at 3 AM when response times spiked. It does not alert you when a container's memory is trending toward its limit. It does not graph CPU usage over the past week to help you right-size your resource limits. For real monitoring, you need metrics collection, storage, visualization, and alerting. The standard stack for Docker is cAdvisor + Prometheus + Grafana, and you can have it running in under fifteen minutes.

Bridge networks work on a single host. Your containers can talk to each other when they are on the same machine. But when you have three application servers across three hosts, a bridge network does nothing for you. Overlay networks solve this — they create a virtual network that spans multiple Docker hosts, letting containers communicate as if they were on the same LAN, regardless of which physical machine they are running on.

You run docker stop myapp and wait. After 10 seconds, Docker force-kills the container. Your application never received the shutdown signal, never flushed its write buffers, never closed database connections. Running docker top on a long-running container reveals dozens of zombie processes consuming PIDs. Both problems share the same root cause: your application is running as PID 1 in the container, and it was never designed for that responsibility.

By default, the Docker daemon runs as root. Every container you start has root-level access to the host kernel. If an attacker escapes the container — through a kernel vulnerability, a misconfigured volume mount, or a privileged container — they land on the host as root. Game over. Rootless mode eliminates this risk by running both the Docker daemon and containers under a regular, unprivileged user account.