Implement docker images as a target / task.

[arrdem]

https://www.youtube.com/watch?v=H6gR_Cv4yWI - https://github.com/GoogleContainerTools/jib It looks like Google has (predictably) spent a bunch of time figuring out how to do this well. Turns out there’s a lot of sublties about producing docker images efficiently, particularly to do with producing layers, the order in which layers get produced.

Google uses the GoogleContainerTools/distroless base image, no Linux install just a Java or whatever “microkernel”.

Google’s Jib is based on a three layer format. It eats your Maven configuration, generates three layers /dependencies, /resources and /classes, and assumes that your libraries are slower moving than your resources or your compiled classes. This allows you to optimize your rebuilds to some degree, because while you still recompile the entire application your /dependencies is a separate and presumed to be slower moving layer which can often be cached.

You’d need something fairly smart with access to build history and version bump history in order to really optimize this process further, as you’d want to split libraries up essentially by the rate at which they are changing. Maybe some user annotation for “stable” vs “unstable” libraries would be adequate here?

[arrdem]

docker build - < Dockerfile - it would probably be easy to metaprogram the docker build using a custom pseudo-dockerfile over stdin, and managing putting a minimal build context together myself.