Add Alpine tags to go-images

[dagood]

Right now we have Debian, Mariner, and Windows images. Upstream also has Alpine. However, apparently the linux-amd64 distribution of Go doesn't work there and it has to be recompiled in-place:

https://github.com/docker-library/golang/blob/7db3fb743f7d5d24d75493eacfc0595ce97979da/1.17/alpine3.15/Dockerfile#L54

(I believe the reason is that Alpine uses musl where other distros use glibc.)

It would be nice to not have to do fresh builds inside our Docker repository, so it would be nice to not do this, but if we do, we could add musl builds to our internal rolling build to avoid building Go in go-images.

[dagood]

Alpine is not supported by the Go maintainers: golang/go#19938

docker-library/golang#250 (comment):

I think our image description should probably link directly to golang/go#19938 -- to summarize that thread's current state, Alpine is not actually an officially supported target for the maintainers of Go (it's non-trivial enough to get the test suite passing on Alpine that we're coming up on two years since it was first attempted in earnest).

The reason this is relevant here is that if we add more Alpine-related variants, I'm afraid it will lend more to the appearance of Alpine being something not only supported, but potentially even recommended by the Go team, which is definitely not accurate (and if we had a clean way to de-emphasize our current Alpine variants until that issue is resolved and upstream officially supports it, I would definitely be considering it).

I think we should not add Alpine, but if we do, we should include "alpha" or a similar marker in the tag name. We have the opportunity to deemphasize these tags because we'd be producing tags that nobody has used before from MCR.

[danegsta]

It seems as though gccgo now properly supports musl/alpine: golang/go#51280. I've done some testing building our project against the Microsoft toolchain in an alpine container (with CGO_ENABLED=1 GOEXPERIMENT=systemcrypto) and I'm getting what seems to be a properly musl linked binary that runs properly.

Would it be possible to revisit adding an alpine image tag? Our product is client software, so the more systems we're able to produce a compliant build for, the better. We can probably get an alpine builder setup ourselves, but it's definitely nice to be able to take advantage of the existing build images.

[dagood]

It seems as though gccgo now properly supports musl/alpine: golang/go#51280.

I'm not sure this was ever a blocker for us. The description mentions bootstrapping, and we don't bootstrap Go in our Dockerfiles--we just plop down a prebuilt build.

Maybe what you have in mind is the update that makes standard Go toolset linux-amd64 binaries work on Alpine, and lets the golang image repo use upstream bits:

• Use upstream binaries for Alpine in 1.21+ docker-library/golang#474

That now applies to all in-support versions, so we wouldn't need to recompile Go while building the Alpine images. This does help a lot. Now Alpine would be built just like another Debian image. We would have upstream help maintaining Go's dependencies, like Debian (and unlike Azure Linux 3).

The fact that Go doesn't support Alpine (in a "tests aren't kept passing" sense) still isn't great. But: I already mentioned that we should/can call it something like "alpha" or "preview". The fact that the official golang images do include Alpine makes a strong case that we should do it too, for build system compatibility. I'll bring this up with the team.

[danegsta]

That makes sense that the Go toolset being built without CGO is the more relevant change here. In our case, I think we'd be absolutely fine with musl/Alpine being a less than fully supported scenario as it seems like users running Alpine as a development environment should be used to the idea that they're living a bit dangerously compared to someone running a more mainstream distro.

[dagood]

@danegsta, would you be open to submitting a PR? I think starting from these resources, it wouldn't be too difficult to add an preview/alpine to variants, force upstream tooling to use Dockerfile-linux.template in that case, and start us generating those images:

• https://github.com/microsoft/go-images/tree/microsoft/main/eng
• https://github.com/microsoft/go-images/blob/f6318d88f103bcc214cf928c36d157ed1156cf60/src/microsoft/versions.json#L54
• https://github.com/microsoft/go-images/blob/microsoft/main/patches/0004-Add-support-for-fips-linux-and-fips-variants-in-micr.patch

[danegsta]

@dagood yeah, I'd be happy to take a look at getting a PR going.

[gdams]

[triage] Right now we don't have any solid customer ask for Alpine tags, putting this on the icebox until that situation changes