Multistage builds

[nicdoye]

I'd like to propose using multistage builds:

Pros:

1. Less tidying up of build requirements = simpler/less code
2. Slightly smaller images (0.3-0.6%)

Cons:

1. Removes some clever stuff like the scanelf in the alpine image (replacing with a hard-coded list).

[tianon]

1. regarding multistage builds in general: Add multi-stage build support official-images#3383

2. Slightly smaller images (0.3-0.6%)

   Do you happen to know what the difference is? that's definitely something I'm keen to fix (because there shouldn't be any unnecessary leftovers with the way we currently build)

3. Removes some clever stuff like the scanelf in the alpine image (replacing with a hard-coded list).

   This is a pretty big con for us -- we used to hand-maintain the runtime dependency list for almost all official images (there are probably still a couple where we haven't updated them yet even), and it turns out to be way too error-prone, which is why we implemented the scanelf solution in the first place, so that's going to be met with lots of resistance from our side.

[nicdoye]

1. Given that there are concerns over how multi-stage builds affect infrastructure, and there's no clear consensus amongst you, the official image builders (who are experts), I guess it's not worth pushing this change.

One further change would be to build the Debian binaries once per Java/Tomcat pair e.g. use COPY --from=tomcat:8.5.34 in the tomcat:8.5.34-slim Dockerfile. (At least one person appears to be against such build plans, though).

2. I'll need to grab so extra time to do the investigation (I can't see why there's a size dIfference, either).

3. I certainly agree that dynamically calculated beats hard-coding every time. (I started with the Debian image, and am far less experienced with alpine, so it was a late kludge).