New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't always start a service defined in yml when docker-compose up #1547
Comments
You could do this:
[edit] |
That could work for sure. However, to build the entire suite of services, you'd need to issue two commands:
It would be preferable to have this in one command... |
+1 |
This is a duplicate of many previous issues (#1439, #697, #942, #1041, #1451, etc) If a container isn't going to start and run with the rest of the containers, it's not really "part of the composition", so I'm -1 on any new keys to define different behaviours for services. There are however, already a few ways to handle this scenario:
For your specific case, there is a new experimental flag in the docker-compose 1.3 release candidate. |
+1, ideally allow the flag to be set from an environment variable. We have a few build/run variants, to this feature would be great |
For my team I made a script that basically does this :
This works well. |
Thanks for the suggestion! I've created an issue here to aggregate many similar suggestions: #1896 |
This feature would be tremendously useful. For example, I have an program that runs an interactive terminal, and passes configuration parameters to the running services (e.g. debug verbosity). Because it uses the same network, volumes, etc., as the other services, it makes sense to keep it in the same compilation. Running it from it's own compilation is doable, but it requires hard-coding the names of the volumes into the compose file. The no-op command idea is fine, but not very elegant, especially if there's a long path to the executable. Another option would be to run a script inside the container that somehow tests what kind of environment it's in, and determine if it was run via |
This helps for me:
|
Apparently If you don't like typing the extra arguments in the CLI you could always do something like services:
<service>:
entrypoint: "bash -c"
command: "exit 0" |
I implemented this using environment variables. Solution on stackoverflow: https://stackoverflow.com/a/61107015/10534470 |
When you issue a
docker-compose up
, all services always start. While you're iterating over some code, this isn't always great (some background: we use consul for service discovery once our images are started, so we don't rely on links too heavily. Having said that, our consul service images do link to one another).When I'm heavily iterating on the code in a particular container and it requires many restarts, it's much easier to have all other containers controlled by docker-compose, and the container you're iterating on to be controlled separately.
The yaml could be something like:
Notice the
always-start
property, being set to false. This would allow me to have a workflow of:I could then
docker compose stop app
anddocker compose up app
independently of all other services. To achieve this at present, you have comment/uncomment the app service within the yaml file.The text was updated successfully, but these errors were encountered: