apocas / dockerode-compose

docker-compose in Node.js using dockerode
Apache License 2.0
143 stars 31 forks source link

services.down() fails if container_name is set in the dockerfile #21

Open alxdca opened 2 years ago

alxdca commented 2 years ago

If the dockerfile defines the container name, then the calling services.down() fails as the down method looks for a container named with the following pattern:

projectName + '_' + serviceName + '_1'

In such case, the down method() should use the container_name defined in the dockerfile instead of its own naming format.

Dr1Ku commented 1 year ago

Indeed, the dreaded message `'Conflict. The container name "/" is already in use by container "". You have to remove (or rename) that container to be able to reuse that name.'

One workaround, as based on the current implementation of down would be:

const projectContainers = await docker.listContainers({
  all: true,
  filters: { label: [`com.docker.compose.service=${serviceName}`] },
});

for await (const projectContainer of projectContainers) {
  const container = await docker.getContainer(projectContainer.Id);

  if (projectContainer.State === 'running') {
    console.log('Stopped running container', projectContainer);
    await container.stop();
  }

  await container.remove();
}  

Whereas serviceName is the name used under your docker-compose's services list/array. One can also add one's own labels.

TheDelta commented 1 year ago

There hasn't been any progress on this issue and thankfully this was mentioned in here, because the error is "eaten" and I was confused why down is not working.

Am I missing something or is it really just taking the "container_name" property (or use default if it doesn't exist). I'm willing to write a PR, just want to be sure I'm not missing something.

I also noticed there is an empty array services = [] which does nothing. I would propose that this error will return successfull / unsucessfull downs, so a developer can react to this properly without being kept in the dark.

ralexrdz commented 6 months ago

I'm having a similar issue.compose.down() is not killing the containers

And also, compose.up() does not do what docker compose up -d command does, that is to replace current running containers with new version in case something in the config changed