Testcontainers-java: DockerComposeContainer not starting up specific services

Created on 17 Dec 2019  路  5Comments  路  Source: testcontainers/testcontainers-java

Hi,

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

aredocker-compose typbug

Most helpful comment

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.

All 5 comments

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)

Are these behaviours reasonable?

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ayedo picture ayedo  路  3Comments

rnorth picture rnorth  路  3Comments

naderghanbari picture naderghanbari  路  3Comments

vmassol picture vmassol  路  3Comments

micheal-swiggs picture micheal-swiggs  路  4Comments