Docker: from Dockerfile to a dead container

Docker: from Dockerfile to a dead container A lifecycle diagram generated by Archify. 01 / Image supply -> container states 02 / Interruptions 03 / Removal Dockerfile · Image supply -> container states 01 Dockerfile Image built · docker build -t app:1.0 . · Image supply -> container states 02 Image built docker build -t app:1.0 . Created · filesystem ready, no process yet · Image supply -> container states 03 Created filesystem ready, no process yet Running · PID 1 alive · Image supply -> container states 04 Running PID 1 alive Exited · writable layer still on disk · Image supply -> container states 05 Exited writable layer still on disk Paused · cgroup freezer, memory retained · Interruptions Paused cgroup freezer, memory retained OOMKilled · exceeded the memory limit · Interruptions OOMKilled exceeded the memory limit Removed · writable layer deleted · Removal Removed writable layer deleted docker build docker create / docker run start: exec PID 1 docker pause (SIGSTOP via freezer) docker unpause docker stop: SIGTERM, SIGKILL after 10s docker start (same writable layer) memory limit exceeded restart policy: on-failure / always docker rm Legend start active state waiting terminal success failure / exit neutral

Exited is not deleted

  • • An exited container still owns its writable layer and its logs
  • • docker start reuses it; docker rm is what frees the disk
  • • This is why docker ps -a shows a graveyard

Stopping is a negotiation

  • • SIGTERM first, then SIGKILL after the grace period
  • • PID 1 must actually handle SIGTERM or you always get killed
  • • ECS and Kubernetes use the same contract, with their own timeouts

Why orchestrators exist

  • • Restart policies fix one host; they do not move work to another host
  • • Nothing here knows about load balancers, rollouts, or capacity
  • • That gap is exactly what ECS and EKS fill