Closed ghost closed 8 months ago
@nywilken
any update on this?
it's a very fundamental feature that this plugin lacks
Any update on this issue? I am facing the same problem. The official doc doesn't explain the current behavior.
Our development team is facing the same problem. Hope a fix can be made :)
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"
]
}
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.
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.
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.
Any effective workarounds?
yeah, just use another container builder
@dimisjim suggestions?
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.
I mean that was my "workaround" too -- setting ENTRYPOINT everywhere back to some 'default'. This is not a solution.
@josh-m-sharpe you're right, it's not a solution. It's a workaround lol
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
"ENTRYPOINT nginx -g 'daemon off;'"
the image works as expectedPacker version
1.6.5
Simplified Packer Buildfile
this is necessary
this should be enough:
considering this exists already:
Operating system and Environment details
Ubuntu 20.10, Docker version 19.03.13, build 4484c46
related: #13