docker run creates and starts a container from an image. Mastering its flags — for port mapping, volume mounts, environment variables, naming, and resource limits — gives you full control over how containers run in both development and production environments.
DockerRunDevOpsCLIdocker run -it ubuntu bash
-i keeps stdin open and -t allocates a pseudo-TTY. Together they give you an interactive shell inside the container. When you exit the shell, the container stops. Use this for debugging and exploration.docker run -d nginx
-d flag runs the container in the background and prints the container ID. The terminal is immediately returned to you. Use docker logs container_id to view output and docker stop container_id to stop it.docker run -d --name mywebserver nginx
--name flag assigns a human-readable name instead of a random one. Named containers are easier to reference in logs, stop, and exec commands: docker stop mywebserver instead of a long container ID.docker run --rm alpine echo "Hello World"
--rm flag automatically removes the container when it exits. Ideal for one-off commands and CI steps where you don't want containers accumulating. Without this, stopped containers remain until manually removed.docker run -d -p 8080:80 nginx
-p host:container flag maps a port on your machine to a port inside the container. This makes nginx accessible at http://localhost:8080. The container port (80) stays fixed; change the host port (8080) as needed.docker run -d -v /host/path:/container/path nginx
-v host:container flag mounts a host directory into the container. Changes made inside the container are immediately reflected on the host and vice versa. Essential for development workflows where you edit files locally.docker run -d -v /host/config:/etc/config:ro nginx
:ro to make the volume read-only inside the container. The container can read the files but cannot modify them. Use this for config files and secrets to prevent accidental modification by the containerized process.docker run -d -e NODE_ENV=production -e PORT=3000 myapp
-e flag sets environment variables inside the container. Use multiple -e flags for multiple variables. The running process can read these like any other environment variable in its language.docker run -d --env-file .env myapp
--env-file flag loads environment variables from a file. Each line should be in KEY=VALUE format. This is cleaner than multiple -e flags and keeps secrets out of shell history.docker run -d --cpus="1.5" --memory="512m" myapp
--cpus limits CPU usage (1.5 = one and a half cores). --memory limits RAM. Setting resource limits prevents a single runaway container from starving the host or other containers. Essential for production and shared environments.docker run -d --network mynetwork myapp
--network flag attaches the container to a named Docker network. Containers on the same network can communicate using container names as hostnames. Create a network first with docker network create mynetwork.docker run image-name to run a container interactively.-d to run in the background and --name to give it a recognizable name.-p host:container and mount volumes with -v host:container.-e KEY=VALUE or --env-file .env.--rm for short-lived commands to avoid container accumulation.docker run creates a new container from an image and starts it. docker start restarts a container that was previously created and stopped. Use docker run for new containers and docker start to restart existing ones.
Use docker exec -it container_name bash (or sh for Alpine-based images). Unlike docker run -it, exec connects to an already-running container without starting a new one. This is the standard way to inspect or debug a live container.
Containers run only as long as their main process (PID 1) is running. If your CMD or ENTRYPOINT exits immediately, the container stops. Common causes: the process runs in the background (use -d with the foreground command), or there's a startup error (check docker logs container_id).