App Connect

Can I bring my own IBM App Connect custom server image? The answer is "yes you can!".

But before that, you might be asking what an IBM App Connect image is and why you would ever want to customize that image yourself.

Let’s play backward a little bit…

You have your integration application, and all you want to do is to package it into a standardized unit for development. You’ve heard that containers allow you to do just that. And you want to manage integration applications just like any of your microservices applications. But more importantly, you want to join the delightful cloud-native club and embrace all of the benefits such as shorter release cycle time, increased efficiency and homogeneity, etc.

In that case, you are in the right place. IBM App Connect provides you with production-ready pre-packaged container images which can also be accessed easily for development purposes.

So, you have your integration runtime packaged as a container image, a base App Connect server image, just like language runtime images (Go, Node.js, etc). But how are you going to incorporate your integration application, which is packaged as BAR file, into it? Now pay attention; this is where Dev and Ops domains are amalgamating, rigid boundaries between them are dissolving to create a mini portable infrastructure with a soul.

You have choices to incorporate your integration application into App Connect server image. In one of the previous community blogs, Lightweight approach to create a custom image for deploying App Connect on OpenShift, John Hosie, IBM App Connect Lead Architect, talks about these options;

When deploying an App Connect integration on OpenShift, you have a choice between uploading the bar file to the App Connect dashboard and "baking it in" to a custom image. There are pros and cons of each of these. Uploading via the dashboard works out of the box and you do not need any additional infrastructure. If you create a baked image, you can automate the whole process and there is no need to use any UI.

Further to this, creating a baked image provides more control over customisation of the container. You could add multiple bar files, bar file overrides, user-defined extension or third-party libraries, etc.

In this article, we will focus on the baking option. Just like layering a fluffy pancake, baking in blueberries and chocolate chips, and maybe toping up with whipped cream... Ok, you got it. You have lots of possibilities… But like everything else in life, you have preferences and restrictions.

Now hopefully you have some conceptual idea on how you can construct the deployment unit of our integration solution.

Probably the next question in your mind will be:

Can I automate my image build process natively on OpenShift without creating a separate build platform? The answer is again, "yes you can!".

There is no doubt that a profound build automation approach will:

• Give you full control over how much change you want to be injected into your build
• Increase the efficiency of your test processes.
• Accelerate CI/CD pipeline development
• Improve DevOps processes

This is nothing new to the development community.

What is new is to accept the fact that the output of your build process is not purely a software package anymore (in our case, a BAR file), instead, it is a container image.

The container image is the runnable unit, going through the runtime lifecycle phases (initiated, terminated, scaled, etc).

The process of building integration images has a lot in common with building any other application: you have your code (Java, ESQL, etc) and integration flows; a build happens when you change the code.

A successful build process outputs an integration image, and you often want to put the image through some different levels of tests. Many of the best practices that apply to building software also apply to images: you can version control to manage image configuration scripts; trigger builds when changes are made to those scripts; perform image builds automatically; test the resulting image artifacts when builds complete.

So, how can you automate your image build process natively on OpenShift without creating a separate build platform?

OpenShift provides an integrated build platform

OpenShift provides an integrated build platform that allows you to automate “the process of transforming input parameters or source code into a resulting runnable image”. The delightful thing is you can define the build process using an OpenShift object (a BuildConfig object) which can be manipulated and run just like any other object. There are a few build strategies available and different options for triggering and for loading or pulling your code into those builds. (Please read the OpenShift documentation for more information)

In this blog, we are going to show you a teaser demo on how the native build platform can accelerate to build a custom integration image from integration source code and deploy on OpenShift as part of Cloud Pak for Integration.

With no overhead of creating and maintaining a separate image registry or build automation toolchain!

We are going to stress the usage of the source to image (S2I) strategy which provides a repeatable method to generate application images from source/binary code.

We are also going to stress the usage of OpenShift templates; another powerful and yet simple instrument that provides a parameterized set of objects that can be processed by OpenShift.

There are only two pieces of artifacts required for this build automation process:

1. App Connect Builder Image

This builder image will be instantiated only when an OpenShift build is triggered. It will take application source code pulled down (from a Git repo) and turns it into the BAR file using “mqsipackagebar” command.  

Notice that we are not pushing the BAR file to an artifact repository; because unlike a traditional build process, our output is not a BAR file. Instead, the end product is an image and the “artifact repository” is the OpenShift image registry itself.

So, what do you think will happen after the builder image container finishes its job? Will it hang out there forever, should you need to maintain the build server? No, it will be stopped and deleted. If you need to kick off another build, a fresh container will be instantiated. However, this doesn’t mean that you cannot access the previous build run status and audit the process. By default, builds that have completed their lifecycle are persisted indefinitely. You can limit the number of previous builds that are retained.

(Learn more how to create builder images)

2. OpenShift Template

• Source Image We define an ImageStream with an ImageStreamTag with a reference to the App Connect server base image
• Build Configuration An OpenShift BuildConfig with a source-to-image strategy stores the configuration necessary to build the App Connect custom server image
  
• Target Image We define another ImageStream containing an ImageStreamTag with a reference to the resulting App Connect custom server image
  
• Integration Server We define an Integration Server object with a reference to the target image stream which holds the resulting App Connect custom server image
  

Let’s check out how this works!

1. You begin with a source code on your Git repository.
2. You then instantiate the template via the `oc` command line utility or WebUI. On starting the template,
   1. OpenShift will create an imagestream.
   2. OpenShift will then create a build pod which pulls the integration source code from Git repository.
   3. The result of the build is a new image, which extends the App Connect server image by adding the BAR file. This new image is published to the image registry on the OpenShift cluster.
   4. Finally, an IntegrationServer is created and each of its pods pulls the custom image from the ImageRegistry to run in its containers.

Summing Up

In this demo, we’ve just instantiated a template and as a result “Integration Server” is created using the integration source code that we’ve pointed to.

We don't have to use any external

• Image Registry
• Artifact Repository
• Build tool
• …
  

Personally, it was once again a very pleasant experience to explore built-in features of OpenShift and to observe how App Connect can nicely make use of them. S2I is a great way to build and compile App Connect applications in a repeatable way, and it just gets better when paired with buildConfigs and templates.

However, this was just a teaser demo to show one of the possibilities.

If you want to accelerate your way to automate your build process, I encourage you all to explore the built-in capabilities of OpenShift yourself and perhaps bring your own recipe. There will never be a perfect recipe for everyone, but let the platform work for you.

Acknowledgements

Thanks to @John Hosie for his help in this demo.

#automation