feat: Unify Dockerfiles

[USA-RedDragon]

Context

• Unify the Docker image for both amd64 and arm64 architectures so that arm64 users no longer need to use a separate tag. With this solution, no users will have to specify -arm64 tags since Docker will resolve the appropriate architecture image automatically.

Choices

There's no real magic to this unification, it uses:

• the Docker-provided $TARGETARCH build argument to choose which base image to use
• opts to build gorcon for both arm64 and amd64
• swaps for the arm64v8/golang:1.22.0-bullseye image for official golang alpine image when building gorcon
• disables CGO for gorcon compilation so that the GCC compiler toolchain doesn't have to be installed and the binary is portable
• removes the deprecated go get command since go build will resolve any missing dependencies based on the go.sum file
• uses the $TARGETARCH build argument to choose which SHA1SUM to check against per-architecture
• Removes --progress=dot:giga from wget in the Go build of gorcon since the Alpine/Busybox variant of wget doesn't support this option, but utilizes -q to to comply with Hadolint DL3047
• I did not unify the unit-test.yml workflow as doing so would prevent running the arm64 and amd64 tests in parallel like they currently are.
• Ignores Hadolint DL3029 (Do not use --platform flag with FROM) as on amd64 this image must still resolve to avoid build errors but is not used in the final image, but it is used in the arm64 build.
• Ignores Hadolint DL3006 (Always tag the version of an image explicitly) as Hadolint is unaware that the final FROM image is based on one of the two FROM's above, both of which are tagged. Therefore this is a false positive.
• and basically cuts the CI workflow YAMLs in half

As @sonroyaalmerol pointed out in #319 (comment), this could possibly require building future dependencies from source if added, though the arm64 emulation in GitHub Actions is likely to always be the slowest point in the image build. Using buildx now means that some of the workflow can run in parallel vs the default builder which was sequential, meaning it's likely the time to build has been reduced by a bit.

Test instructions

1. Built for both architectures with docker buildx build --platform=linux/amd64,linux/arm64 . to verify build sanity
2. On my amd64 desktop, docker buildx build --platform=linux/amd64 . --load -t palworld:test
3. (still on amd64 desktop) docker run -p 8211:8211/udp --rm -it palworld:test and connected via Palworld to verify the server still runs
4. On a Macbook Air M2, I disabled Rosetta in the Docker for Mac settings
5. (still on Macbook) docker buildx build --platform=linux/arm64 . --load -t palworld:test
6. (still on Macbook) docker run -p 8211:8211/udp --rm -it palworld:test and connected via Palworld to verify the server still runs

Checklist before requesting a review

• I have performed a self-review of my code
• I've added documentation about this change to the README.
• I've not introduced breaking changes.

I have introduced breaking changes in that the -arm64 tags suffixes will no longer be required.

[USA-RedDragon]

Hadolint makes two good points that I don't want to ignore:

Dockerfile:18 DL3007 warning: Using latest is prone to errors if the image will ever update. Pin the version explicitly to a release tag

This is the sonroyaalmerol/steamcmd-arm64:latest base image. I personally solved for this by pinning the sha256 digest in my fork (here), but I also utilize Renovate to get PRs when this changes (see the dependency dashboard under dockerfile here: USA-RedDragon/palworld-server-docker#3)

Dockerfile:41 DL3002 warning: Last USER should not be root

Which is solid advice in general. I would consider creating and using appropriate users to be out of scope for this PR, but I'd be happy to make a separate PR for this if y'all want it!

[sonroyaalmerol]

One thing you could do is use sonroyaalmerol/steamcmd-arm64:root instead of the latest tag. This would also allow you to remove USER root from the other linting error. While this is definitely not a fix, at least you'll have the linting errors suppressed for now.

[USA-RedDragon]

Oh hey, that's you!

What's the difference between the root and latest tags? I noticed that the arm64 build used latest, so I was a bit leery of just swapping tags without understanding the difference, lest I unintentionally break something.

Though that would avoid the lint error, the "spirit" of the DL3007 lint rule would still be violated, as it's point is to avoid tags that aren't deterministic

[sonroyaalmerol]

The image is identical to cm2network/steamcmd (the base image used for amd64) but with the addition of Box64 and Box86 which adds compatibility for arm64. The root tag is literally just the latest tag but with root as its active user. The latest tag has steam as its active user as the steamcmd executable within the images are owned and can only be executed by steam.

The only reason the Dockerfile.arm64 used the latest tag was that I hadn't implemented the root tag yet when I PR-ed the arm64 support.

Well, I can definitely add some deterministic tags for version pinning in my image but I can't say the same for the original cm2network/steamcmd image.

[USA-RedDragon]

Thanks for clarifying!

[win5923]

Excellent！