As mentioned in docker-compose run
(2015)
The command passed by run overrides the command defined in the service configuration.
For example, if the web service configuration is started with bash
, then docker-compose run web python app.py
overrides it with python app.py
.
The second difference is the docker-compose run
command does not create any of the ports specified in the service configuration.
This prevents the port collisions with already open ports. If you do want the service's ports created and mapped to the host, specify the --service-ports flag:
$ docker-compose run --service-ports web python manage.py shell
So unless you have those specific needs (overriding a command or running only one container on different ports), docker-compose up
(even for one container) is enough.
Can you help explain why or when you would not want the ports to be created? That is why or when they might conflict with already open ports
Simply because docker-compose run
is made to run one-off commands for your services.
That means that, if you already did a docker-compose up
, all your containers are already running on their specified ports from docker-compose.yml
.
Doing a docker-compose run
at this stage (to execute a one-off command), if it was respecting the same port, would fail immediately. Hence the default non-creation of those ports.
Another use case (in Compose environment variables reference):
To see what environment variables are available to a service, run docker-compose run SERVICE env
.
Most recent (2019+) version of those commands are on docker/docker.github.io
: