Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

馃敡 Docker image seems excessively large (2.4GB) #1058

Open
2 tasks done
TheRealGramdalf opened this issue Feb 22, 2024 · 4 comments
Open
2 tasks done

馃敡 Docker image seems excessively large (2.4GB) #1058

TheRealGramdalf opened this issue Feb 22, 2024 · 4 comments
Labels
enhancement New feature request/PR

Comments

@TheRealGramdalf
Copy link

Is this feature missing in the latest version?

  • I'm using the latest release

Is your feature request related to a problem? Please describe.

The docker image is quite large, ~700MB compressed - and a whopping 2.4GB uncompressed!. This means slow downloads, higher disk usage, etc etc.

Describe the solution you'd like?

After running dive on the image (automaticrippingmachine/automatic-ripping-machine), there appear to be quite a few layers to the image - which, according to my own experience and this stackoverflow question, results in an unnecessarily large image. I believe it should be possible to remove quite a bit of this - at least ~400MB if dives built-in wasted-space-o-meter is to be believed.

The simplest option would be to follow the best practices in the dockerfile, and make each layer clean up after itself (as described in the thread linked above).

Describe alternatives you've considered?

Switching to a leaner base image like Alpine would likely further decrease space used, though I suspect that would come with it's own set of issues (due to using rcinit instead of systemd).

Perhaps the most drastic (but potentially most versatile) option would be to switch to NixOS - it is possible to build docker images from a NixOS configuration (see Arion) which handles version locking, dependency heck, and the majority of necessary system changes without the need for hacky scripts through the relatively simple Nix language. If this sounds interesting enough, I might be able to help packaging ARM for NixOS, since I already use it to manage both my personal computer and some LXC containers running on my server.

Anything else?

Links:

Code of Conduct

  • I agree to follow this project's Code of Conduct
@TheRealGramdalf TheRealGramdalf added the enhancement New feature request/PR label Feb 22, 2024
@TheRealGramdalf TheRealGramdalf changed the title 馃敡 Docker image is excessively large (2.4GB) 馃敡 Docker image seems excessively large (2.4GB) Feb 22, 2024
@microtechno9000
Copy link
Collaborator

The image is quite large and takes a while to download, agree to that. It has become so large to include the handbrake, mkv and other transcoding packages in the arm dependencies image.

I havent heard of dive, but if there is a way we can make the image smaller and keep the same functionality you are welcome to try and raise a PR against the respective image.

As for switching from the current base image, we are only a small developer team so the level of effort involved to move from the current architecture to something new would be too high.

If you can find a way to simplify the install or docker size, your welcome to have a crack and raise a PR.

@TheRealGramdalf
Copy link
Author

The simple option should be relatively simple, just a little time consuming. Regarding switching bases to NixOS, what would your feelings on that be? It should in theory actually simplify quite a bit, since NixOS deals with all the "hacky" details like adding custom udev scripts, installing extra packages, etc etc. In any case, if I were to get a functional version going, would the team be up for switching to that? Or would you prefer that it be someone involved more closely so that they can continue with maintenance if need be?

@TheRealGramdalf
Copy link
Author

Essentially what nix would do is take https://github.com/automatic-ripping-machine/arm-dependencies to the next level - NixOS was created for exactly this purpose - managing dependencies and system settings with the Nix language rather than fifty different config formats across a bunch of different locations on the filesystem. I think using NixOS would be a great use case, but if only I were to ever use it, It's probably not worth going through the hassle.

@microtechno9000
Copy link
Collaborator

Will have a read of Nixs and get back to you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature request/PR
Projects
None yet
Development

No branches or pull requests

2 participants