This feature request follows from #5972 for allowing one layer per-provisioner in docker builder, so that we have some opportunity to optimize the container image for sharing layers.
I spent some time hacking on trying to implement a suggestion from @mwhooker but hit a snag when I realized that just changing the HookedProvisioner
to something that commits after each provisioner wouldn't work and it would instead result in multiple images, produced after each provisioner ran and sharing no layers.
If I understand correctly, packer runs the base image, provisions it and then commits to an image. To achieve layering, I assume that we'd have to run a provisioner, commit the image and then teardown the entire thing and re-do the StepRun
and StepConnect
using the image committed in the previous step.
I just wanted to open this issue to discuss what you'd is the best way to achieve this, before I go around making too many intrusive changes?
ah, of course it makes sense that you'd just be committing the base image. Can I ask for more details of your use-case? Are you looking for an aid in debugging, or something else?
Well, the main reason for me is to enable sharing of layers, so with current packer strategy, you'd kind of have separate packer files for each layer, one deriving from another one. So, to enable sharing of layers, one-layer-per-provisioner seemed like a good strategy to me.
If you are asking what is the use-case of layering in general, then it enables more of sharing between different containers so it becomes easy to distribute images that share a lot of stuff. Layering also kind of helps in memory deduplication for stuff that is shared across two containers if they share the layers.
I haven't completely figured out the details of how it would work in packer, but caching at build time is also an important factor. Docker currently re-uses layers from either previous builds or other images that share the same content, make the subsequent builds much faster.
caching at build time is also an important factor. Docker currently re-uses layers from either previous builds or other images that share the same content, make the subsequent builds much faster.
For the record, this is a feature of docker build
which requires a Dockerfile
and just having layers won't give any caching of builds.
caching at build time is also an important factor. Docker currently re-uses layers from either previous builds or other images that share the same content, make the subsequent builds much faster.
For the record, this is a feature of
docker build
which requires aDockerfile
and just having layers won't give any caching of builds.
So how would one get this caching functionality ? I'm interested in speeding up our builds ?
Caching requires a Dockerfile.
Caching requires a Dockerfile.
That's a shame.
It would be interesting to see if we could at least figure out some sort of coordination between a builder and a provisioner.
For example ansible container maintains a build cache. so perhaps packer could detect this (So when building for AMI you use standard ansible but for docker packer tries to use ansible container) or perhaps the solution is just to have ansible-container as a new builder type ?
Most helpful comment
That's a shame.
It would be interesting to see if we could at least figure out some sort of coordination between a builder and a provisioner.
For example ansible container maintains a build cache. so perhaps packer could detect this (So when building for AMI you use standard ansible but for docker packer tries to use ansible container) or perhaps the solution is just to have ansible-container as a new builder type ?