entrypoint defined in docker-compose.yml wipes out CMD defined in Dockerfile #3140

Closed
mericano1 opened this Issue Mar 15, 2016 · 28 comments

Comments

Projects
None yet
@mericano1

Hi, I am following the example on https://docs.docker.com/compose/startup-order/ to make sure the database is running before I start the application.
My Dockerfile contains the command

CMD ["/usr/bin/java", "-jar", "/usr/lib/gumtree/api-server/server/api-server.war"]

and in my docker-compose.yml I have

entrypoint: ["/usr/bin/wait-for-it.sh", "postgres001:5432", "-t", "120", "--"]

but after the postgres database starts the service container just exits straight away.

api_1        | wait-for-it.sh: postgres001:5432 is available after 42 seconds
postgres001_1 | LOG:  database system is ready to accept connections
api_api_1 exited with code 0

Looking inside the running container I can see the entrypoint does not have the command appended

docker exec b456a362e587 ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.2  0.0  21816  3200 ?        Ss   22:12   0:00 bash /usr/bin/wait-for-it.sh postgres001:5432 -t 120 --

If both command and entrypoint are in the same place (either in the Dockerfile or in the docker-compose.yml) the application starts up properly.

› docker exec 6cafdb9fdcf2 ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.2  0.0  21816  3208 ?        Ss   22:10   0:00 bash /usr/bin/wait-for-it.sh postgres001:5432 -t 120 -- java -jar /usr/lib/gumtree/api-server/server/api-server.war

Any idea is this is a bug or I am doing something wrong?

Thanks

@dnephin dnephin added the area/config label Mar 16, 2016

@dnephin

This comment has been minimized.

Show comment
Hide comment
@dnephin

dnephin Mar 16, 2016

Contributor

hmm, it does kind of feel like a bit in this case, but I think it's been this way for a while. The output of docker inspect <container name> would be good to verify exactly what the engine is receiving.

Contributor

dnephin commented Mar 16, 2016

hmm, it does kind of feel like a bit in this case, but I think it's been this way for a while. The output of docker inspect <container name> would be good to verify exactly what the engine is receiving.

@mericano1

This comment has been minimized.

Show comment
Hide comment
@mericano1

mericano1 Mar 16, 2016

Indeed @dnephin, the CMD gets wiped out

› docker inspect 172ab44fb462
...
"Cmd": null,
"Image": "api-server",
"Volumes": null,
"WorkingDir": "",
"Entrypoint": [
  "/usr/bin/wait-for-it.sh",
  "postgres001:5432",
  "-t",
  "120",
  "--"
]

Indeed @dnephin, the CMD gets wiped out

› docker inspect 172ab44fb462
...
"Cmd": null,
"Image": "api-server",
"Volumes": null,
"WorkingDir": "",
"Entrypoint": [
  "/usr/bin/wait-for-it.sh",
  "postgres001:5432",
  "-t",
  "120",
  "--"
]

@dnephin dnephin added the kind/bug label Mar 16, 2016

@igr

This comment has been minimized.

Show comment
Hide comment
@igr

igr Apr 6, 2016

Same here.

igr commented Apr 6, 2016

Same here.

@max-zelinski

This comment has been minimized.

Show comment
Hide comment
@max-zelinski

max-zelinski May 2, 2016

the same, had to put CMD in compose yaml for now...

the same, had to put CMD in compose yaml for now...

@NMichas

This comment has been minimized.

Show comment
Hide comment
@NMichas

NMichas May 7, 2016

Same here on Docker beta for OSX:

  • Docker version 1.11.1, build-5604cbe
  • docker-compose version 1.7.0, build-0d7bf73

Adding the CMD in docker-compose (or re-specifying it after -- on wait-for-it) works, but it is not such a good solution considering it tightly couples the docker-file with the underlying image.

NMichas commented May 7, 2016

Same here on Docker beta for OSX:

  • Docker version 1.11.1, build-5604cbe
  • docker-compose version 1.7.0, build-0d7bf73

Adding the CMD in docker-compose (or re-specifying it after -- on wait-for-it) works, but it is not such a good solution considering it tightly couples the docker-file with the underlying image.

@derekmahar

This comment has been minimized.

Show comment
Hide comment
@derekmahar

derekmahar May 12, 2016

I also encounter this issue as I describe in "How can I make my Docker compose “wait-for-it” script invoke the original container ENTRYPOINT or CMD command?" and demonstrate using example docker-compose-wait-for-file.

derek@derek-lubuntu:~/Projects/docker-compose-wait-for-file$ docker-compose up
Creating dockercomposewaitforfile_create_1
Creating dockercomposewaitforfile_wait_1
Attaching to dockercomposewaitforfile_create_1, dockercomposewaitforfile_wait_1
create_1  | Sleeping for 10 s.
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
create_1  | Created file /wait/done.
dockercomposewaitforfile_create_1 exited with code 0
wait_1    | Found file [/wait/done].
dockercomposewaitforfile_wait_1 exited with code 0

Adding a CMD to image ubuntu-wait-for-file doesn't help:

derek@derek-lubuntu:~/Projects/docker-compose-wait-for-file$ git diff
diff --git a/ubuntu-wait-for-file/Dockerfile b/ubuntu-wait-for-file/Dockerfile
index 20e92c0..ccbabb7 100644
--- a/ubuntu-wait-for-file/Dockerfile
+++ b/ubuntu-wait-for-file/Dockerfile
@@ -1,3 +1,4 @@
 FROM ubuntu
 ADD wait-for-file.sh /
 RUN chmod +x /wait-for-file.sh
+CMD ["echo", "'Can you see me?'"]
derek@derek-lubuntu:~/Projects/docker-compose-wait-for-file$ docker-compose build
Building create
Step 1 : FROM ubuntu
 ---> b549a9959a66
Step 2 : ADD create-file.sh /
 ---> Using cache
 ---> 67e5db59f8e2
Step 3 : RUN chmod +x /create-file.sh
 ---> Using cache
 ---> c7e361b4408e
Step 4 : ENTRYPOINT /create-file.sh
 ---> Using cache
 ---> 0360027060ca
Successfully built 0360027060ca
Building wait
Step 1 : FROM ubuntu
 ---> b549a9959a66
Step 2 : ADD wait-for-file.sh /
 ---> Using cache
 ---> db75cb689f0e
Step 3 : RUN chmod +x /wait-for-file.sh
 ---> Using cache
 ---> d9a991cdd174
Step 4 : CMD echo 'Can you see me?'
 ---> Using cache
 ---> 19f4ad2a167c
Successfully built 19f4ad2a167c
derek@derek-lubuntu:~/Projects/docker-compose-wait-for-file$ docker-compose up
Creating dockercomposewaitforfile_create_1
Creating dockercomposewaitforfile_wait_1
Attaching to dockercomposewaitforfile_create_1, dockercomposewaitforfile_wait_1
create_1  | Sleeping for 10 s.
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
create_1  | Created file /wait/done.
dockercomposewaitforfile_create_1 exited with code 0
wait_1    | Found file [/wait/done].
dockercomposewaitforfile_wait_1 exited with code 0

derekmahar commented May 12, 2016

I also encounter this issue as I describe in "How can I make my Docker compose “wait-for-it” script invoke the original container ENTRYPOINT or CMD command?" and demonstrate using example docker-compose-wait-for-file.

derek@derek-lubuntu:~/Projects/docker-compose-wait-for-file$ docker-compose up
Creating dockercomposewaitforfile_create_1
Creating dockercomposewaitforfile_wait_1
Attaching to dockercomposewaitforfile_create_1, dockercomposewaitforfile_wait_1
create_1  | Sleeping for 10 s.
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
create_1  | Created file /wait/done.
dockercomposewaitforfile_create_1 exited with code 0
wait_1    | Found file [/wait/done].
dockercomposewaitforfile_wait_1 exited with code 0

Adding a CMD to image ubuntu-wait-for-file doesn't help:

derek@derek-lubuntu:~/Projects/docker-compose-wait-for-file$ git diff
diff --git a/ubuntu-wait-for-file/Dockerfile b/ubuntu-wait-for-file/Dockerfile
index 20e92c0..ccbabb7 100644
--- a/ubuntu-wait-for-file/Dockerfile
+++ b/ubuntu-wait-for-file/Dockerfile
@@ -1,3 +1,4 @@
 FROM ubuntu
 ADD wait-for-file.sh /
 RUN chmod +x /wait-for-file.sh
+CMD ["echo", "'Can you see me?'"]
derek@derek-lubuntu:~/Projects/docker-compose-wait-for-file$ docker-compose build
Building create
Step 1 : FROM ubuntu
 ---> b549a9959a66
Step 2 : ADD create-file.sh /
 ---> Using cache
 ---> 67e5db59f8e2
Step 3 : RUN chmod +x /create-file.sh
 ---> Using cache
 ---> c7e361b4408e
Step 4 : ENTRYPOINT /create-file.sh
 ---> Using cache
 ---> 0360027060ca
Successfully built 0360027060ca
Building wait
Step 1 : FROM ubuntu
 ---> b549a9959a66
Step 2 : ADD wait-for-file.sh /
 ---> Using cache
 ---> db75cb689f0e
Step 3 : RUN chmod +x /wait-for-file.sh
 ---> Using cache
 ---> d9a991cdd174
Step 4 : CMD echo 'Can you see me?'
 ---> Using cache
 ---> 19f4ad2a167c
Successfully built 19f4ad2a167c
derek@derek-lubuntu:~/Projects/docker-compose-wait-for-file$ docker-compose up
Creating dockercomposewaitforfile_create_1
Creating dockercomposewaitforfile_wait_1
Attaching to dockercomposewaitforfile_create_1, dockercomposewaitforfile_wait_1
create_1  | Sleeping for 10 s.
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
wait_1    | Waiting for file [/wait/done].
create_1  | Created file /wait/done.
dockercomposewaitforfile_create_1 exited with code 0
wait_1    | Found file [/wait/done].
dockercomposewaitforfile_wait_1 exited with code 0
@Satchitananda

This comment has been minimized.

Show comment
Hide comment
@Satchitananda

Satchitananda May 24, 2016

Same, why docker guys not to fix it?

Same, why docker guys not to fix it?

@ransingh

This comment has been minimized.

Show comment
Hide comment
@ransingh

ransingh Jun 2, 2016

I am having the same issue.
entrypoint in docker-compose is wiping out CMD specified inside the dockerfile.

Here is the inspect output of the container

           "Cmd": null,
            "Image": "ransingh/siglee-api:61e2686",
            "Volumes": {
                "/home/siglee/siglee-api/log": {}
            },
            "WorkingDir": "/home/siglee/siglee-api",
            "Entrypoint": [
                "./wait_for_db",
                "db"
            ],

ransingh commented Jun 2, 2016

I am having the same issue.
entrypoint in docker-compose is wiping out CMD specified inside the dockerfile.

Here is the inspect output of the container

           "Cmd": null,
            "Image": "ransingh/siglee-api:61e2686",
            "Volumes": {
                "/home/siglee/siglee-api/log": {}
            },
            "WorkingDir": "/home/siglee/siglee-api",
            "Entrypoint": [
                "./wait_for_db",
                "db"
            ],
@gannicottb

This comment has been minimized.

Show comment
Hide comment
@gannicottb

gannicottb Jun 9, 2016

Same here. :(

CMD defined in the app Dockerfile like so:
CMD ["java", "-jar", "./target/app.jar"]

Entrypoint defined in docker-compose.yml like so:
entrypoint: ["/usr/scripts/wait-for-it.sh", "db:5432", "-- "]

Container inspect on the app:
"Entrypoint": [ "/usr/scripts/wait-for-it.sh", "cotillion_db:5432" ],

Would love to see this fixed so I don't have to copy the CMD from the container into compose (especially as a general practice for many such container + db setups).

Same here. :(

CMD defined in the app Dockerfile like so:
CMD ["java", "-jar", "./target/app.jar"]

Entrypoint defined in docker-compose.yml like so:
entrypoint: ["/usr/scripts/wait-for-it.sh", "db:5432", "-- "]

Container inspect on the app:
"Entrypoint": [ "/usr/scripts/wait-for-it.sh", "cotillion_db:5432" ],

Would love to see this fixed so I don't have to copy the CMD from the container into compose (especially as a general practice for many such container + db setups).

@numbnut

This comment has been minimized.

Show comment
Hide comment
@numbnut

numbnut Jul 21, 2016

Same for me on OSX:
docker: Docker version 1.12.0-rc4, build e4a0dbc, experimental
docker-compose: docker-compose version 1.8.0-rc2, build c72c966
It would be very nice to see this fixed.

numbnut commented Jul 21, 2016

Same for me on OSX:
docker: Docker version 1.12.0-rc4, build e4a0dbc, experimental
docker-compose: docker-compose version 1.8.0-rc2, build c72c966
It would be very nice to see this fixed.

@aanand

This comment has been minimized.

Show comment
Hide comment
@aanand

aanand Jul 21, 2016

Contributor

I'm not convinced this is a bug. It's consistent with docker run:

FROM alpine
CMD ["echo", "default command"]
$ docker build -t 3140 .

$ docker run --name no-entrypoint 3140
default command

$ docker inspect no-entrypoint
...
            "Cmd": [
                "echo",
                "default command"
            ],
...

$ docker run --name with-entrypoint --entrypoint echo 3140
<outputs a blank line>

$ docker inspect with-entrypoint
...
            "Cmd": null,
...

Apparently, this also happens when you set ENTRYPOINT in a Dockerfile which inherits a CMD from its parent image: see moby/moby#19611.

The discussion in that issue suggests two things:

  • This is by design.
  • It's not well-documented.

On top of that, our startup order document is wrong, as @mericano1 has discovered. So I think this is a docs issue.

Contributor

aanand commented Jul 21, 2016

I'm not convinced this is a bug. It's consistent with docker run:

FROM alpine
CMD ["echo", "default command"]
$ docker build -t 3140 .

$ docker run --name no-entrypoint 3140
default command

$ docker inspect no-entrypoint
...
            "Cmd": [
                "echo",
                "default command"
            ],
...

$ docker run --name with-entrypoint --entrypoint echo 3140
<outputs a blank line>

$ docker inspect with-entrypoint
...
            "Cmd": null,
...

Apparently, this also happens when you set ENTRYPOINT in a Dockerfile which inherits a CMD from its parent image: see moby/moby#19611.

The discussion in that issue suggests two things:

  • This is by design.
  • It's not well-documented.

On top of that, our startup order document is wrong, as @mericano1 has discovered. So I think this is a docs issue.

@derekmahar

This comment has been minimized.

Show comment
Hide comment
@derekmahar

derekmahar Jul 21, 2016

If it's by design, then I think it might be useful for a container to have a straightforward mechanism to invoke the ENTRYPOINT or CMD of its parent, similar to how many object-oriented programming languages enable a constructor to invoke a parent constructor creating a chain of constructor invocations to the root object.

If it's by design, then I think it might be useful for a container to have a straightforward mechanism to invoke the ENTRYPOINT or CMD of its parent, similar to how many object-oriented programming languages enable a constructor to invoke a parent constructor creating a chain of constructor invocations to the root object.

@numbnut

This comment has been minimized.

Show comment
Hide comment
@numbnut

numbnut Jul 21, 2016

Just an addition about the docker-compose documentation. The docker-compose.yml in the example implies that the command is not deleted, if the entrypoint is set in a compose file. Maybe the example is wrong, but that was the way I ran into this trap.

numbnut commented Jul 21, 2016

Just an addition about the docker-compose documentation. The docker-compose.yml in the example implies that the command is not deleted, if the entrypoint is set in a compose file. Maybe the example is wrong, but that was the way I ran into this trap.

@aanand

This comment has been minimized.

Show comment
Hide comment
@aanand

aanand Jul 21, 2016

Contributor

Yes, that's what I mean. We should fix that, add a note to the entrypoint documentation in the Compose file doc, and also ensure it's noted in the Engine docs for the ENTRYPOINT Dockerfile instruction and --entrypoint flag.

Contributor

aanand commented Jul 21, 2016

Yes, that's what I mean. We should fix that, add a note to the entrypoint documentation in the Compose file doc, and also ensure it's noted in the Engine docs for the ENTRYPOINT Dockerfile instruction and --entrypoint flag.

@aanand aanand added kind/docs and removed kind/bug labels Jul 21, 2016

@aanand

This comment has been minimized.

Show comment
Hide comment
@aanand

aanand Jul 21, 2016

Contributor

@derekmahar That's an interesting idea, but that discussion should probably happen in a new issue on docker/docker.

Contributor

aanand commented Jul 21, 2016

@derekmahar That's an interesting idea, but that discussion should probably happen in a new issue on docker/docker.

@MrShoco

This comment has been minimized.

Show comment
Hide comment
@MrShoco

MrShoco Jul 25, 2016

Same bug
Docker version 1.11.2, build b9f10c9
docker-compose version 1.8.0-rc2, build c72c966

MrShoco commented Jul 25, 2016

Same bug
Docker version 1.11.2, build b9f10c9
docker-compose version 1.8.0-rc2, build c72c966

@aanand

This comment has been minimized.

Show comment
Hide comment
@aanand

aanand Jul 25, 2016

Contributor

@MrShoco It's not a bug - please read the discussion.

Contributor

aanand commented Jul 25, 2016

@MrShoco It's not a bug - please read the discussion.

@aanand

This comment has been minimized.

Show comment
Hide comment
@aanand

aanand Jul 25, 2016

Contributor

Compose-side docs updated in #3764.

Contributor

aanand commented Jul 25, 2016

Compose-side docs updated in #3764.

@aanand

This comment has been minimized.

Show comment
Hide comment
@aanand

aanand Jul 25, 2016

Contributor

Engine-side docs updated in moby/moby#25012.

Contributor

aanand commented Jul 25, 2016

Engine-side docs updated in moby/moby#25012.

@MrShoco

This comment has been minimized.

Show comment
Hide comment
@MrShoco

MrShoco Jul 25, 2016

@aanand Thanks, a bug in the documentation misled me.

MrShoco commented Jul 25, 2016

@aanand Thanks, a bug in the documentation misled me.

@lefterisnik

This comment has been minimized.

Show comment
Hide comment
@lefterisnik

lefterisnik Oct 4, 2016

I face a similar problem when I have something like that on the docker-compose file:

entrypoint: /srv/wait-for-it.sh postgres:5432 --
command: bash -c "python manage.py migrate && uwsgi --ini /etc/web/uwsgi.ini --py-autoreload 1"

Also, when I try to run:

docker-compose run web bash -c "python manage.py migrate && uwsgi --ini /etc/web/uwsgi.ini --py-autoreload 1"

I get a python console only.

What am doing wrong?

I face a similar problem when I have something like that on the docker-compose file:

entrypoint: /srv/wait-for-it.sh postgres:5432 --
command: bash -c "python manage.py migrate && uwsgi --ini /etc/web/uwsgi.ini --py-autoreload 1"

Also, when I try to run:

docker-compose run web bash -c "python manage.py migrate && uwsgi --ini /etc/web/uwsgi.ini --py-autoreload 1"

I get a python console only.

What am doing wrong?

@adonay28

This comment has been minimized.

Show comment
Hide comment
@adonay28

adonay28 Nov 13, 2016

I'm facing this issue too:

i have the entrypoint in docker-compose.yml:
entrypoint: ./wait-for-it.sh -t 60 --strict mydb:3306

and the cmd in the Dockerfile:
CMD ["java","-jar","Testone_10006.jar"]

It waits until the db is available but then it doesn't do anything.

I'm facing this issue too:

i have the entrypoint in docker-compose.yml:
entrypoint: ./wait-for-it.sh -t 60 --strict mydb:3306

and the cmd in the Dockerfile:
CMD ["java","-jar","Testone_10006.jar"]

It waits until the db is available but then it doesn't do anything.

@dschroe

This comment has been minimized.

Show comment
Hide comment
@dschroe

dschroe Nov 13, 2016

same problem here

dschroe commented Nov 13, 2016

same problem here

@ngocdaothanh

This comment has been minimized.

Show comment
Hide comment
@ngocdaothanh

ngocdaothanh Nov 24, 2016

Hey, from the discussion above I understand that entrypoint in docker-compose.yml will override CMD in Dockerfile.

But is there a way to embed the original CMD in Dockerfile to entrypoint in docker-compose.yml?

Hey, from the discussion above I understand that entrypoint in docker-compose.yml will override CMD in Dockerfile.

But is there a way to embed the original CMD in Dockerfile to entrypoint in docker-compose.yml?

@imaia

This comment has been minimized.

Show comment
Hide comment
@imaia

imaia Dec 27, 2016

Why override CMD when someone is only overriding entrypoint? Maybe, this "feature" just complicates things. Maybe it is a bug.

imaia commented Dec 27, 2016

Why override CMD when someone is only overriding entrypoint? Maybe, this "feature" just complicates things. Maybe it is a bug.

@james-turner

This comment has been minimized.

Show comment
Hide comment
@james-turner

james-turner Jan 6, 2017

I'm also inclined to say I don't like this behaviour.

It would be preferable to either
a) maintain the original CMD in the parent image, such that when the child image specifies ENTYPOINT the 2 are concatenated (as expected) so you get ENTRYPOINT + CMD.
b) allow the child image to invoke the parent CMD such that you can manually compose ENTRYPOINT + CMD without having to copy/paste CMD from the parent image into your child dockerfile.

Otherwise; there is no way for child images to prefix a cmd in a parent image without having to duplicate the parent CMD invocation. The parent CMD might change in a subsequent version of the parent image, consequently causing the child image to break because the copied invocation is incorrect now.

I'm also inclined to say I don't like this behaviour.

It would be preferable to either
a) maintain the original CMD in the parent image, such that when the child image specifies ENTYPOINT the 2 are concatenated (as expected) so you get ENTRYPOINT + CMD.
b) allow the child image to invoke the parent CMD such that you can manually compose ENTRYPOINT + CMD without having to copy/paste CMD from the parent image into your child dockerfile.

Otherwise; there is no way for child images to prefix a cmd in a parent image without having to duplicate the parent CMD invocation. The parent CMD might change in a subsequent version of the parent image, consequently causing the child image to break because the copied invocation is incorrect now.

@craigotis

This comment has been minimized.

Show comment
Hide comment
@craigotis

craigotis Jan 7, 2017

This is really confusing to me. It seems crucial for a compose file to prepend to the command that's run by the underlying Dockerfile.

The compose file should not, IMO, be in charge of the commands run by the underlying Dockerfile unless that's the author's intention. This means that every time my Dockerfile commands change, for the multitude of application images I'm using, I have to know to also update my compose file - effectively duplicating config.

There needs to be a way to run a command (specified by the compose file) prior to the execution of the underlying CMD specified by the Dockerfile.

craigotis commented Jan 7, 2017

This is really confusing to me. It seems crucial for a compose file to prepend to the command that's run by the underlying Dockerfile.

The compose file should not, IMO, be in charge of the commands run by the underlying Dockerfile unless that's the author's intention. This means that every time my Dockerfile commands change, for the multitude of application images I'm using, I have to know to also update my compose file - effectively duplicating config.

There needs to be a way to run a command (specified by the compose file) prior to the execution of the underlying CMD specified by the Dockerfile.

@stas stas referenced this issue in occrp/id-backend Jul 23, 2017

Closed

Deployment #31

randomorder added a commit to randomorder/dati-ckan-docker that referenced this issue Nov 23, 2017

@shin-

This comment has been minimized.

Show comment
Hide comment
@shin-

shin- Mar 28, 2018

Member

Closing as this is not a Compose issue.

Member

shin- commented Mar 28, 2018

Closing as this is not a Compose issue.

@shin- shin- closed this Mar 28, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment