Chapter 9. Example Workflow: Deploying Red Hat JBoss BRMS Application on Openshift with Webhooks Enabled for Automatic Application Updates

This workflow details how to configure Red Hat JBoss BRMS, GitHub, and OpenShift to have your configuration changes automatically push to OpenShift. This example covers:

Note

Make sure you are running Red Hat JBoss BRMS on your local machine.

9.1. Forking the Repository

  1. Visit the Decision Server example page while you are logged in to GitHub.

  2. Fork the repository.

    You are redirected to your new fork.

  3. Copy the HTTPS clone URL for your fork.

This Decision Server example receives a name, and if it matches the user name specified as master in the rules file, then the user is recognized and greeted as the master user. If the name does not match, then the user is recognized as an intruder.

9.2. Cloning the Repository

From the Red Hat JBoss BRMS workbench:

  1. From the File Explorer, click Authoring → Administration.
  2. Click Repositories → Clone repository.
  3. Type the Repository Name decision-services.
  4. Select an Organizational Unit.
  5. Type in the HTTPS clone URL of your forked Git repository: https://github.com/<Your_Github_Username>/decisionserver.git

  6. Click Clone.

    Once cloned, the repository displays the commit history.

9.3. Creating a Hook to Automate GitHub Updates

To make Red Hat JBoss BRMS automatically update your GitHub repository any time a file in this project changes:

Note

You must have SSH key access configured for GitHub before following these steps.

  1. From the command line, navigate into the /.niogit directory in the project you forked earlier: 

    $ cd EAPHOME/bin/.niogit/decision-services.git

    The path above is the default, which may differ depending on where the workbench has been configured to store its data. This location is set using the org.uberfire.nio.git.dir system property.

  2. Set the remote URL for this project: 

    $ git remote set-url origin git@github.com:/decisionserver

  3. Navigate into the hooks directory: 

    $ cd hooks

  4. Create a simple post-commit file: 

    $ touch post-commit

  5. Edit the file and type the following: 

    #!/bin/sh

git push origin master
  6. Save your changes and exit the file.

  7. Change the permissions on the file to allow Red Hat JBoss BRMS the access it requires: 

    $ chmod 777 post-commit

    The hook is now configured, meaning that any change to the files in this Red Hat JBoss BRMS project will automatically update your forked decisionserver GitHub repository.

9.4. Modifying the Example Decision Server Rules

From the Red Hat JBoss BRMS workbench:

  1. Click Authoring → Project authoring.

  2. Under DRL, click to load the HelloRules.drl file: 

    package org.openshift.quickstarts.decisionserver.hellorules

query "get greeting"()
    greeting : Greeting()
end

rule "greet master"
    when
        person : Person( name == "john")
    then
        String salutation = "Hello " + person.getName() + "! What can I help you with today?";
        insert(new Greeting(salutation));
end
rule "greet strangers"
    when
        person : Person(name != "john")
    then
        String salutation = "Hey there " + person.getName() + ". I don't think I know you yet!";
        insert(new Greeting (salutation));
end
  3. Modify the lines with john by replacing them with your user name.

  4. Click Save, type a check in comment, and click Save again.

    The hook you created earlier will automatically update your forked GitHub repository with these saved changes.

9.5. Creating a Decision Service on OpenShift

From the OpenShift web console:

  1. Log in using the username and password recommended to you by your administrator.
  2. To create a new project, click New Project.
  3. Type a unique name, display name, and description for the new project.

  4. Click Create.

    The web console’s welcome screen loads.

  5. Click Add to Project.
  6. In the Filter by keyword field, start typing decision to see the available xPaaS templates related to Decision Server.
  7. Click the decisionserver63-basic-s2i template.
  8. In the Parameters section, change the KIE_SERVER_PASSWORD to the password to access the KIE Server REST or JMS interface.

  9. Change the SOURCE_REPOSITORY_URL to the Git source URI for your forked repository. For example: 

    https://github.com/<your_github_username>/decisionserver.git
  10. Change the SOURCE_REPOSITORY_REF to master.
  11. Change the CONTEXT_DIR to greeting.
  12. Scroll to the bottom of the page and click Create.

While your application builds, you can click View Log from the Overview page to see the build progress.

9.6. Improving Build Time Using Maven

Follow the details in this OpenShift blog post to configure the Maven proxy, which improves the build times of java builds on OpenShift.

9.7. Integrating the Maven Proxy

To change the build configuration so that it uses the Maven proxy, complete the following from the OpenShift web console:

  1. Click Browse → Builds → <your_application>
  2. Click the three vertical dots next to Start Build and then click Edit (Raw).

  3. Add the MAVEN_MIRROR_URL environment variable below the KIE_CONTAINER_DEPLOYMENT variable: 

    strategy
 sourceStrategy:
  env:
   -
    name: KIE_CONTAINER_DEPLOYMENT
    value: 'HelloRulesContainer=org.openshift.quickstarts:decisionserver-hellorules:1.2.0.Final'
   -
    name: MAVEN_MIRROR_URL
    value: 'http://nexus-ci.cloudapps.bos.openshift3roadshow.com/content/groups/public/'

    The value for MAVEN_MIRROR_URL can be found in Maven by viewing the repositories, then copying the path for the Public Repositories group.

  4. Click Save.
  5. Click the Configuration tab of your build to verify that MAVEN_MIRROR_URL is actively listed under Environment Variables.

Now that you have Maven configured for this OpenShift project, the build process will be shorter for all future builds. This is because subsequent builds only need to download updated files, which are then combined with the previously loaded files.

9.8. Test the Service

After integrating the Maven proxy, you can test that service is working and see how quickly the build process completes compared to previous builds. From the OpenShift web console:

  1. Click Browse → Builds → <your_application>
  2. Click Start Build.
  3. In the list at the bottom of the screen, click the new build you just started.
  4. Click the Logs tab, then click Follow.

  5. Verify that the new build is using the new Maven proxy to download locally by finding the line in the log that references Downloading. For example: 

    I0130 12:32:25.664594     1 sti.go:492] Downloading: http://nexus-ci.cloudapps.openshift.com/content/groups/public/org/kie/kie-maven-plugin/6.3.0.Final-redhat-5/kie-maven-plugin-6.3.0.Final-redhat-5.pom
  6. When the build is complete, you can check the new build time against the previous build by clicking Browse → Builds → <your_application> and viewing the summary. The newest build will be considerably shorter with the Maven proxy in use.
  7. Click Overview to see the status of the pod. It displays a Not Ready status while it is checked with readiness probes.
  8. Click Browse → Pods to follow its progress. The status of the Containers Ready column will change to 1/1 when the pod has passed the readiness probes.

9.9. Configure the OpenShift Webhook

From the OpenShift web console:

  1. Click the Browse tab, then click Builds.
  2. Click your build name, then click the Configuration tab.
  3. Click the copy icon next to GitHub webhook URL to copy your webhook payload URL.
  4. Navigate to your forked repository on GitHub, then click Settings.
  5. Click Webhooks & Services.
  6. Click Add webhook.
  7. Paste your webhook URL into the Payload URL field.
  8. Click Disable SSL verification, then confirm it in the pop-up window.
  9. Click Add webhook to save.

Github pings the OpenShift server to ensure communication is successful. A green check mark next to the webhook URL signifies that it is configured correctly. Hover your cursor over the check mark to view the status of the last ping.

The next time you push a code change to your forked repository, your application will automatically rebuild.

9.10. Testing the Configured Hooks

From the Red Hat JBoss BRMS workbench:

  1. Load the HelloRules.drl file: 

    package org.openshift.quickstarts.decisionserver.hellorules

query "get greeting"()
    greeting : Greeting()
end

rule "greet master"
    when
        person : Person( name == "john")
    then
        String salutation = "Hello " + person.getName() + "! What can I help you with today?";
        insert(new Greeting(salutation));
end
rule "greet strangers"
    when
        person : Person(name != "john")
    then
        String salutation = "Hey there " + person.getName() + ". I don't think I know you yet!";
        insert(new Greeting (salutation));
end
  2. Modify the String salutation line by changing At your service my master to something else.
  3. Click Save, type a check-in comment, and click Save again.

The hook that you created earlier updates your forked GitHub repository, and then the GitHub webhook triggers a new build in OpenShift.

With this configuration, you need only save your configuration changes on the Red Hat JBoss BRMS workbench, and the rest of the process is completely automated.