Docker Container Lifecycle: Every Command You Need to Know

Docker Architecture: A Quick Recap

Before touching commands, it helps to remember what is actually happening when you type something into your terminal.

The Docker architecture has three pieces that talk to each other. You have the Docker CLI, which is what you type into. The CLI sends your request to a REST API. The REST API then talks to the Docker daemon. The daemon is the engine that actually does the work.

So the flow is:

Docker CLI  >  REST API  >  Docker Daemon

The daemon must always be running. If you type a Docker command and the daemon is not up, nothing works. You will see an error that says it cannot connect to the daemon. That is your first hint that the service needs to be started.

Installing Docker and Starting the Daemon

On an Amazon Linux or any RHEL-based system, installation is one command:

yum install docker -y

Once installed, start the Docker service:

systemctl start docker

To confirm the version:

docker -v

Now you are ready. Without starting the daemon first, every Docker command you run will fail with a connection error. Think of the daemon as the engine. The CLI is just the steering wheel. If the engine is off, turning the wheel does nothing.

Basic Commands to Get Oriented

These are the commands you will type more than anything else:

List all images on your machine:

docker images

List all containers (running and stopped):

docker ps -a

List only the currently running containers:

docker ps

The difference between docker ps and docker ps -a is simple. docker ps shows you only what is alive right now. docker ps -a shows you everything, including containers that have been stopped or exited. In practice, you will almost always use docker ps -a because you want to see the full picture.

Pulling Images from Docker Hub

Before you can create a container, you need an image. Images are pulled from Docker Hub. Think of Docker Hub as a registry, a library of pre-built images that you can grab and use.

To pull Amazon Linux:

docker pull amazonlinux

To pull Ubuntu:

docker pull ubuntu

After pulling, run docker images again and you will see both listed. The output shows the image name, tag, image ID, when it was created on Docker Hub, and the size.

Here is a helpful analogy. In AWS, you have AMIs, Amazon Machine Images. An AMI is a copy of an operating system that you use to launch an EC2 instance. A Docker image works the same way. It is a packaged copy of an operating system, and sometimes an application on top of it. From that image, you create containers, just like from an AMI you launch instances.

Creating Containers: Interactive and Detached Modes

Now let us create a container. The command is docker run, and you will use it constantly.

Interactive Mode

To create a container and log into it immediately:

docker run -it --name amazon-linux-container amazonlinux

Breaking this down:

• docker run creates and starts the container

• -it puts you into interactive mode, meaning your terminal connects directly to the container's shell

• --name amazon-linux-container gives the container a human-readable name

• amazonlinux is the image to use

The moment you hit enter, you are inside the container. Your prompt changes to show you a different shell. That is the container. You can install software inside it, create files, do whatever you need. It is like a very lightweight virtual machine, except it is not actually a virtual machine. It is a package running on top of your host system.

For example, inside an Amazon Linux container, you can run:

yum install git -y

Git installs inside the container. Your EC2 instance does not get Git. Only the container does.

Exiting a Container Without Stopping It

This is something that trips up a lot of people. If you press Ctrl + D inside a container, you exit and the container stops. If you do not want to stop the container, use this key combination instead:

Ctrl + P, then Ctrl + Q

This detaches your terminal from the container while leaving the container running. When you run docker ps -a, the container status will still show as Up, not Exited.

Detached Mode

Sometimes you do not want to log into the container at all. You just want it running in the background. For that, add -d:

docker run -itd --name ubuntu-container ubuntu

The -d flag stands for detached. The container starts, runs in the background, and you stay on your host machine. No automatic login. You get back your prompt immediately.

After running this, do docker ps -a. You will see the container listed as running, with a container ID. The container ID is the full identifier, though the output shows only the first few characters.

Logging Into a Running Container

Once a container is running, there are two ways to get inside it.

docker attach

docker attach ubuntu-container

docker attach connects your terminal to the main process of the container. This is the primary process that keeps the container alive. The problem is that if you exit from an attached session with Ctrl + D, you terminate that main process, and the container stops.

docker exec

docker exec -it ubuntu-container /bin/bash

This is the preferred way. docker exec creates a new process inside the container rather than attaching to the main one. When you exit this session, the container keeps running because you never touched its main process.

The difference in plain terms:

docker attach hooks you into the container's main thread. If you leave, the thread is gone and the container dies.

docker exec spawns a fresh shell process. When you leave, only that shell dies. The container carries on.

For day-to-day work, always use docker exec. It is safer and does not risk accidentally killing a running container.

To exit cleanly from either method without stopping the container:

Ctrl + P, then Ctrl + Q

Container Lifecycle: Start, Stop, Restart, Kill

Containers can be in several states. Running, stopped, paused, and dead. Here is how you move between them.

Stopping a Container

docker stop ubuntu-container

docker stop sends a graceful shutdown signal (SIGTERM) to the container's main process. It gives the process time to finish what it is doing, save any state it needs to, and then shut down cleanly. Only after that does the container stop.

Starting a Container

docker start ubuntu-container

If a container is stopped, this starts it again. Run docker ps -a after and the status changes from Exited to Up.

Restarting a Container

docker restart ubuntu-container

This stops and starts the container in one command.

Killing a Container

docker kill ubuntu-container

docker kill sends an immediate SIGKILL signal. It does not wait for the process to finish anything. The container is gone right now. No graceful cleanup, no waiting.

The difference between stop and kill is one of the most common interview questions on Docker:

docker stop gracefully stops the container. It waits for running processes to finish before shutting down.

docker kill forcefully stops the container immediately. Processes inside it are terminated without warning.

In production, always prefer docker stop. Use docker kill only when a container is stuck and not responding to stop.

Pausing and Unpausing a Container

docker pause ubuntu-container

Pausing freezes all processes inside the container. The container is still there, still consuming memory, but nothing inside it is executing. Think of it as hitting a pause button on a video.

When you try to log into a paused container, you will get an error saying the container is paused and cannot be executed. To resume:

docker unpause ubuntu-container

Removing Containers

Once you are done with a container and do not need it anymore, remove it.

First, stop it:

docker stop ubuntu-container

Then remove it:

docker rm ubuntu-container

If you try to remove a running container, you will get an error. You must stop it first, or use the force flag:

docker rm -f ubuntu-container

The -f flag force removes a running container without needing to stop it first. It is the equivalent of kill and remove in one step.

Inspecting Containers

docker inspect

docker inspect ubuntu-container

This command dumps the complete configuration and state of the container in JSON format. Container ID, creation time, current state (running, paused, dead), the image it was built from, environment variables, network settings, volume mounts, the process ID it is using, the platform it runs on, and much more.

If you ever need to debug why a container is behaving a certain way, docker inspect is your first stop. It tells you everything Docker knows about that container.

docker logs

docker logs ubuntu-container

This shows the stdout and stderr output from inside the container. If your application running inside the container is logging anything, this is where you see it. If the container is new and nothing has been run, the logs will be empty.

In real deployments, checking container logs is how you debug application errors.

docker top

docker top ubuntu-container

This shows all the processes currently running inside the container. It is the container equivalent of the top command in Linux. If you have an application server running inside the container, you will see that process listed here along with its PID.

docker stats

docker stats ubuntu-container

This shows live resource usage for the container: CPU percentage, memory usage, memory limit, network I/O, and block I/O. The output refreshes continuously, similar to the top command.

To stop the live output, press Ctrl + C.

This is the command you reach for when you want to know how much CPU or memory a container is consuming at any given moment. In production, this is your quick check before deeper investigation.

Copying Files into a Container

There are times when you have a file on your host machine and need it inside a running container. The command for this is docker cp.

Say you have a file called hello.txt on your EC2 instance and you want it inside the container at /tmp/:

docker cp hello.txt ubuntu-container:/tmp/

To verify it arrived:

docker exec -it ubuntu-container /bin/bash
cd /tmp
ls

You will see hello.txt sitting there. This is useful when you need to inject configuration files, certificates, or any other files into an already-running container without rebuilding the image.

Saving and Loading Images as TAR Files

This is not something you do every day, but it is good to know.

If you have built an image and need to share it with someone who cannot pull from Docker Hub, you can package the image into a TAR file:

docker save ubuntu > ubuntu.tar

This compresses the entire image into a single TAR archive. You can then copy this file to another machine using SCP or any file transfer method.

On the receiving end, to load that TAR file back as a Docker image:

docker load -i ubuntu.tar

After loading, run docker images and the image will appear as if it had been pulled from Docker Hub.

The ideal way to share images is through Docker Hub: push from one machine, pull on another. But when Docker Hub is not an option, save and load get the job done.

Cleaning Up Unused Images

In any active environment, images accumulate. Developers pull images, build images, experiment, and then leave old ones sitting around eating up disk space. Docker has a built-in command to clean all of that up:

docker image prune

This deletes all unused images, meaning images that no running or stopped container is currently using. It will not touch images that are actively being used.

This is an important command to know for interviews. The question often comes up as: "How do you clean up unused Docker images?" The answer is docker image prune.

Creating an Image from a Container

Normally, the right way to create a Docker image is through a Dockerfile, which gives you a repeatable, automated, version-controlled build process. But there is another way that is worth knowing.

If you have been working inside a container, installing software, making configurations, and you want to capture that state as a new image, you can use docker commit.

Here is the scenario. Start with a Ubuntu base container:

docker run -it --name uc ubuntu

Inside it, install a few things:

apt update -y
apt install apache2 python3 mysql-server -y

Exit the container without stopping it:

Ctrl + P, then Ctrl + Q

Now commit the container state to a new image:

docker commit uc uc-new-image

Run docker images and you will see uc-new-image listed. This new image contains Ubuntu with Apache, Python 3, and MySQL all pre-installed. Anyone who creates a container from this image gets all of that automatically.

To verify:

docker run -it --name uc-new-cont uc-new-image

Inside the new container, check if Python 3 is there:

python3 --version

It is there. Because that container was created from an image that had it baked in.

Again, in real-world practice, Dockerfiles are the way to build images. But docker commit is useful when you need to quickly snapshot a working container state, or when you are experimenting and do not want to write a Dockerfile yet.

Quick Reference: All Commands Covered

Here is a clean reference of every command discussed in this session.

Installation and setup:

yum install docker -y          # Install Docker on Amazon Linux / RHEL
systemctl start docker         # Start the Docker daemon
docker -v                      # Check Docker version

Images:

docker images                  # List all local images
docker pull <image-name>       # Pull an image from Docker Hub
docker rmi <image-name>        # Remove an image
docker save <image> > <file.tar>    # Save image to TAR file
docker load -i <file.tar>           # Load image from TAR file
docker image prune             # Delete all unused images

Containers - creating and running:

docker run -it --name <name> <image>      # Create and log in interactively
docker run -itd --name <name> <image>     # Create in detached mode (background)

Containers - logging in:

docker attach <container-name>                    # Attach to main process (risky)
docker exec -it <container-name> /bin/bash        # Open a new shell (preferred)

Containers - lifecycle:

docker ps                      # List running containers
docker ps -a                   # List all containers
docker stop <name>             # Gracefully stop a container
docker start <name>            # Start a stopped container
docker restart <name>          # Restart a container
docker kill <name>             # Forcefully stop a container
docker pause <name>            # Freeze all processes in a container
docker unpause <name>          # Resume a paused container
docker rm <name>               # Remove a stopped container
docker rm -f <name>            # Force remove a running container

Containers - inspection and monitoring:

docker inspect <name>          # Full container details in JSON
docker logs <name>             # View container output logs
docker top <name>              # Show running processes inside container
docker stats <name>            # Live CPU and memory usage

Files and images from containers:

docker cp <file> <container>:<path>       # Copy local file into container
docker commit <container> <new-image>     # Create image from container state

stop vs kill: The Interview Question

This comes up in nearly every Docker interview, so it deserves its own summary.

docker stop sends SIGTERM to the main process inside the container. The process can catch this signal, finish its current work, write anything to disk, and shut down cleanly. Docker waits a default of ten seconds for this to complete. If the process has not stopped by then, Docker sends SIGKILL automatically.

docker kill sends SIGKILL immediately. There is no waiting, no grace period, no chance for the process to clean up. The container stops right now.

Which one to use: In production, always use docker stop for containers running databases, web servers, or any stateful application. Use docker kill only when a container is hung and not responding to stop.

Summary

What we covered in this session represents the complete operational lifecycle of Docker containers. Starting from pulling base images off Docker Hub, to creating containers in interactive and detached modes, to managing their state through start, stop, restart, pause, and kill, to logging in safely using docker exec, to monitoring resources with docker stats and docker top, and finally to cleaning up images with docker image prune and saving images as TAR files when Docker Hub is not available.

The commands here are not theoretical. These are the exact commands DevOps engineers type every day. Whether you are debugging a running container, checking its resource footprint, copying a config file into it, or snapshotting its state with docker commit, all of this belongs in your working vocabulary.

Practice each command, run them on a real EC2 instance, and the muscle memory builds fast. Docker is not hard. It just takes repetition.