docker squash: Consolidate image layers#13929
Conversation
|
Thanks @jlhawn! before we proceed, I'm interested to hear if @crosbymichael agrees with this implementation, based on #332 (comment)
ping @crosbymichael interested in your opinion, to prevent giving people "false hope" |
|
@thaJeztah I'm happy to wait to see what the rest of the team thinks, but I'll go ahead and implement it anyway for the following reasons:
|
👍 don't let me stop you! |
44b9636 to
75aec15
Compare
docker squash
docker squashdocker squash: Consolidate image layers
|
I've added integration tests and docs, so this is no longer a work-in-progress. @vincentwoo @tianon @cpuguy83 @SvenDowideit @thaJeztah @yosifkit @rhatdan please take a look and/or try it out and let me know what you think. |
api/client/squash.go
Outdated
There was a problem hiding this comment.
why have a deprecated option on a new cmd?
There was a problem hiding this comment.
oh, is that what the #notrunc means? I actually just copied this section from the implementation of the docker history command. 😞
...
Just got back from reading the comments/docs on pkg/mflag. It all makes sense now 😵
|
Oops - sorry -jumped the gun on the design review. Wanna squash (LOL) your commits? :-) |
|
@jlhawn thanks for going the distance on this one. I'm glad I pinged you. As an end user who would start using this immediately, I'd also want to know:
|
Yeah, I understand that can be pretty common. I should have a little extra time to add this.
whiteouts - now there's an implementation detail that shouldn't be exposed! The efficiency of squashing layers depends solely upon how many files/directories are in the filesystem. It uses the same method of generating a layer diff as all storage drivers do (aside from AUFS) with their parent layer: Mount both the image rootfs and its ancestor and perform a filepath walk of both, detecting all additions, changes, and deletions. The more stuff that there is in either filesystem then the longer time squashing will take. It's really no different than
Yes, the resulting image will have the same runtime config as the original image. |
|
Ah, what I meant by "efficiently" was just that "removed nodes do not end up in the squashed final image", and less "does the squash go fast". I take it from your answer that they do not, which is dope! |
|
Oh, sorry. Yeah, they will not end up in the resulting image. Keep in mind, though, that squashing does require additional disk space (on the machine that builds and squashes the layers) as it effectively copies everything that was in the final image. So you will need to delete the unused original layers to reclaim that disk space. |
|
Sounds great. There are quite a few things that I think will make this CLI tool better, but they're all pointless unless this gets merged. +1 to getting this in! |
|
I also want to get this in, We have a home grown version of this running for our internal builds because of the amount of layers required to build some JBOSS applications. Getting a standard way is a big plus. |
graph.Squash consolidates all layers in between the given image and an ancestor image into a single layer and returns the newly created image. A nil ancestor argument indicates that the layer should be squashed all the way to a single new base image. tagStore.Squash first performs a lookup of a given image name or ID and the ancestor name or ID before calling graph.Squash. This allows you to use image tags rather than IDs to squash image layers. Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
A new API endpoint in needed to remotely request that a new image be created by consolidating the layers of one image or the layers between an image and an ancestor image. Image IDs or names/tags are accepted. Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
This new CLI command allows users to merge the layers of an image into a new image, either all images or up to an ancestor layer. Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
Tests absolute and relativ squashing and well as squash conditions which should result in non-ops returning the same image. Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
Updates API v20 markdown as well as adds manpage markdown for `docker squash` and adds `squash` to the cli reference markdown. Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
Done 😃 |
|
@jlhawn dockercon's over what's it gonna take to get this bad boy merged |
|
@jlhawn can you give us an update on the status of this PR? Is it still awaiting review? |
|
@jlhawn I think this will have to be reevaluated/rethought once the client-side builder is in place. WDYT? Would you mind closing it? |
Sorry, closing this. |
|
Does that mean you're nixing stuff like |
This patch adds a new CLI command:
Example use cases:
Consolidating all layer of an image to a new single-layered image.
Let's inspect the history of the
busyboximage.It has 3 layers total, but we can now
squashit and tag it as something else.Now we have these 2 images.
But
better_busyboxonly has a single layer in its history.Merging layers of a newly built image into a single layer relative to the base image.
Let's build an image using this Dockerfile:
And inspect the history of this new image:
See that it has 6 layers. That's 3 more than were already in the base image. We can squash these 3 into an image with one additional layer relative to the base image, and re-tag this new image.
Now
test_buildonly has a single new layer on top of the original 3 layers frombusybox: