Most integration/service platform projects start small but need to ensure high availability requirements and be scalable to handle growing workloads. This article shows how to use Ansible to automatically provision servers with JBoss Fuse and JBoss ActiveMQ instances to get a highly available service and messaging platform.
What does a new born reliable Integration Platform look like? It needs at least 4 machines and a shared storage (NFSV4 or GFS2) as described in the following paragraphs.
Here we will run 2 couples of failover configured A-MQ instances. We link them together in a network of brokers. In the nominal case, A-MQ A instance should be active on one machine and A-MQ B instance should be active on the other machine. Their failover instances are placed symmetrically on the other machine.
This configuration has several advantages :
One might argue that dedicating machines to A-MQ is an overkill at the beginning. Why not just put them also on the same machines as the JBoss Fuse engines? Well that can be true if messaging is not that highly demanding in our use cases, but limitations will appear quickly when trying to scale the messaging infrastructure once the platform grows. In fact we would like to be able to scale your messaging infrastructure independently from the application services hosted on JBoss Fuse instances. In other words, if we do not allocate resources to A-MQ from the beginning, our new born might be crippled and not be able to grow in the future.
Ansible is a powerful tool to automate IT infrastructure provisioning, application deployment, configuration management and continuous delivery. It is an agentless system meaning that we do not have to install anything on the target machines. The only thing that is needed is a standard ssh access.
To get the cluster up and running in little time, I have created an Ansible role that automates the following tasks :
Below are the default variables to run the role.
In order to run it, we must create a playbook and redefine those variables for Fuse machines and each A-MQ host. You can find an example play book in the test folder.
├── ansible.cfg ├── distrib -> folder to put packages in │ ├── jboss-a-mq-6.3.0.redhat-187.zip │ ├── jboss-fuse-karaf-6.3.0.redhat-187.zip │ └── readme.txt ├── group_vars │ ├── all.yml -> all the default variables │ ├── amq.yml -> all defaults related to A-MQ machines │ └── fuse.yml -> all defailts related to Fuse machines ├── host_vars -> specific configuration to hosts. │ ├── amq-a-master.yml │ ├── amq-a-slave.yml │ ├── amq-b-master.yml │ └── amq-b-slave.yml ├── inventory └── playbook.yml
So now the question is how do we grow this new born infrastructure? For JBoss Fuse instances, it is very straightforward, just add machines to the inventory and Ansible will take care of setting up this machine.
For Active MQ, we need to think first about the topology of our network. Depending on the use cases this might differ.
I have written a previous post detailing the concentrator topology for IOT purposes. It also explains how to scale down a network of brokers properly.
Scalable Network of Active MQ brokers for handing massive connections
If you need your integration platform to grow larger and be highly elastic, consider using PaaS solutions such as Openshift. I would say that as a general rule of thumb if you exceed 5 machines in your integration cluster, it can already be interesting to consider the Openshift iPaaS approach.
You can learn the basics about Ansible go to https://www.ansible.com/get-started.
At some point you might want to scale down your integration platform, you can go ahead and make an Ansible role to automate down scaling. Furthermore you could write Ansible scripts to automate application deployments to Fuse containers.
Originally published February 13, 2017
Latest update February 13, 2017
Related posts :