Module Review: Container Lifecycle

This module explores the core principles of the Container Lifecycle, deriving solutions from first principles and hardware constraints to build world-class, production-ready expertise.

1. Key Takeaways

  1. The State Machine: Containers move through Created, Running, Paused, Stopped, and Dead. This mirrors standard operating system process states, but is heavily isolated by Linux Namespaces.
  2. Graceful Shutdown: docker stop sends SIGTERM, waits 10s by default, then sends SIGKILL. docker kill sends SIGKILL immediately, analogous to pulling the power plug.
  3. PID 1 Responsibility: PID 1 is the kernel’s special child. It must handle signals and reap zombie processes. If your app lacks this capability, inject an init process like tini or dumb-init to prevent process table exhaustion.
  4. Exec vs Attach: attach multiplexes your terminal into the main process (PID 1) streams. exec spawns a new, entirely separate process inside the same namespace, which is the correct way to debug without interfering with the main application loop.
  5. Logs: Docker captures stdout/stderr to JSON files on the host. Always configure log rotation to prevent disk exhaustion.
    • War Story: A prominent payment gateway once experienced a complete node outage because a high-throughput microservice logged every HTTP header to stdout. Without log rotation configured in the Docker daemon, the json-file driver silently consumed 500GB of host disk space until the kernel panicked.
  6. Self-Healing: Use Restart Policies (always, on-failure) and Healthchecks to make your system resilient to crashes and deadlocks. Healthchecks act as the “pulse” of your application, ensuring the container orchestrator can actively verify readiness rather than relying on PID 1 simply being alive.

Analogy: The Container Restaurant

Think of a Container as a dedicated Restaurant Kitchen.

  • PID 1 is the Head Chef. If the Head Chef quits (PID 1 exits), the entire kitchen shuts down immediately.
  • Graceful Shutdown (docker stop) is telling the Head Chef: “Stop taking new orders and finish plating the current ones. You have 10 seconds before we cut the power.”
  • Zombie Processes are like completed orders sitting on the counter. If the Head Chef doesn’t “reap” them (hand them to waiters), the counter fills up, and the kitchen grinds to a halt.

2. Flashcards

Which signal does `docker stop` send first?
SIGTERM (Signal 15)
What happens if the main process (PID 1) exits?
The container stops immediately.
Why is `docker attach` dangerous in production?
Pressing `Ctrl+C` sends SIGINT to PID 1, killing the container.
Which restart policy should you use for a database?
`always` or `unless-stopped` (to ensure it survives reboots).
What is the default log driver in Docker?
`json-file` (writes logs to a file on the host).
How do you debug a running container without killing it?
Use `docker exec -it <id> /bin/bash` to open a new shell sidecar.

3. Scenario Quiz

Scenario: You have a critical payment service. You deploy an update, but the container keeps restarting every minute. docker logs shows nothing unusual before it exits.

What is the most likely cause?
A. The disk is full.
B. The Healthcheck is failing.
C. The restart policy is set to `no`.

4. Next Steps

Now that you understand the lifecycle, you need to network these containers together.