[HN Gopher] Dive: A tool for exploring a Docker image, layer con...
___________________________________________________________________
Dive: A tool for exploring a Docker image, layer contents and more
Author : tomas789
Score : 312 points
Date : 2024-01-08 15:35 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| notatoad wrote:
| I found dive super useful for understanding how docker images
| work, and how to write efficient dockerfiles. Reading the docs is
| one thing, but making a change to the dockerfile and then seeing
| how it has affected the resulting layer structure is what really
| made me get it.
| greenie_beans wrote:
| this helped me debug a docker thing recently, very handy tool!
| animeshjain wrote:
| I used dive when I was trying to cut down on the size of the
| image. Diffing and seeing what files/directories go into each
| layer was very useful.
| runfaster2000 wrote:
| 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...
| geek_at wrote:
| 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...
| thunderbong wrote:
| That's an awesome article!
| WirelessGigabit wrote:
| 2019! Can you post an update?
| TechIsCool wrote:
| I love dive and its something that I use in my tool kit multiple
| times a month.
|
| I am curious if anyone knows how to get the contents of the file
| you have highlighted, a lot of the times I use dive to validate
| that a file exists in a layer and then I want to peak at it.
| Currently I normally revert to running the container and using
| cat or extracting the contents and then wandering into the
| folders.
| oooyay wrote:
| Dive is incredible, it saved my butt numerous times and taught me
| a lot about layers. It's so good that Docker Desktop emulated its
| functionality.
| diazc wrote:
| There's other great TUI terminal tools like dive here [0],
| lazydocker and dry come to mind.
|
| And some in the docker category as well:
|
| [0] https://terminaltrove.com/
| pricci wrote:
| Lazydocker has a similar, although simpler, funtionality.
|
| Edit: just checked and it allows to see the layers, but only
| shows the commands of each one
| a_t48 wrote:
| Dive is great. It struggles a bit with very very large images but
| beyond that no real complaints.
| tornadofart wrote:
| What exactly is meant by a layer?
| manojlds wrote:
| Docker images have layers. Sort of like snapshots.
| gilnaa wrote:
| Like an onion
| jake_morrison wrote:
| Like ogres
| iCarrot wrote:
| It is a Docker's term:
| https://docs.docker.com/build/guide/layers/
| tornadofart wrote:
| Thanks.
| miquong wrote:
| 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, so no docker needed (though it's still useful for
| creating the original image).
|
| https://github.com/google/go-containerregistry/blob/main/cmd...
|
| (updated: better link)
| pbowyer wrote:
| 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.
| natebc wrote:
| some startup performance savings in fewer http requests to
| fetch the image. small for sure but it's something?
| electroly wrote:
| 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.
| whirlwin wrote:
| Depends. If you would have to fetch a big layer often
| because of updates, that's not good. But if what is
| changing frequently is in a smaller layer, it will be more
| favorable
| mcpherrinm wrote:
| If files are overwritten or removed in a lower layer, there
| can be size savings from that.
| apt-get wrote:
| 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.
| miquong wrote:
| Eventually, once zstd support gets fully supported, and tiny
| gzip compression windows are not a limitation, then
| compressing a full layer would almost certainly have a better
| ratio over several smaller layers
|
| https://github.com/opencontainers/image-spec/issues/803
| fishpen0 wrote:
| Less performance and more security. Lots of ameteur images
| use a secret file or inadvertently store a secret to a layer
| without realizing an rm or other process in another layer
| doesn't actually eliminate it. If the final step of your
| build squashes the filesystem flat again you can remove a lot
| of potentially exposed metadata and secrets stored in
| intermediate layers
| vbezhenar wrote:
| What's the reason docker uses tar archives instead of ordinary
| directories for layer contents? This tool is great but it fixes
| something that should not exist in the first place.
| cachvico wrote:
| So images are serialized and able to be transmitted over a
| network.
|
| When an image is used (or "run"), it becomes a container, which
| makes it behave (to the client) like ordinary files &
| directories.
| maxloh wrote:
| 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?
| bombela wrote:
| 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.
| mardifoufs wrote:
| In hindsight, docker is probably much better off with Go,
| considering the use case. And I say that as someone who loves
| python and isn't too much into go!
| arccy wrote:
| when you run containers, you want to care as little about the
| underlying system as possible, and go makes it easy to be in
| its own little world.
|
| plus ecosystem effects of you can just use the packages of a
| different implementation for part of your code.
| fishpen0 wrote:
| Kubernetes specifically is in go because google invented go and
| also invented Kubernetes. Their internal teams have a lot of go
| engineers due to the whole inventing it thing
| dmlittle wrote:
| I believe the original Kubernetes proof of concept was
| written in Java
| sureglymop wrote:
| There's a tool from google called container-diff that's also
| really useful!
|
| I use it to see what random scripts one is encouraged to pipe
| into bash would do to a system.
___________________________________________________________________
(page generated 2024-01-08 23:00 UTC)