docker-compose 'run' wrongly uses old ports for linked containers when yaml changes

[ferdynice]

Version 1.4.0.

The docker-compose 'run' command wrongly uses old ports for linked containers when the yaml configuration file has changed between runs.

How to reproduce:

• Define a yaml with a service (i.e. web) and a linked service (i.e. db) and expose db port on host.
• Start the web service using 'run' (so that the linked db instance is created because it runs for the first time). It does not matter if you use the 'service-ports' option, because this only affects the service you are actually starting, not linked services.
• Stop the web service if it's still active. (Hit Ctrl-C or use docker-compose command if you ran it in bg).
• Kill the db service.
• Change the db port mapping in the yaml. (So it uses another host port).
• Now, when you start the web service again using 'run', it does not use the new port but still the old port configuration.

It think this is a bug, because docker-compose 'up' command actually does use the new ports defined in the yaml.

Should the 'run' command not do the same?

[aanand]

Arguably a bug, yes. Right now, docker-compose run merely tries to ensure that upstream dependencies are running, but doesn't try to ensure that they're up-to-date.

This is mostly a holdover from before smart recreate was implemented (and before it became the default behaviour). Back then, it made no sense to recreate your db container every time you wanted to run a one-off command in a web container.

It would've been particularly bad if you were running docker-compose up in one terminal and doing one-off docker-compose run command in another, you'd essentially have to restart docker-compose up each time in order to re-attach to the db container.

Now that smart recreate is the default, that's less of an issue - the db container will only be recreated if its configuration has changed. You'll still have to restart docker-compose up to re-attach in that scenario, though - this would have to be fixed, perhaps by @dnephin's suggested approach in #1866.

[dnephin]

I feel like the current behaviour is still correct. run shouldn't do everything that up does. If you need to update the environment, run up after making changes. run should only take care of running the command in a new container.

[kilianc]

@dnephin the problem with that approach is that up/down commands don't fully cover all the use cases and many people use run as workaround.

For example a sockets/api ready dependency (like a db connection) is usually express as

docker-compose run wait_for_db && docker-compose run --service-ports my-app

I have no way ATM to correctly controlled the exposed ports through environment variables.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because it had not recent activity during the stale period.