compose: Pip install of docker-compose 1.24 fails

Description of the issue

Running pip install docker-compose==1.23.2 succeeds but pip install docker-compose fails.

Context information (for bug reports)

Error output is: /usr/bin/python2 -m pip install --ignore-installed --no-user --prefix /tmp/pip-build-env-Jeq6Db --no-warn-script-location --no-binary :none: --only-binary :none: -i https://pypi.org/simple -- setuptools wheel "cffi>=1.1; python_implementation != 'PyPy'"" failed with error code 1 in None

Steps to reproduce the issue

Against docker:stable image run apk add --quiet --no-cache bash py-pip && pip install --quiet docker-compose==1.24.0

Observed result

/usr/bin/python2 -m pip install --ignore-installed --no-user --prefix /tmp/pip-build-env-Jeq6Db --no-warn-script-location --no-binary :none: --only-binary :none: -i https://pypi.org/simple -- setuptools wheel "cffi>=1.1; python_implementation != 'PyPy'"" failed with error code 1 in None`

Expected result

Successful install.

Additional information

Running Docker-in-Docker for Gitlab test runner. Probably not relevant?

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 72
  • Comments: 41

Commits related to this issue

Most upvoted comments

This is related to the new SSH support which added some new dependencies. On our test systems these dependencies are already available once pip is installed.

Unfortunately on alpine this is not the case and you need to install them manually:

$ apk add py-pip python-dev libffi-dev openssl-dev gcc libc-dev make

We will work on updating the documentation ASAP. Apologies for the inconvenience.

As an alternative, docker-compose is also released as Docker image, so a quick fix would be replacing docker:stable by docker/compose:1.24.0 as base image.

@carlmjohnson are you running inside of an Alpine container? I am and I’m seeing the same issue. The top half of my .gitlab-ci.yml file looked like this:

image: docker:stable

services:
  - docker:stable-dind

before_script:
  - apk add --no-cache --quiet py-pip
  - pip install --quiet docker-compose
  - docker login --username "$CI_REGISTRY_USER" --password "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"

But, I had to change it to pin the Compose version.

image: docker:stable

services:
  - docker:stable-dind

before_script:
  - apk add --no-cache --quiet py-pip
  - pip install --quiet docker-compose~=1.23.0
  - docker login --username "$CI_REGISTRY_USER" --password "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"

Ran into this as well in gitlab-ci. I added a few more dependencies to fix my issue with the 1.24 release. Although, May be better to pin to the previous as others mentioned.

image: docker:stable

before_script:
  - apk update
  - apk upgrade
  - apk add python python-dev py-pip build-base libffi-dev openssl-dev libgcc
  - pip install docker-compose

Notably, i had to add libffi-dev openssl-dev libgcc to my previous dependencies.

@ulyssessouza thanks for the explanation.

It was extremely convenient and fast to install just the docker-compose package. I’m loathe to add six indirect development dependencies to my application’s build. The effect on build time is noticeable. Of course, this isn’t a good benchmark, but I hope it reflects the general trend.

$ docker run --rm -it docker:stable time sh -c 'apk add --no-cache --quiet py-pip && pip install --quiet docker-compose~=1.23.0'
real    0m 7.09s
user    0m 3.67s
sys     0m 0.76s
$ docker run --rm -it docker:stable time sh -c 'apk add --no-cache --quiet py-pip python-dev libffi-dev openssl-dev gcc libc-dev make && pip install --quiet docker-compose'
real    1m 38.93s
user    1m 7.77s
sys     0m 7.44s

I’d love to try the new docker/compose image. I remember following that conversation, but didn’t realize that it was released… however, the image page doesn’t describe the available tags and the latest build is failing!

Some issues with this solution:

  • I don’t see a latest or stable tag, which are useful and seem standard for other docker images. So, I’ll have to pay closer attention to releases and update my build script more often. I don’t even see “optimistic” version tags, like docker/compose:1.23, which would keep me on a stable major/minor version and still deliver patches.
  • The docker/compose image sets docker-compose as an ENTRYPOINT and is, therefore, unfit for use as a GitLab CI base image. (see also https://github.com/docker/compose/issues/6614)
image: docker/compose:1.23.2

services:
  - docker:stable-dind

before_script:
  - docker login --username "$CI_REGISTRY_USER" --password "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
Running with gitlab-runner 11.0.0 (5396d320)
  on nextgen-aws-east1d-autoscale.amazonaws.com ec265edf
Using Docker executor with image docker/compose:1.23.2 ...
Starting service docker:stable-dind ...
Pulling docker image docker:stable-dind ...
Using docker image sha256:85e924caedbd3e5245ad95cc7471168e923391b22dcb559decebe4a378a06939 for docker:stable-dind ...
Waiting for services to be up and running...
Pulling docker image docker/compose:1.23.2 ...
Using docker image sha256:65f21bf3ffc929410490621982ff648d02f268fefb063f55dc3129eb70a9cdf3 for docker/compose:1.23.2 ...
Running on runner-ec265edf-project-10964250-concurrent-0 via runner-ec265edf-gitlab-docker-machine-1553872466-7e37c8d8...
Cloning repository...
Cloning into '/builds/vaeit/nextgen/itpie-api'...
Checking out d073b9e2 as infra-457-compose...
Skipping Git submodules setup
No such command: sh
...
ERROR: Job failed: exit code 1
  • I don’t think the docker/compose image is compatible with docker:stable-dind, the way we’re supposed to use it with GitLab’s CI, even if I override the ENTRYPOINT problem.
image: 
  name: docker/compose:1.23.2
  entrypoint: [""]

services:
  - docker:stable-dind

before_script:
  - docker login --username "$CI_REGISTRY_USER" --password "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
Running with gitlab-runner 11.0.0 (5396d320)
  on nextgen-aws-east1d-autoscale.amazonaws.com ec265edf
Using Docker executor with image docker/compose:1.23.2 ...
Starting service docker:stable-dind ...
Pulling docker image docker:stable-dind ...
Using docker image sha256:85e924caedbd3e5245ad95cc7471168e923391b22dcb559decebe4a378a06939 for docker:stable-dind ...
Waiting for services to be up and running...
Pulling docker image docker/compose:1.23.2 ...
Using docker image sha256:65f21bf3ffc929410490621982ff648d02f268fefb063f55dc3129eb70a9cdf3 for docker/compose:1.23.2 ...
Running on runner-ec265edf-project-10964250-concurrent-0 via runner-ec265edf-gitlab-docker-machine-1553872466-7e37c8d8...
Cloning repository...
Cloning into '/builds/vaeit/nextgen/itpie-api'...
Checking out 1efaf55f as infra-457-compose...
Skipping Git submodules setup
$ docker login --username "$CI_REGISTRY_USER" --password "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
Warning: failed to get default registry endpoint from daemon (Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?). Using system default: https://index.docker.io/v1/
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
ERROR: Job failed: exit code 1

Please document breaking changes like these. My builds started failing out of nowhere. It’s not documented in the official installation instructions and there’s not even a changelog. This blows.

docker-compose fails on clean alpine as 1.24 introduces dependency on paramiko. Pip install paramiko fails on clean alpine as it depends on gcc, make and some other packages. This can be resolved by installing paramiko using apk apk add --no-cache py-pip py-paramiko pip install docker-compose

Same issue using gitlab dind with image docker:stable.

before_script:
  - apk add --no-cache py-pip
  - pip install docker-compose

suggested solution with docker-compose fix version resolves it.

before_script:
  - apk add --no-cache py-pip
  - pip install docker-compose~=1.23.0

There is now a docker/compose image that will work with gitlab (https://github.com/docker/compose/issues/6614). So the solution is to drop the script for building docker compose with pip and just use a different base image in your .gitlab-ci.yml.

image: docker/compose:1.25.0-rc1

Had the same issue.

I stubbornly tried out @AnthonyMastrean suggestion:

image:
  name: docker/compose:X.X.X
  entrypoint: [""]

While Anthony got a docker daemon connection error for me it worked!

I tried it with versions 1.23.2 and 1.24.

Not exactly sure why, it’s a long time ago I setup this CI file. I did notice I’m using docker run --network host when running the integration tests. Possibly that has something to do with it.

I’ll share the interesting bits of my ci file:

image:
  name: docker/compose:1.24.0
  entrypoint: [""]

stages:
  - build
  - deploy

services:
  - docker:dind

variables:
  # lots of vars

# Run lint, test, and release in one job, this makes the build +/- 2,5 minutes
# faster because images do not have to be repulled between stages.
build:
  stage: build
  script:
    - docker pull $CONTAINER_IMAGE:builder || true
    - docker build --target builder --cache-from $CONTAINER_IMAGE:builder --tag $CONTAINER_IMAGE:builder .
    - docker push $CONTAINER_IMAGE:builder
    - docker run $CONTAINER_IMAGE:builder make test
    - docker run $CONTAINER_IMAGE:builder make lint
#    - apk add --no-cache py-pip .       THIS IS NO LONGER NECESSARY
#    - pip install docker-compose .       THIS IS NO LONGER NECESSARY
    - docker-compose up -d redis db
    - docker run --network host $CONTAINER_IMAGE:builder make integration
    - docker build --target release --cache-from $CONTAINER_IMAGE:builder --tag $CONTAINER_IMAGE:$CI_COMMIT_SHORT_SHA --tag $CONTAINER_IMAGE:latest .
    - docker push $CONTAINER_IMAGE:$CI_COMMIT_SHORT_SHA
    - docker push $CONTAINER_IMAGE:latest

The application itself is not run inside the docker-compose file. I wanted to run the linters and unit tests first and fail early. Only afterwards install docker compose using pip and run the integration tests. That is why I’m probably using docker run --network host to run the integration tests; the docker commands all relate to the image being built, while the docker-compose setup only provides the dependant services.

The only thing I don’t like about this is the docker/compose image does not have latest or stable tags. Knowing myself I’ll probably use 1.24 for the next couple of years until it breaks 😂

Seems I could refactor the compose file and and run everything using docker-compose given it’s built-in the image already, but I fear I’ll hit Anthony’s issue and waste a couple of hours. Rather enjoy the 🌞 for now. Hope this helps someone!

(p.s. just realized I have to update this in over 20 repos… fml)

I’m using docker in docker with gitlab-ci and using their docker-compose docker build as suggested here https://github.com/docker/compose/issues/6617#issuecomment-477974325 and you’re going to need those deps moving forward > 1.24.0

I was wondering why my whole build setup was failing for a few days. Installing 1.23.0 seems to be a nice temporary workaround, but it would be better to have a real solution. I’m not so willing to install gcc&co inside my build machines.

Same issue here. However I moved to using the “official” installation method. Even in the alpine image. I’m installing glibc like: https://github.com/docker/compose/blob/master/Dockerfile.run Just don’t do the “apk del curl” in the end. And then using:

curl -L https://github.com/docker/compose/releases/download/1.24.0/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose
chmod +x /usr/local/bin/docker-compose

To download docker-compose.