Support Rebase for Tomcat/Liberity Server

[showpune]

Patch is a very important feature for enterprise application, normally, it is solved by rebase of buildpack.

The Tomcat server is managed by buildpacks, so it means if there is CVE issue in Tomcat, customer need to trigger a rebuild instead of rebase.

But the rebuild based on customer input, it means the rebuild need to start from customer input. But sometime the customer just have the built result image and input like the source code is gone, it is hard to ask the operator to trigger the rebuild process.

Is there any possible solution to support rebase of Tomcat server? It is the same as other App server like Tomee, Liberity and APM agent.

[showpune]

I just realized the JDK is also built into image as a BP in paketo buildpack, so it have the same issue.

For JDK, it generate the layer like

1. JDK
2. JDK Helper
3. java-security-properties
   Can we make layer as rebasable and replace the layer generate by BPs?

[dmikusa]

This isn't really something that you can do. At least not the way that Paketo buildpacks have structured base images & dependency installation. You can only rebase the run image with pack, so if the files you want to update are not on the run image then you can't rebase to update those files and you need to rebuild.

In the cases that you've mentioned like the JVM, Tomcat, and Liberty these are all installed by buildpacks into layers. They're not part of the run image, so you can't rebase to update them.

The only thing I can mention is that you should be able to take advantage of caching with rebuilds in the situation you mentioned (if you have the source code). Buildpacks are not like Dockerfiles in that with Dockerfiles, if one layer changes then every layer after that is invalidated and rebuilt too. With buildpacks, caching is smarter so if Tomcat changes but your app does not, all the buildpack should do is download and install a new Tomcat layer. It will then export the app image with the latest run image and all the buildpack generated layers (most of which are cached since they haven't changed).

If you don't have the source code, there's not much you can do at least with pack. You need that to rebuild.

---

On a slightly different note, there is some work being done in the community to create a Paketo UBI-based stack. That stack is doing some new things using buildpack extensions to dynamically set the runtime image to one that includes the JVM selected. This would let you pick the JVM in a similar way to what you can do now, but the JVM is then part of the run image. That should allow you to then rebase the image and get JVM and OS updates. This option has limitations as well. First, it's still very early days. Second, there's been no talk about selecting different JVM vendors using this method, and also no plans to support app servers.

The challenge with this approach is that you have a combinational explosion of run images that need to be maintained and updated. One for your base image, then one for each JVM version & vendor (4 or 5 versions x 10+ vendors), and if you wanted to include app servers that would be way more (40 or 50 JVM combinations x each app server). It is hard to scale and present the same level of choice we have currently.

Dynamic modifications to the run image are technically possible with buildpack extensions, but the problem with that is you then lose rebase support.

Anyway, thought I'd mentioned this as well. In case it's of interest.