Other than being super useful, Dive has an underrated feature: its author is a great developer and very fun to work with.
Dive: A tool for exploring a Docker image, layer contents and more
41–50 of 62 posts
Re: Dive: A tool for exploring a Docker image, layer contents and more
#42A 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 would argue system tools and utilities, CLIs and networking software are where Go shines the most.
Rust is probably the only good modern alternative that is mature.
Re: Dive: A tool for exploring a Docker image, layer contents and more
#43Dive has saved my ass so many times it's not funny when trying to pull apart what various common docker containers do when I'm extending them.
A+ software.
Re: Dive: A tool for exploring a Docker image, layer contents and more
#44For 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 you've got a 50 layer image then each time you open a file, I believe the kernel has to look for that file in all 50 layers before it can fail with ENOENT.
Re: Dive: A tool for exploring a Docker image, layer contents and more
#45A 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?
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
I think k8s came from
Borg though which is pre-Go
Re: Dive: A tool for exploring a Docker image, layer contents and more
#46Dive is a gem. It's helped me find a lot of cruft ...
- unneeded build dependencies. Used a scratch image and/or removed build deps in the same step - node_modules for dev-deps . Used prod - Embeded Chromium builds (with puppetteer). Removed chromium and remoted an external build
Docker desktop now has this feature built in, but I've been using dive for years to find wasted space & potential security issues.
Re: Dive: A tool for exploring a Docker image, layer contents and more
#47For 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,…
This is a great recommendation. It is worth noting that unlike Docker, crane is root- and daemonless which makes it work great in Nix (it's called 'crane' in the Nix repository). This allows for Nix to be used to manage dependencies for both building (e.g. Go) as well as packaging and deploying (e.g. gnu tar, crane).
Re: Dive: A tool for exploring a Docker image, layer contents and more
#48Earlier 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.
If you've got a 50 layer image then each time you open a file, I believe the kernel has to look for that file in all 50 layers before it can fail with ENOENT.
That seems ripe for optimization, if true, especially since those layers are all immutable.
Re: Dive: A tool for exploring a Docker image, layer contents and more
#49Earlier quoted context omitted.
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
I think k8s came from Borg though which is pre-Go
K8s was a generational iteration of Borg, but it was a full re-write with an emphasis on making it more universally usable and pluggable.
> We've incorporated the best ideas from Borg in Kubernetes, and have tried to address some pain points that users identified with Borg over the years.
Borg was written in C++, but only contained container scheduling, resource allocation and some service discovery. Many other features of what is now Kubernetes were built later and essentially "shimmed" onto Borg.
Kubernetes was a re-write of Borg to rebuild many of its original features from the ground up using the lessons they had learned since originally building Borg. By this time, Go had been developed and was being actively used for many of these shims and supporting services surrounding Borg. Since the same team(s) were rebuilding Borg that had developed and maintained these other services, and because many of these shims and supporting services (which are already in Go) were being incorporated into Kubernetes, they decided to build the new version (which became Kubernetes) in Go.
Sources:
- https://kubernetes.io/blog/2015/04/borg-predecessor-to-kuber...
- https://storage.googleapis.com/gweb-research2023-media/pubto...
Re: Dive: A tool for exploring a Docker image, layer contents and more
#50There'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.
This is less related to general container utilities but I’m an avid user of GoogleContainerTools/container-structure-test. It’s a handy way to run integration tests on container apps or images.
These Google open source projects seem to be in need of some TLC as a lot of the original maintainers have moved on, which is a shame. I try to throw a PR their way and close out the odd issue when I can. The testing tool in particular is invaluable to keep my sanity with a large amount of base images I have to maintain internally.