We are using packer to build a container with a parent that includes an entrypoint. In the packer build we "reset" entrypoint with ENTRYPOINT []
. Unfortunately the container is being committed with the entrypoint of the parent still in place.
Doing this in a Dockerfile gets rid of the entrypoint from parent:
FROM ep-issue:parent
ENTRYPOINT []
CMD []
While the same in packer version does not:
{
"builders": [
{
"type": "docker",
"image": "ep-issue:parent",
"pull": "false",
"commit": "true",
"changes": [
"ENTRYPOINT []",
"CMD []"
]
}
],
"post-processors": [
{
"type": "docker-tag",
"repository": "ep-issue",
"tag": "child2"
}
]
}
This is actually a issue with the Docker cli:
$ docker inspect postgres --format "{{ .Config.Entrypoint }}"
[docker-entrypoint.sh]
$ docker run -d --name testing postgres
4267a7f6f166e9009fdceb4ce232307482c87cf03ac14aa0f5e5aae38cfdddee
$ docker commit --change "ENTRYPOINT []" 4267a7f6f166
sha256:37903e8002b37273bb368eb00fe3333a0ce4fb31c34c81fb7ffac6e0f714dd11
$ docker inspect sha256:37903e8002b37273bb368eb00fe3333a0ce4fb31c34c81fb7ffac6e0f714dd11 --format "{{ .Config.Entrypoint }}"
[docker-entrypoint.sh]
I suggest that you open an issue with Moby and link it here.
The weird thing is if I pause packer (using debug mode) and run for example docker commit -c 'ENTRYPOINT ["tini", "--"]' -c 'CMD ["top"]'
( the same command packer runs) the resulting image will get the ENTRYPOINT/CMD fields updated only out of packer.
I hit this issue too, and found a solution. This
"builders": [
{
"type": "docker",
"image": "some_image",
"pull": true,
"commit": true,
"changes": [
"ENTRYPOINT [\"\"]",
"CMD [\"\"]"
]
}
],
effectively reset the entrypoint to []
for me.
As I have never used it before, I'm not sure if this is a recent change in the way to specify it or a bug in the documentation, but 'works for me'. Hope this helps.
One thing we could do is run "ENTRYPOINT []"
& "CMD []"
by default in a docker build ? 馃
Just ran into this. Using a base image with an ENTRYPOINT
= null
, packer in version 1.4.0 sets the entrypoint to /bin/sh
which breaks the image because the process to run is defined solely in CMD
. Is it required to change the entrypoint, if such a change was not specified in the changes
section of the packer config?
Also, docs say that ENTRYPOINT
in changes
can only be set to a string, which contradicts the workaround of @javierbertoli but I'm testing it right now, anyway.
Most helpful comment
I hit this issue too, and found a solution. This
effectively reset the entrypoint to
[]
for me.As I have never used it before, I'm not sure if this is a recent change in the way to specify it or a bug in the documentation, but 'works for me'. Hope this helps.