Live data from Hacker News

Dive: A tool for exploring a Docker image, layer contents and more

github.com

21–30 of 62 posts

Re: Dive: A tool for exploring a Docker image, layer contents and more

#21
A dumb question: Why are most of the container/infrastructure tools written in GoLang?

Examples that come to my mind include Docker, Podman, nerdctl, Terraform and Kubernetes.

Is there any obvious advantage that GoLang offers, making it so popular for building these tools?

Re: Dive: A tool for exploring a Docker image, layer contents and more

#22
post #15

For image and layer manipulation, crane is awesome - as is the underlying go-containerregistry library. It lets you add new layers, or edit any metadata (env vars, labels, entrypoint, etc) in existing images. You can also "flatten" an image with multiple layers into a single layer. Additionally you can "rebase" an image (re-apply your changes onto a new/updated base image). It does all this directly in the registry,…

Is there any performance benefit to having fewer layers? My understanding is that there's no gain by merging layers as the size of the image remains constant.

Re: Dive: A tool for exploring a Docker image, layer contents and more

#23
post #22
post #15

For image and layer manipulation, crane is awesome - as is the underlying go-containerregistry library. It lets you add new layers, or edit any metadata (env vars, labels, entrypoint, etc) in existing images. You can also "flatten" an image with multiple layers into a single layer. Additionally you can "rebase" an image (re-apply your changes onto a new/updated base image). It does all this directly in the registry,…

Is there any performance benefit to having fewer layers? My understanding is that there's no gain by merging layers as the size of the image remains constant.

some startup performance savings in fewer http requests to fetch the image. small for sure but it's something?

Re: Dive: A tool for exploring a Docker image, layer contents and more

#24
post #23
post #22

Earlier quoted context omitted.

Is there any performance benefit to having fewer layers? My understanding is that there's no gain by merging layers as the size of the image remains constant.

some startup performance savings in fewer http requests to fetch the image. small for sure but it's something?

In practice I've found the performance savings often goes the other way--for large (multi-GB) images it's faster to split it up into more layers that it can download in parallel from the registry. It won't parallelize the download of a single layer and in EC2+ECR you won't get particularly good throughput with a single layer.

Re: Dive: A tool for exploring a Docker image, layer contents and more

#25
post #14

Dive is great. Tools like that are critical for both learning and developing confidence on what you are precisely building/shipping. Dredge is another tool to look at. I use it for diffing layers. https://github.com/mthalman/dredge/blob/main/docs/commands/i...

It really does sound amazing. Would have needed this when you guys (hn) and reddit helped me figure out what a rogue Raspberry Pi was doing in our server closet https://blog.haschek.at/2019/the-curious-case-of-the-RasPi-i...

That's an awesome article!

Re: Dive: A tool for exploring a Docker image, layer contents and more

#26
post #14

Dive is great. Tools like that are critical for both learning and developing confidence on what you are precisely building/shipping. Dredge is another tool to look at. I use it for diffing layers. https://github.com/mthalman/dredge/blob/main/docs/commands/i...

It really does sound amazing. Would have needed this when you guys (hn) and reddit helped me figure out what a rogue Raspberry Pi was doing in our server closet https://blog.haschek.at/2019/the-curious-case-of-the-RasPi-i...

2019! Can you post an update?

Re: Dive: A tool for exploring a Docker image, layer contents and more

#27
post #22
post #15

For image and layer manipulation, crane is awesome - as is the underlying go-containerregistry library. It lets you add new layers, or edit any metadata (env vars, labels, entrypoint, etc) in existing images. You can also "flatten" an image with multiple layers into a single layer. Additionally you can "rebase" an image (re-apply your changes onto a new/updated base image). It does all this directly in the registry,…

Is there any performance benefit to having fewer layers? My understanding is that there's no gain by merging layers as the size of the image remains constant.

If files are overwritten or removed in a lower layer, there can be size savings from that.

Re: Dive: A tool for exploring a Docker image, layer contents and more

#29
post #22
post #15

For image and layer manipulation, crane is awesome - as is the underlying go-containerregistry library. It lets you add new layers, or edit any metadata (env vars, labels, entrypoint, etc) in existing images. You can also "flatten" an image with multiple layers into a single layer. Additionally you can "rebase" an image (re-apply your changes onto a new/updated base image). It does all this directly in the registry,…

Is there any performance benefit to having fewer layers? My understanding is that there's no gain by merging layers as the size of the image remains constant.

There are some useful cases — for example, if you're taking a rather bloated image as a base and trimming it down with `rm` commands, those will be saved as differential layers, which will not reduce the size of the final image in the slightest. Only merging will actually "register" these deletions.

Re: Dive: A tool for exploring a Docker image, layer contents and more

#30
post #21

A dumb question: Why are most of the container/infrastructure tools written in GoLang? Examples that come to my mind include Docker, Podman, nerdctl, Terraform and Kubernetes. Is there any obvious advantage that GoLang offers, making it so popular for building these tools?

I think I can answer for Docker. The first prototype was written in Python, the company was a Python shop. The main reason for a rewrite in Go was to ride the popularity of Go that was growing at the time (2012).

source: I was there.

Post reply on HN