tainer and the performance benefits are typically not much better than using a cluster-local proxy holding the dependencies. Another drawback of S2I is that the generated image also contains the whole build environment. This fact not only increases the size of the application image but also increases the surface for a potential attack as builder tools can become vulnerable, too. To get rid of unneeded builder tools like Maven, OpenShift offers  chained builds , which take the result of an S2I build and create a slim runtime image. We look at chained builds in “Chained builds” on page 227. OpenShift also supports Docker builds directly within this cluster. Docker builds work by mounting the Docker daemon’s socket directly in the build container, which is then used for a  docker build . The source for a Docker build is a Dockerfile and a directory holding the context. You can also use an  Image  source that refers an arbi‐ trary image and from which files can be copied into the Docker build context direc‐ tory. As mentioned in the next section, this technique, together with triggers, can be used for chained builds. Alternatively, you can use a standard multistage Dockerfile to separate the build and runtime parts. Our example repository contains a fully working multistage Docker build example that results in the same image as the chained build described in the next section. The mechanics of a chained build are shown in Figure 25-2. A chained build consists of an initial S2I build, which creates the runtime artifact like a binary executable. This artifact is then picked up from the generated image by a second build, typically a Docker kind of build. Chained builds Docker builds Solution  |  227