You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
DockerComposeContainer not starting up specific services #2191
Problem:
DockerComposeContainer starts up all the services in compose.yml even using withServices to select services I want to start up.
Investigation:
I found that (#1528) introduced the ability to start up specific services by adding services name after docker-compose up -d [services_names]
but it was removed accidentally in (#1847) when adding scale related settings.
In (#1847), it replaced [services_names] entirely by --scale [service=n],
but docker-compose up --scale [service=n] means start up ALL services in compose.yml with default 1 instance and the mentioned services with [n] instance.
Suggestion:
I think the correct way is adding the services name after the scale attribute. docker-compose up [scale setting] [services_name]
i.e. docker-compose up --scale service_b=2 service_a service_b
Hi @E4Edwards, thanks for reporting. That does looks like a bug that we should fix.
I think your proposal is good, and addresses another edge case neatly (we set servicename=1 for any service that is declared but does not have a scale setting, which would override any default in the compose file).
So just to be clear:
If the Compose file contains service_a, service_b, service_c...
and withServices("service_a", "service_b") has been used
and withScaledService("service_b", 2) has been used
Then the resulting command should be docker-compose up --scale service_b=2 service_a service_b
That seems correct to me, and we'd happily accept a PR to fix it.
When I was trying to fix the problem, I have another question would like to clarify.
Besides withServices and withScaledService, I found that withExposedService is another method for user to provide config related to services.
When user sets services config by withScaledService and withExposedService but does not include those services name in withServices, the program should start up those unmentioned services automatically.
Otherwise, it is no point to set config for non-started up services.
Scenario 1:
withServices("service_a", "service_b") has been used withScaledService("service_c", 2) has been used withExposedService("service_d") has been used
Result command should be: docker-compose up --scale service_c=2 service_a service_b service_c service_d
Scenario 2:
withServices has not been used withScaledService("service_c", 2) has been used withExposedService("service_d") has been used
Result command should be: docker-compose up --scale service_c=2 (All services will be started up)
I provide an PR. In addition, I add respected unit test to the project.
But I didn't consider the case for withExposedService. Because I think it is not needed for docker-compose and it is making it more complex, and when the user wants to have some exposed ports can provide it in the docker-compose.yml (via fixed or dynamic host port) and also it is not sufficient for some cases, as some services needed to expose several ports.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this is a mistake, please reply to this comment to keep it open. If there isn't one already, a PR to fix or at least reproduce the problem in a test case will always help us get back on track to tackle this.
Replying to stale bot: This still needs to be fixed, and it looks like there's even a PR out for it. At a very minimum, there shouldn't be exposed methods & related documentation for a feature that doesn't work. Thus it shouldn't be auto-closed.
Activity
rnorth commentedon Dec 27, 2019
Hi @E4Edwards, thanks for reporting. That does looks like a bug that we should fix.
I think your proposal is good, and addresses another edge case neatly (we set
servicename=1for any service that is declared but does not have a scale setting, which would override any default in the compose file).So just to be clear:
service_a,service_b,service_c...withServices("service_a", "service_b")has been usedwithScaledService("service_b", 2)has been usedThen the resulting command should be
docker-compose up --scale service_b=2 service_a service_bThat seems correct to me, and we'd happily accept a PR to fix it.
E4Edwards commentedon Jan 2, 2020
When I was trying to fix the problem, I have another question would like to clarify.
Besides
withServicesandwithScaledService, I found thatwithExposedServiceis another method for user to provide config related to services.When user sets services config by
withScaledServiceandwithExposedServicebut does not include those services name inwithServices, the program should start up those unmentioned services automatically.Otherwise, it is no point to set config for non-started up services.
Scenario 1:
withServices("service_a", "service_b")has been usedwithScaledService("service_c", 2)has been usedwithExposedService("service_d")has been usedResult command should be:
docker-compose up --scale service_c=2 service_a service_b service_c service_dScenario 2:
withServiceshas not been usedwithScaledService("service_c", 2)has been usedwithExposedService("service_d")has been usedResult command should be:
docker-compose up --scale service_c=2(All services will be started up)Are these behaviours reasonable?
mnafshin commentedon Jan 14, 2020
I provide an PR. In addition, I add respected unit test to the project.
But I didn't consider the case for withExposedService. Because I think it is not needed for docker-compose and it is making it more complex, and when the user wants to have some exposed ports can provide it in the docker-compose.yml (via fixed or dynamic host port) and also it is not sufficient for some cases, as some services needed to expose several ports.
stale commentedon Apr 13, 2020
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this is a mistake, please reply to this comment to keep it open. If there isn't one already, a PR to fix or at least reproduce the problem in a test case will always help us get back on track to tackle this.
mjustin commentedon Apr 13, 2020
Replying to stale bot: This still needs to be fixed, and it looks like there's even a PR out for it. At a very minimum, there shouldn't be exposed methods & related documentation for a feature that doesn't work. Thus it shouldn't be auto-closed.