chore: Linted Dockerfiles

[rotten]

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

This Pull Request updates the Dockerfile and Dockerfile.hdfs to pass "linting" via the hadolint Dockerfile linter.

The previous Dockerfiles had numerous issues with generally regarded "best practices" for Dockerfiles.

There is probably some optimization (of image size) and lockdown (for security issues) that can still be done, this sets the files on a solid footing for approaching that work.

Checklist

• [ x ] I have written necessary rustdoc comments -- (updated the docker folder readme)
• [ n/a ] I have added necessary unit tests and integration tests
• [ n/a ] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features Sqlsmith: Sql feature generation #7934).
• [ no ] My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
• [ n/a ] All checks passed in ./risedev check (or alias, ./risedev c)
• [ no ] My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

• [ no ] My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

• [ no ] My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note

• Dockerfile cleanup

[xxchan]

Thanks for your contribution! But there are some changes just merged. Can you resolve conflicts?

[rotten]

I've resolved the merge conflicts. I'm testing the builds on my laptop now and the pipeline is re-running.

[rotten]

It took a couple of tweaks, but builds with the new image work on my laptop now, and all of the pipeline tests here are passing. LMK if you have any questions!

[xxchan]

Others LGTM

[xxchan]

My idea is we just apt-update once in base, and avoid apt-update again in other stages, and finally delete it in the risingwave stage. How do you think?

[rotten]

I think it is fine as long as we don't mind having all of those other packages installed for all of the build targets.

[rotten]

Oh, and you have to run update each time because I'm cleaning out the results of the update at the end of each package install to avoid the linter complaining that we are leaving interim package build artifacts in the various build targets.

[xxchan]

Yes, I mean we don't clean here and maybe just ignore the lint.

[rotten]

I'd really prefer to leave each build stage "clean" if possible. Adding a bunch of linter exceptions is do-able if you really hate this. Since folks may build the container to any stage, it is better to keep each stage independent and as clean as possible if we can.

[xxchan]

IMO this doesn't have any real benefits, except reducing a lint, and it hurts caching at the same time. Caching apt-update can be quite helpful, e.g., #7734

[wcy-fdu]

Hi @rotten , thank you for your interest and contribution to RisingWave.
We leave Dockerfile.hdfs as a standalone docker file because we only use it to manually package RisingWave images that support HDFS, and will not use it for automated testing and CI, so that your changes should ignore this file.

[rotten]

You could also consider adding the hdfs customizations as a different build target in the same docker file since the two files are almost identical.