dive VS Moby

Dive is a great tool for debugging this. I like image reduction work just because it gives me a chance to play with Dive: https://github.com/wagoodman/dive

One easy low hanging fruit I see a LOT for ballooning image sizes is people including the kitchen sink SDK/CLI for their cloud provider (like AWS or GCP), when they really only need 1/100 of that. The full versions of both of these tools are several hundred mb each

Whether you work with Docker regularly or even create your own Docker containers, Dive is a great tool for streamlining image sizes, potentially helping you save storage costs and speed up deployments.

If you’re happy to pull the image, then sort of yes. You can either use docker inspect or a tool like dive (https://github.com/wagoodman/dive) to see how each layer was created. This will give you an idea of the Dockerfile.

Also, check out dive. It is an amazing tool for examining containers and find your size issues.

Did you try using dive ? It allows you to see each layer, so you can see the files that are added

I like this tool: https://github.com/wagoodman/dive

Also do I get shiny flair for https://github.com/wagoodman/dive/pull/443? Perhaps "Void shouter"?

This tool is really useful for showing the size of each layer, making it obvious which layer is blowing up your image size: https://github.com/wagoodman/dive

Having been featured in our February 2023, and January 2024 Release Radars, Moby is the original Linux Container runtime. This new version adds a bunch of changes to the Docker CLI and Moby itself with additional features. There's bug fixes and enhancements, with the main thing for users to be on the look out for containers that were created using Docker Engine 25.0.0. These containers might have duplicate MAC addresses, and thus must be recreated. The same goes for those containers created with Moby 25.0+ and with user defined MAC addresses. Read up on all these changes in the release notes.

Formlabs does this as well for their 3d printers, my earliest encounter of this was when Docker started getting popular: https://github.com/moby/moby/blob/master/pkg/namesgenerator/...

> Podman is designed to help with this by providing stronger default security settings compared to Docker. Features like rootless containers, user namespaces, and seccomp profiles, while available in Docker, aren't enabled by default and often require extra setup.

Seccomp has been enabled by default since 2015: https://github.com/moby/moby/pull/18780

It is true that Rootless isn't enabled by default but its "extra setup" can be done with a single command (`dockerd-rootless-setuptool.sh install`)

Perhaps.

Thing is, https://github.com/moby/moby/blob/670bc0a46c4ca03b75f1e72f73... is using https://github.com/mistifyio/go-zfs which features code like `out, err := zfsOutput("get", "-H", key, d.Name)` (Source: https://github.com/mistifyio/go-zfs/blob/master/zfs.go#L315) to get a single zfs property.

Somebody chose to use a library as abstraction that looks good but is implemented as a MVP (nothing wrong with that). "In the future, we hope to work directly with libzfs" should have raised an alarm somewhere, though.

AppArmor can restrict /proc and this is even used by docker: https://github.com/moby/moby/blob/master/contrib/apparmor/te...

Docker by default also applies a seccomp system call whitelist per [1] and restricts capabilities per [2], amongst numerous other default hardening practices that are applied. If a Docker container really had a need to call the "reboot" system call, this permission could be explicitly added.

More complex sandboxing techniques include opening handles for sockets, pipes, files, etc and then hardening seccomp filters on top to prevent any new handles being opened. In this way, some containers can read/write defined files on a volume without having any ability to otherwise interact with file systems such as opening new files (all file system related system calls could be disabled).

[1] https://github.com/moby/moby/blob/master/profiles/seccomp/de...

[2] https://docs.docker.com/engine/security/#linux-kernel-capabi...

Docker has to run as root, or use otherwise insecure methods ("rootless" is a sham, it requires suid binaries and CVE ridden unprivileged user namespaces).

I agree with ports, working[0][1][2] on it.

[0] https://github.com/moby/moby/discussions/45524

Useful with Docker, see https://github.com/moby/moby/pull/35697

I’ve integrated pigz into different build and CI pipelines a few times. Don’t expect wonders since some steps still need to run serially, but a few seconds here and there might still add up to a few minutes on a large build.

Link to the GitHub discussion: https://github.com/moby/moby/discussions/45524