chore: Dockerfile consistency

[polarathene]

Describe your changes

• Further consistency between openSUSE + Alpine Dockerfile variants, with revised inline docs.
• Dockerfile adopts HereDoc syntax for better formatting in RUN.
• Associated Dockerfile.md docs revised with:
  • Minor revision + some typo fixes.
  • Organization of links to bottom of the document as refs.
  • Two new links referencing an issue comment for context on base image performance and package selection.

---

NOTE: I could revert the Alpine change for addgroup / adduser, but figured maintenance is easier if you don't have to think about useradd vs adduser differences.

• An added bonus is it should be quite apparent that the only real differences between the two is very minimal now that it'd be easy to have the main Dockerfile with only two lines for Alpine support (and selected via a --build-arg or --target stage), making Dockerfile.alpine redundant. Separate Dockerfile is absolutely fine though 👍

Adopting the HereDoc feature was originally proposed in Feb 2023 but rejected due to being considered too new. It's been over 2 years since then and anyone building images today should really be using Docker v23 (Feb 2023) at a minimum.

HereDoc removes the && \ noise with RUN, the value is treated as a multi-line string that /bin/sh -c receives (symlinked to bash by openSUSE Leap, or to ash by Alpine_), thus it's more like a typical inline shell script.

What is your pull request about?

• Improvement
• Typo fix
• Documentation update
• Update of other files

[polarathene]

After this PR, I think the two variants should be fairly straight-forward maintenance wise, thanks for your patience 😅

With the two links added to Dockerfile.md, the intent is to further clarify differences and context should any other contributor engage with these two Dockerfile in future.

The last item to resolve #2422 is updating the workflow to default to openSUSE Leap to be consistent with DockerHub and prefer the glibc base image. But until migrating away from openSUSE Leap, you'd have the reduced architecture support.

Hence it'd be better to have DockerHub + GHCR publishing both image variants, but I'm not yet familiar with the GHA caching approach so I will need to defer that task until I have time to grok that better. The original PR that contributed the workflow lacks context and I prefer to understand the decision well before changing it.

[drwetter]

Thanks for your work @polarathene !

The last item to resolve #2422 is updating the workflow to default to openSUSE Leap to be consistent with DockerHub and prefer the glibc base image. But until migrating away from openSUSE Leap, you'd have the reduced architecture support.

I would just leave it like it is, for now. Don´t even know how about the usage of those containers for sure. The only thing I was able to retrieve was this: https://github.com/testssl/testssl.sh/packages

[polarathene]

I would just leave it like it is, for now.

Perhaps for 3.3 then. Alpine variants are typically tagged with a prefix -alpine when an image has more than one base image offered.