Packer overrides CMD and ENTRYPOINT already set in FROM image

[ghost]

This issue was originally opened by @dimisjim as hashicorp/packer#10311. It was migrated here as a result of the Packer plugin split. The original body of the issue is below.

---

Overview of the Issue

A dev familiar with Dockerfile expects Packer to keep the ENTRYPOINT and/or CMD set in the image where the build is based from. Why would Packer reset these, if they are not overridden explicitly in the commit argument of the builder?

Reproduction Steps

1. Create a simple nginx image based on the official one.
2. if no CMD is defined in the commit argument of the builder, it defaults to /bin/sh
3. only when "ENTRYPOINT nginx -g 'daemon off;'" the image works as expected

Packer version

1.6.5

Simplified Packer Buildfile

this is necessary

source "docker" "nginx" {
  image   = "nginx"
  commit  = true
  changes = [
    "EXPOSE 80",
    "ENTRYPOINT nginx -g 'daemon off;'"
  ]
}

this should be enough:

source "docker" "nginx" {
  image   = "nginx"
  commit  = true
  changes = [
    "EXPOSE 80",
  ]
}

considering this exists already:

Operating system and Environment details

Ubuntu 20.10, Docker version 19.03.13, build 4484c46

related: #13

[dimisjim]

@nywilken

any update on this?

it's a very fundamental feature that this plugin lacks

[northben]

Any update on this issue? I am facing the same problem. The official doc doesn't explain the current behavior.

[CeliaS1]

Our development team is facing the same problem. Hope a fix can be made :)

[CeliaS1]

To be more precise : Here is the definition of the 'Cmd' and 'Entrypoint' fields on a base image pulled from DockerHub :

# docker inspect debian:bullseye-slim -f '{{ .ContainerConfig.Cmd }}
[/bin/sh -c #(nop)  CMD ["bash"]]
# docker inspect debian:bullseye-slim -f '{{ .ContainerConfig.Entrypoint }}
[]

When we build an image derived from this Debian base image with Packer, even if we only add a LABEL, the 'Cmd' and 'Entrypoint' fields are modified, which is not the case when using a Dockerfile :

# docker inspect <our_image> -f '{{ .ContainerConfig.Cmd }}
[]
# docker inspect <our_image> -f '{{ .ContainerConfig.Entrypoint }}
[/bin/sh]

Note : Extract from the Packer's template, which is very simple :

source "docker" "debian-bullseye" {
  image  = 'debian:bullseye-slim'
  commit = true
  changes = [
    "LABEL env=devel"
  ]
}

[CeliaS1]

It seems that this problem can't be solved easily. The behavior comes from the way the Docker builder works : it is derived from the docker commit command, and Packer run the container with run_command which define the entrypoint to /bin/sh :

["-d", "-i", "-t", "--entrypoint=/bin/sh", "--", "{{.Image}}"]

That's the reason why the CMD and ENTRYPOINT are changed. The Docker builder is a beautiful plugin but, unfortunately, not very usable.

[CeliaS1]

Hi, Maybe we can imagine a simple solution like this : when a Docker image is build and do not define CMD nor ENTRYPOINT values, the Docker Plugin get this parameters from the base image (defined in the source.docker block) and automatically add them into the "changes" array, so that they would be taken into account by the docker commit --change command.

What do you think about it ? Thanks.

[josh-m-sharpe]

I've run into this issue and it's super unexpected. packer should definitely not clobber CMD/ENTRYPOINT if it's not defined in the packer script.

[huyz]

Any effective workarounds?

[dimisjim]

yeah, just use another container builder

[huyz]

@dimisjim suggestions?

[dimisjim]

https://github.com/docker/buildx

[huyz]

I think I figured out a workaround.

Instead of leaving ENTRYPOINT blank, I set ENTRYPOINT to a command that is effectively equivalent to nothing but that Packer won't clobber:

    "ENTRYPOINT [\"/bin/sh\", \"-c\", \"exec \\\"$0\\\" \\\"$@\\\"\"]",

Ugly but seems to work.

[josh-m-sharpe]

I mean that was my "workaround" too -- setting ENTRYPOINT everywhere back to some 'default'. This is not a solution.

[huyz]

@josh-m-sharpe you're right, it's not a solution. It's a workaround lol