Creating a Container in Docker: Practical Usage and Considerations

Spin up a shell or deploy an application—in Docker, it starts with a single command: docker run. Behind this simplicity, there’s nuance in how containers are created, named, and networked. Version used for all examples: Docker 24.0+ (behavior may differ in earlier releases).

The Basics: docker run

docker run [OPTIONS] IMAGE [COMMAND] [ARG...]

• IMAGE: Source image, e.g., nginx:1.25-alpine.
• COMMAND: Optional, overrides default command in the image’s Dockerfile.
• OPTIONS: Container settings.

Minimal Example

Test your engine and networking stack—start with the canonical hello world:

docker run hello-world

Expected output:

Hello from Docker!
...

Successful output here means basic Docker networking, image pull, and runtime are functional.

Detached Mode and Port Mapping

Deploying a web service? For background execution with transparent host-to-container port mapping:

docker run -d --name webdemo -p 8080:80 nginx:1.25-alpine

• -d: Detached mode.
• --name: Human-readable container handle.
• -p 8080:80: Host port 8080 → container port 80.

Container logs can be viewed via:

docker logs webdemo

Note: If port 8080 is taken, Docker returns:

Error starting userland proxy: listen tcp 0.0.0.0:8080: bind: address already in use.

Change the host port as needed.

Container Creation Without Immediate Start

Occasionally, it’s preferable to configure or inspect before starting. Enter docker create:

docker create --name staging-busybox busybox:1.36

Produces a stopped container. Start it later with:

docker start staging-busybox

This can be useful in automated CI scripts where configuration is staged before runtime.

Interactive Containers (Debug, Ad-hoc Admin)

For exploratory work or debugging:

docker run -it --rm ubuntu:22.04 bash

• -i -t: Interactive mode with terminal.
• --rm: Clean up after exit.
• The container shuts down and disappears after logging out, keeping environments ephemeral.

Gotcha: Ctrl+C inside some containers exits the shell and kills the process. To preserve the container for debugging post-mortem, skip --rm.

Volumes, Persistence, and Data

By default, a container’s filesystem is ephemeral. To persist or inject data:

docker run -v "$(pwd)"/data:/var/lib/data alpine:3 echo "persistent test"

• -v: Attach a host directory to a container path.
• Useful for stateful services (e.g., Postgres data at /var/lib/postgresql/data).

Common Flags Reference

Non-Obvious Tip: Retaining Container State Between Runs

Suppose you want to perform an operation, commit the result, and launch a new container based on changes:

1. Create and run a container interactively:

   docker run --name edit-me -it ubuntu:22.04 bash
   

2. After exit, commit changes:

   docker commit edit-me my-ubuntu-with-changes
   

3. You can now run my-ubuntu-with-changes as a new baseline.

Known issue: The new image includes all container layers—watch disk usage if repeating this often.

Side Notes and Trouble Spots

• Docker’s error reporting is often terse. If container launch fails without clear output, check docker events in another terminal.
• For heavily parameterized containers (e.g., databases), environment variables passed with -e can be critical. Example for Postgres:

  docker run -e POSTGRES_PASSWORD=secret -d postgres:16
  

• Resource limits (--memory, --cpus) are available but sometimes ignored on Windows hosts—test accordingly.

ASCII Diagram: Basic Docker Flow

   [Docker Image] --(docker run)--> [Container Process]
                             \_ (volumes, ports, env)

Further Reading

• Docker Run Reference
• Common Docker Networking Pitfalls
• Docker Hub Image Registry

In practice, running a container is usually the starting point—real use comes from combining run-time options, file system mounts, and network mappings. Not all use cases are covered here, but mastery of docker run itself is foundational. Sometimes, a simple docker run isn’t enough—consider Compose or Kubernetes for orchestrated multi-container scenarios.