Compose: Change Docker image entrypoint to shell

[ebuildy]

Is your feature request related to a problem? Please describe.

Using the image docker/compose, the entrypoint is docker-compose bin, this makes the image difficult to use inside CI tools such as GitlabCI that require a shell.

Also, as an official Docker® image, this image should work like image docker (see https://github.com/docker-library/docker/blob/6e5ccf3c71e86b98bb75600b4309ccf1bc87775e/18.06/docker-entrypoint.sh), they can execute docker command or default shell command.

Describe the solution you'd like

The entrypoint of docker/compose image should have the same logic than docker image. Or you could create a new flavor docker/compose:sh that have default shell entrypoint.

Describe alternatives you've considered
I can override the entrypoint or create a new public Docker image, extending docker/compose with the same entrypoint logic than docker image.

Additional context

• gitlabCI Docker executor

[ebuildy]

I have done this image > https://github.com/ebuildy/compose/blob/docker-image-entrypoint-shell/docker-image/entrypoint.sh work pretty well!

[ijc]

use inside CI tools such as GitlabCI that require a shell.

Please can you expand upon this requirement, what exactly does it mean that GitlabCI requires a shell? Do you have a reference for that? (You can assume I know ~0 about gitlabci)

Why would you need to run the shell within the compose image, instead of using e.g. alpine or something which needs a shell?

Why can you not use --entrypoint to override in cases where the default is not what you want?

[ebuildy]

Ho you are right, I should explain first what gitlabCI does, according https://docs.gitlab.com/runner/executors/docker.html#the-entrypoint

The Docker executor doesn’t overwrite the ENTRYPOINT of a Docker image.

That means that if your image defines the ENTRYPOINT and doesn’t allow to run scripts with CMD, the image will not work with the Docker executor.

As such, to use the docker/compose image, we need to override the entrypoint. This is not a big problem, but as the official image docker have another logic of the entrypoint, smarter, I found too bad that docker/compose do not. This is not consistent, and Docker® should propose official images with same logic.

[ijc]

Please can you give an example of what you are trying to do and show why it doesn't work?

The example given at https://docs.gitlab.com/runner/executors/docker.html#the-entrypoint with the entrypoint.sh running docker build and passing Dummy Script as the CMD etc suggests to me that it is not required to be able to run literal shell commands and that it is acceptable that images do use entrypoint such that they interpret CMD as something other than a shell script, specifically arguments to the command in ENTRYPOINT.

So from my reading given ENTRYPOINT ["/code/.tox/py37/bin/docker-compose"] or similar things like:

 build:
   image: docker/compose:version
   script:
   - up
   - down
   - ps

should work just fine.

I'm afraid I don't put much stock in the argument that all images docker/* should behave the same way, so the fact of docker/dockers behaviour does not seem relevant how docker/compose behaves.

[ebuildy]

gitlabCI Docker executor must execute shell commands to setup the container, as such, we must override the default docker/compose entrypoint, this is not a big deal because it's possible.

I suggest a technique, that you use in official docker image (and plenty another images, I am pretty sure this is a good practice), this entrypoint logic make the image works exactly like before, and add the possibility to execute other commands such as sh -c without dirty hack.

I see plenty of Docker images implementing this entrypoint logic:

• https://github.com/docker-library/php/blob/master/docker-php-entrypoint
• https://github.com/docker-library/mysql/blob/696fc899126ae00771b5d87bdadae836e704ae7d/5.5/docker-entrypoint.sh#L6

As an entreprise, we love when things are "standard" and seamless :-)

[ijc]

I'd still love to see an example of what you are actually doing and how it is failing.

[AnthonyMastrean]

@ijc I show GitLab CI build scripts and runner output over on https://github.com/docker/compose/issues/6617#issuecomment-478028445.

What GitLab CI _does_ with the image that's defined is up to the GitLab CI Runner code (it's open source, I'm sure I could go find it, but I haven't yet). Looks like it tries to run _in_ the image (like run or exec sh). Since docker/compose defines an ENTRYPOINT, it gets messed up.

But, like I show in my last example, I don't think changing the ENTRYPOINT is enough? (or I'm doing it wrong or I'm not doing something else that'll hopefully be obvious to someone else)

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

[ijc]

Thanks @AnthonyMastrean the need to do a docker login was the bit of info I was missing to justify this requirement.

Looks like docker login really wants a working docker socket, I'm not sure if gitlab will provide you with one though, but I guess it must be possible since you were planning to use docker-compose which will want it. I guess you need some bind mounts or to set $DOCKER_HOST or something, but as I said at the top I no essentially 0 about gitlab..

[ebuildy]

Thanks you @AnthonyMastrean for the example, like I said, the image docker is perfect, and the way they wrote the entrypoint.sh will not change the behavior of docker/compose.

I can do a PR from my fork (https://github.com/ebuildy/compose/blob/docker-image-entrypoint-shell/docker-image/entrypoint.sh) to see changes, maybe this will help?

[AnthonyMastrean]

@ijc GitLab's CI defines "services" that provide network accessible services to the build, even the Docker socket. Step #3 here shows an example CI configuration and some relevant comments.

I think they use image: docker:stable to provide the Docker CLI and services: ["docker:dind"] to provide the API/engine.

[ulyssessouza]

Solved by https://github.com/docker/compose/pull/6641
That will be included in the next release.

[ulyssessouza]

@AnthonyMastrean @ebuildy A new RC of docker-compose is available with the solution to this issue. WDYT about having a try? It's the 1.25.0-rc1

[ebuildy]

Finally! Thanks you