Hi @SbiCA, a great feature for sure. I think docker compose supports a lot of different use cases and is a very important feature. I had it on my list right from the start (#4), but I never had time for it.

This week I would like to improve some small parts in the build pipeline and add another section to the README.md about your issue #120. Next week I’m busy, but I could start working on this feature the following week.

Of course, your help is always welcome! If you like, just go ahead and start with a feature branch - or we'll work together on this feature. What do you think?

@HofmeisterAn sure I would be open for collaboration, since I'm in a similar situation regarding my availability. Maybe we could have a gitter or slack channel for that purpose or what would be your favorite way of having design discussions?

Gitter, Slack or MS Teams would be nice. I'm using all three of them. Anything you prefer? As soon as I’m back next week we can start having design discussions.

@SbiCA I think it would be great if you join the official Slack channel: http://slack.testcontainers.org/.
Maybe, we can add the feature already in the official project? What do you think?

Waiting for this feature too!

I agree, this feature would be great. Maybe you can get in touch with @SbiCA. A pull request is more than welcome. I am happy to help as much as I can, like feature discussions, tests, code reviews, etc. I just can’t bring myself to do all the development now, due other projects.

Same here 😢 , sorry for having raised the expectations/adding delay here.

Any way to join?

I think no one started yet. Would you like to start? Maybe some more will join than.

I'd be happy to help, is anyone working on it?

I think no one is working on it right now. Contribution is more than welcome.

Cool, I'll give it a shot.

Thinking about the API design for this, I have a few points to raise:

1. Since all of the public API surface revolves around working with a single container, I propose this API for compose:

   var compose = new DockerComposeBuilder()
     .WithComposeFile("path/to/docker-compose.yml")
     .Build();
   
   await compose.UpAsync();
   await compose.DownAsync();

2. Regarding implementation - since compose is not part of the Docker Engine API, and the docker compose command has been part of Docker Desktop for a while now, I assume it is acceptable to use the docker compose command for the different compose methods (docker compose up, docker compose down etc.).

It would be nice to consider the testcontainers-java implementation. I'm not very familiar with it, but I think it is a good idea not to differentiate too much. OC, it should still be idiomatic with .NET.

The java implementation is spinning a container to run compose commands, I assume because they could not assume docker-compose is installed on all machines back when it was implemented. This is where I think it makes sense to diverge from their implementation, because for a long time now compose is bundled with Docker Desktop.

May I ask how do you plan on implementing this?

https://github.com/mariotoffia/FluentDocker seems neatly implemented.

Are you on official slack? @LoremFooBar

Basically by running docker compose commands. I'll ping you on slack.

The java implementation is spinning a container to run compose commands, I assume because they could not assume docker-compose is installed on all machines back when it was implemented. This is where I think it makes sense to diverge from their implementation, because for a long time now compose is bundled with Docker Desktop.

what about running these tests as part of the CI pipeline for example?
Probably this is the importance of having a docker image with docker compose client in it

The java implementation is spinning a container to run compose commands, I assume because they could not assume docker-compose is installed on all machines back when it was implemented. This is where I think it makes sense to diverge from their implementation, because for a long time now compose is bundled with Docker Desktop.

what about running these tests as part of the CI pipeline for example? Probably this is the importance of having a docker image with docker compose client in it

I find it reasonable to have the developer properly set up a CI environment for their needs, and that includes any binaries required to run their tests. We can ensure a clear error message is displayed when compose is unavailable on the machine. IMO the alternative is over complicated for most cases.

Any news about it?

Unfortunately, I was not able to make much progress eventually.

Still working on this feature? Currently this is the only feature that still makes us use FluentDocker instead of TestContainers...

I think nobody is working on the Compose support right now.

Hi @HofmeisterAn
I really need this feature in my project, so I think I can make it happen. I'll keep you updated.

is this feature any closer to being merged?
I'm happy to help where I can to get this over the line/on par with the Java version.
The only question is whether we should run a container (to run compose commands) as the Java version does, whether we should check whether docker compose is installed on the target system, whether we should require Docker desktop, or whether we should download and run a version of compose ourselves.

See here for more information.

Thanks,
Sean.

I came across this issue today after being a bit perplexed by the idea of a "Docker Wormhole Configuration"

It feels like a bit of an anti-pattern, and possibly a security concern. In the event that a container is compromised, am I correct in concluding that there is an easy path to instructing the docker daemon to start other containers of any image on the host?

Further reference: https://ro14nd.de/Docker-Wormhole-Pattern

I'll try to build and test patch #1082 over the next few days...

Hey!
What's blocking the already-existing PR? We definitely need something like this in our project.
Thanks

Hey! What's blocking the already-existing PR? We definitely need something like this in our project. Thanks

I reviewed the pull request (#1082) some time ago and have a few suggestions and things I would like to discuss first (nkz-soft#1) before merging the feature and bringing it upstream.