Exec Fails If Container #1 Does Not Exist

[benyanke]

When using the --scale flag in non-swarm mode, containers are created like:

• app_1
• app_2
• app_3

If _1 gets killed, and the up command is run again, instead of _1 getting created again, it creates _4.

However, this causes exec to break, which appears to be hardcoded to _1.

If the following containers exist:
app_2
app_3
app_4

and you run: docker-compose exec app bash, the error is returned: ERROR: No container found for app_1.

[benyanke]

Upon further research, it looks like I can use the --index flag to manually specify.

I'd like to propose the default be the first image, instead of 1. This would be accomplished by sorting the list of images and grabbing the id of the first one.

[shin-]

@benyanke Thanks for the report! Do you have a repro case for the situation where the container with index 4 is created instead of number 1?

Also please note that this may all change soon as we work on #6140

[benyanke]

Yes - I do have a reliable test case, though will need to fetch it from work on Monday. I have some simple provisioning shell scripts I wrote, and the rolling upgrade script specifically triggers this issue.

I'll post the test case Monday - feel free to bug me here if it slips from my radar.

[benyanke]

Here you go. In my case, I'm using this in the context of a poor-man's rolling deploy without getting into swarm.

# running : app_1, app_2

docker stop "app_1"
docker rm "app_1"
docker-compose up -d --remove-orphans --no-recreate --scale app=2

# running : app_2, app_3

docker stop "app_2"
docker rm "app_2"
docker-compose up -d --remove-orphans --no-recreate --scale app=2

# running : app_3, app_4

This continues on infinitely, meaning that after a couple deploys, you end up in a situation like: app_37, app_38, and app_39 are the running containers.

[shin-]

Thanks!

Interesting - I'm surprised that the index 1 isn't always reallocated. I'll try and take a look at why it does that at some point.

[benyanke]

As was I! Figured it was probably not the desired behavior.

[leckylao]

Upon further research, it looks like I can use the --index flag to manually specify.

I'd like to propose the default be the first image, instead of 1. This would be accomplished by sorting the list of images and grabbing the id of the first one.

I agree with @benyanke that docker-compose exec should take the first container comes up instead of hardcoded 1. Tested still has the error "No container found" for Docker version 18.09.2.

Here's my workaround using docker exec @shin- :

CONTAINER_NAME="api_php_"
# lets find the first container
FIRST_NUM=`docker ps | awk '{print $NF}' | grep $CONTAINER_NAME | awk -F  "_" '{print $NF}' | sort | head -1`

# Composer install
docker exec $CONTAINER_NAME$FIRST_NUM composer install

[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. Thank you for your contributions.

[benyanke]

I haven't seen any work on this, so just commenting to un-stale it.

[stale]

This issue has been automatically marked as not stale anymore due to the recent activity.

[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. Thank you for your contributions.

[stale]

This issue has been automatically closed because it had not recent activity during the stale period.

[Alexander-Shukaev]

Still broken. Impossible to docker-compose exec into a container instance spawned by docker-compose run.