Docker Container Lifecycle: Create, Run, Stop & Remove Containers

This chapter provides a deep dive into the Docker Container Lifecycle, examining how containers transition between different operational states—from pulling a base image to running, pausing, stopping, restarting, and finally deletion. Understanding these state transitions is essential for effective container management and DevOps workflows.

1. Why Do We Need Container Lifecycle Management?

When working with Docker, applications do not run in isolation; they depend on immutable blueprints called Images, which instantiate into active, isolated execution environments called Containers.

To maintain a clean development or production environment, engineers must understand how containers are provisioned, how they consume host resources, how they respond to termination signals, and how dependencies between images and containers prevent accidental deletions.

2. Core Mental Model: The Blueprint and the House

Real-Life Analogy: Think of a Docker Image as an architectural blueprint or a prefabricated house kit sitting in a catalog. The blueprint itself is static and cannot be lived in.

When you execute docker run, you are building an actual house on a plot of land based on that blueprint.

• Stopping a container is like turning off the electricity and locking the doors temporarily.
• Deleting a container is like tearing down the house while keeping the original blueprint catalog intact.
• You cannot throw away the blueprint from your filing cabinet if a house built from it is still actively occupied!

3. Environment Cleanup and Image-Container Dependency Conflicts

Before walking through the container lifecycle, it is crucial to understand how Docker protects resources through reference counting. If you attempt to delete an image that is currently tied to a container (even an exited one), Docker will block the operation.

Inspecting All Containers (Running & Exited)

To view all containers regardless of whether they are active or stopped, use the -a (all) flag:

docker ps -a

Encountering the Image Deletion Conflict Error

If you try to remove an image (docker rmi) that has a dependent container, Docker throws a conflict error:

$ docker rmi nginx:latest
Error response from daemon: conflict: unable to remove repository reference "nginx:latest" (must force) - container b1a2c3d4e5f6 is using its referenced image

Resolution Workflow

To successfully clean up the environment, you must remove the dependent container before removing the image:

# Step 1: Remove the stopped/exited container using its ID or Name
docker rm b1a2c3d4e5f6

# Step 2: Verify no conflicting containers remain
docker ps -a

# Step 3: Successfully remove the image
docker rmi nginx:latest

4. Step-by-Step Container Lifecycle Flow

A Docker container moves through several distinct states throughout its operational lifespan.

5. Phase 1: Pulling the Image (Blueprint Acquisition)

Before a container can exist, its blueprint must be available locally. If an image is not present on your local machine, Docker automatically fetches it from Docker Hub.

# Pull the Nginx web server image (defaults to the latest tag if unspecified)
docker pull nginx

# Verify the image is stored locally
docker images

6. Phase 2: Moving from None to Running (docker run)

When you execute an image, Docker creates a writable container layer over the read-only image blueprint and starts the process.

The Foreground Trap (Blocking the Terminal)

If you run a container directly without background options, it attaches to your current shell session, occupying your terminal window:

docker run nginx

Note: Pressing Ctrl + C sends a termination signal (SIGINT) to the container, shutting down the Nginx process and transitioning the container directly into an Exited state.

Running in Detached Mode (Daemonized)

To run a container in the background and keep your terminal free, use the detached flag (-d) combined with a custom container name (--name):

docker run -d --name web_app nginx

Verifying Running Containers

To check active containers:

docker ps

7. Phase 3: Inspecting Container Metadata (docker inspect)

To examine deep configuration details—such as network settings, IP addresses, environment variables, and exact execution status—use the inspect command:

docker inspect web_app

8. Phase 4: Pausing and Unpausing Containers (docker pause / docker unpause)

You can temporarily freeze all processes inside a running container without stopping the container or clearing its memory state.

# Suspend all processes inside the container
docker pause web_app

# Verify paused state in container listing
docker ps

# Resume container execution
docker unpause web_app

9. Phase 5: Stopping and Starting Containers (Soft Delete & Revival)

Stopping a container performs a graceful shutdown by sending a SIGTERM signal (followed by SIGKILL if necessary), moving the container into an Exited state.

# Gracefully stop the container (Soft Delete)
docker stop web_app

# Verify it no longer appears in standard ps, but appears in ps -a
docker ps -a

# Restart/Start an exited container back to a running state
docker start web_app

Alternatively, you can instantly stop and restart a container in a single command using docker restart:

docker restart web_app

10. Phase 6: Killing and Removing Containers (Hard Delete & Cleanup)

When a container finishes its service or needs to be purged permanently, it must be terminated and removed from disk.

Hard Termination (docker kill)

Unlike docker stop (which performs a graceful shutdown), docker kill immediately halts the container processes by sending a SIGKILL signal:

docker kill web_app

Container Removal (docker rm)

Once a container is stopped or killed, remove its instance to free up host disk space:

docker rm web_app

11. Comprehensive Container Lifecycle Command Reference

Summary and Key Takeaways

• Dual Architecture: Docker operates on two primary components: static blueprints (Images) and active execution instances (Containers).
• Dependency Protection: Docker prevents the deletion of images that are actively referenced by existing containers (even those in an Exited state).
• Detached Mode (-d): Essential for running service containers (like Nginx) in the background without locking up the user terminal.
• Graceful vs. Forceful Shutdown: Use docker stop for polite, graceful termination (SIGTERM), and docker kill for immediate, forceful termination (SIGKILL).
• Pausing vs. Stopping: docker pause freezes processes in memory instantly, whereas docker stop shuts down processes while preserving container state on disk.
• State Inspection: Always utilize docker ps -a to audit the exact health, uptime, and exit codes of all system containers.