Tzahi12345 / YoutubeDL-Material

Self-hosted YouTube downloader built on Material Design
MIT License
2.56k stars 266 forks source link

[DISTRIBUTION/DOCKER] Move Docker Builds possibly to Ubuntu Minimal, away from Alpine #574

Closed GlassedSilver closed 2 years ago

GlassedSilver commented 2 years ago

Alpine is pain. More precisely: musl is pain.

Angry Pingu

dejan995 commented 2 years ago

@GlassedSilver This is a good idea. Moving to Ubuntu opens up so much other options as well. But the issue is that the image comes with a lot more overhead than Alpine, which means our docker image will be a bit larger. One way I can think of to counter this, is to rewrite the Dockerfile to use the minimal amounts of RUN commands. This is because every new RUN creates an extra layer in the final image and adding to the final size of it. I will fork the repo over the weekend and see what I can come up with.

I have one question though. I looked over the current Dockerfile and noticed that we are not getting ffmpeg directly from the Alpine repos. Is there a reason for this? I looked over the issues but I couldn't find why it is done like this.

GlassedSilver commented 2 years ago

@GlassedSilver This is a good idea. Moving to Ubuntu opens up so much other options as well.

Yeah, I think it's a smart move, also Ubuntu repos are pretty well maintained, so we're not switching to some cool kid distro that has lousy package maintenance.

But the issue is that the image comes with a lot more overhead than Alpine, which means our docker image will be a bit larger.

Let's be honest here, this is a media downloader, manager and player application. Users will host this in environments with ridiculous amounts of storage to begin with. Whilst I absolutely get your point, we're talking about 29MB here.

I am not concerned in the slightest.

One way I can think of to counter this, is to rewrite the Dockerfile to use the minimal amounts of RUN commands. This is because every new RUN creates an extra layer in the final image and adding to the final size of it.

Sounds like a good idea! 👍

I will fork the repo over the weekend and see what I can come up with.

Keep us updated! :)

Just putting it out here though, this is milestoned for 4.4, so no need to rush. However, if this can be brought into 4.3 I won't complain. The sooner we get away from alpine the better.

I've come to the conclusion that the ultra small footprint of alpine is bought at the expense of a thorough concept. So its size is basically a false advertisement, who knows what else is broken and only becomes apparent in troubleshooting months later.

I've been enjoying connectivity issues with alpine for such a long time now and never had I thought it failed at the most mundane jobs an OS could possibly be tasked with in the 21st century... To think how many hours I wasted investigating this...

I have one question though. I looked over the current Dockerfile and noticed that we are not getting ffmpeg directly from the Alpine repos. Is there a reason for this? I looked over the issues but I couldn't find why it is done like this.

Heh, bringing up yet another veteran war flashback scene here. :)

Alpine apparently gets its edge repo ffmpeg binary from the latest release, which would SEEM fair, if you don't consider that ffmpeg themselves, for a good reason, state on their website that it's probably a good idea (and 99% safe to do so) to run builds compiled from master instead of the latest releases.

Master branch has fixes that didn't make it into any release in ~2 months now. This repo isn't anyone to talk about releases and nightlies etc... But... this is a problem in the world of fast moving standards or content delivery, where constant adaption of these new realities is needed: #546

ffmpeg HAS to be received from master builds (or alternatively be built in our docker built VM straight from the repo's current commit, could be cool as well I guess? Nobody would be as bleeding edge as us 😎 (especially because I do intend to make weekly docker builds a thing, Linuxserver.io-style 🎉 #576))