You run a container from an image using the docker run command, which creates a writable container layer from the image and executes its default command or a specified override.
The docker run command is the primary way to start a container from a Docker image. It creates a new container instance from the specified image, adds a writable layer on top, and executes the container's default command (defined by CMD or ENTRYPOINT in the Dockerfile) or a command you provide. The container runs in isolation but can be configured to expose ports, mount volumes, set environment variables, and define resource limits through various flags.
When you run docker run, Docker first checks if the specified image exists locally. If not, it attempts to pull the image from a configured registry (like Docker Hub). It then creates a container from that image, assigns a unique ID and name (or uses a generated one), and finally starts the container. The container runs until its main process exits, at which point the container stops. The --restart flag can automatically restart the container if it exits.
The -d or --detach flag runs the container in the background, returning control to the terminal. Without this flag, the container runs in the foreground, and its logs are printed to your terminal. The -it combination (interactive + pseudo-TTY) is essential for running shells inside containers, allowing you to debug or explore the container's filesystem.
-d, --detach: Run container in background and print container ID
-p, --publish: Publish a container's port(s) to the host (format: host:container)
-v, --volume: Bind mount a volume (format: source:destination)
--name: Assign a name to the container for easier reference
-e, --env: Set environment variables
--rm: Automatically remove the container when it exits (cleanup)
-it: Allocate a pseudo-TTY and keep STDIN open (interactive mode)
--restart: Restart policy (no, always, on-failure, unless-stopped)
--memory, --cpus: Resource limits
The --rm flag is particularly useful for short-lived containers like development servers or test runs, as it automatically deletes the container when it stops, preventing accumulation of stopped containers on your system. Without this flag, containers persist in the stopped state, which you can view with docker ps -a. For production services like databases or web servers, you typically omit --rm so the container remains available after restarts.
You have an image called myapp:latest. How would you start a container that runs in the background and maps host port 8080 to container port 80?
If you run docker run myapp and the container exits right away, what are the common reasons and how would you verify them?
How would you launch a container interactively to get a shell inside the image for debugging?
Your feature needs to run a container from myapp while mounting /var/logs from the host and setting ENV=prod. Walk me through the exact docker run command you’d use and why.
After deploying a container with docker run -d myapp, you notice it isn’t receiving traffic. What steps do you take to troubleshoot the networking and port mapping?
In a CI pipeline a docker run fails with “port already allocated”. How would you resolve the conflict and what trade‑offs does your solution have?
We need to launch the same image on dozens of hosts, each with different CPU/memory limits and log destinations. How would you design a strategy for running these containers at scale, considering start‑up time, isolation, and observability?
Explain how you would use docker run options to enforce security best practices—such as dropping privileges, using a read‑only filesystem, and limiting capabilities—and what impact they have on the application.
A container started with docker run is intermittently crashing due to OOM. How would you modify the run command and what monitoring would you put in place to catch the issue early?
Our legacy monolith is being containerized, and we currently have many ad‑hoc docker run scripts. How would you design a standardized system or tooling to launch containers across teams while handling versioning, secrets, and compliance?
Discuss the trade‑offs between using docker run in CI/CD pipelines versus moving to an orchestrator like Kubernetes for large‑scale deployments, and outline a migration plan.
You need containers launched from images to be reproducible across multiple data centers with different host OS kernels. What considerations would you embed into the run process and how would you enforce them organization‑wide?