Packer: Packer docker builder does not reset ENTRYPOINT properly

Created on 10 Apr 2019  路  6Comments  路  Source: hashicorp/packer

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"
    }
  ]
}
buildedocker upstream-bug

Most helpful comment

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.

All 6 comments

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.

Was this page helpful?
0 / 5 - 0 ratings