Master Docker Container Management: Run, Stop, Resource Limits & Best Practices

Run Container

docker run is the method to start a container. Three ways to specify the command executed at container start: (1) CMD instruction, (2) ENTRYPOINT instruction, (3) specify directly in the docker run command line.

When the container starts, executing pwd returns / as the current directory. Use docker ps or docker container ls to view running containers on the Docker host.

<code>docker ps -a
docker container -a</code>

These commands list all containers, including stopped or exited ones.

1.1 Keep Container Running

Container lifecycle depends on the command run at start; as long as that command does not exit, the container stays alive. To keep a container running, execute a long‑running command, e.g.:

<code>docker run ubuntu /bin/bash -c "while true;do sleep 1;done"</code>

Adding -d runs the container in the background, freeing the terminal.

Note the CONTAINER ID (short) and NAMES fields. The short ID is the first 12 characters of the long ID. Use

--name

to assign a name; otherwise Docker generates one. Subsequent operations can refer to the container by long ID, short ID, or name.

<code>docker stop xxx  # xxx is ID or name</code>

1.2 Enter Container

docker attach – attach to the container’s primary process terminal. Ctrl+C exits and stops the container.

docker exec – run a new command in an existing container.

Example to open an interactive bash:

<code>docker exec -it <container> bash|sh</code>

Differences:

(1) attach connects to the original process without starting a new one.

(2) exec starts a new process inside the container.

(3) Use

docker logs

to view the original process output.

<code>docker logs -f xxxx  # follow output</code>

2. Best Practices for Running Containers

Containers can be classified as service containers (daemons providing services) or tool containers (temporary work environments). Service containers should be started with

-d

; tool containers are often run with

run -it

.

Running

busybox

with

run -it

enters the container immediately; after exiting, the container stops. Tool containers typically use lightweight base images such as busybox, debian, ubuntu.

3. Stop/Start/Restart Containers

Use

docker stop

to stop a running container (sends SIGTERM).

docker kill

sends SIGKILL for immediate termination.

Restart stopped containers with

docker start

.

docker restart

performs stop then start. To enable automatic restart, use

--restart

(e.g.,

--restart=always

or

--restart=on-failure:3

).

<code>docker run -d --restart=always xxx</code>

--restart=always means the container will be restarted immediately regardless of exit reason. The parameter can also be --restart=on-failure:3 , which restarts up to three times if the process exits with a non‑zero code.

4. Pause/Unpause Containers

Use

docker pause

to temporarily suspend a container (e.g., for snapshots).

docker unpause

resumes it.

5. Remove Containers

Exited containers still consume filesystem space. Delete them with

docker rm

. To remove all exited containers:

<code>docker rm -v $(docker ps -aq -f status=exited)</code>

6. State Machine

Creating a container:

docker create --name myhttpd httpd

. Starting it:

docker start myhttpd

.

docker run

combines create and start.

7. Resource Limits

Containers share host CPU, memory, and I/O. Docker provides mechanisms to limit each.

7.1 Memory Limits

Use

-m

or

--memory

to set a memory cap, and

--memory-swap

to set memory + swap cap.

<code>docker run -m 200M --memory-swap=300M ubuntu</code>

This allows up to 200 MB RAM and 100 MB swap. Default is unlimited.

Stress test example:

<code>docker run -it -m 200M --memory-swap=300M progrium/stress --vm 1 --vm-bytes 280M</code>

7.2 CPU Limits

CPU weight is set with

-c

or

--cpu-shares

(default 1024). It is a relative weight, not an absolute limit.

<code>docker run --name "containerA" -c 1024 ubuntu
docker run --name "containerB" -c 512 ubuntu</code>

When both need CPU, containerA receives twice the share of containerB.

Weight matters only under CPU contention; idle containers can use full CPU.

Stress test:

<code>docker run --name containerA -it -c 1024 progrium/stress --cpu 1
docker run --name containerB -it -c 512 progrium/stress --cpu 1</code>

7.3 Block I/O Bandwidth Limits

Block I/O can be limited with weight (

--blkio-weight

) and with

bps

or

iops

parameters.

<code>docker run --name containerA -it --blkio-weight 600 ubuntu
docker run --name containerB -it --blkio-weight 300 ubuntu</code>

Device‑specific limits:

<code>docker run -it --device-write-bps /dev/sda:30MB ubuntu
time dd if=/dev/zero of=test.out bs=1M count=800 oflag=direct</code>

8. Underlying Container Technologies

cgroup and namespace are the core mechanisms.

cgroup implements resource limits.

namespace provides isolation of resources.

8.1 cgroup

cgroup (Control Group) lets Linux set limits on CPU, memory, and I/O for processes. Docker options like

--cpu-shares

,

-m

,

--device-write-bps

configure cgroups.

<code>docker run -it --cpu-shares 512 progrium/stress -c 1</code>

Corresponding cgroup files are located under

/sys/fs/cgroup

(e.g.,

/sys/fs/cgroup/cpu/docker

).

8.2 namespace

Namespaces give each container its own view of system resources. Six types exist: mount, UTS, IPC, PID, network, and user.

Mount – separate filesystem view.

UTS – independent hostname.

IPC – isolated shared memory and semaphores.

PID – own PID space.

Network – independent network interfaces and IP.

User – separate user IDs.

Example to set a custom hostname:

<code>docker run -it -h myhostname --cpu-shares 512 progrium/stress -c 1</code>