Feature Request: Migrate Runtime Docker image to Alpine (or similar) from Ubuntu

[rraub]

Describe the Feature The Ubuntu image contains a lot of bloat and ends up being over 200MB, which increases costs and startup times. This bloat also comes with many security findings that we could omit with a smaller base image. I'm not saying Alpine is the perfect choice here, but we should be able to shrink the runtime image by over half by moving to a smaller base image.

I'm also totally open to other base images. Alpine isn't always the best choice, but it's a good common one to start with.

(also sorry about blowing away most of the template for this feature request; I only had a bug request template to choose from)

[fhunleth]

It used to be Debian. I know Alpine is smaller, but Debian might be a quick step in the right direction?

@joshk You switched from Debian to Ubuntu in 74e410e75. Do you remember why?

[joshk]

Hi Ryan

Nothing to apologize for, the issue bug template isn't suited for this sort of discussion.

I can't remember the reason I switched to Ubuntu, and I'm more than happy to look into other options.

Looking at Ubuntu vs Debian vs Alpine

Ubuntu Noble : 76MB Debian Bullseye : 77MB Alpine 3.20 : 44MB

If we want to have a smaller image we would need to look into Alpine.

Regarding your points around increased costs, startup times, and security issues, are there some numbers or references we can put behind those? For example, if we are to change the base image it would be useful to point to a tangible benefit the switch has provided.

[rraub]

I didn't realize the image sizes had grown to be so similar for the prebuilt erlang/elixir images that you referenced! 30mb difference isn't that huge. However, I'm more focused on the resulting runtime image which starts off as:

• https://hub.docker.com/layers/library/ubuntu/noble-20240605/images/sha256-3963c438d67a34318a3672faa6debd1dfff48e5d52de54305988b932c61514ca?context=explore (28mb)
• https://hub.docker.com/layers/library/alpine/3.20.2/images/sha256-eddacbc7e24bf8799a4ed3cdcfa50d4b88a323695ad80f317b6629883b2c2a78?context=explore (3mb)

Obviously the final built image contains quite a bit more (hard to compare apples to apples without a working alpine build). But the main goal is just reducing the image down to the essentials to reduce the security surface area and save on bandwidth while also enjoying faster startup times.

Cost impacts are going be quite low, for example AWS ECR Storage is $0.10 per GB / month, However if you don't have a optimal setup (using a public network) you could incur egress data transfer fees of $0.09 per GB (reference). This isn't as big of a factor, but sometimes these small costs add up when image caching isn't working in your favor and every container that scales up/down incurs this data transfer.

Additionally @fhunleth pointed me towards a few noticeable performance regressions with musl (alpine) vs libc (ubuntu) this would out weight any image size advantages.

[fhunleth]

Regarding the performance regressions, I believe the Alpine one should be completely fixed for NervesHub since we're using OTP 27. Sorry for not making that clear. I meant to point that out for other projects.

[joshk]

@rraub I totally agree with you that we should prioritize a reduced security surface.

Would you have some time or opportunity to try putting together a PR which uses Alpine instead?

[joshk]

@rraub would you like me to keep this issue open?

[rraub]

Unfortunately, I've not got the time to put together a PR, and as we've discussed, the potential isn't as clear or as large as we initially thought. So yes, we can close this issue for now and perhaps revisit it later if need be. Thank you @joshk !