Public | Automated Build

Last pushed: 10 days ago
Short Description
jBPM Workbench Showcase
Full Description

jBPM Workbench Showcase Docker image

JBoss jBPM Workbench Showcase Docker image.

Table of contents

  • Introduction
  • Usage
  • Users and roles
  • Logging
  • GIT internal repository access
  • Persistent configuration
  • Experimenting
  • Notes
  • Release notes

Introduction

The image contains:

  • JBoss Wildfly 10.0.0.Final
  • jBPM Workbench 6.5.0.Final
  • jBPM Dashbuilder 6.5.0.Final

This image inherits from jboss/jbpm-workbench:latest and provides some additional configurations:

  • Default users and roles
  • Some examples
  • Single Sign On configuration for jBPM Workbench and jBPM Dashbuilder

This is a ready to run Docker image for jBPM Workbench. Just run it and try the jBPM Workbench!

Usage

To run a container:

docker run -p 8080:8080 -p 8001:8001 -d --name jbpm-workbench jboss/jbpm-workbench-showcase:latest

Once container and web applications started, you can navigate to it using one of the users described in section Users and roles, using the following URL:

    http://localhost:8080/jbpm-console

Please note that in this image the examples and demos are enabled by default, so you need external connection to GitHub.
If your container runs without internet connection, please set KIE_DEMO the environment variable to value false as:

docker run -p 8080:8080 -p 8001:8001 -e KIE_DEMO=false -d --name jbpm-workbench jboss/jbpm-workbench-showcase:latest

Users and roles

This showcase image contains default users and roles:

USER        PASSWORD    ROLE
*************************************************
admin       admin       admin,analyst,kiemgmt
krisv       krisv       admin,analyst
john        john        analyst,Accounting,PM
mary        mary        analyst,HR
sales-rep   sales-rep   analyst,sales
katy        katy        analyst,HR
jack        jack        analyst,IT
salaboy     salaboy     admin,analyst,IT,HR,Accounting

Logging

You can see all logs generated by the standalone binary running:

docker logs [-f] <container_id>

You can attach the container by running:

docker attach <container_id>

The jBPM Workbench web application logs can be found inside the container at path:

/opt/jboss/wildfly/standalone/log/server.log

Example:
sudo nsenter -t $(docker inspect --format '{{ .State.Pid }}' $(docker ps -lq)) -m -u -i -n -p -w
-bash-4.2# tail -f /opt/jboss/wildfly/standalone/log/server.log

GIT internal repository access

The workbench stores all the project artifacts in an internal GIT repository. By default, the protocol available for accessing the GIT repository is SSH at port 8001.

This showcase image provides some examples at the uf-playground repository, that you can clone it by running:

git clone ssh://admin@localhost:8001/uf-playground

By default, the GIT repository is created when the application starts for first time at $WORKING_DIR/.niogit, considering $WORKING_DIR as the current directory where the application server is started.

You can specify a custom repository location by setting the following Java system property to your target file system directory:

    -Dorg.uberfire.nio.git.dir=/home/youruser/some/path

NOTE: This directory can be shared with your docker host and with another containers using shared volumes when running the container, if you need so.

If necessary you can make GIT repositories available from outside localhost using the following Java system property:

    -org.uberfire.nio.git.ssh.host=0.0.0.0

You can set this Java system properties permanent by adding the following lines in your standalone-full.xml file as:

    <system-properties>
      <!-- Custom repository location. -->
      <property name="org.uberfire.nio.git.dir" value="/home/youruser/some/path"/>
      <!-- Make GIT repositories available from outside localhost. -->
      <property name="org.uberfire.nio.git.ssh.host" value="0.0.0.0"/>
    </system-properties>

NOTE: Users and password for ssh access are the same that for the web application users defined at the realm files.

Persistent configuration

As Docker defaults, once a container has been removed, the data within that container is removed as well.

At first glance this should not imply any issues as the assets authored on your workbench containers are not lost if you don't remove the container, you can stop and restart it
as many times as you need, and have different kie execution server container's consuming those assets, the problem comes if you need to remove and create new workbench containers.

In the case you need to create a persistent environment you can use an approach based on Docker Volumes. Here are two ways of doing it.

Using default GIT root directory

By default, the internal GIT root directory for the workbench container is located at /opt/jboss/wildfly/bin/.niogit, so you can make this directory persistent in your docker host by running the container using a docker shared volumne as:

# Use -v <SOURCE_FS_PATH>:<CONTAINER_FS_PATH>
docker run -p 8080:8080 -p 8001:8001 -v /home/myuser/wb_git:/opt/jboss/wildfly/bin/.niogit -d --name jbpm-workbench jboss/jbpm-workbench-showcase:latest

As the above command, now your workbench git repository will be persistent at your host filesystem's path /home/myuser/wb_git. So if you remove this container and start a new one just by using same shared volume, you'll find all your assets on the new workbench's container as well.

Using custom GIT root directory

Considering this showcase module as the base for this example, follow the next steps:

1.- Edit the standalone-full-jbpm.xml and change the default GIT repository location for your favourite one:

<system-properties>
    <property name="org.kie.demo" value="${org.kie.demo:true}"/>
    <property name="org.kie.example" value="${org.kie.example:true}"/>
    <property name="designerdataobjects" value="${designerdataobjects:false}"/>

    <!-- Make GIT repositories root directory at /opt/jboss/wildfly/mygit. -->
    <property name="org.uberfire.nio.git.dir" value="/opt/jboss/wildfly/mygit"/>

    <!-- Make GIT repositories available from outside localhost. -->
    <property name="org.uberfire.nio.git.ssh.host" value="0.0.0.0"/>
</system-properties>

2.- Edit the Dockerfile and add these lines:

USER root
RUN mkdir -p $JBOSS_HOME/mygit
RUN chown jboss:jboss $JBOSS_HOME/mygit
USER jboss

3.- Create your Docker image:

docker build --rm -t jboss/jbpm-workbench-showcase:MY_TAG

At this point, the default GIT root directory for the workbench will be located inside the Docker container at /opt/jboss/wildfly/mygit. So all your assets will be stored in the underlying git structure on this path.

In order to keep the git repositories between different containers you can just start the container by configuring a new host volume as:

# Use -v <SOURCE_FS_PATH>:<CONTAINER_FS_PATH>
docker run -p 8080:8080 -p 8001:8001 -v /home/myuser/wb_git:/opt/jboss/wildfly/mygit -d --name jbpm-workbench jboss/jbpm-workbench-showcase:MY_TAG

As the above command, now your workbench git repository will be persistent at your local filesystem path /home/myuser/wb_git. So if you remove this container and start a new one just by using same shared volume, you'll find all your assets on the new workbench's container as well.

Experimenting

To spin up a shell in one of the containers try:

docker run -t -i -p 8080:8080 -p 8001:8001 jboss/jbpm-workbench-showcase:latest /bin/bash

You can then noodle around the container and run stuff & look at files etc.

Notes

  • The context path for jBPM Workbench web application is jbpm-console and the context path for jBPM Dashbuilder web application is dashbuilder
  • jBPM Workbench version is 6.5.0.Final
  • jBPM Workbench requires running JBoss Wildfly using the full server profile
  • Internet connection required if using examples and demos (active by default)
  • No support for clustering
  • Use of embedded H2 database server by default
  • No support for Wildfly domain mode, just standalone mode
  • This image is not intended to be run on cloud environments such as RedHat OpenShift or Amazon EC2, as it does not meet all the requirements.
  • Please give us your feedback or report a issue at Drools Setup or Drools Usage Google groups.

Release notes

6.5.0.Final

Docker Pull Command
Owner
jboss
Source Repository

Comments (10)
mbiarnes
a day ago

Hi Laura,

This site is for Docker images of jboss BxMS and related problems
of download, installation etc.
The problem you encoutered is related to working of workbench, this issue is more technically.
I would suggest you address your requests Drools Setup or Drools Usage Google groups

lauradp
5 days ago

Hi,
I'm having trouble in deploying my processes after destroynin and creating the jbpm container again:
Caused by: org.apache.maven.model.building.ModelBuildingException: 1 problem was encountered while building the effective model for @@@@@_DEPLOYMENTID@@@@@
[FATAL] Non-resolvable parent POM: Failure to transfer @@@@@_PROJECTNAME@@@@@:pom:1.0.0-SNAPSHOT from http://@@@@@_HOSTNAME_@@@@@:8080/jbpm-console/maven2/ was cached in the local repository, resolution will not be reattempted until the update interval of guvnor-m2-repo has elapsed or updates are forced. Original error: Could not transfer artifact RSI-LTA:LTA-EnterpriseBPM:pom:1.0.0-SNAPSHOT from/to guvnor-m2-repo (http://@@@@@_HOSTNAME_@@@@@:9080/jbpm-console/maven2/): Unauthorized (401) @ line 5, column 11

How can I solve this issue?

mbiarnes
2 months ago

Hi lauradp,

It means that those Docker community images just have the necessary files and configurations to be able to run in a docker environment, but they do not follow any concrete constraints that most of the cloud environments, such as OpenShift, require in order to perform the provisioning and deployment of the applications into the different nodes. For example, these Docker images provide basics scripts to resolve the network addresses and ports to allow the communication between containers, but on an OpenShift environment, all these network configurations should be provided by a kubernetes controller, so the images must provide some concrete registration methods and will use different discovery methods as well. Same for file system and its clustering, etc. And note that probably those configurations can be different when using an AWS service or using other vendors.
Summarizing, those Docker community images can be used for showcasing the applications and used as base images as well for being extended and customized in order to work on a concrete cloud environment, but it cannot be expected to be working if deploying an OpenShift or AWS environment for example.

mbiarnes
2 months ago

Hi gcampoverde,
you have to modify the standalone-full-jbpm.xml in your Dockerimage. (Look for <datasources>).
Pls. look at https://docs.jboss.org/author/display/WFLY10/DataSource+configuration since you have first to install the right driver as module on WF

lauradp
2 months ago

Thanks @gcampoverde!

What does "This image is not intended to be run on cloud environments such as RedHat OpenShift or Amazon EC2, as it does not meet all the requirements." mean? which requirements are not met by this image?

gcampoverde
2 months ago

Hi lauradp,

You have to put this in your command line:

docker exec -u 0 -i -t <IDCONTAINER> bash

Regards,

Gcampoverde

lauradp
3 months ago

Hi,
is there any way for logging in as root?

Thanks in advance for your help.

gcampoverde
4 months ago

Hi,

I can't use my PostgreSQL datasource. I have done the next steps:

1.- I have created the module.xml file
2.- I have configured the datasource on Wildfly as well
3.- I couln't found the application's JPA descriptor ( context.xml ) and for that reason I can't specify the hibernate dialect for PostgreSQL
4.- If I erase the H2 datasource I get an error related with a connection pool ExampleDS.

What I have to do to get my PostgreSQL connection working with JBPM instead of H2.

Thanks in advance for your help.

romartin
a year ago

Hi @biswars,

These docker showcase images are just working for H2. If you want to do so, you have to customize the image.

To add the MySQL support basically the main updates to be done are:

  • Add the Wildfly module for the MySQL jdbc client
  • Configure the datasource on Wildfly as well
  • Configure the application's JPA descriptor ( context.xml ) and specify the hibernate dialect for MySQL
  • If you change the datasource default name "example", you have to configure JPA for it as well.

You can find some examples here -> https://github.com/droolsjbpm/kie-docker-ci-images/tree/master/kie-wb

Here you can find some docker customized images that are used for our CI environment and add support for MySQL and Postgres as well, so you can try to give it a look as an example.

Hope this helps

biswars
a year ago

How can I use this with MySQL DB instead of H2 ? If jBPM was installed using jbpm-installer, then build.properties and db/jbpm-persistence-JPA2.xml can be changed to use MySQL. Can the same be done here in the dockerfile ?