Red Hat AMQ using 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 contain 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 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 enhances performance to process lower-layer services, such as short-lived protocol handlers.

In our case, a middleware capable of fulfilling such a 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 their 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.

Why Ansible?

When it comes to automating complex middleware deployments like Red Hat AMQ 7, choosing the right automation tool is crucial. Ansible stands out as an exceptional choice for several compelling reasons.

Ansible is an open-source automation platform that can manage configurations, deploy applications, and orchestrate complex IT workflows. Unlike other automation tools, Ansible is agentless, meaning you don’t need to install any additional software on your target servers – it works directly over SSH, making it lightweight and secure.

What advantages do I have with Ansible?

For AMQ 7 deployments specifically, Ansible offers several key advantages:

Declarative Configuration: Ansible uses YAML syntax, which allows you to describe your AMQ 7 configuration in a human-readable format. This means your broker configurations, security settings, and cluster topologies can be version-controlled and easily reviewed.
Idempotency: Ansible’s idempotent nature ensures that running the same playbook multiple times will result in the same outcome. This is particularly important when managing AMQ 7 clusters, where consistency across nodes is critical.
Role-based Organization: Through Ansible roles (as shown in our project structure), we can modularize different aspects of the AMQ 7 deployment. This makes it easy to reuse common configurations across different environments while maintaining environment-specific variations.
Template Support: Ansible’s powerful templating engine (using Jinja2) allows us to maintain dynamic configurations. This is especially useful for managing different AMQ 7 topologies – from single broker instances to complex master/slave configurations.
Integration with Red Hat Products: Being a Red Hat product itself, Ansible has excellent integration with other Red Hat products, including AMQ 7. This means better support, tested modules, and documented best practices.
Vault Integration: For securing sensitive information like SSL certificates and credentials, Ansible Vault provides built-in encryption capabilities, essential for managing AMQ 7 security configurations.
Inventory Management: Ansible’s inventory system makes it simple to manage different environments (development, staging, production) and their specific configurations, perfect for maintaining multiple AMQ 7 clusters.

For instance, in our deployment automation, Ansible allows us to:

Manage complex configurations through templates
Handle TLS certificates and security settings securely
Configure different broker topologies using the same base playbooks
Ensure consistent deployments across all environments
Manage protocol settings and queue configurations systematically

The combination of these features makes Ansible an ideal choice for automating AMQ 7 deployments, especially in enterprise environments where reliability, security, and maintainability are paramount.

Remember, automation isn’t just about saving time – it’s about creating reproducible, reliable, and maintainable infrastructure. Ansible helps achieve this while keeping the automation code itself clean and manageable.

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:

Automating AMQ 7 High Availability Deployment

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 highly 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

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

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

AMQ 7 on AWS: A Cloud Perspective

While this article focuses on automating AMQ 7 deployment using Ansible, it’s worth noting that this automation can be extended to AWS environments, opening new possibilities for cloud-native messaging infrastructure.

Running AMQ 7 on AWS allows you to leverage cloud benefits while maintaining the robust messaging capabilities you need. A typical architecture might include:

Multi-AZ deployment using AWS Availability Zones for high availability
Amazon EFS for shared storage configuration in HA setups
Network Load Balancers for client connection management
Auto Scaling Groups for automatic broker recovery
Private subnets in a VPC for enhanced security

Here’s a basic example of how AMQ 7 master/slave pairs could be deployed across availability zones:

The same Ansible automation we’ve discussed can be adapted for AWS using dynamic inventories and AWS-specific configurations. This provides a pathway to cloud adoption while maintaining the benefits of automated, consistent deployments.

Stay tuned for a future article where we’ll dive deep into AMQ 7 on AWS architecture patterns and cloud-specific considerations!

Conclusion

In this article, I presented a streamlined approach to deploying Red Hat AMQ 7 using Ansible automation, offering a path to modernize your messaging infrastructure deployment process. The solution provides flexibility to implement various topologies, from single broker instances to complex fault-tolerant clusters, all through automated, repeatable deployments.

The combination of AMQ 7’s robust messaging capabilities with Ansible’s automation power addresses several critical enterprise needs:

Consistent, error-free deployments across environments
Flexible high-availability configurations
Streamlined security implementation
Reduced operational overhead
Version-controlled infrastructure

Looking ahead, this automation foundation becomes even more valuable as organizations move toward cloud adoption, whether on AWS or in hybrid environments. The ability to automate complex middleware deployments is no longer just a convenience—it’s a crucial capability for maintaining agility and reliability in modern IT operations.

Above all, understanding when and how to implement messaging middleware like AMQ 7 is key to a successful architecture. In the following article, we’ll dive deeper into asynchronous communication patterns and examine how these automated deployments can be extended to cloud environments.

Stay tuned for more insights into messaging architecture, cloud deployment patterns, and automation best practices!

Automating Red Hat AMQ 7 High Availability Deployment with Ansible