Investigate layered docker support

[philwebb]

Somewhat related to #1813 and also raised in https://github.com/dsyer/spring-boot-thin-launcher/issues/25. It would be nice if it were easy to create layered JAR files to reduce the amount of space needed.

[psoares]

It's definitely an interesting idea. However, most of my springboot apps require different dependencies (mostly different spring-boot-starters). How would we create a reusable base image without cramming all the spring boot starters and their dependencies in it? There are so many possible combinations.

As far as I'm aware, we can only derive from a single base layer with the FROM instruction of a Dockerfile.

[wilkinsona]

The idea is that the base image would be specific to a particular application. It would contain the things that rarely change (typically the application's third-party dependencies). The application's own code (that changes more frequently) would then be layered on top.

Right now, I think the most likely outcome of this issue is some build tooling that helps to create that separation.

[gclayburg]

Hey everyone, I ran into this issue as well a while back and created a dockerprepare gradle plugin that does this.

plugins {
  id "com.garyclayburg.dockerprepare" version "1.3.2"
}

When you just run the plugin like this with no configuration, it splits the spring boot app into 2 docker layers as suggested by @wilkinsona .

It also can create a 3rd layer for cases where you know you will be creating many microservices applications that share similar dependencies. A typical configuration might look like this in build.gradle:

dockerprepare {
    commonService = ['org.springframework.boot:spring-boot-starter-web']
}

So in this case the docker image will have:

1. common service layer, composed of spring-boot-starter-web and all its transitive dependencies
2. application dependencies, composed of all other dependencies listed in build.gradle
3. application code built by gradle

What do you think?

[philwebb]

@gclayburg Thanks for the link. This looks very similar to what we had in mind except we were thinking we might be able to change our fat jar support to directly support a layered setup.

[gclayburg]

Right, that makes sense @philwebb . I originally started working on that project to learn more about the gradle dsl and just ended up making an entire plugin. As I got farther along I was thinking this stuff probably should be in the spring boot plugin itself. I used groovy to create it, but if I were to do it over I'd probably just stick with Java and its strong typing. There are times where groovy just feels messier than it should be.

[stefanocke]

Google's jib might also be of interest.
Currently it creates layers for:

• dependencies
• snapshot dependencies
• application resources
• application classes

Even with just one Spring Boot app, that saves a good amount of megabytes to up- and download from the registry, since dependencies don't change that often.
If they implement this feature it might become even more flexible and one can split the dependency layer further to allow layer reuse across multiple Spring Boot apps / microservices (like the common-service-layer mentioned above or maybe something like a spring boot + spring cloud layer).

[dsyer]

Please can everyone just remember that spring boot fat jars are already (since 1.3?) optimized for layering - BOOT-INF/lib and BOOT-INF/classes are the only sensible choices and the same in practice to what jib would choose. The getting started guide even does it that way: https://spring.io/guides/gs/spring-boot-docker/. It’s hard to see how we could improve on that.

[mdiskin]

Hi Dave @dsyer , I agree work has been done to optimize the run-time but this is also a play to optimize the build, artifact push and deploy where similar containers (as in our case use the same base jar rails).
I like the idea of leveraging jib now or when it's feature complete enough for spring boot layers.
I'd also like to see memory and performance nods to graals and AOT to be considered in the future since containers are already opinionated on target OS might as well get native platform benefits offered.

[dsyer]

@mdiskin your first sentence looks like maybe you didn't finish it, so I'm not sure what you were saying. Can you expand a bit on what the actual problem is you are trying to solve?

It sounds like Jib might be what you need. What did you mean about Jib not being feature complete?

I don't see what AOT has to do with this issue. If you have an app that can be AOTed, you can containerize it, but there are no layering strategies that will help with that.

[mdiskin]

@dsyer the main benefits I see is the ability to reuse docker image layers across multiple containers. So in our micro services work we use the same set of jars over and over again that adds 30-50mb. If this can be created as a shared layer the actual final image creates just the small final layer of the unique assets for each. This helps speed up our CI builds, lessens the push time/network and storage on the nexus artifact and at deploy time speeds up the container pull to the k8s nodes and startup times (cached layers).

Yes the AOT is separate but something similar that either jib or spring boot fat jars could offer to reduce down that plumbing donkey work. Did you want me to add an issue for this?

To jib feature complete the post earlier referenced a open feature GoogleContainerTools/jib#403 and other 0.10 ones such as this GoogleContainerTools/jib#431