I would like to suggest that we add the following topics to our best practices/specs:
Be explicit about the fact that our base images should be optional; if the contributor is confident in using smaller base images, those should be preferred. We could mention some preferred light weight base images not maintained by us (ie. alpine, stock ubuntu, stock debian, etc). Currently our base image is large in size and attack surface. It is useful for novice contributors as it simplifies things, but everyone else pays the price with every pull and increased vulnerability.
Towards alleviating the two issues mentioned above, I suggest that we encourage more advanced contributors the usage of the builder pattern using multi-stage builds (https://docs.docker.com/develop/develop-images/multistage-build/#use-multi-stage-builds). Our part could be to provide pre-baked examples (ie. what to copy from the builder image to the execution image) for typical usage in R, python, java and other key areas.
Hi all,
I would like to suggest that we add the following topics to our best practices/specs:
Be explicit about the fact that our base images should be optional; if the contributor is confident in using smaller base images, those should be preferred. We could mention some preferred light weight base images not maintained by us (ie. alpine, stock ubuntu, stock debian, etc). Currently our base image is large in size and attack surface. It is useful for novice contributors as it simplifies things, but everyone else pays the price with every pull and increased vulnerability.
Towards alleviating the two issues mentioned above, I suggest that we encourage more advanced contributors the usage of the builder pattern using multi-stage builds (https://docs.docker.com/develop/develop-images/multistage-build/#use-multi-stage-builds). Our part could be to provide pre-baked examples (ie. what to copy from the builder image to the execution image) for typical usage in R, python, java and other key areas.