Reusing of docker compose containers is not possible

[tiloio]

We have simple use case: We want to spin up some background containers (like a database or a file storage) to run our test against it. The test are cleaning the containers as they need. These containers should be reused on every test run so we save time in every TDD cycle.

We define these containers in a docker-compose.yml and use the docker-compose cli with docker-compose up.
docker-compose up reuses the container everytime with the option --no-recreate.
This approach is working fine.

If we try that with testcontainers we get everytime the error that the containers are already existing.

const composeFilePath = path.resolve(__dirname, "dir-containing-docker-compose-yml");
const composeFile = "docker-compose.yml";

const await new DockerComposeEnvironment(composeFilePath, composeFile).up();

According to the docs its also not possible to pass in options like --no-recreate.

Is testcontainers made to serve our usecase? Or should we stick to the raw docker-compose cli?

[cristianrgreco]

Hi @tiloio, just so I understand, you are running code like:

 await new DockerComposeEnvironment(composeFilePath, composeFile).up();

Before every test/test suite, and because the container is already running, it fails.

1. Is the failure a conflict?
2. In your docker-compose.yml file have you specified the container_name?

[tiloio]

We are running it before every test run ( currently in the Jest global setup).

The container_name is specified and we get a conflict for that name.

[cristianrgreco]

@tiloio #289, specifically:

const startedEnvironment = await new DockerComposeEnvironment(fixtures, yaml)
      .withNoRecreate()
      .up();

[cristianrgreco]

@tiloio it seems this does not work because the environments have different ID labels:

    const startedEnvironment1 = await new DockerComposeEnvironment(fixtures, "docker-compose-with-name.yml")
      .withNoRecreate()
      .up();

    const startedEnvironment2 = await new DockerComposeEnvironment(fixtures, "docker-compose-with-name.yml")
      .withNoRecreate()
      .up();

but this will work, is it OK for you?

    const environment = new DockerComposeEnvironment(fixtures, "docker-compose-with-name.yml")
      .withNoRecreate();

    const startedEnvironment1 = await environment.up();
    const startedEnvironment2 = await environment.up();

[tiloio]

We are starting every time a new process. So this will not work.

Why is it different to the normal docker compose up?

[cristianrgreco]

I've got it working so that you can do:

await new DockerComposeEnvironment(fixtures, "docker-compose-with-name.yml")
  .withNoRecreate()
  .up();

await new DockerComposeEnvironment(fixtures, "docker-compose-with-name.yml")
  .withNoRecreate()
  .up();

And it won't conflict. I take it that will work?

[cristianrgreco]

Released in v7.22.0

[tiloio]

I forgot to mention that we are using TESTCONTAINERS_RYUK_DISABLED=true.
So we want to really reuse the containers between runs.

When I now use the v7.22.0 like that:

  process.env.TESTCONTAINERS_RYUK_DISABLED = "true";
  
  const composeFilePath = path.resolve(baseDirectory, "local");
  const composeFile = "compose.yml";

  await new DockerComposeEnvironment(composeFilePath, composeFile)
    .withNoRecreate()
    .withWaitStrategy("s3", Wait.forLogMessage("Documentation: https://docs.min.io"))
    .withWaitStrategy("dynamodb", Wait.forLogMessage("CorsParams:"))
    .up();

I will get a

Error: Containers3  Creating
Containerdynamodb  Creating
Error response from daemon: Conflict. The container name "/dynamodb" is already in use by container "7903a6e10837f2d9d930d85f15ec3eb87c2a129973a446c449eaeac269e3ab04". You have to remove (or rename) that container to be able to reuse that name.

So we are not able to run the DockerComposeEnvironment between multiple test runs.
Imagine having a npm task like

\\package.json
{
   \\ ...
   "scripts": {
       \\ ...
      "start": "node start-compose.js"
   }
}

Then using this npm run start and after a few minutes a npm run start again. I want to reuse all containers to not wait again for that startup.

[cristianrgreco]

@tiloio if ryuk is disabled and you are not downing/stopping the docker-compose env yourself, then it should stay running even after the tests have terminated, and withNoRecreate should mean there is no conflict when starting the same environment. See the test I added in the referenced PR which shows withNoRecreate working. If you have an issue please share your docker-compose file and preferably some repro

[kylemillar608]

@cristianrgreco I am having the same issue as @tiloio. I have created a small project to demonstrate the issue. https://github.com/kylemillar608/testcontainers-sample

Recreate issue-

1. Run npm install
2. Run tsc
3. Run npm test OR run docker-compose up in the src/test directory
4. Run npm test again

Expected behavior-
The test run in step 4 should be successful regardless of which command is run in step 3.

Actual behavior-
Test run fails due to ERROR: for db Cannot create container for service db: Conflict. The container name "/db" is already in use by container "8f8d76a37d66bf67193249218bfd7e9d3d63909a3597f1598986e60c0be15e5a". You have to remove (or rename) that container to be able to reuse that name.

Note: The issue does not present itself if you run docker-compose up followed by docker-compose up --no-recreate. If you run npm test, then docker-compose up --no-recreate, the issue IS there.

[cristianrgreco]

Ah I understand, thanks @kylemillar608.

What's happening is that for each node instance there is a unique testcontainers session ID created, and each docker-compose container is labelled with this unique ID. The reason for this is so the reaper can find these containers and delete them. If however you start a completely new node instance (your step 4), then the label has changed and withNoRecreate has no effect as it's seen as a different docker-compose environment.

The first solution that comes to mind is to not label the docker-compose containers if withNoRecreate is specified. This will mean however that resources will not be cleaned up by the reaper if the process terminates unexpectedly, though it seems you would be disabling the reaper and handling this issue yourselves anyway.

Another solution would be to add some argument to withNoRecreate, to indicate that it should not be recreated across different instances, that way you can opt-in to turn off the default reaper behaviour, something like
withNoRecreate({ teardownAfterProcessTerminates: false }), or withNoRecreate({ unref: true }). It's kind of a best of both worlds as you don't have to explicitly disable the reaper, and for people who don't split their tests across multiple instances they get auto resource cleanup.

@kylemillar608/@tiloio let me know if you have any thoughts/suggestions on this.

[kylemillar608]

@cristianrgreco So, just to clarify, if I run npm test and then run docker-compose up --no-recreate it won't work because the docker container created w/ npm test has been given a special label w/ the session ID? I wouldn't have expected the docker-compose command to be affected by that label.

Is there any reason we need the session ID if ryuk is disabled? If not, if TESTCONTAINERS_RYUK_DISABLED = true, we can just default to not using session ID's. That would remove the requirement for an extra option in the withNoRecreate() function. Right now, the options in withNoRecreate() seems kind of redundant to disabling ryuk to me, but I am not sure if that is true.