Improve docker-compose container lifecycle for local development, such as reusing already started containers

[Davio]

In some testing situations, it is okay to spin up docker-compose containers once, keep them running and reuse them for both local development and testing. For instance, if your test setup is configured to clear your data at the start (and end) of each run and / or preload it with specific data.

For Spring Boot itself, we can just add the spring-boot-docker-compose module and configure the its lifecycle to start_only.

When containers in a docker-compose file have been ran previously, a project prefix is assigned to each container, usually the name of the current folder.

When the docker-compose testcontainers module starts the containers, it uses a random project ID. This obviously does not match the project ID when you previously manually (or through Spring Boot) started the containers. This causes a runtime error because it tries to start new containers, but the ports are already allocated.

It would be nice if the docker-compose module allowed containers to be reused between development and testing and have some lifecycle options such as 'start only' which would work well for iterative local development.

[lpaolella]

Hi, I'm here to ask this exact question. In our development workflow, we're used to start a docker compose, a local instance of the service (we're using Quarkus) and just run a suite against this as a "black box", so we can use the same suite locally (against the running process) and in CI (against the built artifact). We'd like to switch to testcontainers to be able to handle the lifecycle of the containers inside the test suite (to test when an external dependency is unavailable, for example), without losing the option of just running the same suite with the running docker compose file. This is mostly useful because:

• it seems (correct me if I'm wrong) that there's no straightforward way to keep the containers running after the test goal is finished, which really simplifies local development as you can do postmortem analysis of the containers when a test doesn't work as expected or there are errors
• it makes reusing containers across suites more straightforward than the recommended method, which really speeds up local development and CI runs (where it makes sense of course), plus it seems there's no withReuse for compose containers?
• it generally would allow for greater flexibility in plugging testcontainers into existing workflows (like our case)

Ideally, we would like a way to:

• run the docker compose separately and just bind a testcontainer to the running containers [this would happen in local development]
• if the tests are started and the containers aren't available, launch the docker compose (and bind the containers) [this would happen in CI]

Our issues so far have been:

1. when using ComposeContainer -> there seems to be no way to reuse the containers, so they're killed every time, and there seems to be no way to bind to an existing running docker compose project. We tried a "hack" running it with:
   .withOptions("--project-name=<ourdockercomposeprojectname>")
   But it results in this error:

[ERROR] Errors: 
[ERROR]   RabbitMqIntegrationTest.setUp:32 » ContainerLaunch Container startup failed for image alpine/socat:1.7.4.3-r0

2. when using GenericContainer -> there seems to be no way to bind it to a running container from a docker compose file

If you have any suggestion on how to get closer to our target, and which requirements it makes sense to "sacrifice" for a more idiomatic approach, we'd be very grateful.

Thanks and have a nice day!