Skip to content

Automating Red Hat AMQ 7 High Availability Deployment with Ansible

Red Hat AMQ 7 Full Deployment Automation?

In this article I’m going to provide you with the automation necessary to deploy Red Hat AMQ 7 from 0 to hero with a flexible design using Ansible. However, before going to the details, let’s check some concepts!

Why Messaging and Concurrency?

Concurrent systems often contains a combination of asynchronous and synchronous processing services. Therefore there is a strong incentive for system programmers to use asynchrony to improve performance.

In addition, asynchronous programs are generally more efficient, because services can be mapped directly onto asynchrony mechanisms, such as Message Brokers.

On the other hand, there is a strong incentive for application developers to use synchronous processing to simplify their programming effort. However, synchronous programs are usually less complex, because certain services can be constrained to run a well-defined points in the processing sequence.

There are two different goals to consider when specifying a software architecture that executes services both synchronously and asynchronously.

However, we will leave the overall approach to the Half-Sync/Half-Async pattern to a different post.

What is important here is that an asynchronous design enhance performance to process lower-layer services, such as short-lived protocol handlers.

In our case, a middleware capable to fulfill such pattern is the Red Hat JBoss AMQ.

Red Hat JBoss AMQ

In our current scenario, I would like to present Red Hat AMQ 7 (AMQ 7). Such middleware provides fast, lightweight, and secure messaging for Internet-scale applications.

In addition, AMQ 7 components use industry-standard message protocols and support a wide range of programming languages and operating environments. Also it gives you the strong foundation you need to build modern distributed applications.

For instance, you can share message processing load grouping together multiple instances of AMQ 7 brokers. On top of that, you can configure the brokers not only to manage its own messages and connections but to connect to other brokers with “cluster bridges”. After that your brokers can send topology information, such as queues and consumers, as well as load balancing messages.

What are we doing here?

Above all, you can create with the project below a complex design installation for AMQ 7.

Before that, here below is the previous article using bash:

so it can be easily used everywhere. The second is using Ansible and is presented below!

Do you have an architecture design?

This solution provides you the capabilities to create a high available AMQ 7 cluster using a specific type of persistence for HA.

AMQ 7 supports two different strategies for backing up a server: shared store and replication.

This is a project that automates the AMQ 7 shared store high availability installation.

However, the automation is so flexible that you can have from simple designs to a more complex HA topology.

https://github.com/AbrahamArellano/redhat_amq7_ansible_playbook

Single Broker Instance

AMQ_7_Single_Broker_InstanceThis example features multiple JMS clients interacting with a single broker to demonstrate execution of basic send and receive messaging patterns.

Symmetric Broker Cluster

AMQ_7_Symmetric_Broker_Cluster

This example features a cluster of 3 broker instances, all grouped together to allow for internal load balancing.

Fault-Tolerant Broker Cluster

This example features 3 master and 3 slave broker instances, all clustered within the same group, allowing automatic master/slave pairing and failover.

How to start with the deployment?

This project provides the automation necessary to deploy Red Hat AMQ using Ansible and is fairly straightforward and provides you a way to deploy based on templating.

Step 1: Download the project

Git clone this repository to [GIT_SOURCE].

Step 2: Let’s understand what we do have here?

Once you download the project you will see 2 Ansible playbooks:

  • amq-install.yaml: deploys AMQ
  • amq-uninstall.yaml: undeploy AMQ
  • roles: location of the AMQ templates

Step 2.1: Templates to configure

Within the amq-install role you will find templates that describes the main components to be adjusted:

Step 2.2: Understanding relevant templates to configure

Security Configuration
<management-address>activemq.management</management-address> 
<management-notification-address> 
  jms.topic.notificationsTopic
</management-notification-address>

<security-settings>
    <security-setting match="#"> 
        <permission type="createNonDurableQueue" roles="admin"/>
        <permission type="deleteNonDurableQueue" roles="admin"/>
        <permission type="createDurableQueue" roles="admin"/>
        <permission type="deleteDurableQueue" roles="admin"/>
        <permission type="createAddress" roles="admin"/>
        <permission type="deleteAddress" roles="admin"/>
        <permission type="consume" roles="admin"/>
        <permission type="browse" roles="admin"/>
        <permission type="send" roles="admin"/>
        <permission type="manage" roles="admin"/>
    </security-setting>
    <security-setting match="jms.queue.activemq.management"> 
        <permission type="consume" roles="admin"/>
        <permission type="send" roles="admin"/>
        <permission type="manage" roles="admin"/>
    </security-setting>
</security-settings>
Dead Letter and Expiry Queue Configuration

AMQ Broker includes a default address that establishes a default set of configuration settings to be applied to any created queue or topic.

Additionally, the default configuration defines two queues: DLQ (Dead Letter Queue) which handles messages that arrive with no known destination, and Expiry Queue holds messages that lived past their expiration and therefore should not be routed to their original destination.

<address-settings>
    <address-setting match="activemq.management#"> 1
        <dead-letter-address>DLQ</dead-letter-address>
        <expiry-address>ExpiryQueue</expiry-address>
        <redelivery-delay>0</redelivery-delay>
        <max-size-bytes>-1</max-size-bytes>
        <message-counter-history-day-limit>10</message-counter-history-day-limit>
        <address-full-policy>PAGE</address-full-policy>
        <auto-create-queues>true</auto-create-queues>
        <auto-create-addresses>true</auto-create-addresses>
        <auto-create-jms-queues>true</auto-create-jms-queues>
        <auto-create-jms-topics>true</auto-create-jms-topics>
    </address-setting>
    <address-setting match="#"> 2
        <dead-letter-address>DLQ</dead-letter-address>
        <expiry-address>ExpiryQueue</expiry-address>
        <redelivery-delay>0</redelivery-delay>
        <max-size-bytes>-1</max-size-bytes>
        <message-counter-history-day-limit>10</message-counter-history-day-limit>
        <address-full-policy>PAGE</address-full-policy>
        <auto-create-queues>true</auto-create-queues>
        <auto-create-addresses>true</auto-create-addresses>
        <auto-create-jms-queues>true</auto-create-jms-queues>
        <auto-create-jms-topics>true</auto-create-jms-topics>
    </address-setting>
</address-settings>

Step 2.3: Playbook configuration

# Queues
amq_broker_disable_destination_autocreate: False
amq_broker_queues: queue.in,queue.out

# Nio option
amq_broker_nio: True

# TLS
amq_broker_tls: True
amq_broker_tls_keystore: "{{ amq_home }}/certs/broker.keystore"
amq_broker_tls_keystore_password: "{{ vault_amq_broker_tls_keystore_password }}"
amq_broker_tls_keystore_dest: "{{ amq_broker_dir }}/{{ amq_broker_name }}/etc/broker.keystore"


# Mutual authentication (requires TLS)
amq_broker_tls_mutual_authentication: False
amq_broker_tls_truststore: "{{ amq_home }}/certs/broker.truststore"
amq_broker_tls_truststore_password: "{{ vault_amq_broker_tls_truststore_password }}"
amq_broker_tls_truststore_dest: "{{ amq_broker_dir }}/{{ amq_broker_name }}/etc/broker.truststore"

# Protocol disablement
amq_broker_disable_amqp_protocol: False
amq_broker_disable_hornetq_protocol: False
amq_broker_disable_mqtt_protocol: False
amq_broker_disable_stomp_protocol: False

# Patch AMQ
amq_broker_patch: False

Within the playbook you can configure:

  • Define queues
  • Enable NIO
  • Security settings
  • Protocol configuration
  • Enabling Patching

Step 3: How to execute this?

Run Installation

sudo ansible-playbook -vvv --vault-id @prompt -i ../redhat_amq7/inventories/ amq-install.yaml

Run Uninstall

sudo ansible-playbook -vvv --vault-id @prompt -i ../redhat_amq7/inventories/ amq-uninstall.yaml

Conclusion

In conclusion, I presented a clean deployment process of Red Hat AMQ 7 using Ansible, in order to optimize the integration experience.

Above all, Understanding when to use a middleware like AMQ is key for a successful design and in a following article we will talk about the considerations about asynchronous communication.

Stay tuned!

Tags:

1 thought on “Automating Red Hat AMQ 7 High Availability Deployment with Ansible”

  1. Pingback: Automating AMQ 7 High Availability Deployment

Leave a Reply

Your email address will not be published. Required fields are marked *