1.2. Version Compatibility and Support

1.3. Support for Windows O/S

The developer tooling (oc client and Container Development Kit) for FIS is fully supported on the Windows O/S. The examples shown in Linux command-line syntax can also work on the Windows O/S, provided they are modified appropriately to obey Windows command-line syntax.

1.4. Getting Started for Administrators

If you are an administrator, we recommend you read the instructions in the OpenShift Primer to get started with installing and administering a small OpenShift cluster.

1.5. Comparison: Fuse Standalone and Fuse Integration Services

There are several major functionality differences:

An application deployment with Fuse Integration Services consists of an application and all required runtime components packaged inside a Docker image. Applications are not deployed to a runtime as with Fuse Standalone, the application image itself is a complete runtime environment deployed and managed through OpenShift.

Patching in an OpenShift environment is different from Fuse Standalone, as each application image is a complete runtime environment. To apply a patch, the application image is rebuilt and redeployed within OpenShift. Core OpenShift management capabilities allow for rolling upgrades and side-by-side deployment to maintain availability of your application during upgrade.

Provisioning and clustering capabilities provided by Fabric in Fuse have been replaced with equivalent functionality in Kubernetes and OpenShift. There is no need to create or configure individual child containers as OpenShift automatically does this for you as part of deploying and scaling your application.

Fabric endpoints are not used within an OpenShift environment. Kubernetes services must be used instead.

Messaging services are created and managed using the A-MQ for OpenShift image and not included directly within a Karaf container. Fuse Integration Services provides an enhanced version of the camel-amq component to allow for seamless connectivity to messaging services in OpenShift through Kubernetes.

Live updates to running Karaf instances using the Karaf shell is strongly discouraged as updates will not be preserved if an application container is restarted or scaled up. This is a fundamental tenet of immutable architecture and essential to achieving scalability and flexibility within OpenShift.

The SSH Agent is not included in the Apache Karaf micro-container, so you cannot connect to it using the bin/client console client.

Protocol compatibility and Camel components within a Fuse Integration Services application: non-HTTP based communications must use TLS and SNI to be routable from outside OpenShift into a Fuse service (Camel consumer endpoint).

Chapter 2. Get Started for Administrators

If you are an OpenShift administrator, you can set up Fuse Integration Services (FIS) for other users by installing the FIS images streams and templates as described here.

2.1. Prepare the OpenShift Server

Start the OpenShift Server.

Log in to the OpenShift Server as an administrator, as follows:

oc login -u adminUser -p adminPassword

Install the FIS image streams. Enter the following commands at a command prompt:

Chapter 3. Get Started for Developers

You can start using Fuse Integration Services by creating an application and deploying it to OpenShift using one of the following OpenShift Source-to-Image (S2I) application development workflows:

S2I binary workflow

S2I with build input from a binary source. This workflow is characterised by the fact that the build is partly executed on the developer’s own machine. After building a binary package locally, this workflow hands off the binary package to OpenShift. For more details, see Binary Source from the OpenShift 3.5 Developer Guide.

S2I source workflow

S2I with build input from a Git source. This workflow is characterised by the fact that the build is executed entirely on the OpenShift server. For more details, see Git Source from the OpenShift 3.5 Developer Guide.

3.1. Prerequisites

3.1.1. Access to an OpenShift Server

The fundamental requirement for developing and testing FIS projects is having access to an OpenShift Server. You have the following basic alternatives:

3.1.1.1. Install Container Development Kit (CDK) on Your Local Machine

To get started quickly, the most practical alternative for a developer is to install Red Hat CDK on their local machine. Using CDK, you can boot a virtual machine (VM) instance that runs an image of OpenShift on Red Hat Enterprise Linux (RHEL) 7. An installation of CDK consists of the following key components:

A virtual machine (libvirt, VirtualBox, or Hyper-V)

Minishift to start and manage the Container Development Environment

For FIS 2.0, we recommend you install version 3.1 of CDK. Detailed instructions for installing and using CDK 3.1 are provided in the following guide:

Red Hat CDK is intended for development purposes only. It is not intended for other purposes, such as production environments, and may not address known security vulnerabilities. For full support of running mission-critical applications inside of docker-formatted containers, you need an active RHEL 7 or RHEL Atomic subscription. For more details, see Support for Red Hat Container Development Kit (CDK).

3.1.1.2. Get Remote Access to an Existing OpenShift Server

Your IT department might already have set up an OpenShift cluster on some server machines. In this case, the following requirements must be satisfied for getting started with FIS 2.0:

The server machines must be running a supported version of OpenShift Container Platform (as documented in the Supported Configurations page). The examples in this guide have been tested against version 3.5.

Ask the OpenShift administrator to install the latest FIS 2.0 container base images and the FIS templates on the OpenShift servers.

Ask the OpenShift administrator to create a user account for you, having the usual developer permissions (enabling you to create, deploy, and run OpenShift projects).

Ask the administrator for the URL of the OpenShift Server (which you can use either to browse to the OpenShift console or connect to OpenShift using the oc command-line client) and the login credentials for your account.

3.1.2. Java Version

On your developer machine, make sure you have installed a Java version that is supported by JBoss Fuse 6.3. For details of the supported Java versions, see Supported Configurations.

3.1.3. Install the Requisite Client-Side Tools

We recommend that you have the following tools installed on your developer machine:

Apache Maven 3.3.x

Required for local builds of OpenShift projects. Download the appropriate package from the Apache Maven download page. Make sure that you have at least version 3.3.x (or later) installed, otherwise Maven might have problems resolving dependencies when you build your project.

Git

Required for the OpenShift S2I source workflow and generally recommended for source control of your FIS projects. Download the appropriate package from the Git Downloads page.

OpenShift client

If you are using CDK, you can add the oc binary to your PATH using minishift oc-env which displays the command you need to type into your shell (the output of oc-env will differ depending on OS and shell type):

If you are not using CDK, follow the instructions in the CLI Reference to install the oc client tool.

(Optional) Docker client

Advanced users might find it convenient to have the Docker client tool installed (to communicate with the docker daemon running on an OpenShift server). For information about specific binary installations for your operating system, see the Docker installation site.

Make sure that you install versions of the oc tool and the docker tool that are compatible with the version of OpenShift running on the OpenShift Server.

3.2. Prepare Your Development Environment

After installing the required software and tools, prepare your development environment as follows.

3.2.1. Configure Maven Repositories

Configure the Maven repositories, which hold the archetypes and artifacts you will need for building an FIS project on your local machine. Edit your Maven settings.xml file, which is usually located in ~/.m2/settings.xml (on Linux or macOS) or Documents and Settings\<USER_NAME>\.m2\settings.xml (on Windows). The following Maven repositories are required:

You must add the preceding repositories both to the dependency repositories section as well as the plug-in repositories section of your settings.xml file.

3.2.2. (Optional) Install Developer Studio

Red Hat JBoss Developer Studio is an Eclipse-based development environment, which includes support for developing Fuse Integration Services applications. For details of how to install this development environment, see Install Red Hat JBoss Developer Studio.

3.3. Create and Deploy a Project Using the S2I Binary Workflow

In this section, you will use the OpenShift S2I binary workflow to create, build, and deploy an FIS project.

Create a new FIS project using a Maven archetype. For this example, we use an archetype that creates a sample Spring Boot Camel project. Open a new shell prompt and enter the following Maven command:

When prompted, enter org.example.fis for the groupId value and fis-spring-boot for the artifactId value. Accept the defaults for the remaining fields.

If the previous command exited with the BUILD SUCCESS status, you should now have a new FIS project under the fis-spring-boot subdirectory. You can inspect the XML DSL code in the fis-spring-boot/src/main/resources/spring/camel-context.xml file. The demonstration code defines a simple Camel route that continuously sends message containing a random number to the log.

In preparation for building and deploying the FIS project, log in to the OpenShift Server as follows:

oc login -u developer -p developer https://OPENSHIFT_IP_ADDR:8443

Where, OPENSHIFT_IP_ADDR is a placeholder for the OpenShift server’s IP address as this IP address is not always the same.

Note

The developer user (with developer password) is a standard account that is automatically created on the virtual OpenShift Server by CDK. If you are accessing a remote server, use the URL and credentials provided by your OpenShift administrator.

Create a new project namespace called test (assuming it does not already exist), as follows:

oc new-project test

If the test project namespace already exists, you can switch to it using the following command:

oc project test

You are now ready to build and deploy the fis-spring-boot project. Assuming you are still logged into OpenShift, change to the directory of the fis-spring-boot project, and then build and deploy the project, as follows:

cd fis-spring-boot
mvn fabric8:deploy

At the end of a successful build, you should see some output like the following:

Click Overview on the left-hand navigation bar to return to the overview of the services in the test namespace. To shut down the running pod, click the down arrow
beside the pod icon. When a dialog prompts you with the question Scale down deployment fis-spring-boot-1?, click Scale Down.

(Optional) If you are using CDK, you can shut down the virtual OpenShift Server completely by returning to the shell prompt and entering the following command:

minishift stop

3.3.1. Redeploy and Undeploy the Project

To redeploy or undeploy your projects, you can use the following commands.

To redeploy the project, rerun mvn fabric8:deploy.

To undeploy the project, run mvn fabric8:undeploy.

3.3.2. Opening the HawtIO Console

To open the HawtIO console for a pod running the FIS Spring Boot example, proceed as follows:

From the Applications → Pods view in your OpenShift project, click on the pod name to view the details of the running FIS Spring Boot pod. On the right-hand side of this page, you see a summary of the container template:

From this view, click on the Open Java Console link to open the HawtIO console.

Note

In order to configure OpenShift to display a link to HawtIO console in the pod view, the pod running a FIS image must declare a tcp port within a name attribute set to jolokia:

3.4. Create and Deploy a Project Using the S2I Source Workflow

In this section, you will use the OpenShift S2I source workflow to build and deploy an FIS project based on a template. The starting point for this demonstration is a quickstart project stored in a remote Git repository. Using the OpenShift console, you will download, build, and deploy this quickstart project in the OpenShift server.

Navigate to the OpenShift console in your browser (https://OPENSHIFT_IP_ADDR:8443, replace OPENSHIFT_IP_ADDR with the IP address that was displayed in the case of CDK) and log in to the console with your credentials (for example, with username developer and password, developer).

On the Projects screen of the OpenShift console, click New Project.

On the New Project screen, enter test in the Name field and click Create. The Select Image or Template screen now opens.

Note

If the test project already exists in OpenShift, click on the test project and then click Add to Project to open the Add to Project screen.

On the Add to Project screen, from the Browse Catalog tab, click Java to open the list of Java templates.

Scroll down to find the s2i-spring-boot-camel-xml template and click the Select button.

The s2i-spring-boot-camel-xml template form opens, as shown below. You can accept all of the default settings on this form. Scroll down to the bottom of the form and click Create.

Note

If you want to modify the application code (instead of just running the quickstart as is), you would need to fork the original quickstart Git repository and fill in the appropriate values in the Git repository URL and Git reference fields.

The Application created screen now opens. Click Continue to overview to go to the Overview tab of the OpenShift console (which shows an overview of the available services and pods in the current project). If you have not previously created any application builds in this project, this screen will be empty.

In the navigation pane on the left-hand side, select Builds→Builds to open the Builds screen.

Click the s2i-spring-boot-camel-xml build name to open the s2i-spring-boot-camel-xml build page, as shown below.

Click View log to view the log for the latest build — if the build should fail for any reason, the build log can help you to diagnose the problem.

Note

The build can take several minutes to complete, because a lot of dependencies must be downloaded from remote Maven repositories. To speed up build times, we recommend you deploy a Nexus server on your local network.

If the build completes successfully, click Overview in the left-hand navigation pane to view the running pod for this application.

Click in the centre of the pod icon (blue circle) to view the list of pods for s2i-spring-boot-camel-xml.

Click on the pod Name (in this example, s2i-spring-boot-camel-xml-1-hviyy) to view the details of the running pod.

Click on the Logs tab to view the application log and scroll down the log to find the log messages generated by the Camel application.

Click Overview on the left-hand navigation bar to return to the overview of the services in the test namespace. To shut down the running pod, click the down arrow
beside the pod icon. When a dialog prompts you with the question Scale down deployment s2i-spring-boot-camel-xml-1?, click Scale Down.

(Optional) If you are using CDK, you can shut down the virtual OpenShift Server completely by returning to the shell prompt and entering the following command:

minishift stop

Chapter 4. Develop an Application for the Spring Boot Image

4.1. Overview

This chapter explains how to develop applications for the Spring Boot image.

Where the following files are important for developing an application:

pom.xml

Includes additional dependencies. Camel components that are compatible with Spring Boot are available in the starter version, for example camel-jdbc-starter or camel-infinispan-starter. Once the starters are included in the pom.xml they are automatically configured and registered with the Camel content at boot time. Users can configure the properties of the components using the application.properties file.

application.properties

It is an important file that allows you to externalize your configuration and work with the same application code in different environments. For details, see Externalized Configuration

For example, in this Camel application you can configure certain properties such as name of the application or the IP addresses, and so on.

application.properties

# the options from org.apache.camel.spring.boot.CamelConfigurationProperties can be configured here
camel.springboot.name=MyCamel
# lets listen on all ports to ensure we can be invoked from the pod IP
server.address=0.0.0.0
management.address=0.0.0.0

Application.java

It is an important file to run your application. As a user you will import here a file camel-context.xml to configure routes using the Spring DSL.

The Application.java file specifies the @SpringBootApplication annotation, which is equivalent to @Configuration, @EnableAutoConfiguration and @ComponentScan with their default attributes.

Demonstrates how to use Apache CXF with Spring Boot based on a fabric8 Java base image. The quickstart uses Spring Boot to configure an application that includes a CXF JAXRS endpoint with Swagger enabled.

spring-boot-cxf-jaxws-archetype

Demonstrates how to use Apache CXF with Spring Bootbased on a fabric8 Java base image. The quickstart uses Spring Boot to configure an application that includes a CXF JAXWS endpoint.

4.5. Camel Starter Modules

4.5.1. Overview

Starters are Apache Camel modules intended to be used in Spring Boot applications. There is a camel-xxx-starter module for each Camel component (with few exceptions listed below).

Starters meet the following requirements:

Allow auto-configuration of the component using native Spring Boot configuration system which is compatible with IDE tooling.

To keep the main thread blocked so that Camel stays up, either include the spring-boot-starter-web dependency, or add camel.springboot.main-run-controller=true to your application.properties or application.yml file.

You can customize the Camel application in the application.properties or application.yml file with camel.springboot.* properties.

4.6. Unsupported Starter Modules

The following components do not have a starter because of compatibility issues:

camel-blueprint (intended for OSGi only)

camel-cdi (intended for CDI only)

camel-core-osgi (intended for OSGi only)

camel-ejb (intended for JEE only)

camel-eventadmin (intended for OSGi only)

camel-ibatis (camel-mybatis-starter is included)

camel-jclouds

camel-mina (camel-mina2-starter is included)

camel-paxlogging (intended for OSGi only)

camel-quartz (camel-quartz2-starter is included)

camel-spark-rest

camel-swagger (camel-swagger-java-starter is included)

Chapter 5. Develop Camel Applications in Spring Boot

5.1. Introduction to Camel Spring Boot

Spring Boot component provides auto configuration for Apache Camel. Auto-configuration of the Camel context auto-detects Camel routes available in the Spring context and registers the key Camel utilities such as producer template, consumer template, and the type converter as beans.

Every Camel Spring Boot application should use dependencyManagement with productized versions, see quickstart pom. Versions that are tagged later can be omitted to not override the versions from BOM.

You can customize the Camel application in the application.properties or application.yml file.

5.3. Auto-configured Camel context

Camel auto-configuration provides a CamelContext instance and creates a SpringCamelContext. It also initializes and performs shutdown of that context. This Camel context is registered in the Spring application context under camelContext bean name and you can access it like other Spring bean.

5.4. Auto-detecting Camel routes

Camel auto configuration collects all the RouteBuilder instances from the Spring context and automatically injects them into the CamelContext. It simplifies the process of creating new Camel route with the Spring Boot starter. You can create the routes by adding the @Component annotated class to your classpath.

The method CamelContextConfiguration and beforeApplicationStart(CamelContext) will be called before the Spring context is started, so the CamelContext instance passed to this callback is fully auto-configured. You can add many instances of CamelContextConfiguration into your Spring context and all of them will be executed.

5.7. Disabling JMX

To disable JMX of the auto-configured CamelContext use camel.springboot.jmxEnabled property as JMX is enabled by default.

For example, you could add the following property to your application.properties file:

5.10. Spring type conversion API bridge

Spring consist of type conversion API. Spring API is similar to the Camel type converter API. Due to the similarities between the two APIs Camel Spring Boot automatically registers a bridge converter (SpringTypeConverter) that delegates to the Spring conversion API. That means that out-of-the-box Camel will treat Spring Converters similar to Camel.

This allows you to access both Camel and Spring converters using the Camel TypeConverter API, as shown below:

Here, Spring Boot delegates conversion to the Spring’s ConversionService instances available in the application context. If no ConversionService instance is available, Camel Spring Boot auto configuration creates an instance of ConversionService.

5.11. Disabling type conversions features

To disable registering type conversion features of Camel Spring Boot such as TypeConverter instance or Spring bridge, set the camel.springboot.typeConversion property to false as shown below:

camel.springboot.typeConversion = false

5.12. Adding XML routes

By default, you can put Camel XML routes in the classpath under the directory camel, which camel-spring-boot will auto detect and include. From Camel version 2.17 onwards you can configure the directory name or disable this feature using the configuration option, as shown below:

5.13. Adding XML Rest-DSL

By default, you can put Camel Rest-DSL XML routes in the classpath under the directory camel-rest, which camel-spring-boot will auto detect and include. You can configure the directory name or disable this feature using the configuration option, as shown below:

When prompted, enter org.example.fis for the groupId value and fis-spring-boot-camel-amq for the artifactId value. Accept the defaults for the remaining fields.

Navigate to the quickstart directory fis-spring-boot-camel-amq:

$ cd fis-spring-boot-camel-amq

Customize the client credentials for logging on to the broker, by setting the ACTIVEMQ_BROKER_USERNAME and ACTIVEMQ_BROKER_PASSWORD environment variables. In the fis-spring-boot-camel-amq project, edit the src/main/fabric8/deployment.yml file, as follows:

7.1.2. Spring Boot Externalized Configuration

In Spring Boot, externalized configuration is the mechanism that enables you to inject configuration values from external sources into Java code. In your Java code, injection is typically enabled by annotating with the @Value annotation (to inject into a single field) or the @ConfigurationProperties annotation (to inject into multiple properties on a Java bean class).

The configuration data can come from a wide variety of different sources (or property sources). In particular, configuration properties are often set in a project’s application.properties file (or application.yaml file, if you prefer).

7.1.3. Kubernetes ConfigMap

A Kubernetes ConfigMap is a mechanism that can provide configuration data to a deployed application. A ConfigMap object is typically defined in a YAML file, which is then uploaded to the Kubernetes cluster, making the configuration data available to deployed applications.

7.1.4. Kubernetes Secrets

A Kubernetes Secrets is a mechanism for providing sensitive data (such as passwords, certificates, and so on) to deployed applications.

7.1.5. Spring Cloud Kubernetes Plug-In

The Spring Cloud Kubernetes plug-in implements the integration between Kubernetes and Spring Boot. In principle, you could access the configuration data from a ConfigMap using the Kubernetes API. It is much more convenient, however, to integrate Kubernetes ConfigMap directly with the Spring Boot externalized configuration mechanism, so that Kubernetes ConfigMaps behave as an alternative property source for Spring Boot configuration. This is essentially what the Spring Cloud Kubernetes plug-in provides.

7.1.6. How to Enable Spring Boot with Kubernetes Integration

In a typical Spring Boot Maven project, you can enable the integration by adding the following Maven dependency to your project’s POM file:

To complete the integration, you need to add some annotations to your Java source code, create a Kubernetes ConfigMap object, and modify the OpenShift service account permissions to allow your application to read the ConfigMap object. These steps are described in detail in Section 7.2, “Tutorial for ConfigMap Property Source”.

7.2. Tutorial for ConfigMap Property Source

The following tutorial is based on the spring-boot-camel-config-archetype Maven archetype, which enables you to experiment with setting Kubernetes Secrets and ConfigMaps. The Spring Cloud Kubernetes plug-in is also enabled, making it possible to integrate Kubernetes configuration objects with Spring Boot Externalized Configuration.

7.2.1. Build and run the spring-boot-camel-config quickstart

Perform the following steps to create a simple Camel Spring Boot project:

When prompted, enter org.example.fis for the groupId value and fis-configmap for the artifactId value. Accept the defaults for the remaining fields.

Log in to OpenShift and switch to the OpenShift project where you will deploy your application. For example, to log in as the developer user and deploy to the test project, enter the following commands:

Where, OPENSHIFT_IP_ADDR is a placeholder for the OpenShift server’s IP address.

At the command line, change to the directory of the new fis-configmap project and create the Secret object for this application:

oc create -f sample-secret.yml

Note

It is necessary to create the Secret object before you deploy the application, otherwise the deployed container enters a wait state until the Secret becomes available. If you subsequently create the Secret, the container will come out of the wait state.

Build and deploy the quickstart application. From the top level of the fis-configmap project, enter:

mvn fabric8:deploy

View the application log as follows. Open the OpenShift console in your browser and select the relevant project namespace (for example, test). Click in the center of the circular pod icon for the fis-configmap service and then — in the Pods view — click on the pod Name to view the details of the running pod (alternatively, you will get straight through to the details page, if there is only one pod running). Now click on the Logs tag to view the application log and scroll down to find the log messages generated by the Camel application.

The default recipient list, which is configured in src/main/resources/application.properties, sends the generated messages to two dummy endpoints: direct:async-queue and direct:file. This causes messages like the following to be written to the application log:

Before you can update the configuration of the fis-configmap application using a ConfigMap object, you must give the fis-configmap application permission to view data from the OpenShift ApiServer. Enter the following command to give the view permission to the fis-configmap application’s service account:

A service account is specified using the syntax system:serviceaccount:PROJECT_NAME:SERVICE_ACCOUNT_NAME. The fis-config deployment descriptor defines the SERVICE_ACCOUNT_NAME to be qs-camel-config.

To see the live reload feature in action, create a ConfigMap object as follows:

oc create -f sample-configmap.yml

The new ConfigMap overrides the recipient list of the Camel route in the running application, configuring it to send the generated messages to three dummy endpoints: direct:async-queue, direct:file, and direct:mail. This causes messages like the following to be written to the application log:

7.2.2. Configuration Properties bean

A configuration properties bean is a regular Java bean that can receive configuration settings by injection. It provides the basic interface between your Java code and the external configuration mechanisms.

Provides property settings for injection into configuration. The default property source is the application’s application.properties file, and this can optionally be overridden by a ConfigMap object or a Secret object.

Configuration Properties bean

Receives configuraton updates from the property sources. A configuration properties bean is a Java bean decorated by the @Configuration and @ConfigurationProperties annotations.

Spring bean registry

With the requisite annotations, a configuration properties bean is registered in the Spring bean registry.

Integration with Camel bean registry

The Camel bean registry is automatically integrated with the Spring bean registry, so that registered Spring beans can be referenced in your Camel routes.

7.2.2.2. QuickstartConfiguration class

The configuration properties bean for the fis-configmap project is defined as the QuickstartConfiguration Java class (under the src/main/java/org/example/fis/ directory), as follows:

The @Configuration annotation causes the QuickstartConfiguration class to be instantiated and registered in Spring as the bean with ID, quickstartConfiguration. This automatically makes the bean accessible from Camel. For example, the target-route-queue route is able to access the queueUserName property using the Camel syntax ${bean:quickstartConfiguration?method=getQueueUsername}.

The @ConfigurationProperties annotation defines a prefix, quickstart, that must be used when defining property values in a property source. For example, a properties file would reference the recipients property as quickstart.recipients.

7.2.3. How to set up the Secret

The Kubernetes Secret in this quickstart is set up in the standard way, apart from one additional required step: the Spring Cloud Kubernetes plug-in must be configured with the mount paths of the Secrets, so that it can read the Secrets at run time.

For more details, see the chapter on Secrets in the Kubernetes reference documentation.

7.2.3.1. Sample Secret object

The quickstart project provides a sample Secret, sample-secret.yml, as follows:

Identifies the Secret. Other parts of the OpenShift system use this identifier to reference the Secret.

quickstart.queue-username

Is meant to be injected into the queueUsername property of the quickstartConfiguration bean. The value must be base64 encoded.

quickstart.queue-password

Is meant to be injected into the queuePassword property of the quickstartConfiguration bean. The value must be base64 encoded.

Property values in Secret objects are always base64 encoded (use the base64 command-line utility). When the Secret is mounted in a pod’s filesystem, the values are automatically decoded back into plain text.

Note

Kubernetes does not allow you to define property names in CamelCase (it requires property names to be all lowercase). To work around this limitation, use the hyphenated form queue-username, which Spring Boot matches with queueUsername. This takes advantage of Spring Boot’s relaxed binding rules for externalized configuration.

7.2.3.2. Configure volume mount for the Secret

The application must be configured to load the Secret at run time, by configuring the Secret as a volume mount. After the application starts, the Secret properties then become available at the specified location in the filesystem.

The Example 7.1, “deployment.yml file” listing shows the application’s deployment.yml file (located under src/main/fabric8/), which defines the volume mount for the Secret.

In the volumeMounts section, the deployment declares a new volume mount, which references the camel-config volume and specifies that the Secret volume should be mounted to the path /etc/secrets/camel-config in the pod’s filesystem.

7.2.3.3. Configure spring-cloud-kubernetes to read Secret properties

To integrate secrets with Spring Boot externalized configuration, the Spring Cloud Kubernetes plug-in must be configured with the secret’s mount path. Spring Cloud Kubernetes reads the secrets from the specified location and makes them available to Spring Boot as property sources.

The Spring Cloud Kubernetes plug-in is configured by settings in the bootstrap.yml file, located under src/main/resources in the quickstart project, as shown in the Example 7.2, “bootstrap.yml file” listing.

The spring.cloud.kubernetes.secrets.paths property specifies the list of paths of secrets volume mounts in the pod.

Note

A bootstrap.properties file (or bootstrap.yml file) behaves similarly to an application.properties file, but it is loaded at an earlier phase of application start-up. It is more reliable to set the properties relating to the Spring Cloud Kubernetes plug-in in the bootstrap.properties file.

7.2.4. How to set up the ConfigMap

In addition to creating a ConfigMap object and setting the view permission appropriately, the integration with Spring Cloud Kubernetes requires you to match the ConfigMap’s metadata.name with the value of the spring.application.name property configured in the project’s bootstrap.yml file.

7.2.4.1. Sample ConfigMap object

The quickstart project provides a sample ConfigMap, sample-configmap.yml, as follows:

7.2.4.2. Setting the view permission

As shown in the Example 7.1, “deployment.yml file” listing, the serviceAccountName is set to qs-camel-config in the project’s deployment.yml file. Hence, you need to enter the following command to enable the view permission on the quickstart application (assuming that it deploys into the test project namespace):

7.3. ConfigMap PropertySource

Kubernetes has the notion of ConfigMap for passing configuration to the application. The Spring cloud Kubernetes plug-in provides integration with ConfigMap to make config maps accessible by Spring Boot.

The ConfigMapPropertySource when enabled will look up Kubernetes for a ConfigMap named after the application (see spring.application.name). If the map is found it will read its data and do the following:

7.3.3. Apply Property Named application.properties

You can also define the ConfigMap properties in the style of a Spring Boot application.properties file. In this case we use a single property named application.properties and list the property settings inside it:

7.3.4. Deploying a ConfigMap

To deploy a ConfigMap and make it accessible to a Spring Boot application, perform the following steps:

In your Spring Boot application, use the externalized configuration mechanism to access the ConfigMap property source. For example, by annotating a Java bean with the @Configuration annotation, it becomes possible for the bean’s property values to be injected by a ConfigMap.

In your project’s bootstrap.properties file (or bootstrap.yaml file), set the spring.application.name property to match the name of the ConfigMap.

Enable the view permission on the service account that is associated with your application (by default, this would be the service account called default). For example, to add the view permission to the default service account:

7.4. Secrets PropertySource

Kubernetes has the notion of Secrets for storing sensitive data such as password, OAuth tokens, etc. The Spring cloud Kubernetes plug-in provides integration with Secrets to make secrets accessible by Spring Boot.

The Secrets property source when enabled will look up Kubernetes for Secrets from the following sources:

Access to secrets via API may be restricted for security reasons — the preferred way is to mount a secret to the POD.

7.5. PropertySource Reload

Some applications may need to detect changes on external property sources and update their internal status to reflect the new configuration. The reload feature of Spring Cloud Kubernetes is able to trigger an application reload when a related ConfigMap or Secret change.

This feature is disabled by default and can be enabled using the configuration property spring.cloud.kubernetes.reload.enabled=true (for example, in the bootstrap.properties file).

The following levels of reload are supported (property spring.cloud.kubernetes.reload.strategy):

refresh

(default) only configuration beans annotated with @ConfigurationProperties or @RefreshScope are reloaded. This reload level leverages the refresh feature of Spring Cloud Context.

Note

The PropertySource reload feature can only be used for simple properties (that is, not collections) when the reload strategy is set to refresh. Properties backed by collections must not be changed at runtime.

restart_context

the whole Spring ApplicationContext is gracefully restarted. Beans are recreated with the new configuration.

shutdown

the Spring ApplicationContext is shut down to activate a restart of the container. When using this level, make sure that the lifecycle of all non-daemon threads is bound to the ApplicationContext and that a replication controller or replica set is configured to restart the pod.

7.5.1. Example

Assuming that the reload feature is enabled with default settings (refresh mode), the following bean will be refreshed when the config map changes:

Any change to the property named bean.message in the Config Map associated with the pod will be reflected in the output of the program.

The reload feature supports two operating modes:

event

(default) watches for changes in ConfigMaps or secrets using the Kubernetes API (web socket). Any event will produce a re-check on the configuration and a reload in case of changes. The view role on the service account is required in order to listen for config map changes. A higher level role (eg. edit) is required for secrets (secrets are not monitored by default).

polling

re-creates the configuration periodically from config maps and secrets to see if it has changed. The polling period can be configured using the property spring.cloud.kubernetes.reload.period and defaults to 15 seconds. It requires the same role as the monitored property source. This means, for example, that using polling on file mounted secret sources does not require particular privileges.

The following properties can be used to configure the reloading feature:

spring.cloud.kubernetes.reload.enabled

Enables monitoring of property sources and configuration reload. Type is Boolean and default is false.

spring.cloud.kubernetes.reload.monitoring-config-maps

Allow monitoring changes in config maps. Type is Boolean and default is true.

spring.cloud.kubernetes.reload.monitoring-secrets

Allow monitoring changes in secrets. Type is Boolean and default is false.

spring.cloud.kubernetes.reload.strategy

The strategy to use when firing a reload (refresh, restart_context, shutdown). Type is Enum and default is refresh.

spring.cloud.kubernetes.reload.mode

Specifies how to listen for changes in property sources (event, polling). Type is Enum and default is event.

spring.cloud.kubernetes.reload.period

The period in milliseconds for verifying changes when using the polling strategy. Type is Long and default is 15000.

Note the following points:

The spring.cloud.kubernetes.reload.* properties should not be used in ConfigMaps or Secrets. Changing such properties at run time may lead to unexpected results;

Deleting a property or the whole config map does not restore the original state of the beans when using the refresh level.

Chapter 8. Develop an Application for the Karaf Image

8.1. Create a Karaf Project using Maven Archetype

To create a Karaf project using a Maven archetype, follow these steps:

8.4.2.1. Property placeholders resolvers

The bundle fabric8-karaf-core exports a service PlaceholderResolver with the following interface:

public interface PlaceholderResolver {
/**
* Resolve a placeholder using the strategy indicated by the prefix
*
* @param value the placeholder to resolve
* @return the resolved value or null if not resolved
*/
String resolve(String value);
/**
* Replaces all the occurrences of variables with their matching values from the resolver using the given source string as a template.
*
* @param source the string to replace in
* @return the result of the replace operation
*/
String replace(String value);
/**
* Replaces all the occurrences of variables within the given source builder with their matching values from the resolver.
*
* @param value the builder to replace in
* @rerurn true if altered
*/
boolean replaceIn(StringBuilder value);
/**
* Replaces all the occurrences of variables within the given dictionary
*
* @param dictionary the dictionary to replace in
* @rerurn true if altered
*/
boolean replaceAll(Dictionary<String, Object> dictionary);
/**
* Replaces all the occurrences of variables within the given dictionary
*
* @param dictionary the dictionary to replace in
* @rerurn true if altered
*/
boolean replaceAll(Map<String, Object> dictionary);
}

The PlaceholderResolver service acts as a collector for different property placeholder resolution strategies. The resolution strategies it provides by default are listed in the table.

List of resolution strategies

Prefix

Example

Description

env

env:JAVA_HOME

lookup the property from OS environment variables.

sys

sys:java.version

lookup the property from Java JVM system properties.

service

service:amq

lookup the property from OS environment variables using the service naming idiom.

service.host

service.host:amq

lookup the property from OS environment variables using the service naming idiom returning the hostname part only.

service.port

service.port:amq

lookup the property from OS environment variables using the service naming idiom returning the port part only.

k8s:map

k8s:map:myMap/myKey

lookup the property from a Kubernetes ConfigMap (via API)

k8s:secret

k8s:secret:amq/password

lookup the property from a Kubernetes Secrets (via API or volume mounts)

The property placeholder service supports the following options:

List of property placeholder service options

Name

Default

Description

fabric8.placeholder.prefix

$[

The prefix for the placeholder

fabric8.placeholder.suffix

]

The suffix for the placeholder

fabric8.k8s.secrets.path

null

A comma delimited list of paths were secrets are mapped

fabric8.k8s.secrets.api.enabled

false

Enable/Disable consuming secrets via APIs

To set the property placeholder service options you can use system properties or environment variables or both.

To access ConfigMaps on OpenShift the service account needs view permissions

8.4.2.2. Adding a custom property placeholders resolvers

You can add a custom placeholder resolver to support a specific need, such as custom encryption. You can also use the PlaceholderResolver service to make the resolvers available to Blueprint and ConfigAdmin.

8.4.3.2. Configuration plugin

The fabric8-karaf-cm provides a ConfigurationPlugin which resolves configuration property placeholders.

To enable property substitution with the fabric8-karaf-cm plug-in, you must set the Java property, fabric8.config.plugin.enabled to true. For example, you can set this property using the JAVA_OPTIONS environment variable in the Karaf image, as follows:

The fabric8 evaluator supports chained evaluators, such as ${env+service:MY_ENV_VAR}. You need to resolve MY_ENV_VAR variable against environment variables. The result is then resolved using service function. For example,

The fabric8-maven-plugin:resources goal will detect if your using the fabric8-karaf-checks feature and automatically add the Kubernetes for readiness and liveness probes to your container’s configuration.

8.4.5.1. Adding Custom Heath Checks

You can provide additional custom heath checks to prevent the Karaf server from receiving user traffic before it is ready to process the requests. TO enable custom health checks you need to implement the io.fabric8.karaf.checks.HealthChecker or io.fabric8.karaf.checks.ReadinessChecker interfaces and register those objects in the OSGi registry.

Your project will need to add the following mvn dependency to the project pom.xml file.

Chapter 9. Using Persistent Storage in Fuse Integration Services

Fuse Integration Services (FIS) applications are based on OpenShift containers, which do not have a persistent filesystem. Every time you start an application it is started in a new container with an immutable Docker image. Hence any persisted data in the file systems is lost when the container stops. But applications need to store some state as data in a persistent store and sometimes applications share access to a common data store. OpenShift platform supports provisioning of external stores as Persistent Storage.

9.1. Volumes

emptydir (empty directory): This is a default volume type. It is a directory which gets allocated when the pod is created on a local host. It is not copied across the servers and when you delete the pod the directory is removed.

configmap: It is a directory with contents populated with key-value pairs from a named configmap.

hostPath (host directory): It is a directory with specific path on any host and it requires elevated privileges.

secret (mounted secret): Secret volumes mount a named secret to the provided directory.

persistentvolumeclaim or pvc (persistent volume claim): This links the volume directory in the container to a persistent volume claim you have allocated by name. A persistent volume claim is a request to allocate storage. Note that if your claim is not bound, your pods will not start.

Volumes are configured at the Pod level and can only directly access an external storage using hostPath. Hence it is harder to mange the access to shared resources for multiple Pods as hostPath volumes.

9.2. PersistentVolumes

PersistentVolumes allow cluster administrators to provision cluster wide storage which is backed by various types of network storage like NFS, Ceph RBD, AWS Elastic Block Store (EBS), etc. PersistentVolumes also specify capacity, access modes, and recycling policies. This allows pods from multiple Projects to access persistent storage without worrying about the nature of the underlying resource.

Here the host path is /data/pv0001 and storage capacity is limited to 2MB. For example, when using OpenShift CDK it will provision the directory /data/pv0001 from the virtual machine hosting the OpenShift Cluster. To create this PersistentVolume, add the above configuration in a file pv.yaml and use the command:

oc create -f pv.yaml

To verify the creation of PersistentVolume, use the following command, which will list all the PersistentVolumes configured in your OpenShift cluster:

oc get pv

9.4. PersistentVolumeClaims

A PersistentVolume exposes a storage endpoint as a named entity in an OpenShift cluster. To access this storage from Projects, PersistentVolumeClaims must be created that can access the PersistentVolume. PersistentVolumeClaims are created for each Project with customized claims for a certain amount of storage with certain access modes.

The sample configuration below creates a claim named pvc0001 for 1MB of storage with read-write-once access against a PersistentVolume named pv0001.

Any data written by the application to the directory /usr/share/data is now persisted across container restarts. Add this configuration in the file src/main/fabric8/deployment.yml in a FIS application and create OpenShift resources using command:

mvn fabric8:resource-apply

To verify that the created DeploymentConfiguration has the volume mount and volume use the command:

oc describe deploymentconfig <application-dc-name>

For FIS quickstarts, the <application-dc-name> is the Maven project name, for example spring-boot-camel.

Chapter 10. Patching Fuse Integration Services

10.1. Patching Overview

You might need to perform one or more of the following tasks to bring the Fuse Integration Services (FIS) product up to the latest patch level:

Update the FIS images on your OpenShift server, so that new application builds are based on patched versions of the Fuse base images.

10.2. Patch Application Dependencies

In the context of Fuse Integration Services (FIS), applications are built entirely using Maven artifacts downloaded from the Red Hat Maven repositories. Hence, to patch your application, all that you need to do is to edit your project’s POM file, changing the Maven dependencies to use the appropriate FIS patch version.

It is important to upgrade all of the Maven dependencies for FIS together, so that your project uses dependencies that are all from the same patch version. The FIS project consists of a carefully curated set of Maven artifacts that are built and tested together. If you try to mix and match Maven artifacts from different FIS patch levels, you could end up with a configuration that is untested and unsupported by Red Hat. The easiest way to avoid this scenario is to use a Bill of Materials (BOM) file in Maven, which defines the versions of all the Maven artifacts supported by FIS. When you update the version of a BOM file, you automatically update the versions for all the FIS Maven artifacts in your project’s POM.

The POM file that is generated by a FIS Maven archetype or by a FIS template in OpenShift has a standard layout that uses a BOM file and defines the versions of certain required plug-ins. It is recommended that you stick to this standard layout in your own applications, because this makes it much easier to patch and upgrade your application’s dependencies.

10.2.1. Update Dependencies in a Spring Boot Application

The following code fragment shows the standard layout of a POM file for a Spring Boot application in FIS, highlighting some important property settings:

Notice how the dependencyManagement section of the POM references the fabric8-project-bom-camel-spring-boot BOM file, which defines the versions for all of the Spring Boot Maven artifacts in FIS. When it comes to patching or upgrading the application, the following version settings are important:

fabric8.version

Defines the version of the fabric8-project-bom-camel-spring-boot BOM file. By updating the BOM version to a particular patch version, you are effectively updating all of the FIS Maven dependencies as well.

fabric8.maven.plugin.version

Defines the version of the fabric8-maven-plugin plug-in. The fabric8-maven-plugin plug-in is tightly integrated with each version of FIS. Hence, whenever you patch or upgrade FIS, it is essential to upgrade the fabric8-maven-plugin plug-in to the matching version.

10.2.2. Update Dependencies in a Karaf Application

The following code fragment shows the standard layout of a POM file for a Karaf application in FIS, highlighting some important property settings:

Notice how the dependencyManagement section of the POM references the fabric8-project-bom-fuse-karaf BOM file, which defines the versions for all of the Karaf Maven artifacts in FIS. When it comes to patching or upgrading the application, the following version settings are important:

fabric8.version

Defines the version of the fabric8-project-bom-fuse-karaf BOM file. By updating the BOM version to a particular patch version, you are effectively updating all of the FIS Maven dependencies as well.

fabric8.maven.plugin.version

Defines the version of the fabric8-maven-plugin plug-in. The fabric8-maven-plugin plug-in is tightly integrated with each version of FIS. Hence, whenever you patch or upgrade FIS, it is essential to upgrade the fabric8-maven-plugin plug-in to the matching version.

10.2.3. Available BOM Versions

The following table shows the BOM versions corresponding to different patch releases of JBoss Fuse.

Table 10.1. JBoss Fuse Releases and Corresponding BOM Version

JBoss Fuse Release

BOM Version

Fabric8 Maven Plug-In Version

JBoss Fuse 6.3.0 GA

2.2.170.redhat-000004

3.1.80.redhat-000004

JBoss Fuse 6.3.0 Roll Up 1

2.2.170.redhat-000010

3.1.80.redhat-000010

JBoss Fuse 6.3.0 Roll Up 2

2.2.170.redhat-000013

3.1.80.redhat-000013

JBoss Fuse 6.3.0 Roll Up 4

2.2.170.redhat-000019

3.1.80.redhat-000019

JBoss Fuse 6.3.0 Roll Up 5

2.2.170.redhat-000022

3.1.80.redhat-000022

JBoss Fuse 6.3.0 Roll Up 6

2.2.170.redhat-000023

3.1.80.redhat-000023

JBoss Fuse 6.3.0 Roll Up 7

2.2.170.redhat-000024

3.1.80.redhat-000024

JBoss Fuse 6.3.0 Roll Up 8

2.2.170.redhat-000030

3.1.80.redhat-000030

To upgrade your application POM to a specific JBoss Fuse patch release, set the fabric8.version property to the corresponding BOM version, and the fabric8.maven.plugin.version property to the corresponding Fabric8 Maven plug-in version.

To discover the latest available versions, you can check the Red Hat Maven repository directly:

The BASEURL points at the relevant branch of the Git repository that stores the quickstart templates and it will always have the latest templates at HEAD. So, any time you run the preceding commands, you will get the latest version of the templates.

10.4. Patch the FIS Images

The FIS images are updated independently of the main Fuse product. If any patches are required for the FIS images, updated images will be made available on the standard FIS image streams and the updated images can be downloaded from the Red Hat image registry, registry.access.redhat.com. Fuse Integration Services provides the following image streams (identified by their OpenShift image stream name):

fis-java-openshift

fis-karaf-openshift

These image streams are normally installed on the openshift project on the OpenShift server. To check the status of the FIS images on OpenShift, login to OpenShift as an administrator and enter the following command:

You can also configure your Fuse applications so that a rebuild is automatically triggered whenever a new FIS image becomes available. For details, see the section Setting Deployment Triggers in the OpenShift Container Platform 3.5 Developer Guide.

Appendix A. Spring Boot Maven Plug-In

A.1. Spring Boot Maven Plugin Overview

This appendix describes the Spring Boot Maven Plugin. It provides the Spring Boot support in Maven and allows you to package the executable jar or war archives and run an application in-place.

A.2. Goals

The Spring Boot Plugin includes the following goals:

spring-boot:run runs your Spring Boot application.

spring-boot:repackage repackages your .jar and .war files to be executable.

spring-boot:start and spring-boot:stop both are used to manage the lifecycle of your Spring Boot application.

spring-boot:build-info generates build information that can be used by the Actuator.

Appendix B. Karaf Maven Plug-In

B.1. Using the karaf-maven-plugin

The karaf-maven-plugin enables you to create a Karaf server assembly, which is a microservices style packaging of a Karaf container. That is, the finished assembly contains all of the essential components of a Karaf installation (for example, including the contents of the etc/, data/, lib, and system directories), but stripped down to the bare minimum required to run your application.

B.2. Karaf Maven Plug-In Goals

The following Karaf Maven plug-in goals are relevant to building server assemblies in Fuse Integration Services (FIS):

B.2.1. karaf:assembly Goal

The recommended way to create a Karaf server assembly is to use the karaf:assembly goal provided by the karaf-maven-plugin. This assembles a server from the Maven dependencies in the project pom.

B.2.1.1. Example of a Maven Assembly

You can create a Karaf server assembly using the karaf:assembly goal provided by the karaf-maven-plugin. This goal assembles a microservices style server assembly from the Maven dependencies in the project POM. In a FIS project, it is recommended that you bind the karaf:assembly goal to the Maven install phase. The project uses bundle packaging and the project itself gets installed into the Karaf container by listing it inside the startupBundles element. The following example displays the typical Maven configuration in a FIS quickstart:

B.2.1.2. Parameters

The karaf:assembly goal supports the following parameters:

startupFeature

This will result in the feature bundles being listed in startup.properties at the appropriate start level and the bundles being copied into the system/ internal repository. You can use <feature-name> or <feature-name>/<feature-version> formats.

bootFeature

This will result in the feature name being added to boot-features in the features service configuration file and all the bundles in the feature copied into the system/ internal repository. You can use <feature-name> or <feature-name>/<feature-version> formats.

installedFeature

This will result in all the bundles in the feature being installed in the system/ internal repository. Therefore, at run time the feature may be installed without access to external repositories. You can use <feature-name> or <feature-name>/<feature-version> formats.

libraries

The plugin accepts the libraries element, which can have one or more library child elements that specify a library URL. For example:

Appendix C. Fabric8 Maven Plug-In

C.1. Overview

With the help of fabric8-maven-plugin, you can deploy your Java applications to OpenShift. It provides tight integration with Maven and benefits from the build configuration already provided. This plug-in focuses on the following tasks:

Building Docker-formatted images and,

Creating OpenShift resource descriptors

It can be configured very flexibly and supports multiple configuration models for creating:

A Zero-Config setup, which allows for a quick ramp-up with some opinionated defaults. Or for more advanced requirements,

An XML configuration, which provides additional configuration options that can be added to the pom.xml file.

C.1.1. Building Images

The fabric8:build goal is for creating Docker-formatted images containing an application. It is easy to include build artifacts and their dependencies in these images. This plugin uses the assembly descriptor format from the maven-assembly-plugin to specify the content which will be added to the image.

C.1.2. Kubernetes and OpenShift Resources

Kubernetes and OpenShift resource descriptors can be created with fabric8:resource. These files are packaged within the Maven artifacts and can be deployed to a running orchestration platform with fabric8:apply.

C.1.3. Configuration

There are three levels of configuration:

Zero-Config mode helps to make some very useful decisions based on what is present in the pom.xml file like, what base image to use or which ports to expose. It is used for starting up things and for keeping quickstart applications small and tidy.

XML plugin configuration mode is similar to what docker-maven-plugin provides. It allows for type safe configuration with IDE support, but only a subset of possible resource descriptor features is provided.

Kubernetes and OpenShift resource fragments are user provided YAML files that can be enriched by the plugin. This allows expert users to use plain configuration file with all their capabilities, but also to add project specific build information and avoid boilerplate code.

C.4. Generators

The Fabric8 Maven plug-in provides generator components, which have the capability to build images automatically for specific kinds of application. In the case of Fuse Integration Services, the following generator types are supported:

Depending on certain characteristics of the application project, the generator framework auto-detects what type of build is required and invokes the appropriate generator component.

Note

The open source community version of the Fabric8 Maven plug-in provides additional generator types, but these are not supported in the Fuse Integration Services product.

C.4.1. Zero-Configuration

Generators do not require any configuration. They are enabled by default and run automatically with default settings when the Fabric8 Maven plug-in is invoked. But you can easily customize the configuration of the generators, if you need to.

C.4.2. Modes for Specifying the Base Image

In Fuse Integration Services, the base image for an application build can either be a Java image (for Spring Boot applications) or a Karaf image (for Karaf applications) The Fabric8 Maven plug-in supports the following modes for specifying the base image:

istag

(Default) The image stream mode works by selecting a tagged image from an OpenShift image stream. In this case, the base image is specified in the following format:

<namespace>/<image-stream-name>:<tag>

Where <namespace> is the name of the OpenShift project where the image streams are defined (normally, openshift), <image-stream-name> is the name of the image stream, and <tag> identifies a particular image in the stream (or tracks the latest image in the stream).

docker

The docker mode works by selecting a particular Docker-formatted image directly from an image registry. Because the base image is obtained directly from a remote registry, an image stream is not required. In this case, the base image is specified in the following format:

[<registry-location-url>/]<image-namespace>/<image-name>:<tag>

Where the image specifier optionally begins with the URL location of the remote image registry <registry-location-url>, followed by the image namespace <image-namespace>, the image name <image-name>, and the tag, <tag>.

Note

The default behaviour of the open source community version of fabric8-maven-plugin is different from the Red Hat productized version (for example, in the community version, the default mode is docker).

C.4.2.1. Default Values for istag Mode

When istag mode is selected (which is the default), the Fabric8 Maven plug-in uses the following default image specifiers to select the Fuse images (formatted as <namespace>/<image-stream-name>:<tag>):

openshift/fis-java-openshift:2.0
openshift/fis-karaf-openshift:2.0

Note

In the Fuse image streams, the individual images are tagged with build numbers — for example, 2.0-1, 2.0-2, and so on. The 2.0 tag is configured to always track the latest image.

C.4.2.2. Default Values for docker Mode

When docker mode is selected, and assuming that the OpenShift environment is configured to access registry.access.redhat.com, the Fabric8 Maven plug-in uses the following default image specifiers to select the Fuse images (formatted as <image-namespace>/<image-name>:<tag>):

C.4.2.3. Mode Configuration for Spring Boot Applications

To customize the mode configuration and base image location used for building Spring Boot applications, add a configuration element to the fabric8-maven-plugin configuration in your application’s pom.xml file, in the following format:

C.4.2.4. Mode Configuration for Karaf Applications

To customize the mode configuration and base image location used for building Karaf applications, add a configuration element to the fabric8-maven-plugin configuration in your application’s pom.xml file, in the following format:

C.4.2.5. Specifying the Mode on the Command Line

As an alternative to customizing the mode configuration directly in the pom.xml file, you can pass the mode settings directly to the mvn command, by adding the following property settings to the command line invocation:

//build from Docker-formatted image directly, registry location, image name or tag are subject to change if desirable
-Dfabric8.generator.fromMode=docker
-Dfabric8.generator.from=<custom-registry-location-url>/<image-namespace>/<image-name>:<tag>
//to use ImageStream from different namespace
-Dfabric8.generator.fromMode=istag //istag is default
-Dfabric8.generator.from=<namespace>/<image-stream-name>:<tag>

C.4.3. Spring Boot

The Spring Boot generator gets activated when it finds a spring-boot-maven-plugin plug-in in the pom.xml file. The generated container port is read from the server.port property application.properties, defaulting to 8080 if it is not found.

In addition to the common generator options, this generator can be configured with the following options:

Table C.3. Spring-Boot configuration options

Element

Description

Default

assemblyRef

If a reference to an assembly is given, then this is used without trying to detect the artifacts to include.

targetDir

Directory within the generated image where the detected artefacts are put. Change this only if the base image is changed too.

/deployments

jolokiaPort

Port of the Jolokia agent exposed by the base image. Set this to 0 if you don’t want to expose the Jolokia port.

8778

mainClass

Main class to call. If not specified, the generator searches for the main class as follows. First, a check is performed to detect a fat-jar. Next, the target/classes directory is scanned to look for a single class with a main method. If none is found or more than one is found, the generator does nothing.

webPort

Port to expose as service, which is supposed to be the port of a web application. Set this to 0 if you don’t want to expose a port.

8080

color

If set, force the use of color in the Spring Boot console output.

The generator adds Kubernetes liveness and readiness probes pointing to either the management or server port as read from the application.properties. If the server.ssl.key-store property is set in application.properties then the probes are automatically set to use https.

C.4.4. Karaf

The Karaf generator gets activated when it finds a karaf-maven-plugin plug-in in the pom.xml file.

In addition to the common generator options, this generator can be configured with the following options:

Table C.4. Karaf configuration options

Element

Description

Default

baseDir

Directory within the generated image where the detected artifacts are put. Change this only if the base image is changed too.

/deployments

jolokiaPort

Port of the Jolokia agent exposed by the base image. Set this to 0 if you don’t want to expose the Jolokia port.

8778

mainClass

Main class to call. If not specified, the generator searches for the main class as follows. First, a check is performed to detect a fat-jar. Next, the target/classes directory is scanned to look for a single class with a main method. If none is found or more than one is found, the generator does nothing.

user

User and/or group under which the files should be added. The user must already exist in the base image. It has the general format <user>[:<group>[:<run-user>]]`. The user and group can be given either as numeric user- and group-id or as names. The group id is optional.

jboss:jboss:jboss

webPort

Port to expose as service, which is supposed to be the port of a web application. Set this to 0 if you don’t want to expose a port.

D.3. Running the Goal on any Maven Project

You can also run the validate goal on any Maven project, without adding the Plugin to the pom.xml file. You need to specify the Plugin, using its fully qualified name. For example, to run the goal on the camel-example-cdi plugin from Apache Camel, execute the following:

D.4. Options

The maven plugin supports the following options which you can configure from the command line (use -D syntax), or defined in the pom.xml file in the <configuration> tag.

D.4.1. Table

Parameter

Default Value

Description

downloadVersion

true

Whether to allow downloading Camel catalog version from the internet. This is needed, if the project uses a different Camel version than this plugin is using by default.

failOnError

false

Whether to fail if invalid Camel endpoints was found. By default the plugin logs the errors at WARN level

logUnparseable

false

Whether to log endpoint URIs which was un-parsable and therefore not possible to validate

includeJava

true

Whether to include Java files to be validated for invalid Camel endpoints

includeXML

true

Whether to include XML files to be validated for invalid Camel endpoints

includeTest

false

Whether to include test source code

includes

-

To filter the names of java and xml files to only include files matching any of the given list of patterns (wildcard and regular expression). Multiple values can be separated by comma.

excludes

-

To filter the names of java and xml files to exclude files matching any of the given list of patterns (wildcard and regular expression). Multiple values can be separated by comma.

ignoreUnknownComponent

true

Whether to ignore unknown components

ignoreIncapable

true

Whether to ignore incapable of parsing the endpoint uri

ignoreLenientProperties

true

Whether to ignore components that uses lenient properties. When this is true, then the uri validation is stricter but would fail on properties that are not part of the component but in the uri because of using lenient properties. For example using the HTTP components to provide query parameters in the endpoint uri.

showAll

false

Whether to show all endpoints and simple expressions (both invalid and valid).

D.5. Validating include test

If you have a Maven project, then you can run the plugin to validate the endpoints in the unit test source code as well. You can pass in the options using -D style as shown:

Appendix E. JVM Environment Variables

E.1. S2I Java Builder Image with OpenJDK 8

In this S2I builder image for Java builds, you can run results directly without using any other application server. It is suitable for microservices with a flat classpath (including fat jars).

You can configure java options when using the FIS images. All the options for the FIS images are set by using environment variables as given below. For the JVM options, you can use the environment variable JAVA_OPTIONS. Also, provide JAVA_ARGS for the arguments which are given through to the application.

E.2. S2I Karaf Builder Image with OpenJDK 8

This image can be used with OpenShift’s Source To Image in order to build Karaf4 custom assembly based maven projects.

ARTIFACT_DIR: Path to target/ where the jar files are created for multi-module builds. These are added to ${MAVEN_ARGS}.

ARTIFACT_COPY_ARGS: Arguments to use when copying artifacts from the output directory to the application directory. Useful to specify which artifacts will be part of the image.

MAVEN_CLEAR_REPO: If set, remove the Maven repository after you build the artifact. This is useful for keeping the application image small, however, It prevents the incremental builds. The default value is false.

E.3.2. Run Time

You can use the following environment variables to influence the run script:

JAVA_APP_DIR: the directory where the application resides. All paths in your application are relative to the directory.

JAVA_LIB_DIR: this directory contains the Java jar files as well an optional classpath file, which holds the classpath. Either as a single line classpath (colon separated) or with jar files listed line-by-line. However, If not set, then JAVA_LIB_DIR is the same as JAVA_APP_DIR directory.

JAVA_OPTIONS: options to add when calling java.

JAVA_MAX_MEM_RATIO: It is used when no -Xmx option is given in JAVA_OPTIONS. This is used to calculate a default maximal heap Memory based on a containers restriction. If used in a Docker container without any memory constraints for the container, then this option has no effect.

JAVA_MAX_CORE: It restricts manually the number of cores available, which is used for calculating certain defaults like the number of garbage collector threads. If set to 0, you cannot perform the base JVM tuning based on the number of cores.

JAVA_DIAGNOSTICS: Set this to fetch some diagnostics information, to standard out when things are happening.

JAVA_MAIN_CLASS: A main class to use as an argument for java. When you give this environment variable, all jar files in $JAVA_APP_DIR directory are added to the classpath and in the $JAVA_LIB_DIR directory.

JAVA_APP_JAR: A jar file with an appropriate manifest, so that you can start with java -jar. However, if it is not provided, then $JAVA_MAIN_CLASS is set. In all cases, this jar file is added to the classpath.

JAVA_APP_NAME: Name to use for the process.

JAVA_CLASSPATH: the classpath to use. If not given, the startup script checks for a file ${JAVA_APP_DIR}/classpath and use its content as classpath. If this file doesn’t exists, then all jars in the application directory are added under (classes:${JAVA_APP_DIR}/*).

JAVA_DEBUG: If set, remote debugging will be switched on.

JAVA_DEBUG_PORT: Port used for remote debugging. The default value is 5005.

E.3.3. Jolokia Configuration

You can use the following environment variables in Jolokia:

AB_JOLOKIA_OFF: If set, disables the activation of Jolokia (echos an empty value). By default, Jolokia is enabled.

AB_JOLOKIA_CONFIG: If set, uses the file (including path) as Jolokia JVM agent properties. However, If not set, the /opt/jolokia/etc/jolokia.properties will be created using the settings.

AB_JOLOKIA_HOST: Host address to bind (Default value is 0.0.0.0)

AB_JOLOKIA_PORT: Port to use (Default value is 8778)

AB_JOLOKIA_USER: User for basic authentication. By default, it is jolokia

AB_JOLOKIA_PASSWORD: Password for basic authentication. By default, authentication is switched off

AB_JOLOKIA_PASSWORD_RANDOM: Generates a value and is written in /opt/jolokia/etc/jolokia.pw file

AB_JOLOKIA_HTTPS: Switch on secure communication with HTTPS. By default, self-signed server certificates are generated, if no serverCert configuration is given in AB_JOLOKIA_OPTS

AB_JOLOKIA_ID: Agent ID to use

AB_JOLOKIA_DISCOVERY_ENABLED: Enables the Jolokia discovery. The default value is false.

AB_JOLOKIA_OPTS: Additional options to be appended to the agent configuration. Options are given in the format key=value

Here is an option for integration with various environments:

AB_JOLOKIA_AUTH_OPENSHIFT: Switch on client authentication for OpenShift TSL communication. Ensure that the value of this parameter must be present in a client certificate. If you enable this parameter, it will automatically switch Jolokia into HTTPS communication mode. The default CA cert is set to /var/run/secrets/kubernetes.io/serviceaccount/ca.crt

Application arguments can be provided by setting the variable JAVA_ARGS to the corresponding value.

Appendix F. Tuning JVMs to Run in Linux Containers

F.1. Overview

Java processes running inside the Linux container do not behave as expected when you allow JVM ergonomics to set the default values for the garbage collector, heap size, and runtime compiler. When you execute a Java application without any tuning parameters — for example, java -jar mypplication-fat.jar — the JVM automatically sets several parameters based on the host limits, not the container limits.

This section provides information about the packaging of Java applications inside a Linux container so that the container’s limits are taken into consideration for calculating default values.

F.2. Tuning the JVM

The current generation of Java JVMs are not container-aware, so they allocate resources based on the size of the physical host, not on the size of the container. For example, a JVM normally sets the maximum heap size to be 1/4 of the physical memory on a host. On a large host machine, this value can easily exceed the memory limit defined for a container and, if the container limit is exceeded at run time, OpenShift will kill the application.

To solve this issue, you can use the FIS base image that is capable of understanding that a Java JVM runs inside a restricted container and automatically adjusts the maximum heap size, if not done manually. It provides a solution of setting the maximum memory limit and the core limit on the JVM that runs your application.

F.3. Default Behaviour of FIS Images

In Fuse Integration Services, the base image for an application build can either be a Java image (for Spring Boot applications) or a Karaf image (for Karaf applications). FIS images execute a script that reads the container limits and uses these limits as the basis for allocating resources. By default, the script allocates the following resources to the JVM:

50% of the container memory limit,

50% of the container core limit.

F.4. Custom Tuning of FIS images

The script sets the CONTAINER_MAX_MEMORY and CONTAINER_CORE_LIMIT environment variables, which can be read by a custom application to tune its internal resources. Additionally, you can specify the following runtime environment variables that enable you to customize the settings on the JVM that runs your application:

JAVA_OPTIONS

JAVA_MAX_MEM_RATIO

To customize the limits explicitly, you can set the JAVA_MAX_MEM_RATIO environment variable by editing the deployment.yml file, in your Maven project. For example:

Legal Notice

The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.