Use multi-stage Dockerfiles for all images

[joelanford]

The SDK build process currently has a pretty convoluted process for building docker images that involves several make targets and hack scripts.

I propose that we reduce this complexity by consolidating all image build steps into multi-stage Dockerfiles. With this change we will:

1. Update Dockerfiles to perform go binary builds in a builder stage rather than copying in a pre-built binary.
2. Update the image-build make targets to remove the make dependencies that build go binaries in the local environment
3. Update the image-build make targets to call docker directly.
4. Remove the hack/image-build-* scripts that are obsolete due to 3).
5. Move all Dockerfiles into hack/image/<image-name>. They were previously split between hack/image/ and images/
6. Move loading of images into kind from the image build step to the e2e tests where the images are actually required to be loaded into kind. Image building shouldn't be concerned with e2e setup.

This will give the project several benefits:

1. Reproducible builds. All images will be built using identical environments, regardless if run in CI or by a developer locally.
2. Reduce complexity. The build steps are now more self-contained in the respective Dockerfiles.
3. Co-location in hack/image reduces the overhead of remembering where various files are for each image build.
4. Simplified support for multiple architectures. Now that the go build happens as part of the image build, it is now much simpler to ensure the binary target architecture matches the image architecture.

There are some things I would consider out-of-scope for this:

1. Large overhauls of the Makefile. For now, I think we can have the docker go build stage call make to build the same binaries we always have.
2. Changes to the travis configuration and the way images are pushed and deployed.

[camilamacedo86]

Note that the scorecard images are not == these ones. Could we change the scorecard images to follow any final result define here? WDYT about add it in the scope of this change?

[joelanford]

Yeah I'm including the scorecard images in the scope of this.

I'll have a PR up shortly.

[aemperador]

@joelanford did a PR get put up for this? I like this proposal and would like to see it come to life

[estroz]

@aemperador I don't think this is going to happen quite yet actually. During testing I saw a host of issues with multi-platform builds and generally slow builds, which we can't have in CI. I'll be looking into multi-stage builds after we revamp our release process (see #4034).

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[estroz]

/lifecycle frozen