5 ms·

From the Dockerfile: FROM scratch COPY --from=qemux/qemu-docker:4.14 / / Is this different than the following? FROM qemux/qemu-docker:4.14

skissane 3y ago
The first example collapses all the layers into one, which can result in a smaller image than the second If a layer creates a file and then a subsequent layer deletes it, the deleted file is still present in the image taking up space. If you squash the layers, the deleted file is gone “scratch” used to be an empty layer, but in newer versions is now just syntax to state that you want a layer without a parent layer
minasmorath 3y ago
It's different in that it's creating a new unique intermediate layer, but admittedly I'm struggling to see the value for most workflows. I assume there's an important detail I'm missing, as is the usual case with interesting Dockerfiles.
charles_f 3y ago
I think it's meant to remove a layer, as you're modifying the base layer rather than altering it through a second layer. Probably to limit size. (but that's a theory)
Guillaume86 3y ago
I suppose the goal is not inheriting environment variables, entrypoint definition etc, not sure
CSMastermind 3y ago
Not an expert but I believe the first approach doesn't inherit the metadata, configuration, or layering history from the original image, it just copies the files and folders.
andix 3y ago
It removes the references to the base image. I don’t see any benefits. Security scanners have a harder time to track issues, because they can’t just detect the image is depending on an insecure base image. It also strips the possibility to deduplicate some base layers, or a partial pull if you already have one of the base layers in the cache (Debian or Ubuntu are very common, you might have even the exact same version already in the layer cache).
- c-hendricks 3y ago
  Would any changes to the tag get pulled with `docker build --pull`?
kroese 3y ago
I did this to prevent inheriting environment variables from the base image. Unfortunately Docker does not provide a way to do this when using FROM.

skissane 3y ago

The first example collapses all the layers into one, which can result in a smaller image than the second If a layer creates a file and then a subsequent layer deletes it, the deleted file is still present in the image taking up space. If you squash the layers, the deleted file is gone “scratch” used to be an empty layer, but in newer versions is now just syntax to state that you want a layer without a parent layer

minasmorath 3y ago

It's different in that it's creating a new unique intermediate layer, but admittedly I'm struggling to see the value for most workflows. I assume there's an important detail I'm missing, as is the usual case with interesting Dockerfiles.

charles_f 3y ago

I think it's meant to remove a layer, as you're modifying the base layer rather than altering it through a second layer. Probably to limit size. (but that's a theory)

Guillaume86 3y ago

I suppose the goal is not inheriting environment variables, entrypoint definition etc, not sure

CSMastermind 3y ago

Not an expert but I believe the first approach doesn't inherit the metadata, configuration, or layering history from the original image, it just copies the files and folders.

andix 3y ago

It removes the references to the base image. I don’t see any benefits. Security scanners have a harder time to track issues, because they can’t just detect the image is depending on an insecure base image. It also strips the possibility to deduplicate some base layers, or a partial pull if you already have one of the base layers in the cache (Debian or Ubuntu are very common, you might have even the exact same version already in the layer cache).

c-hendricks 3y ago
Would any changes to the tag get pulled with `docker build --pull`?

kroese 3y ago

I did this to prevent inheriting environment variables from the base image. Unfortunately Docker does not provide a way to do this when using FROM.