Getting started with Red Hat Fuse Development Environment

It’s been a while that I blogged. Last year I changed employer and at my new job I focus on Red Hat Fuse. Red Hat Fuse is, in short, the cloud-native integration platform or toolkit if you will. It’s based on Apache Camel and Apache MQ.

The last few months I spent to get familiar with Fuse-Camel and OpenShift, and still learning. Although I’ve a lot to investigate still, in the next months I hope to write a lot about Fuse and relating technology.

Code Ready Studio Splash

The first thing you’ll need to work with a language and or framework is a development environment. For Red Hat Fuse, the IDE of choice is Code Ready Studio. Besides an IDE, you’ll probably also need tools like SoapUI, Maven, Git, Postman maybe, etc., etc. And along the way you might find other tools you’ll need. For instance, I wanted to have a proper editor for XSDs, WSDLs and XSLTs. Eclipse, which is the base IDE of Code Ready Studio, does not have proper designers for that. So, I ended up installing Oracle SOA QuickStart (JDeveloper), as I’m familiar with that. (Ssshhh, don’t tell anybody.)

For several years I create scripts for every repetitive job I do, which also function as a form documentation on how I did it. Vagrant is my tool of choice to generate VMs for my environments. I wrote about that here for instance. This article is about combining Vagrant, MobaXterm and Total Commander to create a seamless desktop. I also wrote about splitting up different provisioners to install several tools.

For my new development environment I wanted to make it more professional. I wanted the following:

1. Create VMs based upon a box in the Vagrant Cloud. I wrote about that last year.
2. The VMs needed to be based on CentOS instead of Oracle Linux. Some of the Linux preparation scripts needed to be adapted.
3. Extract the install scripts as much as possible from the Vagrant file.
4. Move all settings like memory, number of CPUs, location of the VM files, shared folder locations, etc. to a separate settings file. This allows me to adapt the vagrant file with additional provisioners and have it committed and pushed, while a colleague who has different settings is still able to update/pull it.
5. Be able to pick and choose which provisioners needed to be run. So, I could add different IDEs while my colleague does not need to have it installed.
6. Have readme.md descriptions that describe where to download and place the installers.

Project in GitHub

I committed the new vagrant project in my GitHub vagrant repo. I already described most of the requirements and features above in the readme. I’ll try not to repeat the obvious here.

Settings

I moved the settings of the vagrant project to the settings.yml. The settings are referenced in the Vagrantfile. Vagrant is built in Ruby and a Vagrant file is in essence just a Ruby script file. So, I used the second answer in this Stackoverflow question. You can load a yaml file as follows:

The settings file is then manifested as a multi-dimensional array. Every level in the yaml file is a dimension. For example, the memory settings can be referenced as:

In the same manner I created a provisioners.yml file. Every provisioner in the Vagrant file is represented in this file. With options like the user as which the provisioner should run and if the provisioner should run once for default installers, never for optional provisioners, or always for provisioners that should run every time. For the amq provisioner, there is a separate start option, that refers to a separate provisioner that is run every time the VM is started.

The options in the provisioners.yml file are referenced as follows:

Vagrantfile snippets to configure and run provisioners

In this snippet you see that I declare 3 variables (lines 4–6) to get the values from the provisioners. The last line is the actual provisioner. It uses these variables to define the run property and the path. In this example snippet in the path a reference to the runAs.sh (line 1) script is used. This is a very simple script that replaces the duplicated scriptlets I had in my previous Vagrantfiles. It echos that it runs a script for the product in the first argument, the actual script is provided as the second argument, and the user as who the script must be run is the third parameter.

You can (re-)run a provisioner using the command “vagrant provision --provision-with _provisioner-name_” as described at the bottom of the readme of the project. However, you could also set the run property of the particular provisioner in the provisioners.yml file temporarily to “allways”, before doing a “vagrant up” (which means that the vm should be down first).

Readme’s and Installers

In the current version of the readme the supported installers used in the provisioners are described. Some of them download the needed installers from the particular repository, as needed. For instance the maven provisioner does this. For others you’ll need to download them up front. This is because you need to have an account on the website, or you need to acknowledge an end user license agreement. For instance, Code Ready Studio should be downloaded. From the readme you can click to the readme of the install binaries. For instance to that for the Redhat installers. In this readme a link is given to the download page for the installer. The provisioners expect the downloaded installer in the same location as that Readme file in your local Github clone. Also with the exact same name mentioned in the description. If you want to use another version of the product, you would need to change the particular install script.

For instance, the Oracle JDK 8 is needed for SoapUI 5.5.0 (I didn’t get the current 5.6.0 version working with the newer Java, one thing to sort out.) Also if you would want to use Oracle JDeveloper. The current version describes to install Oracle JDK 8 update 261. However, the current update is 271. To use that you would need to update the install script accordingly. (Be careful there is another java install script here. That one is deprecated.)

Conclusion

This article is long enough, with a high TLDR-level (Too long didn’t read). So, I’ll end here. Most of it is quite self-describing. You might want to read my previous articles on Vagrant to learn how I got this far. And to get an explanation to other peculiarities that I learned in the last few years.

If you’ll be able to set this up yourself (you might want to fork my repo first), then you’ll have an extendable development environment for Fuse integrations and other fancy technologies, that can be destroyed, build up and extended at any time.

Next on my list of articles-to-write: how to create a SOAP Service with Red Hat Fuse and with as much XML and as little Java as possible.