Running Docker Containers: Zero to Useful in Minutes

Modern application workflows rely on containerization for reproducibility and rapid deployment. The core of this: launching containers predictably, with proper flag usage and environment management. Here’s a practical engineering approach that covers initial setup through real-world management—cutting through to what matters.

Container Primer: Isolation Without the Overhead

A container delivers a self-contained user space—executable, portable, and lightweight. Unlike a traditional VM, it shares the host kernel, resulting in low startup time and minimal resource waste. Here's a high-level ASCII view:

+---------------------+
|  Host OS Kernel     |
|  +--------------+   |
|  | Container 1  |   |
|  |   (Nginx)    |   |
|  +--------------+   |
|  +--------------+   |
|  | Container 2  |   |
|  |   (App)      |   |
|  +--------------+   |
+---------------------+

Step 1: Ensure Docker Engine Is Installed

Docker Engine (tested with v24.0.2+) is required. On Linux (Ubuntu example):

sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io

On Windows/macOS, Docker Desktop from docker.com provides a standard experience.

Validate install:

docker --version
# Docker version 24.0.2, build cb74dfc

Systems with incomplete install often throw:

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

Check the service or user group permissions if you hit this.

Step 2: Retrieve an Image from Registry

Images are immutable layers, typically pulled from Docker Hub if not found locally:

docker pull nginx:1.25.2

• Specifying a tag (nginx:1.25.2) is best practice for reproducibility.
• Avoids unexpected upgrades.

Image digest can be checked with:

docker images --digests | grep nginx

Step 3: First Container—Expectation vs. Reality

Run a basic container:

docker run nginx:1.25.2

Outcome: The container likely starts and immediately exits. Why? The Nginx image expects its entrypoint to run in the foreground, but the default configuration runs as a daemon—terminating the PID 1 process triggers container exit. This is one of the fastest ways new users get burned.

Step 4: Useful Container Execution With Detachment and Port Mapping

Set Nginx to run persistently and expose port 80 on a custom host port:

docker run -d -p 8080:80 nginx:1.25.2

Where:

• -d launches detached (background process).
• -p map host port 8080 → container port 80.

Check status:

docker ps --filter ancestor=nginx:1.25.2

Access the default Nginx test page via http://localhost:8080.

Note: If you see "port is already allocated", verify nothing else is bound to 8080 (sudo lsof -i :8080).

Step 5: Container Naming for Robust Workflow

Naming simplifies orchestration, especially in CI or when scripting container admin:

docker run -d -p 8080:80 --name nginx-test nginx:1.25.2

Stop and remove by name:

docker stop nginx-test
docker rm nginx-test

No need to memorize container IDs.

Step 6: Running Interactive and One-off Commands

Debug or explore a base Ubuntu image (helpful when troubleshooting CI/CD builds):

docker run --rm -it ubuntu:22.04 bash

• --rm auto-removes the container post-exit.
• -it (interactive terminal) passes your input and output.
• Tag with explicit version.

Forgot bash? Try /bin/sh. Not installed on small Alpine images? That’s a separate rabbit hole.

Step 7: Handling Data Persistence—Volumes in Practice

Containers are ephemeral. Map a host directory for persistent or shared data.

docker run -d -p 8081:80 -v /srv/html:/usr/share/nginx/html:ro --name nginx-static nginx:1.25.2

• -v /srv/html:/usr/share/nginx/html:ro: Host folder (read-only) becomes the container’s web root.
• Update the host, see changes reflected in real time.

Gotcha: SELinux or filesystem permissions can cause “403 Forbidden” errors in Nginx logs. Adjust labels or permissions as required.

Step 8: Core docker run Flag Cheat Sheet

Alternate patterns (--network, --env, etc.) are often crucial when debugging microservices locally.

Practical Notes

• Image Version Pinning: Always use a specific tag—base images change subtly between releases.
• Logs: Use docker logs <container> to fetch output; helpful when debugging silent failures.
• Resource Limits: Not shown here, but --memory, --cpus, and related flags matter under load.
• Networking: For multi-container apps, consider custom bridges or compose files.

Known pain points: Docker Desktop sometimes blocks port binding due to OS firewall. On Linux, rootless mode has differences in volume permissions.

Summary

Launching and managing containers hinges on mastering a concise set of docker run options and understanding the lifecycle (image acquisition, port and volume mapping, process monitoring). Reliable workflows depend on explicit versioning, named containers, and awareness of runtime and storage trade-offs.

Most seasoned engineers automate further using Compose or Kubernetes, but the knowledge above underpins all higher abstractions.

Next Considerations

• Leverage Docker Compose for multi-container orchestration.
• Author a minimal Dockerfile to parameterize custom application images.
• Tie into CI/CD (Jenkins, GitHub Actions) to ensure automated, reproducible deployments.

It isn’t always perfect—container networking, file system propagation, or build caching can break assumptions. That’s the real world.

References

• Official Docker Engine Docs: https://docs.docker.com/engine/
• Nginx Docker Best Practices: https://hub.docker.com/_/nginx