JBoss EAP S2I Builder Image version 1.2, which is the latest version of the builder image, that comes with OpenShift Enterprise 3.1, it provides an environment variable that can be set to point to a maven mirror url, unsurprisingly it is called MAVEN_MIRROR_URL. I will use that variable to get the maven artifacts through our Nexus instance.

To check that our builds will use our internal nexus instance, we can browse to the public group page and verify that there is no dependency currently stored.

Let’s create a new project and create a sample application using nexus.

For the application, we will be using the EAP S2I Builder image, and we will use the default sample project, and we will set a build MAVEN_MIRROR_URL.

You should notice that I’ve used internal DNS name of our nexus instance, which is nexus.ci.svc.cluster.local, which follows the pattern <service-name>.<project>.svc.cluster.local for services. This is a very powerful feature of OpenShift that provides DNS names for every service, and much more.

When building the application, we will notice that maven dependencies are being pulled from our nexus instance, instead of the default public Red Hat JBoss' repositories.

Once our build is finished, we will also see how our nexus repository artifact group is filled with all the dependencies that have been pulled down.

And we will have our application running.

Here, we can a historical view of the builds before and after setting MAVEN_MIRROR_URL. The first build in OpenShift always takes longer than any other build as it has to push all the base layers to the registry after the build. Successive builds will just push the application layer. From build #2 to #5 we can see the time it takes a normal build, without using Nexus, averaging 1 minute and 13 seconds

Build #7 introduces the change with MAVEN_MIRROR_URL set, but as this is the first build after the environment variable has been set, it still took 1 minute and 8 seconds to complete. This build was populating Nexus with all the pulled down dependencies.

In builds #8 to #10 we can see that the average time it takes now to build is 42 seconds

As can be seen, we get an average benefit of 31 seconds in building time after introducing our integration with an artifact repository manager, like Nexus.

Not always one can have the comfort of working with S2i builder images that expose the ability to set a Maven mirror like the Middleware Services images provided by Red Hat does, in that cases you need to think of other mechanisms to integrate these images with an artifact repository manager.

The options can vary, ranging from the most obvious, modify or extend the builder image, using incremental builds, up to creating builder image from scratch. Since I do not like modifying existing images, especially those created by others, I will show how to extend existing Wildfly S2I Builder images to make use of a Nexus artifact repository manager. The same approach can be used with any other builder image, and some other technologies that use or can benefit from the use of an artifact repository manager, especially that Nexus or Artifactory support storing dependencies for other languages than just java.

I have created a file that will install all the required resources needed to work with the Nexus instance provided in the OpenShift install. These resources are:

The change that I’ve done to the default Wildfly S2I builder image is as simple as providing an overloaded settings.xml file in my custom S2I builder images that points to the nexus artifact repository manager. This change is the easiest to prove this functionality, although probably a better option would be to provide environment variable to customize the assembly process.

To install the Wildfly version:

Once we have our custom Wildfly S2I images built,

we can just create a sample application with them.

Here, we see as well that our build process is fetching the required maven dependencies from the provided Nexus artifact repository manager.

This first build took 3 minutes and 11 seconds, it includes building with the plain wildfly-9 image available on Github, and the time needed to pull down the image. This image was not doing any dependency management.

In the second build, I updated the BuildConfig to use wildfly-nexus-9 builder image and this build took 1 minutes and 24 seconds. The reason for that is that Nexus was caching all the dependencies, since I used a clean nexus instance.

On the third and fourth build, all the dependencies were already cached in Nexus and build time dropped to 37 and 35 seconds, respectively.

As in the previous example, with EAP, we get a benefit of more than 40 seconds in our build time by using an artifact repository manager, like Nexus.

Another option, I’ve mentioned before, we can use to improve Maven based Java builds in OpenShift is to enable the incremental builds. Unfortunately not all images support this feature, since it requires the existence of save-artifacts script, responsible for saving artifacts used during builds. In our cases these will be maven dependencies. This will have the same behavior as having a local maven repository into the build image itself, with the drawback of reaching out for the previously built image and getting the dependencies out of it.

To test this mode, I have created a sample resources file that can be easily tested.

After we’ve created the resources, let’s do some builds and look at the times.

As can be seen in the image above, the times for the second and third build, which are the builds benefiting from the stored artifacts takes much less time, 48 and 47 seconds, but it’s the same time it takes when using the artifact repository manager, so there is no additional benefit in time, although it is much simpler for those images that support incremental mode, as the developer will only need to specify a flag in the BuildConfig.

In this example, the application and pulled down dependencies are not adding a big overhead in size to the initial eap64-openshift S2I image, only 7 MB.

But we need to be careful with this approach as there are other images or applications that will have much more dependencies, and the size of the generated image can grow enormously. 130 MB in the following example using Fuse Integration Services.

For every application that we build we will be getting a performance benefit by caching into an artifact repository manager it’s dependencies. Initially we will be perceiving a performance benefit for the second and subsequent builds of every application, but as the artifact repository manager stores more and more dependencies this benefit will be also seen in initial builds of new applications, and most of the dependencies will already be cached.

Also, we can use incremental builds to get better performance on Java based builds, but it is important to understand that even this approach is easier to set up there are some drawbacks for this approach, like the need for the image to support incremental mode. Also, in this scenario, as the build process saves the dependencies within the image being built it means that if successive builds are run in different nodes, every node will have to first pull down the image from the OpenShift’s Docker registry which might take longer than pulling down the dependencies again.

The most important benefit of using Nexus or any other artifact repository dependency manager is the security and the fact that dependencies downloaded by one developer/build will be reused over all the builds using the same dependencies. Whereas in the case of incremental builds only the dependencies downloaded during previous build can be reused and only by the same build. This might have huge impact for any Java-based organization.

In this blog, I’ve highlighted how we can improve the build time of Maven based Java builds in OpenShift, but also a very important topic is the use of the internal DNS service names to reference from one project to another. The only caveat to this, is that if we are using the multi-tenant OVS networking plugin, our cluster administrators will have to make visible our ci project to all other projects: