Example 25-1. S2I Build using a Java builder image apiVersion : v1 kind : BuildConfig metadata : name : random-generator-build spec : source : git : uri : https://github.com/k8spatterns/random-generator strategy :  sourceStrategy : from : kind :  DockerImage name :  fabric8/s2i-java output : to : kind : ImageStreamTag name : random-generator-build:latest triggers :  -  type : ImageChange Reference to the source code to fetch; in this case, pick it up from GitHub. sourceStrategy  switches to S2I mode and the builder image is picked up directly from Docker Hub. The ImageStreamTag to update with the generated image. It’s the committed builder container after the  assemble  script has run. Rebuild automatically when the builder image is updated. S2I is a robust mechanism for creating application images, and it is more secure than plain Docker builds because the build process is under full control of trusted builder images. However, thisi approach still has some drawbacks. For complex applications, S2I can be slow, especially when the build needs to load many dependencies. Without any optimization, S2I loads all dependencies afresh for every build. In the case of a Java application built with Maven, there is no caching as when doing local builds. To avoid downloading the internet again and again, it is rec‐ ommended to set up a cluster internal Maven repository that serves as a cache. The builder image then has to be configured to access this common repository instead of downloading the artifacts from remote repositories. Another way to decrease the build time is to use  incremental builds  with S2I, which allows reusing artifacts created or downloaded in a previous S2I build. However, a lot of data is copied over from the previously generated image to the current build con‐ 226  |  Chapter 25: Image Builder