Split dockerfile to build container and runtime container

[defect]

So, after rebuilding the container for the Nth time i started toying with the idea of breaking out the building parts of the process into it's own container since we don't really need activator/sbt/etc. to run collins once the zip has been produced.

This creates a Dockerfile.build which sets up the basic build toolchain and should in my mind make it easier and quicker to get started with building collins. For instance, after creating the build container we can build the zip by running

~/W/t/collins (split_dockerfiles) >time docker run -v $(pwd)/target:/build/target b97efa2bb6dc ./scripts/package.sh
[..]
docker run b97efa2bb6dc ./scripts/package.sh  0.03s user 0.03s system 0% cpu 1:49.67 total

which should be a lot quicker than building from scratch since we already have the dependencies and toolchain. If we're making a lot of changes we can have a container re-compiling on changes by running

~/W/t/collins (split_dockerfiles) >docker run -it -v $(pwd)/app:/build/app 5f787656d457 activator
[info] Loading project definition from /build/project
[info] Set current project to collins (in build file:/build/)
[collins] $ ~ compile
[info] Compiling 331 Scala sources and 9 Java sources to /build/target/scala-2.11/classes...
[info] 'compiler-interface' not yet compiled for Scala 2.11.7. Compiling...
[info]   Compilation completed in 13.051 s
[success] Total time: 74 s, completed Jun 27, 2017 9:46:21 PM
1. Waiting for source changes... (press enter to interrupt)
[info] Compiling 1 Scala source to /build/target/scala-2.11/classes...
[success] Total time: 5 s, completed Jun 27, 2017 9:46:43 PM
2. Waiting for source changes... (press enter to interrupt)

The final "runtime" container becomes a lot simpler too.

I haven't really tried all different use-cases here, but I thought I'd ask for some feedback. Does this make sense at all?

@tumblr/collins @byxorna @michaeljs1990 Thoughts?

[michaeljs1990]

Smaller image size is always a big plus. I know our version of this image has gotten pretty large I think almost up to 1G now. It's a little strange to me to have the container depend on the output of another container but I think as long as it has a script or makefile for generating the image it should be fine.

[byxorna]

This will break the docker build on the hub, because the target zip won't be compiled. How can this be changed to not break existing automated builds on dockerhub, and maintain the oneshot behavior of "docker build ." doing the needful?

[byxorna]

Can we just glob this?

[michaeljs1990]

https://docs.docker.com/engine/userguide/eng-image/multistage-build/#use-multi-stage-builds seems to be the new hotness but not sure how bleeding edge you want to go with a solution.

[byxorna]

@michaeljs1990 if docker hub supports multistage builds, I'd rather do that! Keep in mind, we need to ensure we don't break other downstreams that may depend on tooling we pull into the image during build (ex for runtime tools like curl) that may change when you strip down the build to remove the sdk

[defect]

Good point about the automated builds! I'll check the multi-stage build stuff out. I haven't used that yet, but it looks pretty neat.

I'm not quite sure how to handle downstream images that use tools that just happen to be in our current image since we install a lot of stuff for building. If we have a more streamlined image for deployment, should we just include some of the tools that seems like nice-to-haves? Say, curl/wget, netcat, ipmitool and friends?

EDIT:

Multi-stage builds are a new feature in Docker 17.05

Oh wow, that's newer than i thought :P

EDIT 2: Looks like multistage support on the docker hub isn't that far away: docker/hub-feedback#1039

[defect]

Closing in favor of #562 which seems more promising :)