2 Running software in containers

This chapter builds a practical foundation for running software in containers with Docker. It walks through creating both detached (daemon) and interactive containers, using a simple but realistic monitoring setup composed of an NGINX web server, a mailer, and a watcher agent. Along the way, it covers essential commands and workflows—running and naming containers, attaching/detaching terminals, listing and inspecting running containers, viewing logs (and the pitfalls of unbounded log growth), stopping/restarting services, and using exec for ad‑hoc commands—so you can verify behavior and iterate confidently while keeping container output and lifecycle under control.

With the basics in place, the chapter explains how Linux PID namespaces isolate processes so each container sees its own PID 1 and process list, improving security and eliminating many software conflicts (for example, port and file clashes) by scoping resources per container. It then tackles scaling and coordination concerns you hit as you run more containers: flexible identification via auto‑generated names and unique IDs (including truncated IDs and CID files), understanding container states (created, running, restarting, exited), and respecting dependency order when starting services. These ideas are applied to expand the single site into a small “farm” architecture while avoiding metaconflicts at the Docker layer.

The chapter then shows how to make systems environment‑agnostic and resilient. It uses read‑only filesystems with targeted writable exceptions (such as volumes and tmpfs) and environment variable injection to configure software like WordPress cleanly, decoupling it from specific hosts and co‑deployed services (for example, database host, credentials, and per‑site database names). To increase durability, it introduces restart policies with exponential backoff, clarifies the implications of the restarting state, and demonstrates when to prefer lightweight init systems or entrypoint/startup scripts to supervise child processes and validate preconditions. It closes with cleanup best practices—stopping/removing containers, understanding signal differences, using auto‑removal for short‑lived tasks, and composing quick commands to reclaim resources—so experimentation doesn’t leave behind stray state.