1

I'm using docker 3.5. In this docker version I've got an issue with nodes dependencies at start time. I tried to resolve it as it was recommended using external sh script coping into docker file. It lead to more issues. For example `script is present but execution was not detected, executed, but program was not started. My docker-compose is up, but swarm mode is failed and so on...

I think I'm not clear with Docker life cycle. Lets imagine we have Dockerfile, docker-compose.yml and docker-swarm.yml. Each of them has an CMD and ENTRYPOINT instruction.

Starting docker-compose I can detect that my service waits for required one (because of waiting script). In case I'm using swarm mode i'm getting fails and my service can't start correctly.

Can you please help with considering lifecycle?

there are instructions:

  • CMD (docker file)
  • ENTRYPOINT (docker file)
  • entrypoint (docker-compose)
  • command (docker-compose)
  • entrypoint (docker-swarm)
  • command (docker-swarm)

Is it possible to have information about execution order of specified instructions for different scenarios?

Sergii
  • 7,044
  • 14
  • 58
  • 116

1 Answers1

3

There is no "execution order" between an entrypoint and a command, regardless of whether it is defined in your image (Dockerfile) or overridden at runtime (with a compose file or cli argument). There is only one command that docker will run to start your container, and when that command exits, the container exits.

If you only define an entrypoint or a command, docker will run that. If you define both an entrypoint and a command, docker will append the command as an argument to the entrypoint. So if you have:

ENTRYPOINT ["/bin/app", "arg1"]
CMD ["script.sh", "arg2"]

Docker will run your container with the command:

/bin/app arg1 script.sh arg2

meaning that script.sh is passed as a cli argument to /bin/app.

If you use the shell/string syntax instead of the exec/json syntax, this can get a bit strange since the shell syntax wraps your command with a /bin/sh -c "$string", and more importantly, the -c arg to /bin/sh only takes a single argument. That means:

ENTRYPOINT /bin/app arg1
CMD script.sh arg2

Will run:

/bin/sh -c "/bin/app arg1" /bin/sh -c "script.sh arg2"

which will ultimately run:

/bin/app arg1

The standard workflow to call a command after running your entrypoint script, is to include the following line a the end of the entrypoint.sh script:

exec "$@"

which will run any cli args to the entrypoint script, typically the value of CMD, as the new pid 1.

BMitch
  • 231,797
  • 42
  • 475
  • 450
  • I do not understand why "script.sh arg2" is discarded? – MikiBelavista May 27 '19 at 15:14
  • 1
    In the second example? `-c` only takes one argument. The others args are available as `$1` etc to the string being run, but that string did not include anything like `$1`. – BMitch May 27 '19 at 15:19