I'd also fix the very first example. Stuff like LABEL, ENV, EXPOSE, CMD or ENTRYPOINT that rarely ever changes should be at the top, followed by ARG, prior to the first ADD/COPY/RUN statements. That way, you can re-use layer caching more efficiently.
In general, I think it's also a good general idea to keep yourself to one, maximum two RUN statements per image - I've seen it way too many times that some junior writes RUN apt update, RUN apt install -yf foo, RUN apt clean... which will leave all the intermediate crap from apt still part of the final image as the third command (the apt clean) will just set tombstone files [1][2] in the layer's overlay image.
(Side note, it boggles my mind why you can't tell Docker to flatten multiple subsequent "metadata only" layers like LABEL/ENV/CMD/ENTRYPOINT/ARG into one single one)
Additionally, I'd add a warning for multi-stage builds that ARG needs to be redeclared in following stages (a simple ARG xyz is sufficient, no need to repeat a default value), and that CMD/ENTRYPOINT set in the first stage for some reason tend to be overwritten in a stage that is FROM first-stage.
Sometimes, following a security vulnerability, users end up in intense discussions with the maintainers of Docker images.
It's challenging to navigate such situations effectively. The apparent simplicity of Docker images can be deceptive and pose risks. It's important to exercise caution to avoid potential problems.
See:
"Docker Hub image for version 12.4 contains a cryptominer [Confirmed!]"
In general, I think it's also a good general idea to keep yourself to one, maximum two RUN statements per image - I've seen it way too many times that some junior writes RUN apt update, RUN apt install -yf foo, RUN apt clean... which will leave all the intermediate crap from apt still part of the final image as the third command (the apt clean) will just set tombstone files [1][2] in the layer's overlay image.
(Side note, it boggles my mind why you can't tell Docker to flatten multiple subsequent "metadata only" layers like LABEL/ENV/CMD/ENTRYPOINT/ARG into one single one)
Additionally, I'd add a warning for multi-stage builds that ARG needs to be redeclared in following stages (a simple ARG xyz is sufficient, no need to repeat a default value), and that CMD/ENTRYPOINT set in the first stage for some reason tend to be overwritten in a stage that is FROM first-stage.
[1] https://github.com/aws-samples/linux-container-primitives-pr...
[2] https://jvns.ca/blog/2019/11/18/how-containers-work--overlay...