Expose Network used by docker-compose

[muirandy]

I have a number of containers that I need to spin up to do a system test. I need to add another container which is external to the docker-compose file, and this needs to connect to the network thats already in use.

I can't get the network from the DockerComposeContainer. Nor can I access the ambassadorContainer as it is private. Neither is there a way to "add" the extra container into the DockerComposeContainer. I need one of these two options!

As the GenericContainer allows me to call getNetwork(), I propose we add the same to the DockerComposeContainer.

Could I have some feedback before I head off to implement the change?

[muirandy]

Turns out the ambassadorContainer's network isn't the one I'm looking for - it returns the "bridge" network. Not sure how this could be implemented - I can't see where we can get the correct Network from :(

[muirandy]

I can get what I need for now by defining the extra container in a second docker-compose file. However, it seems like this is still a sensible addition - I just don't know how I'd implement it!

[mnafshin]

Almost the same problem.
I want to use the docker-compose network as the network for ryuk container. Unfortunately, it is not possible yet.

BTW: As I am building my images in "docker-compose.yml" file, I must use ".withLocalCompose(true)", that I can not use ambassador container.

[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. 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.

[KraTos5589]

If the secondary container could be started before the docker compose file then @muirandy - it could be solved by changing the network in docker compose file as external and pass the network of the secondary container as environment variable. I did something like

docker-compose.yml

networks:
  default:
    external:
      name: ${NETWORK}

Java Code

GenericContainer contianer = new GenericContainer("");
new DockerComposeContainer<>(new File("src/test/resources/docker-compose-test.yml"))
.withEnv("NETWORK", contianer.getNetwork().getId())

[LionH]

I have the same issue here. I don't think @KraTos5589 resolution could be acceptable in my case as I can't change the original docker compose file.
I have a ClassRule DockerComposeContainer and I need to add another ClassRule LocalStackContainer. The LocalStack Container accepts to set the Network and I only need to get the network used by the Docker Compose file and pass it to the other.
I expect this to work and should be cleaner to accept several Container definitions specified in different ClassRule.
Any thoughts on this?

[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. 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.

[muirandy]

This is still an issue.

…

On 26 Jul 2020, at 22:11, stale[bot] ***@***.***> wrote:  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. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[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. 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.

[muirandy]

Keep open

…

On 25 Oct 2020, at 05:09, stale[bot] ***@***.***> wrote:  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. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.