Docker-compose issue - Change from 10/30 to 10/31

Deploying Applications
#1

Last night, my automated build ran properly and created all of its containers correctly:

Creating docker_redis_1 …
Creating docker_cowbull_svc_1 …
Creating docker_cowbull_webapp_1 …

And my tests were able to run successfully. Today (10/31) and the container names have been appended with a random identifier, making it impossible to connect to them:

Creating docker_redis_1_6c62b2eb2cd9 …
Creating docker_cowbull_svc_1_994bd24bd543 …
Creating docker_cowbull_webapp_1_2b7fe6543442 …

Is this a bug or a change in behaviour

David

#2

Are you using a machine executor or a Docker executor? For either one, which image are you using?

(If you wish, you can install Docker Compose yourself, right down to a specific version).

#3

I’m using the Docker executor. It’s worked for months but the behaviour just changed overnight - literally ran my last build about 8pm Eastern and then tonight it failed because of the container names; here’s the snipped of code

      - setup_remote_docker

      - run:
          name: Docker login
          command: |
            docker login --username=$doclog --password=$docpass

      - run:
          name: Docker up
          environment:
            COWBULL_ENVIRONMENT: "CircleCI"
          command: |
            set -o pipefail
            export BUILD_NUMBER=$MAJOR_VERSION"."$MINOR_VERSION"."$CIRCLE_BUILD_NUM
            export doclog=${doclog}
            echo "Testing ${BUILD_NUMBER}"
            docker-compose -f vendor/docker/docker-compose-cicd.yml up -d
#4

:slight_smile:

#5

Hi, I’m using

jobs:
  build:
    docker:
      - image: circleci/python:2.7
#6

OK. Have a look to see whether your version of Docker or Docker Compose changed. If you re-run the one that used to work, does that still work? I wonder if an upstream change has broken things for you.

That could come from a CircleCI change in their convenience image, but equally it could come upstream from them, and there is not much they can do about that. I have installed a specific version of DC using Pip, on a bare-bones Docker image, and it has been rock-solid for ~12 months (daily builds).

#7

I was finally able to fix this by doing a workaround - basically looking at the docker ps output to grab the name of the container:

docker-compose -f vendor/docker/docker-compose-cicd.yml up -d
webapp=$(docker ps -a --format '{{.Names}}' | grep "docker_cowbull_webapp_1_")
echo "export webapp=$webapp" >> $BASH_ENV

The tests have been running regularly (at least once a week) for 3 months and I can’t figure out why this broke; however, the cludge code above at least gets the tests running again. The cause appears to be the difference in naming standards (appending a random identifier) which started last week.

PS. the last line echo "export webapp=$webapp" >> $BASH_ENV ensures that the env. var. with the container name is passed to the next step.

Hopefully this might help if anyone else runs in to this.

#8

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.