Solve runner-helper container maintenence burden
Problem
For Linux, we currently support several different flavors of runner-helper: ubi-fips, ubuntu, alpine3.12, alpine3.13, alpine3.14, alpine3.15
We used to only have a single alpine image, but then introduced the ubuntu flavor to solve DNS problems users were facing with alpine.
We introduced ubi-fips for FIPS support.
For Windows, we have servercore images (with Windows Powershell and Powershell Core) and we've just introduced nanoserver support (but not yet easily selectable) with just Powershell Core. The difference between the two images is ~5GB vs. ~500MB, so we definately want to push more for using nanoserver.
Each flavor includes different versions of git and git-lfs. There's been a new major release of git-lfs for some time, but we're unable to upgrade across all flavors. I think it would be preferable to have consistent software versions.
Due to the amount of different flavors we have, there's a larger surface area for vulnerabilities, and although Renovate now helps us keep up to date with this, it leads to some hard decisions to be made where an upgrade is required due to security, but removing a flavor might break builds. This is the case with alpine 3.12, which is incompatible with older Docker versions, but is otherwise no longer supported. 3.13 is also about to reach EOL.
Proposal
For the majority of users, I don't think they care about what flavor of container is used. It makes sense to pick alpine for most cases, because it's the smaller image. Ubuntu only seems to be chosen when alpine has DNS issues.
Sometime ago I put together a debian-based minified helper container, that strips out everything we don't need. At the time, this was looked upon as though it would be difficult to maintain, however, I'm now wondering whether we've approached a point where it outweighs the cost of supporting both a ubuntu and alpine based images.
It benefits from being small and glibc based (so we don't encounter the musl DNS issues of alpine). If this became the only Linux helper container we supported along with ubi-fips, I think we'd have more control over the software versions we pin.
Because the container only contains exactly what is needed, it gives us more freedom in the future on how we put such a image together. Whether the software comes from a debian, ubuntu or arch repositories no longer matters, as the only thing we guarantee is the binaries needed to make the gitlab-runner helper work.
For users that currently use their own custom helper and base them off of our images, their migration path would be to instead base them off of ubuntu or alpine and install the few dependencies we expect (such as git, git-lfs and gitlab-runner).
Container sizes
| flavor | uncompressed | compressed |
|---|---|---|
| alpine | 58.9 MB | 22.12 MB |
| ubuntu | 209 MB | 73.97 MB |
| minified | 74.1 MB | 29.82 MB |