-
Notifications
You must be signed in to change notification settings - Fork 280
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
Comments
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. |
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? |
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. |
Will have a read of Nixs and get back to you |
Is this feature missing in the latest version?
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 ifdive
s 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 ofsystemd
).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
The text was updated successfully, but these errors were encountered: