How do you run a container from an image?
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.
- 1
-d, --detach: Run container in background and print container ID - 2
-p, --publish: Publish a container's port(s) to the host (format: host:container) - 3
-v, --volume: Bind mount a volume (format: source:destination) - 4
--name: Assign a name to the container for easier reference - 5
-e, --env: Set environment variables - 6
--rm: Automatically remove the container when it exits (cleanup) - 7
-it: Allocate a pseudo-TTY and keep STDIN open (interactive mode) - 8
--restart: Restart policy (no, always, on-failure, unless-stopped) - 9
--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.
Scenario Questions
0-2 years experience
- 1You 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?
- 2If you run `docker run myapp` and the container exits right away, what are the common reasons and how would you verify them?
- 3How would you launch a container interactively to get a shell inside the image for debugging?
2-5 years experience
- 1Your 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.
- 2After 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?
- 3In 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?
5-8 years experience
- 1We 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?
- 2Explain 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.
- 3A 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?
8+ years experience
- 1Our 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?
- 2Discuss 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.
- 3You 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?
Follow-up Questions
- What does the `--rm` flag do and when would you use it?
- How would you inspect a container that started but then stopped unexpectedly?
- Can you explain the difference between `CMD` and `ENTRYPOINT` in the context of `docker run`?