Forem: Pelisse Romain

Ansible Middleware : Automation of JBoss Web Server (JWS)

Pelisse Romain — Tue, 18 Jun 2024 15:00:00 +0000

In a previous article, we discussed the importance of Ansible from a Middleware perspective and why making Middleware a first-class citizen in the Ansible ecosystem is crucial. In this post, we’ll explore the technical details of utilizing Ansible for automating a Middleware solution.

We’ll focus on one of the most used middleware software: Apache Tomcat. Or rather, the Red Hat supported version of it known as JBoss Web Server (JWS).

Let’s start by defining what exactly JWS is, in case you are not familiar with this specific product. JWS combines a web server (Apache HTTPD), a Java servlet engine (Apache Tomcat), and load balancing components (mod_jk and mod_cluster) to help them scale. All of those elements are supported by Red Hat. In this article, we’ll focus only on the Java servlet engine (Apache Tomcat) as many of the challenges brought up by its automation are typical of other middleware software (such as JBoss EAP, JBoss Data Grid or RH SSO).

What are we trying to achieve?

Our goal here is to automate the deployment of this Java servlet engine, using Ansible. This may seem like a simple endeavor. However it does entail a few tasks and operations to be performed to achieve a proper result.

First, we need to configure the target’s operating system. This includes creating a user and associate group to run JWS as well as the integration into systemd, so that the newly spawned server can be managed by the host’s operating system. JWS also requires that dependencies of the servlet’s engine (mostly a Java Virtual Machine in the proper version) are installed.

In the next step, we'll configure JWS itself, which includes specifying which interface it needs to be bound against, defining which ports it will listen to, and so on. We may also customize the Java server during this step, like enabling some features (ex: SSL) or disable some other ones (for instance, removing the demo webapps shipped with the archive).

At this point, one could think we are done and that the server is ready. Because Apache Tomcat is an application server, however we also want to automate the deployment of its workloads. Which means we need to ensure the webapps its hosting are appropriately deployed.

With all this preparation work finished, we should be able to start the systemd service we configured earlier and double-check that the server, and its webapps, are functioning properly and as expected. This includes that all webapps are indeed deployed, accessible and operational. Here again, Ansible will help us in this validation step.

If you are familiar with Ansible primitives and built-in modules, you know it’s quite a lot of work to automate all of these requirements. Fortunately, most of this work has been implemented and is ready for use inside the Ansible JWS Collection.

An important note here: the four steps we’ve laid out above for JWS actually apply to most, if not all, middleware software (at least, the ones provided and supported by Red Hat). Some steps would be easier or more challenging to automate, depending on which one, but in essence, all will have the same kinds of requirements.

One last thing before we jump into the technical bits: if you want to reproduce the automation we describe in this article, keep in mind that the target’s host is running RHEL 9 and uses Ansible 2.15.9 or above (with Python 3.9.18).

Installing the JWS Collection

Installing the collection dedicated to Red Hat JWS uses the ansible-galaxy command like any other collection. As it is provided by Red Hat, however, it requires to use (instead or on top of Ansible Galaxy) the Red Hat Automation Hub. This can be achieved by adding the repository to the ansible.cfg file:

[defaults]
...

[galaxy]
server_list = automation_hub, galaxy

[galaxy_server.galaxy]
url=https://galaxy.ansible.com/

[galaxy_server.automation_hub]
url=https://cloud.redhat.com/api/automation-hub/

auth_url=https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token

token=<insert-your-token-here>

More information on how to use Red Hat Automation Hub are available here. To obtain the Red Hat Automation Hub token, follow this documentation.

Once this is setup, ansible-galaxycan install the collection:

# ansible-galaxy collection install redhat.jws
Starting galaxy collection install process
Process install dependency map
Starting collection install process
Downloading https://console.redhat.com/api/automation-hub/v3/plugin/ansible/content/published/collections/artifacts/redhat-jws-2.0.0.tar.gz to /root/.ansible/tmp/ansible-local-91vvby1md6/tmpjzlxwbz6/redhat-jws-2.0.0-mj2vji8g
Installing 'redhat.jws:2.0.0' to '/root/.ansible/collections/ansible_collections/redhat/jws'
Downloading https://console.redhat.com/api/automation-hub/v3/plugin/ansible/content/published/collections/artifacts/redhat-runtimes_common-1.2.1.tar.gz to /root/.ansible/tmp/ansible-local-91vvby1md6/tmpjzlxwbz6/redhat-runtimes_common-1.2.1-rwk2o0dw
redhat.jws:2.0.0 was installed successfully
Downloading https://console.redhat.com/api/automation-hub/v3/plugin/ansible/content/published/collections/artifacts/ansible-posix-1.5.4.tar.gz to /root/.ansible/tmp/ansible-local-91vvby1md6/tmpjzlxwbz6/ansible-posix-1.5.4-adyme9vq
Installing 'redhat.runtimes_common:1.2.1' to '/root/.ansible/collections/ansible_collections/redhat/runtimes_common'
redhat.runtimes_common:1.2.1 was installed successfully
Installing 'ansible.posix:1.5.4' to '/root/.ansible/collections/ansible_collections/ansible/posix'
Downloading https://console.redhat.com/api/automation-hub/v3/plugin/ansible/content/published/collections/artifacts/redhat-rhel_system_roles-1.23.0.tar.gz to /root/.ansible/tmp/ansible-local-91vvby1md6/tmpjzlxwbz6/redhat-rhel_system_roles-1.23.0-3gm1eccc
ansible.posix:1.5.4 was installed successfully
Installing 'redhat.rhel_system_roles:1.23.0' to '/root/.ansible/collections/ansible_collections/redhat/rhel_system_roles'
redhat.rhel_system_roles:1.23.0 was installed successfully

Note: Ansible Galaxy comes with dependency management, which means that it fetches any required dependencies for this collection.

Writing the playbook

We can now start working on our playbook itself. We’ll begin by setting it up to use the collection we just installed and we’ll add content incrementally from there.
Testing the collection

Before incorporating any tasks to our playbook, we’ll add the dependency to the Ansible collection for JWS to confirm that the installation was successful:

---
- name: "JBoss Web Server installation and configuration"
  hosts: "all"
  become: true
  collections:
    - redhat.jws

This playbook will not perform any tasks on the target system. It is only designed to verify that the collection is indeed recognized by Ansible:

# ansible-playbook -i inventory jws_dev_to.yml 

PLAY [JBoss Web Server installation and configuration] ***************************************************************************************************************************************

TASK [Gathering Facts] ***********************************************************************************************************************************************************************
ok: [localhost]

PLAY RECAP ***********************************************************************************************************************************************************************************
localhost                  : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Automatically retrieve archive from Red Hat Customer Portal

Now that the Ansible collection for JWS is properly installed and accessible from our playbook, let’s provide the service account information, so that the engine can automatically download the JWS binary files provided by Red Hat.

For the collection to be able to download the JWS archive from the Red Hat Customer Portal, we need to supply the credentials associated with a Red Hat service account. One way to provide those values parameters is to create a service_account.yml which can be passed to Ansible as an extra source of variables:

---
rhn_username: <service_account_id>
rhn_password: <service_account_password>

Note: As those variables contain secrets, it is highly recommended to use Ansible Vault to protect its content. Using this feature of the automation tool, however, is out of the scope of this article.

Now, we have everything in place to run our playbook and install JWS on the target. But before doing so, we will see how to configure the software to match the requirement of our use case.

Ensure Java environment is properly configured

JWS is based on Apache Tomcat which means it’s Java software that requires a Java runtime to be executed. So, our automation needs to ensure that this environment is readily available on the target system.

Here again, we just need to add variables to our playbook and the Ansible Collection for JWS will take care of everything. It will check that the appropriate JVM is available or install if it’s missing:

---
- name: "JBoss Web Server installation and configuration"
  hosts: "all"
  become: yes
  vars:
    jws_java_version: 17
  collections:
    – redhat.jws
  roles:
    - jws

Note: that this feature is only available for system belonging to the RedHat family.

$ ansible -m setup localhost | grep family
        "ansible_os_family": "RedHat",

If the target system is not part of the RedHat family, the installation of the JVM must be added to the pre_tasks section of the playbook.

Preparing the target system

As we mentioned at the beginning of this article, before decompressing the archive and starting the server there are a few configurations that need to be done on target’s system. One of them is to ensure that the necessary user and group have been created.

The Ansible collection for JWS comes with default values for both, but often, those would be required to be replaced:

---
- name: "JBoss Web Server installation and configuration"
  hosts: "all"
  become: yes
  vars:
    [...]
    jws_user: java_servlet_engine
    jws_group: java_web_server
    [...]
  collections:
    - redhat.jws
  roles:
    - jws
  pre_tasks:
    [...]
  tasks:

Once we execute this playbook, on top of fetching the archive from the website, it ensures that the appropriate group and user exists, before decompressing the servlet’s engine files into the defined TOMCAT_HOME. And upon that, Ansible will guarantee the requested JVM is available on the target host.

It’s already pretty nice to have all of this plumbing work done for us, but we can go further. With just a little more configuration, Ansible Collection for JWS can set up a systemd service to run JWS.

Integration with systemd service

The Ansible collection for JWS comes with a playbook and default templates to help set up JWS as a systemd service. Therefore, all that it’s needed to automate this part of our deployment is again to add a variable to our playbook:

---
- name: "JBoss Web Server installation and configuration"
  hosts: "all"
  become: yes
  vars:
    [...]
        jws_systemd_enabled: True
    jws_service_name: tomcat
    [...]
  collections:
    - redhat.jws
  roles:
[...]

Note: that this feature is only available for target systems belonging to the RedHat family.

After a successful execution of the playbook, you can easily confirm that the Java server is running as a systemd service:

# systemctl status tomcat
● tomcat.service - Jboss Web Server
     Loaded: loaded (/usr/lib/systemd/system/tomcat.service; enabled; preset: disabled)
     Active: active (running) since Tue 2024-06-18 14:50:11 UTC; 52s ago
   Main PID: 3365 (java)
      Tasks: 44 (limit: 1638)
     Memory: 116.3M
        CPU: 4.170s
     CGroup: /system.slice/tomcat.service
             └─3365 /etc/alternatives/jre_17/bin/java -Djava.util.logging.config.file=/opt/jws-6.0/tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogM>

Jun 18 14:50:11 a09c3523b337 systemd[1]: Started Jboss Web Server.
Jun 18 14:50:11 a09c3523b337 systemd-service.sh[3357]: Tomcat started.
Jun 18 14:50:11 a09c3523b337 systemd-service.sh[3356]: Tomcat runs with PID: 3365

Deploy a web application

If we come back to our list of requirements we established at the beginning of this article, we can see that the Ansible collection for JWS already took care of most of them. There is only one part of the deployment left to automate: configuring server workloads.

With a different middleware solution than JWS, this part can be complex. Fortunately for us, one of the qualities of the Java server is its simplicity. Deploying webapps only necessitates placing their package file (. war) in the appropriate directory prior to the server start. That’s all!

This can be easily achieved using Ansible primitives, but the collection still helps our automation by supplying a handler to restart the server is a webapp is provisioned for the first time (or updated):

- name: "Deploy demo webapp"
  ansible.builtin.get_url:
    url: 'https://people.redhat.com/~rpelisse/info-1.0.war'
    dest: "{{ tomcat_home }}/webapps/info.war"
  notify:
    - "Restart Tomcat service"

Validation

Our Java server is now deployed and running, its workloads also. All that remains to be implemented is the validation part. Firing up a systemd service is good, checking that it is working is better!

To achieve this, we’ll add a couple tasks to the post_tasks: section of our playbook:

Check that the systemd service is indeed running;
A wait: task to ensure the Java server HTTP port is accessible (no need to go further if this fails);
A get_uri: tasks to get the root path (/) of the server followed by another to check the webapp availability (/info) — availability of the first one not confirming the one of the second one.

[...]
tasks:
[...]
post_tasks:
   - name: "Populate service facts"
    ansible.builtin.service_facts:

   - name: "Check if service is running"
    ansible.builtin.assert:
        that:
        - ansible_facts is defined
        - ansible_facts.services is defined
        - ansible_facts.services['tomcat.service'] is defined
        - ansible_facts.services['tomcat.service']['state'] is defined
        - ansible_facts.services['tomcat.service']['state'] == 'running'
    - name: "Sleep for {{ tomcat_sleep }} seconds to let Tomcat starts "
    ansible.builtin.wait_for:
        timeout: "{{ tomcat_sleep }}"

    - name: " Checks that server is running"
      ansible.builtin.uri:
        url: "http://localhost:8080{{ item.path }}"
        status_code: {{ item.status }}
        return_content: no
     loop:
       { path: '/', status: 404 }
       { path: '/info’, status: 200 }

Conclusion

Keeping the content of the previous article in mind, this demonstration hopefully shows how much the Ansible collection for JWS eases the automation around the Java server. Thanks to it, using Ansible, we fully automated its installation. It has been almost as simple and natural to write this playbook as it would have been for an instance of Nginx. With all this content available, we truly have made JWS a first-class citizen in the Ansible ecosystem.

Automate JBoss Web Server 6 deployment with the Red Hat Ansible Certified Content Collection for JWS

Pelisse Romain — Thu, 15 Feb 2024 17:00:00 +0000

When it comes to Java web servers, Apache Tomcat remains a strong favorite. Some of these instances have been containerized over the years, but many still run in the traditional setup of a Linux-based virtual machine or even on bare metal.

Red Hat JBoss Web Server (JWS) combines the servlet engine (Apache Tomcat) with the web server (Apache HTTPD), and modules for load balancing (mod_jk and mod_cluster). Ansible is an automation tool that provides a suite of tools for managing an enterprise at scale.

In this article, we will illustrate how Ansible can be used to completely automate the deployment of a JBoss Web Server 6 instance on a Red Hat Enterprise Linux 9 server. This automation encompasses the following tasks:

Retrieve the archive containing the JBoss Web Server from the Red Hat Customer Portal and install the files on the system.
Configure the Red Hat Enterprise Linux (RHEL) operating system including the users, groups, and the required setup files to enable JBoss Web Server as a systemd service.
Ensure the required Java Virtual Machine is installed
Fine-tune the configuration of the JBoss Web Server server, such as binding it to the appropriate interface and port.
Deploy web applications along with enabling and starting the JBoss Web Server as a [systemd](https://www.freedesktop.org/wiki/Software/systemd/) service.
Perform a health check to ensure that the deployed application is accessible.

Our Ansible playbook will fully automates all of those operations, so no manual steps will be required.

Preparing the target environment

Prerequisites

Before we start with the automation work, we need to specify the target environment. In this case, you'll be using Red Hat Enterprise Linux 9 with Python 3.9. We'll use this configuration on both the Ansible control node (where Ansible is executed), which will be referred to from now on as controller, and the Ansible target (the system being configured).

The controller for this demonstration has the following requirements:

$ cat /etc/redhat-release
Red Hat Enterprise Linux release 9.3 (Plow)

Verifying the version of Ansible is pretty straightforward, and it also provides the needed information on the Python version used to run it:

$  ansible --version
ansible [core 2.14.9]
  config file = /work/ansible.cfg
  configured module search path = ['/root/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.9/site-packages/ansible
  ansible collection location = /root/.ansible/collections:/usr/share/ansible/collections
  executable location = /usr/bin/ansible
  python version = 3.9.18 (main, Jan  4 2024, 00:00:00) [GCC 11.4.1 20230605 (Red Hat 11.4.1-2)] (/usr/bin/python3)
  jinja version = 3.1.2
  libyaml = True

Note: The procedure in this article may not execute successfully if you use a different Python version or target operating system.

Installing the Red Hat Ansible Certified Content Collection

Once you have Red Hat Enterprise Linux 9 set up and Ansible 2.14 ready to go, you need to install the Red Hat Ansible Certified Content Collection 2.0 for Red Hat JBoss Web Server.

To install the Red Hat Certified Collection for JBoss Web Server, you will need to configure Ansible to use Red Hat Automation Hub as the preferred Galaxy server. Follow the instructions on Automation Hub to retrieve your token and update the ansible.cfg configuration on your Ansible controller. Update the <your-token> field with the token obtained from Automation Hub:

[galaxy]
server_list = automation_hub, galaxy

[galaxy_server.galaxy]
url=https://galaxy.ansible.com/

[galaxy_server.automation_hub]
url=https://cloud.redhat.com/api/automation-hub/api/galaxy/
auth_url=https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token

token=<your-token>

If you are not familiar with Ansible, note that this configuration file lives in the same directory as the Ansible playbook we are going to design for our JWS deployment.

Once you have configured Ansible to use Automation Hub, install the certified collection:

$ ansible-galaxy collection install redhat.jws
Starting galaxy collection install process
Process install dependency map
Starting collection install process
Downloading https://console.redhat.com/api/automation-hub/v3/plugin/ansible/content/published/collections/artifacts/redhat-jws-2.0.0.tar.gz to /root/.ansible/tmp/ansible-local-88isxfxlvv/tmpvujtdugq/redhat-jws-2.0.0-zf_lh9ed
Installing 'redhat.jws:2.0.0' to '/root/.ansible/collections/ansible_collections/redhat/jws'
Downloading https://console.redhat.com/api/automation-hub/v3/plugin/ansible/content/published/collections/artifacts/redhat-runtimes_common-1.1.3.tar.gz to /root/.ansible/tmp/ansible-local-88isxfxlvv/tmpvujtdugq/redhat-runtimes_common-1.1.3-pf34k4r_
redhat.jws:2.0.0 was installed successfully
Installing 'redhat.runtimes_common:1.1.3' to '/root/.ansible/collections/ansible_collections/redhat/runtimes_common'
Downloading https://console.redhat.com/api/automation-hub/v3/plugin/ansible/content/published/collections/artifacts/ansible-posix-1.5.4.tar.gz to /root/.ansible/tmp/ansible-local-88isxfxlvv/tmpvujtdugq/ansible-posix-1.5.4-yie4utve
redhat.runtimes_common:1.1.3 was installed successfully
Installing 'ansible.posix:1.5.4' to '/root/.ansible/collections/ansible_collections/ansible/posix'
ansible.posix:1.5.4 was installed successfully

Ansible Galaxy fetches and downloads the collection's dependencies. These dependencies include the redhat.runtimes_common collection, which helps facilitate the retrieval of the archive containing the JBoss Web Server server from the Red Hat customer portal.

Red Hat customer portal credentials

---
rhn_username: <service_account_id>
rhn_password: <service_account_password>

Installing the Red Hat JBoss Web server

The configuration steps in this section include downloading JBoss Web Server, installing Java, and enabling JBoss Web Server as a system service (systemd).

Configuring the JVM

JBoss Web Server is a Java-based server, so the target system must have a Java Virtual Machine (JVM) installed. Although Ansible primitives can perform such tasks natively, the redhat.jws collection can also take care of this task as well provided that the jws_java_version variable is defined. By default, the value is the latest Red Hat supported version of OpenJDK (17).

While we will keep the latest version for this demonstration, note that a different version of the OpenJDK can be set using the jws_java_version variable:

jws_java_version: 11

Note: This feature works only if the target system's distribution belongs to the Red Hat family.

Enabling JBoss Web Server as a system service (systemd)

The JBoss Web Server server on the target system should run as a service system. The collection can also take care of this task if the jws_systemd_enabled variable is defined as True (which is the default value as the target systems are expected to be RHEL machines).

Note: This configuration works only when systemd is installed and the system belongs to the Red Hat family.

Running the playbook

The Red Hat Ansible Certified Content Collection comes with a playbook that can be used directly to ensure that JWS is properly installed on target instances.

Execute the following command to execute playbook included within the collection along with the extra variables file created previously:

$ ansible-playbook -i inventory -e @service_account.yml redhat.jws.playbook

PLAY [Red Hat JBoss Web Server installation and configuration] *****************

TASK [Gathering Facts] *********************************************************
ok: [localhost]

TASK [redhat.jws.jws : Validating arguments against arg spec 'main'] ***********
ok: [localhost]

TASK [redhat.jws.jws : Check for conflicting Java variables] *******************
skipping: [localhost]

TASK [redhat.jws.jws : Set default values] *************************************
skipping: [localhost]

TASK [redhat.jws.jws : Check that jws_home has been defined.] ******************
ok: [localhost] => {
    "changed": false,
    "msg": "All assertions passed"
}

TASK [redhat.jws.jws : Add firewalld to dependencies list (if enabled)] ********
skipping: [localhost]

TASK [redhat.jws.jws : Add 'openssl' and 'apr' to dependencies list required for natives (if enabled)] ***
skipping: [localhost]

TASK [redhat.jws.jws : Include tasks for Java installation (if Java version is provided)] ***
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/java_install.yml for localhost

TASK [redhat.jws.jws : Add 'java-17-openjdk-headless' to dependencies list] ****
ok: [localhost]

TASK [redhat.jws.jws : Determine JAVA_HOME for selected JVM RPM] ***************
ok: [localhost]

TASK [redhat.jws.jws : Install required dependencies] **************************
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/fastpackage.yml for localhost

TASK [redhat.jws.jws : Check if "zip, unzip, tzdata, sudo, java-17-openjdk-headless" packages are already installed] ***
ok: [localhost]

TASK [redhat.jws.jws : Add missing packages to the yum install list] ***********
ok: [localhost]

TASK [redhat.jws.jws : Install packages: ['java-17-openjdk-headless']] *********
changed: [localhost]

TASK [redhat.jws.jws : Ensure tomcatjss rpm is not installed] ******************
ok: [localhost]

TASK [redhat.jws.jws : Create group: tomcat] ***********************************
changed: [localhost]

TASK [redhat.jws.jws : Create user: tomcat] ************************************
changed: [localhost]

TASK [redhat.jws.jws : Check state of install_dir: /opt] ***********************
ok: [localhost]

TASK [redhat.jws.jws : Ensure install dir is created: /opt] ********************
skipping: [localhost]

TASK [redhat.jws.jws : Set defaults values based on facts (if values not provided)] ***
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/defaults.yml for localhost

TASK [redhat.jws.jws : Set filename for JWS zipfile] ***************************
ok: [localhost]

TASK [redhat.jws.jws : Set native zipfile architecture (if not provided)] ******
ok: [localhost]

TASK [redhat.jws.jws : Set RHEL major version based on facts (if not provided).] ***
ok: [localhost]

TASK [redhat.jws.jws : Set filename for JWS native zipfile] ********************
ok: [localhost]

TASK [redhat.jws.jws : Ensure patch version is specified when installing offline.] ***
skipping: [localhost]

TASK [redhat.jws.jws : Ensure credentials are defined when installing from JBossNetwork API.] ***
ok: [localhost]

TASK [redhat.jws.jws : Check main zipfile] *************************************
skipping: [localhost]

TASK [redhat.jws.jws : Check native zipfile exists] ****************************
skipping: [localhost]

TASK [redhat.jws.jws : Check patch zipfile exists] *****************************
skipping: [localhost]

TASK [redhat.jws.jws : Check native patch zipfile exists] **********************
skipping: [localhost]

TASK [redhat.jws.jws : Include install tasks] **********************************
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/install.yml for localhost

TASK [redhat.jws.jws : Check arguments] ****************************************
ok: [localhost]

TASK [redhat.jws.jws : Check working directory /work for local repository] *****
ok: [localhost]

TASK [redhat.jws.jws : Display install method] *********************************
ok: [localhost] => {
    "msg": "Install method: zipfiles"
}

TASK [redhat.jws.jws : Include installation tasks using zipfiles method] *******
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/install/local.yml for localhost

TASK [redhat.jws.jws : Deploy jws-6.0.0-application-server.zip to target.] *****
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/install/deploy_archive.yml for localhost

TASK [redhat.jws.jws : Check that required parameters have been provided.] *****
ok: [localhost]

TASK [redhat.jws.jws : Check download archive path on target: /opt/jws-6.0.0-application-server.zip] ***
ok: [localhost]

TASK [redhat.jws.jws : Retrieve zipfiles, if missing, from RHN (if credentials provided)] ***
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/install/download_from_rhn.yml for localhost

TASK [redhat.jws.jws : Search for product to download using JBoss Network API] ***
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/rhn/search.yml for localhost

TASK [redhat.jws.jws : Ensure required parameters are provided] ****************
ok: [localhost]

TASK [redhat.jws.jws : Retrieve product download using JBossNetwork API] *******
ok: [localhost]

TASK [redhat.jws.jws : Ensure search results are valid.] ***********************
ok: [localhost]

TASK [redhat.jws.jws : Determine install zipfile from search results] **********
ok: [localhost]

TASK [redhat.jws.jws : Download Red Hat JWS] ***********************************
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/rhn/download.yml for localhost

TASK [redhat.jws.jws : Ensure required parameters are provided] ****************
ok: [localhost]

TASK [redhat.jws.jws : Load metadata on target location for download (/work/jws-6.0.0-application-server.zip)] ***
ok: [localhost]

TASK [redhat.jws.jws : Ensure /work/jws-6.0.0-application-server.zip is accessible] ***
ok: [localhost]

TASK [redhat.jws.jws : Download Red Hat product into {{ rhn_product_path }} (rhn_download_become: {{ rhn_download_become }})] ***
changed: [localhost]

TASK [redhat.jws.jws : Retrieve zipfiles from URL (if provided).] **************
skipping: [localhost]

TASK [redhat.jws.jws : Copy archives /work/jws-6.0.0-application-server.zip to target nodes: /opt/jws-6.0.0-application-server.zip] ***
changed: [localhost]

TASK [redhat.jws.jws : Deploy jws-6.0.0-optional-native-components-RHEL9-x86_64.zip to target.] ***
skipping: [localhost]

TASK [redhat.jws.jws : Include installation tasks for zip operations] **********
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/install/zipfiles.yml for localhost

TASK [redhat.jws.jws : Check arguments] ****************************************
ok: [localhost]

TASK [redhat.jws.jws : Add zipfile to unarchive list] **************************
ok: [localhost]

TASK [redhat.jws.jws : Add native zipfile to unarchive list] *******************
skipping: [localhost]

TASK [redhat.jws.jws : Install Jboss Web Server and required binaries from local zipfiles (install method: zipfiles)] ***
changed: [localhost] => (item={'src': 'jws-6.0.0-application-server.zip', 'creates': '/opt/jws-6.0/tomcat/bin'})

TASK [redhat.jws.jws : Move the zipfile extracted directory to custom jws_home] ***
skipping: [localhost]

TASK [redhat.jws.jws : Move the version.txt to custom jws_home] ****************
skipping: [localhost]

TASK [redhat.jws.jws : Include installation tasks for rpm method] **************
skipping: [localhost]

TASK [redhat.jws.jws : Include systemd tasks] **********************************
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/systemd/systemd.yml for localhost

TASK [redhat.jws.jws : Check arguments] ****************************************
ok: [localhost]

TASK [redhat.jws.jws : Ensure requirements for systemd] ************************
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/fastpackage.yml for localhost

TASK [redhat.jws.jws : Check if "systemd, procps-ng" packages are already installed] ***
ok: [localhost]

TASK [redhat.jws.jws : Add missing packages to the yum install list] ***********
ok: [localhost]

TASK [redhat.jws.jws : Install packages: ['java-17-openjdk-headless']] *********
ok: [localhost]

TASK [redhat.jws.jws : Set required default for jws_service_conf if not provided.] ***
ok: [localhost]

TASK [redhat.jws.jws : Set required default for jws_service_conf if not provided.] ***
ok: [localhost]

TASK [redhat.jws.jws : Set required default for jws_service_conf if not provided.] ***
ok: [localhost]

TASK [redhat.jws.jws : Ensure service script is deployed] **********************
changed: [localhost]

TASK [redhat.jws.jws : Ensure service configurations files is deployed: /opt/jws-6.0/tomcat/conf/jws6-tomcat.conf] ***
changed: [localhost]

TASK [redhat.jws.jws : Ensure systemd service is configured] *******************
changed: [localhost]

TASK [redhat.jws.jws : Include patch install tasks] ****************************
skipping: [localhost]

TASK [redhat.jws.jws : Ensure /opt/jws-6.0/tomcat/ directories have appropriate privileges] ***
ok: [localhost] => (item=conf)
ok: [localhost] => (item=temp)
ok: [localhost] => (item=logs)
ok: [localhost] => (item=webapps)
ok: [localhost] => (item=bin)

TASK [redhat.jws.jws : Ensure /opt/jws-6.0/tomcat/ files have the recommended priviliges, owner and group] ***
changed: [localhost] => (item=./conf/catalina.properties)
changed: [localhost] => (item=./conf/catalina.policy)
changed: [localhost] => (item=./conf/logging.properties)
changed: [localhost] => (item=./conf/jaspic-providers.xml)
changed: [localhost] => (item=conf/tomcat-users.xml)

TASK [redhat.jws.jws : Include ajp sanity check tasks] *************************
skipping: [localhost]

TASK [redhat.jws.jws : Include https sanity check tasks] ***********************
skipping: [localhost]

TASK [redhat.jws.jws : Deploy custom configuration files] **********************
changed: [localhost] => (item={'template': 'templates/6/server.xml.j2', 'dest': '/opt/jws-6.0/tomcat/./conf/server.xml'})
changed: [localhost] => (item={'template': 'templates/6/web.xml.j2', 'dest': '/opt/jws-6.0/tomcat/./conf/web.xml'})
changed: [localhost] => (item={'template': 'templates/6/context.xml.j2', 'dest': '/opt/jws-6.0/tomcat/./conf/context.xml'})
changed: [localhost] => (item={'template': 'templates/6/catalina.properties.j2', 'dest': '/opt/jws-6.0/tomcat/./conf/catalina.properties'})

TASK [redhat.jws.jws : Include selinux configuration tasks] ********************
skipping: [localhost]

TASK [redhat.jws.jws : Remove apps] ********************************************
ok: [localhost] => (item=examples)

TASK [redhat.jws.jws : Create vault configuration (if enabled)] ****************
skipping: [localhost]

TASK [redhat.jws.jws : Ensure firewalld, if enabled, allows communication over 8080.] ***
skipping: [localhost]

RUNNING HANDLER [redhat.jws.jws : Reload Systemd] ******************************
ok: [localhost]

RUNNING HANDLER [redhat.jws.jws : Ensure Jboss Web Server runs under systemd] ***
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/systemd/service.yml for localhost

RUNNING HANDLER [redhat.jws.jws : Check arguments] *****************************
ok: [localhost]

RUNNING HANDLER [redhat.jws.jws : Enable jws service] **************************
changed: [localhost]

RUNNING HANDLER [redhat.jws.jws : Start jws service] ***************************
changed: [localhost]

RUNNING HANDLER [redhat.jws.jws : Restart Jboss Web Server service] ************
changed: [localhost]

PLAY RECAP *********************************************************************
localhost               : ok=66   changed=14   unreachable=0    failed=0    skipped=22   rescued=0  ignored=0

As you can see, quite a lot happened during this execution. Indeed, the redhat.jws role took care of the entire setup of JWS on the target system.

Deploying a web application

Now that JBoss Web Server is running, we will go a bit further by deploying a web application and ensuring it is running. As we’ll need to write our own playbook, the first step will be to copy the one included playbook within the collection and use it as a base:

$ cp ~/.ansible/collections/ansible_collections/redhat/jws/playbooks/playbook.yml .
$ cat playbook.yml
---
- name: "Red Hat JBoss Web Server installation and configuration"
  hosts: all
  become: True
  vars_files:
    - vars.yml
  roles:
    - redhat.jws.jws
$ cp ~/.ansible/collections/ansible_collections/redhat/jws/playbooks/vars.yml .
$ cat vars.yml
---
jws_setup: true
jws_java_version: 17
jws_listen_http_bind_address: 127.0.0.1
jws_systemd_enabled: True
jws_service_systemd_type: forking
jws_selinux_enabled: False

Now, we’ll add a tasks: section to the playbook. This section of the playbook will be run after the roles have executed successfully So, we know that JWS will be operational on the targets at this point.

We will include the following tasks to perform the deployment of a web application:

---
- name: "Red Hat JBoss Web Server installation and configuration"
  hosts: all
  become: True
  vars_files:
    - vars.yml
  roles:
    - redhat.jws.jws
  tasks:
    - name: "Deploy webapp"
      ansible.builtin.get_url:
       url: "https://drive.google.com/uc?export=download&id=1w9ss5okctnjUvRAxhPEPyC7DmbUwmbhb"
       dest: "{{ jws_home }}/webapps/info.war"

Let’s run again the playbook:

$ ansible-playbook -i inventory -e @service_account.yml playbook.yml

PLAY [Red Hat JBoss Web Server installation and configuration] *************************************************************************

TASK [Gathering Facts] *****************************************************************************************************************
ok: [localhost]

…

TASK [Deploy webapp] *******************************************************************************************************************
changed: [localhost]

RUNNING HANDLER [redhat.jws.jws : Restart Jboss Web Server service] ********************************************************************
changed: [localhost]

PLAY RECAP *****************************************************************************************************************************
localhost               : ok=3  changed=2   unreachable=0   failed=0    skipped=0   rescued=0   ignored=0

To be thorough, we will add a post_tasks: section to verify that the web application has been successfully and that the associated service is now available:

post_tasks:
  - name: " Checks that /info is accessible"
    ansible.builtin.uri:
    url: "http://localhost:8080/info"
    status_code: 200
    return_content: no

The benefits of such automation

In short, automation saves time and reduces the risk of error inherent to any human manipulation.

The Red Hat Ansible Certified Content Collection encapsulates (as much as possible) the complexities and the inner workings of Red Hat JBoss Web Server deployment. With the help of the certified Ansible collection, you can focus on your business use case, such as deploying applications, instead of establishing the underlying application server. The result is reduced complexity and faster time to value. The automated process is also repeatable and can be used to set up as many systems as needed

A fully automated setup of a JBoss EAP cluster using Ansible

Pelisse Romain — Wed, 31 Jan 2024 23:00:00 +0000

Foreword

This article assumes that you have prior knowledge of both Ansible and the steps associated with a basic installation of Red Hat JBoss Enterprise Application Platform (JBoss EAP)/WildFly. Visit the Ansible courses page to learn the fundamentals of using Ansible.

An earlier article already covered this topic. However, this article provides a much needed update to its content; particularly documenting how to use the Red Hat Ansible Certified Content Collection for JBoss EAP (redhat.eap) instead of the community version of the collection (middleware_automation.wildfly).

Introduction

The objective of this demonstration is to set up and run three JBoss EAP instances forming a cluster. In this context, the application servers must communicate with each other to synchronize the content of the applications' session. This configuration guarantees that, if one instance fails while processing a request, another one can pick up the work without any data loss. In short, an EAP cluster is strategy to ensure high availability of the apps executed by the JEE server.

Use case: Deploying a JBoss EAP cluster with Ansible

Note that, for simplicity’s sake, we’ll use multicast discovery to identify members of the cluster and assure that the cluster’s formation is fully automated and dynamic. This will allow the cluster to configure itself without additional configuration. It’s worth mentioning that this setup can also work without multicast, but it is not the intended focus of this article.

Prerequisites

The first step is to install Ansible on the workstation, which will be referred to from now on as the Ansible control node along with ensuring that the tool can connect to the target systems. The process for setting up Ansible is out of scope for this article, but do refer to the Ansible documentation to perform this installation (keeping in mind that Ansible version 2.14 or above is recommended).

The second prerequisite is to provide the appropriate token to Ansible so that it can interact with Ansible automation hub to download the redhat.eap collection. Refer to the Red Hat Ansible documentation for this step.

Once the content of the ansible.cfg has been properly configured to use Ansible automation hub, the last step consists of installing the Red Hat Ansible Certified Content Collection for JBoss EAP:

# ansible-galaxy collection install redhat.eap
Starting galaxy collection install process
Process install dependency map
Starting collection install process
Downloading https://console.redhat.com/api/automation-hub/v3/plugin/ansible/content/published/collections/artifacts/redhat-eap-1.4.3.tar.gz to /root/.ansible/tmp/ansible-local-37nv77u54f/tmp3t3je__p/redhat-eap-1.4.3-wo61xl4t
Installing 'redhat.eap:1.4.3' to '/root/.ansible/collections/ansible_collections/redhat/eap'
redhat.eap:1.4.3 was installed successfully
'ansible.posix:1.5.4' is already installed, skipping.
'redhat.runtimes_common:1.1.3' is already installed, skipping.

For the collection to be able to download the JBoss EAP archives from the Red Hat Customer Portal, we need to supply the credentials tied a Red HAT service account. One way to provide those values parameters is to create a service_account.yml which can be passed to Ansible as an extra source of variables:

---
rhn_username: <service_account_id>
rhn_password: <service_account_password>

Note: We could use Ansible's vault to safely encrypt the credential values, but doing that is out of the scope of this article.

Set up the JBoss EAP cluster

A typical JBoss EAP cluster has many machines, each operating a dedicated instance. For the simplicity of testing and ensuring reproducibility on a development system, we are going to use just one server to run several instances of JBoss EAP. Using the Red Hat Ansible Certified Content Collection for JBoss EAP, constructing this type of architecture is relatively easy, as the collection provides all the required plumbing.

The process we are going to automate thanks to Ansible (and the redhat.eap collection) consists of two parts:

Install JBoss EAP on the hosts. This installation involves authenticating against the Red Hat Customer portal and downloading the EAP 7.4 archive prior to decompressing it in the appropriate directory (`JBOSS_HOME`). All of this is facilitated by the `eap_install` role within the `redhat.eap` collection.

Create the configuration files required to run several instances of JBoss EAP on the same host. Because we're executing multiple instances on a single machine, we need to ensure that each instance has its own subdirectories and set of ports so that they can coexist and communicate with each other. Fortunately, this functionality is also provided by a role within the Ansible collection called `eap_systemd`.

Ansible playbook to install JBoss EAP

Here is our Ansible playbook for installing and configuring JBoss EAP:

---
- name: "JBoss EAP installation and configuration"
  hosts: "{{ hosts_group_name | default('localhost') }}"
  become: yes
  vars:
    eap_install_workdir: '/opt'
    eap_version: '7.4.0'
    install_name: jboss-eap
    eap_user: "{{ install_name }}"
    eap_config_base: standalone-ha.xml
    eap_home: "{{ eap_install_workdir }}/{{ install_name }}-{{ (eap_version.split('.'))[0:2] | join('.') }}"

    instance_http_ports:
      - 8080
      - 8180
      - 8280
    app:
      name: 'info-1.1.war'
      url: 'https://drive.google.com/uc?export=download&id=1w9ss5okctnjUvRAxhPEPyC7DmbUwmbhb'
  collections:
    - redhat.eap
  roles:
    - eap_install
  tasks:

    - name: "Set up for WildFly instance {{ item }}"
      include_role:
        name: eap_systemd
      vars:
        eap_config_base: 'standalone-ha.xml'
        eap_basedir_prefix: "/opt/{{ inventory_hostname }}"
        eap_config_name: "{{ install_name }}"
        eap_instance_name: "{{ install_name }}"
        eap_instance_id: "{{ item }}"
        service_systemd_env_file: "/etc/eap-{{ item }}.conf"
        service_systemd_conf_file: "/usr/lib/systemd/system/jboss-eap-{{ item }}.service"
      loop: "{{ range(0,3) | list }}"
  post_tasks:

    - set_fact:
            instance_http_ports:
                - 8080
                - 8180
                - 8280
    - wait_for:
        port: "{{ item }}"
      loop: "{{ instance_http_ports }}"

    - name: "Checks that WildFly server is running and accessible"
      get_url:
        url: "http://localhost:{{ item }}/"
        dest: '/dev/null'
      loop: "{{ instance_http_ports }}"

Run the playbook

Now, let’s run our Ansible playbook and check the resulting output:

$ ansible-playbook -i inventory -e @service_account.yml eap-cluster.yml
PLAY [JBoss EAP installation and configuration] ********************************

TASK [Gathering Facts] *********************************************************
ok: [localhost]

TASK [redhat.eap.eap_install : Validating arguments against arg spec 'main'] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure prerequirements are fullfilled.] *********
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_install/tasks/prereqs.yml for localhost

TASK [redhat.eap.eap_install : Validate credentials] ***************************
ok: [localhost]

TASK [redhat.eap.eap_install : Validate existing zipfiles jboss-eap-7.4.0.zip for offline installs] ***
skipping: [localhost]

TASK [redhat.eap.eap_install : Validate patch version for offline installs] ****
skipping: [localhost]

TASK [redhat.eap.eap_install : Validate existing additional zipfiles jboss-eap-7.4.0.zip for offline installs] ***
skipping: [localhost]

TASK [redhat.eap.eap_install : Check that required packages list has been provided.] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Prepare packages list] **************************
skipping: [localhost]

TASK [redhat.eap.eap_install : Add JDK package java-11-openjdk-headless to packages list] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Install required packages (5)] ******************
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure required local user exists.] *************
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_install/tasks/user.yml for localhost

TASK [redhat.eap.eap_install : Check arguments] ********************************
ok: [localhost]

TASK [redhat.eap.eap_install : Set eap group] **********************************
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure group jboss-eap exists.] *****************
changed: [localhost]

TASK [redhat.eap.eap_install : Ensure user jboss-eap exists.] ******************
changed: [localhost]

TASK [redhat.eap.eap_install : Ensure workdir /opt exists.] ********************
changed: [localhost]

TASK [redhat.eap.eap_install : Ensure archive_dir /opt exists.] ****************
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure server is installed] *********************
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_install/tasks/install.yml for localhost

TASK [redhat.eap.eap_install : Check arguments] ********************************
ok: [localhost]

TASK [redhat.eap.eap_install : Check local download archive path] **************
ok: [localhost]

TASK [redhat.eap.eap_install : Set download paths] *****************************
ok: [localhost]

TASK [redhat.eap.eap_install : Check target archive: /opt/jboss-eap-7.4.0.zip] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Retrieve archive from website: https://github.com/eap/eap/releases/download] ***
skipping: [localhost]

TASK [redhat.eap.eap_install : Retrieve archive from RHN] **********************
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_install/tasks/install/rhn.yml for localhost

TASK [redhat.eap.eap_install : Check arguments] ********************************
ok: [localhost]

TASK [Download JBoss EAP from CSP] *********************************************

TASK [redhat.eap.eap_utils : Check arguments] **********************************
ok: [localhost]

TASK [redhat.eap.eap_utils : Retrieve product download using JBoss Network API] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Determine install zipfile jboss-eap-7.4.0.zip from search results.] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Verify that filtered products has been properly populated.] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Download Red Hat JBoss Enterprise Application Platform] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Install server using RPM] ***********************
skipping: [localhost]

TASK [redhat.eap.eap_install : Check downloaded archive] ***********************
ok: [localhost]

TASK [redhat.eap.eap_install : Copy archive to target nodes] *******************
changed: [localhost]

TASK [redhat.eap.eap_install : Check target archive: /opt/jboss-eap-7.4.0.zip] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Verify target archive state: /opt/jboss-eap-7.4.0.zip] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Read target directory information: /opt/jboss-eap-7.4] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Extract files from /opt/jboss-eap-7.4.0.zip into /opt.] ***
changed: [localhost]

TASK [redhat.eap.eap_install : Note: decompression was not executed] ***********
skipping: [localhost]

TASK [redhat.eap.eap_install : Read information on server home directory: /opt/jboss-eap-7.4] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Check state of server home directory: /opt/jboss-eap-7.4] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Set instance name] ******************************
ok: [localhost]

TASK [redhat.eap.eap_install : Deploy custom configuration] ********************
skipping: [localhost]

TASK [redhat.eap.eap_install : Deploy configuration] ***************************
changed: [localhost]

TASK [Apply latest cumulative patch] *******************************************

TASK [redhat.eap.eap_utils : Check installation] *******************************
ok: [localhost]

TASK [redhat.eap.eap_utils : Set patch directory] ******************************
ok: [localhost]

TASK [redhat.eap.eap_utils : Set download patch archive path] ******************
skipping: [localhost]

TASK [redhat.eap.eap_utils : Check download patch archive path] ****************
skipping: [localhost]

TASK [redhat.eap.eap_utils : Check local download archive path] ****************
ok: [localhost]

TASK [redhat.eap.eap_utils : Check local downloaded archive: {{ patch_bundle }}] ***
skipping: [localhost]

TASK [redhat.eap.eap_utils : Retrieve product download using JBossNetwork API] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Determine patch versions list] ********************
ok: [localhost]

TASK [redhat.eap.eap_utils : Determine latest version] *************************
ok: [localhost]

TASK [redhat.eap.eap_utils : Determine install zipfile from search results] ****
ok: [localhost]

TASK [redhat.eap.eap_utils : Determine selected patch from supplied version: {{ eap_patch_version }}] ***
skipping: [localhost]

TASK [redhat.eap.eap_utils : Check remote downloaded archive: /opt/jboss-eap-7.4.13-patch.zip] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Download Red Hat EAP patch] ***********************
ok: [localhost]

TASK [redhat.eap.eap_utils : Update patch archive path after download] *********
ok: [localhost]

TASK [redhat.eap.eap_utils : Check remote download patch archive path] *********
ok: [localhost]

TASK [redhat.eap.eap_utils : Copy patch archive to target nodes] ***************
changed: [localhost]

TASK [redhat.eap.eap_utils : Check patch state] ********************************
ok: [localhost]

TASK [redhat.eap.eap_utils : Set checksum file path for patch] *****************
ok: [localhost]

TASK [redhat.eap.eap_utils : Check /opt/jboss-eap-7.4/.applied_patch_checksum_6427fed0a0fab256a058232c1aa02efcdb32919d.txt state] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Print when patch has been applied already] ********
skipping: [localhost]

TASK [redhat.eap.eap_utils : Check if management interface is reachable] *******
fatal: [localhost]: FAILED! => {"changed": false, "elapsed": 1, "msg": "Timeout when waiting for localhost:9990"}

TASK [redhat.eap.eap_utils : Set instance name] ********************************
skipping: [localhost]

TASK [redhat.eap.eap_utils : Deploy configuration] *****************************
ok: [localhost]

TASK [redhat.eap.eap_utils : Start eap for patching] ***************************
changed: [localhost]

TASK [redhat.eap.eap_utils : Wait for management interface is reachable] *******
ok: [localhost]

TASK [redhat.eap.eap_utils : Set apply CP conflict default strategy to default (if not defined): --override-all] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Apply patch /opt/jboss-eap-7.4.13-patch.zip to server installed in /opt/jboss-eap-7.4] ***
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_utils/tasks/jboss_cli.yml for localhost

TASK [redhat.eap.eap_utils : Ensure required params for JBoss CLI have been provided] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Ensure server's management interface is reachable] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Execute CLI query 'patch apply --override-all /opt/jboss-eap-7.4.13-patch.zip'] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Display patching result] **************************
ok: [localhost] => {
    "msg": "Apply patch operation result: {\n    \"outcome\" : \"success\",\n    \"response-headers\" : {\n        \"operation-requires-restart\" : true,\n        \"process-state\" : \"restart-required\"\n    }\n}"
}

TASK [redhat.eap.eap_utils : Set checksum file] ********************************
changed: [localhost]

TASK [redhat.eap.eap_utils : Set latest patch file] ****************************
changed: [localhost]

TASK [redhat.eap.eap_utils : Restart server to ensure patch content is running] ***
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_utils/tasks/jboss_cli.yml for localhost

TASK [redhat.eap.eap_utils : Ensure required params for JBoss CLI have been provided] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Ensure server's management interface is reachable] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Execute CLI query 'shutdown --restart'] ***********
ok: [localhost]

TASK [redhat.eap.eap_utils : Wait for management interface is reachable] *******
ok: [localhost]

TASK [redhat.eap.eap_utils : Stop service if it was started for patching] ******
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_utils/tasks/jboss_cli.yml for localhost

TASK [redhat.eap.eap_utils : Ensure required params for JBoss CLI have been provided] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Ensure server's management interface is reachable] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Execute CLI query 'shutdown'] *********************
ok: [localhost]

TASK [redhat.eap.eap_utils : Display resulting output] *************************
skipping: [localhost]

TASK [redhat.eap.eap_install : Ensure required parameters for elytron adapter are provided.] ***
skipping: [localhost]

TASK [Install elytron adapter] *************************************************
skipping: [localhost]

TASK [redhat.eap.eap_install : Install server using Prospero] ******************
skipping: [localhost]

TASK [redhat.eap.eap_install : Check eap install directory state] **************
ok: [localhost]

TASK [redhat.eap.eap_install : Validate conditions] ****************************
ok: [localhost]

TASK [Ensure firewalld configuration allows server port (if enabled).] *********
skipping: [localhost]

TASK [Set up for WildFly instance {{ item }}] **********************************

TASK [redhat.eap.eap_systemd : Validating arguments against arg spec 'main'] ***
ok: [localhost]

TASK [redhat.eap.eap_systemd : Check arguments] ********************************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Check current EAP patch installed] **************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Check arguments for yaml configuration] *********
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Check if YAML configuration extension is supported in WildFly] ***
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Check if YAML configuration extension is supported in EAP] ***
skipping: [localhost]

TASK [Ensure required local user and group exists.] ****************************

TASK [redhat.eap.eap_install : Check arguments] ********************************
ok: [localhost]

TASK [redhat.eap.eap_install : Set eap group] **********************************
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure group jboss-eap exists.] *****************
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure user jboss-eap exists.] ******************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Set destination directory for configuration] ****
ok: [localhost]

TASK [redhat.eap.eap_systemd : Set instance destination directory for configuration] ***
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Check arguments] ********************************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Set base directory for instance] ****************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Check arguments] ********************************
ok: [localhost] => {
    "changed": false,
    "msg": "All assertions passed"
}

TASK [redhat.eap.eap_systemd : Set instance name] ******************************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Set instance name] ******************************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Set bind address] *******************************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Create basedir /opt/localhost0 for instance: jboss-eap-0] ***
changed: [localhost]

TASK [redhat.eap.eap_systemd : Create deployment directories for instance: jboss-eap-0] ***
changed: [localhost]

TASK [redhat.eap.eap_systemd : Deploy custom configuration] ********************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Deploy configuration] ***************************
changed: [localhost]

TASK [redhat.eap.eap_systemd : Include YAML configuration extension] ***********
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Check YAML configuration is disabled] ***********
ok: [localhost]

TASK [redhat.eap.eap_systemd : Set systemd envfile destination] ****************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Determine JAVA_HOME for selected JVM] ***********
ok: [localhost]

TASK [redhat.eap.eap_systemd : Determine JAVA_HOME for selected JVM] ***********
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Set systemd unit file destination] **************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Deploy service instance configuration: /etc/eap-0.conf] ***
changed: [localhost]

TASK [redhat.eap.eap_systemd : Deploy Systemd configuration for service: /usr/lib/systemd/system/jboss-eap-0.service] ***
changed: [localhost]

TASK [redhat.eap.eap_systemd : Perform daemon-reload to ensure the changes are picked up] ***
ok: [localhost]

TASK [redhat.eap.eap_systemd : Ensure service is started] **********************
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_systemd/tasks/service.yml for localhost

TASK [redhat.eap.eap_systemd : Check arguments] ********************************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Set instance jboss-eap-0 state to started] ******
changed: [localhost]

TASK [redhat.eap.eap_systemd : Validating arguments against arg spec 'main'] ***
ok: [localhost]

TASK [redhat.eap.eap_systemd : Check arguments] ********************************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Check current EAP patch installed] **************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Check arguments for yaml configuration] *********
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Check if YAML configuration extension is supported in WildFly] ***
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Check if YAML configuration extension is supported in EAP] ***
skipping: [localhost]

TASK [Ensure required local user and group exists.] ****************************

TASK [redhat.eap.eap_install : Check arguments] ********************************
ok: [localhost]

TASK [redhat.eap.eap_install : Set eap group] **********************************
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure group jboss-eap exists.] *****************
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure user jboss-eap exists.] ******************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Set destination directory for configuration] ****
ok: [localhost]

TASK [redhat.eap.eap_systemd : Set instance destination directory for configuration] ***
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Check arguments] ********************************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Set base directory for instance] ****************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Check arguments] ********************************
ok: [localhost] => {
    "changed": false,
    "msg": "All assertions passed"
}

TASK [redhat.eap.eap_systemd : Set instance name] ******************************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Set instance name] ******************************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Set bind address] *******************************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Create basedir /opt/localhost1 for instance: jboss-eap-1] ***
changed: [localhost]

TASK [redhat.eap.eap_systemd : Create deployment directories for instance: jboss-eap-1] ***
changed: [localhost]

TASK [redhat.eap.eap_systemd : Deploy custom configuration] ********************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Deploy configuration] ***************************
changed: [localhost]

TASK [redhat.eap.eap_systemd : Include YAML configuration extension] ***********
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Check YAML configuration is disabled] ***********
ok: [localhost]

TASK [redhat.eap.eap_systemd : Set systemd envfile destination] ****************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Determine JAVA_HOME for selected JVM] ***********
ok: [localhost]

TASK [redhat.eap.eap_systemd : Determine JAVA_HOME for selected JVM] ***********
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Set systemd unit file destination] **************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Deploy service instance configuration: /etc/eap-1.conf] ***
changed: [localhost]

TASK [redhat.eap.eap_systemd : Deploy Systemd configuration for service: /usr/lib/systemd/system/jboss-eap-1.service] ***
changed: [localhost]

TASK [redhat.eap.eap_systemd : Perform daemon-reload to ensure the changes are picked up] ***
ok: [localhost]

TASK [redhat.eap.eap_systemd : Ensure service is started] **********************
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_systemd/tasks/service.yml for localhost

TASK [redhat.eap.eap_systemd : Check arguments] ********************************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Set instance jboss-eap-1 state to started] ******
changed: [localhost]

TASK [redhat.eap.eap_systemd : Validating arguments against arg spec 'main'] ***
ok: [localhost]

TASK [redhat.eap.eap_systemd : Check arguments] ********************************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Check current EAP patch installed] **************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Check arguments for yaml configuration] *********
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Check if YAML configuration extension is supported in WildFly] ***
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Check if YAML configuration extension is supported in EAP] ***
skipping: [localhost]

TASK [Ensure required local user and group exists.] ****************************

TASK [redhat.eap.eap_install : Check arguments] ********************************
ok: [localhost]

TASK [redhat.eap.eap_install : Set eap group] **********************************
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure group jboss-eap exists.] *****************
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure user jboss-eap exists.] ******************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Set destination directory for configuration] ****
ok: [localhost]

TASK [redhat.eap.eap_systemd : Set instance destination directory for configuration] ***
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Check arguments] ********************************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Set base directory for instance] ****************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Check arguments] ********************************
ok: [localhost] => {
    "changed": false,
    "msg": "All assertions passed"
}

TASK [redhat.eap.eap_systemd : Set instance name] ******************************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Set instance name] ******************************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Set bind address] *******************************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Create basedir /opt/localhost2 for instance: jboss-eap-2] ***
changed: [localhost]

TASK [redhat.eap.eap_systemd : Create deployment directories for instance: jboss-eap-2] ***
changed: [localhost]

TASK [redhat.eap.eap_systemd : Deploy custom configuration] ********************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Deploy configuration] ***************************
changed: [localhost]

TASK [redhat.eap.eap_systemd : Include YAML configuration extension] ***********
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Check YAML configuration is disabled] ***********
ok: [localhost]

TASK [redhat.eap.eap_systemd : Set systemd envfile destination] ****************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Determine JAVA_HOME for selected JVM] ***********
ok: [localhost]

TASK [redhat.eap.eap_systemd : Determine JAVA_HOME for selected JVM] ***********
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Set systemd unit file destination] **************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Deploy service instance configuration: /etc/eap-2.conf] ***
changed: [localhost]

TASK [redhat.eap.eap_systemd : Deploy Systemd configuration for service: /usr/lib/systemd/system/jboss-eap-2.service] ***
changed: [localhost]

TASK [redhat.eap.eap_systemd : Perform daemon-reload to ensure the changes are picked up] ***
ok: [localhost]

TASK [redhat.eap.eap_systemd : Ensure service is started] **********************
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_systemd/tasks/service.yml for localhost

TASK [redhat.eap.eap_systemd : Check arguments] ********************************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Set instance jboss-eap-2 state to started] ******
changed: [localhost]

TASK [set_fact] ****************************************************************
ok: [localhost]

TASK [wait_for] ****************************************************************
ok: [localhost] => (item=8080)
ok: [localhost] => (item=8180)
ok: [localhost] => (item=8280)

TASK [Checks that WildFly server is running and accessible] ********************
ok: [localhost] => (item=8080)
ok: [localhost] => (item=8180)
ok: [localhost] => (item=8280)

PLAY RECAP *********************************************************************
localhost                  : ok=145  changed=28   unreachable=0    failed=0    skipped=52   rescued=1    ignored=0

Although the playbook is quite short, it performs quite a lot of tasks (around one hundred and fifty tasks). First, the eap_install role uses the provided credentials to connect to Red Hat Customer Portal and download the jboss-eap-7.4.zip archive. Ansible then ensures that the target system has all the required prerequisite (user accounts and dedicated group, system dependencies, …). And, finally, the product files are installed in the appropriate folders by decompressing the archive.

After that, the eap_systemd role that will take care of setting up three distinct systemd services, one for each JBoss EAP instance running on the target system. A nice benefit of this approach is that the binary file of JBoss EAP are not duplicated. All the product files live in the /opt/jboss-eap-74 directory. The only files or directories replicated are the ones that are tied to one of the instances. It also means that, in order to update all the instances (to a newly released minor version of EAP), one only needs to update the files located in this folder.

On top of everything, the instances have already been configured to use the standalone-ha.xml configuration as the baseline, so they are, already, set up for clustering.

Verify that JBoss EAP instances and associated services are running

The playbook confirms that each instance can be reached through its own HTTP port. We can also verify that the services are running by using the systemctl command:

# systemctl status jboss-eap-*
● jboss-eap-0.service - JBoss EAP (standalone mode)
   Loaded: loaded (/usr/lib/systemd/system/jboss-eap-0.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2021-12-23 12:31:41 UTC; 1min 55s ago
 Main PID: 1138 (standalone.sh)
    Tasks: 70 (limit: 1638)
   Memory: 532.3M
   CGroup: /system.slice/jboss-eap-0.service
           ├─1138 /bin/sh /opt/jboss-eap-7.4/bin/standalone.sh -c jboss-eap-0.xml -b 0.0.0.0 -Djboss.server.con>
           └─1261 java -D[Standalone] -server -verbose:gc -Xloggc:/opt/localhost0/log/gc.log -XX:+PrintGCDetail>
Dec 23 12:31:44 7b38800644ee standalone.sh[1138]: 12:31:44,548 INFO  [org.jboss.as.patching] (MSC service thread)
Dec 23 12:31:44 7b38800644ee standalone.sh[1138]: 12:31:44,563 WARN  [org.jboss.as.domain.management.security] >
Dec 23 12:31:44 7b38800644ee standalone.sh[1138]: 12:31
…

Deploy an application to the JBoss EAP cluster

At this point, the three JBoss EAP instances are running and configured to form a cluster. As no application has deployed, however, the cluster is not yet active (there is no data that would require some sort of synchronization between the instances).

We are going to modify our Ansible playbook to deploy of an application in each of the three JBoss EAP instances. To do so, we’ll leverage another feature of the Red Hat Ansible Certified Content Collection for JBoss EAP (redhat.eap) that integrate the use of the JBoss command-line tool (jboss-cli):

…
    - name: "Ensures webapp {{ app.name }} has been retrieved from {{ app.url }}"
      get_url:
        url: "{{ app.url }}"
        dest: "{{ wildfly_install_workdir }}/{{ app.name }}"

    - name: "Deploy webapp"
      include_role:
        name: jboss_eap
        tasks_from: jboss_cli.yml
      vars:
        jboss_home: "{{ wildfly_home }}"
        query: "'deploy --force {{ wildfly_install_workdir }}/{{ app.name }}'"
        jboss_cli_controller_port: "{{ item }}"
      loop:
        - 10090
        - 10190
        - 10290
…

Let’s execute again the playbook so that the web application is deployed on all instances. Once the automation completes successfully, the deployment of this application will trigger the formation of the cluster.

Verify the JBoss EAP cluster and application deployment

You can verify the JBoss EAP cluster formation by looking at the log files of any of the three JBoss EAP instances:

$ grep -e 'Received new cluster view for channel ejb:' /opt/jboss-eap-7.4/standalone/log/server.log
…

2023-11-23 15:02:08,252 INFO  [org.infinispan.CLUSTER] (thread-7,ejb,jboss-eap-0) ISPN000094: Received new cluster view for channel ejb: [jboss-eap-0] (3) [jboss-eap-0, jboss-eap-1, jboss-eap-2]
…

To be thorough, you can also check that the application is properly deployed and accessible. To validate the application's operation, we can simply add a separate Ansible playbook called validate.yml. We can then use this new playbook into our playbook.yml:

post_tasks:
  - include_tasks: validate.yml
    loop: "{{ instance_http_ports }}"

The validate.yml file contains the following:

---

- ansible.builtin.assert:
    that:
      - item is defined

- ansible.builtin.wait_for:
    port: "{{ item }}"

- name: "Checks that WildFly server is running and accessible on port {{ item }}"
  ansible.builtin.get_url:
    url: "http://localhost:{{ item }}/"
    dest: '/dev/null'
  changed_when: False

- ansible.builtin.include_tasks: info.yml

This playbook includes another one, called info.yml:

---
- ansible.builtin.assert:
    that:
      - item is defined
    quiet: true

- ansible.builtin.set_fact:
    result_file: "/tmp/info-{{ item }}.txt"

- ansible.builtin.get_url:
    url: "http://localhost:{{ item }}/info/"
    dest: "{{ result_file }}"
  changed_when: False

- ansible.builtin.slurp:
    src: "{{ result_file }}"
  register: info_res

- ansible.builtin.debug:
    msg: "{{ info_res['content'] | b64decode }}

To complete the exercise, we can run the validation playbook and see whether it confirms that our setup is fully functional:

TASK [get_url] ********************************************************************************
changed: [localhost]

TASK [slurp] **********************************************************************************
ok: [localhost]

TASK [debug] **********************************************************************************
ok: [localhost] => {
    "msg": "Request received<br/>Requested URL:\t\t\thttp://localhost:8380/info/<br/>Runs on node:\t\t\tda953ac17443 [IP: 10.0.2.100 ]<br/>Requested by:\t\t\t127.0.0.1 [IP: 127.0.0.1, port: 40334 ]<br/>JBOSS_ID:\t\t\tnull<br/>"
}

Conclusion

We've illustrated how to fully automated the setup and configuration of a three-instance cluster of JBoss EAP, along with the deployment of an application. The playbook is simple and straightforward. Most importantly, we were able to focus primarily on deploying the application. The Red Hat Ansible Certified Content Collection for JBoss EAP included all the required plumbing needed and did the heavy lifting, with little input by the end user.

Deploying a WildFly 30.0.1.Final cluster using Ansible

Pelisse Romain — Thu, 18 Jan 2024 17:00:00 +0000

In this brief demonstration, we’ll set up and run three instances of WildFly on the same machine (localhost). Together they will form a cluster. It’s a rather classic setup, where the appservers needs to synchronize the content of their application’s session to ensure fail over if one of the instances fails. This configuration guarantees that, if one instance fails while processing a request, another one can pick up the work without any data loss. Note that we’ll use a multicast to discover the members of the cluster and ensure that the cluster’s formation is fully automated and dynamic.

Install Ansible and its collection for WildFly

On a Linux system using a package manager, installing Ansible is pretty straightforward:

$ sudo dnf install ansible-core

Please refer to the documentation available online for installation on other operating system. Note that this demonstration assumes you are running both the Ansible controller and the target (same machine in our case) on a Linux system. However, it should work on any other operating system with a few adjustements.

Before going further, double check that you are running a recent enough version of Ansible (2.14 or above will do):

$ ansible --version
ansible [core 2.14.1]
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/home/rpelisse/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.11/site-packages/ansible
  ansible collection location = /home/rpelisse/.ansible/collections:/usr/share/ansible/collections
  executable location = /usr/bin/ansible
  python version = 3.11.0 (main, Oct 24 2022, 00:00:00) [GCC 12.2.1 20220819 (Red Hat 12.2.1-2)] (/usr/bin/python3)
  jinja version = 3.0.3
  libyaml = True

The next, and last, step to ready your Ansible environment is to install the Ansible collection for WildFly on the controller (the machine that will run Ansible):

$ ansible --version
ansible [core 2.14.1]
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/home/rpelisse/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.11/site-packages/ansible
  ansible collection location = /home/rpelisse/.ansible/collections:/usr/share/ansible/collections
  executable location = /usr/bin/ansible
  python version = 3.11.0 (main, Oct 24 2022, 00:00:00) [GCC 12.2.1 20220819 (Red Hat 12.2.1-2)] (/usr/bin/python3)
  jinja version = 3.0.3
  libyaml = True

Set up the WildFly cluster

For simplicity’s sake and to allow you to reproduce this demonstration on a single machine (physical or virtual) or even a container, we opted to deploy our three instances on one target. We chose localhost as a target, so that the demonstration can even be performed without a remote host.

There are essentially two steps to set up the WildFly cluster:

Install WildFly on the targeted hosts (here just localhost). This means downloading the archive from this website and decompressing the archive in the appropriate directory (JBOSS_HOME). These tasks are handled by the wildfly_install role supplied by Ansible collection for WildFly.

Create the configuration files to run several instances of WildFly. Because we’re running multiple instances on a single host, you also need to ensure that each instance has its own subdirectories and set of ports, so that the instances can coexist and communicate. Fortunately, this functionality is provided by a role within the Ansible collection called wildfly_systemd.

Ansible playbook to install WildFly

Here is the playbook we’ll use to deploy our clusters. Its content is relatively self-explanitory, at least if you are somewhat familiar with the Ansible syntax.

- name: "WildFly installation and configuration"
  hosts: "{{ hosts_group_name | default('localhost') }}"
  become: yes
  vars:
    wildfly_install_workdir: '/opt/'
    wildfly_config_base: standalone-ha.xml
    wildfly_version: 30.0.1.Final
    wildfly_java_package_name: java-11-openjdk-headless.x86_64
    wildfly_home: "/opt/wildfly-{{ wildfly_version }}"

    instance_http_ports:
      - 8080
      - 8180
      - 8280
    app:
      name: 'info-1.2.war'
      url: 'https://drive.google.com/uc?export=download&id=13K7RCqccgH4zAU1RfOjYMehNaHB0A3Iq'
  collections:
    - middleware_automation.wildfly
  roles:
    - role: wildfly_install
  tasks:

    - name: "Set up for WildFly instance {{ item }}."
      ansible.builtin.include_role:
        name: wildfly_systemd
      vars:
        wildfly_config_base: 'standalone-ha.xml'
        wildfly_instance_id: "{{ item }}"
        instance_name: "wildfly-{{ wildfly_instance_id }}"
        wildfly_config_name: "{{ instance_name }}.xml"
        wildfly_basedir_prefix: "/opt/{{ instance_name }}"
        service_systemd_env_file: "/etc/wildfly-{{ item }}.conf"
        service_systemd_conf_file: "/usr/lib/systemd/system/wildfly-{{ item }}.service"
      loop: "{{ range(0,3) | list }}"

    - name: "Wait for each instance HTTP ports to become available."
      ansible.builtin.wait_for:
        port: "{{ item }}"
      loop: "{{ instance_http_ports }}"

    - name: "Checks that WildFly server is running and accessible."
      ansible.builtin.get_url:
        url: "http://localhost:{{ port }}/"
        dest: "/opt/{{ port }}"
      loop: "{{ instance_http_ports }}"
      loop_control:
        loop_var: port

In short, this playbook uses the Ansible collection for WildFly to, first, install the appserver by using the wildfly_install role. This will download all the artifacts, create the required system groups and users, install dependency (unzip) and so on. At the end of its execution, all the tidbits required to run WildFly on the target host are installed, but the server is not yet running. That’s what happening in the next step.

In the tasks section of the playbook, we then call on another role provided by the collection: wildfly_systemd. This role will take care of integrating WildFly, as a regular system service, into the service manager. Here, we use a loop to ensure that we create not one, but three different services. Each one will have the same configuration (standalone-ha.xml) but runs on different ports, using a different set of directories to store its data.

Run the playbook!

Now, let’s run our Ansible playbook and observe its output:


PLAY [WildFly installation and configuration] **********************************

TASK [Gathering Facts] *********************************************************
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Validating arguments against arg spec 'main'] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Ensure prerequirements are fullfilled.] ***
included: /root/.ansible/collections/ansible_collections/middleware_automation/wildfly/roles/wildfly_install/tasks/prereqs.yml for localhost

TASK [middleware_automation.wildfly.wildfly_install : Validate credentials] ****
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Validate existing zipfiles wildfly-30.0.1.Final.zip for offline installs] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Validate patch version for offline installs] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Validate existing additional zipfiles {{ eap_archive_filename }} for offline installs] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Check that required packages list has been provided.] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Prepare packages list] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Add JDK package java-11-openjdk-headless.x86_64 to packages list] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Install required packages (5)] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Ensure required local user exists.] ***
included: /root/.ansible/collections/ansible_collections/middleware_automation/wildfly/roles/wildfly_install/tasks/user.yml for localhost

TASK [middleware_automation.wildfly.wildfly_install : Check arguments] *********
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Set wildfly group] *******
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Ensure group wildfly exists.] ***
changed: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Ensure user wildfly exists.] ***
changed: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Ensure workdir /opt/ exists.] ***
changed: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Ensure archive_dir /opt/ exists.] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Ensure server is installed] ***
included: /root/.ansible/collections/ansible_collections/middleware_automation/wildfly/roles/wildfly_install/tasks/install.yml for localhost

TASK [middleware_automation.wildfly.wildfly_install : Check arguments] *********
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Check local download archive path] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Set download paths] ******
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Check target archive: /opt//wildfly-30.0.1.Final.zip] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Retrieve archive from website: https://github.com/wildfly/wildfly/releases/download] ***
included: /root/.ansible/collections/ansible_collections/middleware_automation/wildfly/roles/wildfly_install/tasks/install/web.yml for localhost

TASK [middleware_automation.wildfly.wildfly_install : Check arguments] *********
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Download zipfile from https://github.com/wildfly/wildfly/releases/download/30.0.1.Final/wildfly-30.0.1.Final.zip into /work/wildfly-30.0.1.Final.zip] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Retrieve archive from RHN] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Install server using RPM] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Check downloaded archive] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Copy archive to target nodes] ***
changed: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Check target archive: /opt//wildfly-30.0.1.Final.zip] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Verify target archive state: /opt//wildfly-30.0.1.Final.zip] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Read target directory information: /opt/wildfly-30.0.1.Final] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Extract files from /opt//wildfly-30.0.1.Final.zip into /opt/.] ***
changed: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Note: decompression was not executed] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Read information on server home directory: /opt/wildfly-30.0.1.Final] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Check state of server home directory: /opt/wildfly-30.0.1.Final] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Set instance name] *******
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Deploy custom configuration] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Deploy configuration] ****
changed: [localhost]

TASK [Apply latest cumulative patch] *******************************************
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Ensure required parameters for elytron adapter are provided.] ***
skipping: [localhost]

TASK [Install elytron adapter] *************************************************
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Install server using Prospero] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Check wildfly install directory state] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Validate conditions] *****
ok: [localhost]

TASK [Ensure firewalld configuration allows server port (if enabled).] *********
skipping: [localhost]

TASK [Set up for WildFly instance {{ item }}.] *********************************

TASK [middleware_automation.wildfly.wildfly_systemd : Validating arguments against arg spec 'main'] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Check arguments] *********
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Check current EAP patch installed] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Check arguments for yaml configuration] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Check if YAML configuration extension is supported in WildFly] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Check if YAML configuration extension is supported in EAP] ***
skipping: [localhost]

TASK [Ensure required local user and group exists.] ****************************

TASK [middleware_automation.wildfly.wildfly_install : Check arguments] *********
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Set wildfly group] *******
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Ensure group wildfly exists.] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Ensure user wildfly exists.] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Set destination directory for configuration] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Set instance destination directory for configuration] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Check arguments] *********
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Set base directory for instance] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Check arguments] *********
ok: [localhost] => {
    "changed": false,
    "msg": "All assertions passed"
}

TASK [middleware_automation.wildfly.wildfly_systemd : Set instance name] *******
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Set instance name] *******
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Set bind address] ********
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Create basedir /opt/wildfly-00 for instance: wildfly-0] ***
changed: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Create deployment directories for instance: wildfly-0] ***
changed: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Deploy custom configuration] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Deploy configuration] ****
changed: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Include YAML configuration extension] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Check YAML configuration is disabled] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Set systemd envfile destination] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Determine JAVA_HOME for selected JVM] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Determine JAVA_HOME for selected JVM] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Set systemd unit file destination] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Deploy service instance configuration: /etc/wildfly-0.conf] ***
changed: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Deploy Systemd configuration for service: /usr/lib/systemd/system/wildfly-0.service] ***
changed: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Perform daemon-reload to ensure the changes are picked up] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Ensure service is started] ***
included: /root/.ansible/collections/ansible_collections/middleware_automation/wildfly/roles/wildfly_systemd/tasks/service.yml for localhost

TASK [middleware_automation.wildfly.wildfly_systemd : Check arguments] *********
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Set instance wildfly-0 state to started] ***
changed: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Validating arguments against arg spec 'main'] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Check arguments] *********
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Check current EAP patch installed] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Check arguments for yaml configuration] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Check if YAML configuration extension is supported in WildFly] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Check if YAML configuration extension is supported in EAP] ***
skipping: [localhost]

TASK [Ensure required local user and group exists.] ****************************

TASK [middleware_automation.wildfly.wildfly_install : Check arguments] *********
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Set wildfly group] *******
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Ensure group wildfly exists.] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Ensure user wildfly exists.] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Set destination directory for configuration] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Set instance destination directory for configuration] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Check arguments] *********
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Set base directory for instance] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Check arguments] *********
ok: [localhost] => {
    "changed": false,
    "msg": "All assertions passed"
}

TASK [middleware_automation.wildfly.wildfly_systemd : Set instance name] *******
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Set instance name] *******
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Set bind address] ********
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Create basedir /opt/wildfly-11 for instance: wildfly-1] ***
changed: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Create deployment directories for instance: wildfly-1] ***
changed: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Deploy custom configuration] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Deploy configuration] ****
changed: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Include YAML configuration extension] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Check YAML configuration is disabled] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Set systemd envfile destination] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Determine JAVA_HOME for selected JVM] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Determine JAVA_HOME for selected JVM] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Set systemd unit file destination] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Deploy service instance configuration: /etc/wildfly-1.conf] ***
changed: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Deploy Systemd configuration for service: /usr/lib/systemd/system/wildfly-1.service] ***
changed: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Perform daemon-reload to ensure the changes are picked up] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Ensure service is started] ***
included: /root/.ansible/collections/ansible_collections/middleware_automation/wildfly/roles/wildfly_systemd/tasks/service.yml for localhost

TASK [middleware_automation.wildfly.wildfly_systemd : Check arguments] *********
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Set instance wildfly-1 state to started] ***
changed: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Validating arguments against arg spec 'main'] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Check arguments] *********
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Check current EAP patch installed] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Check arguments for yaml configuration] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Check if YAML configuration extension is supported in WildFly] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Check if YAML configuration extension is supported in EAP] ***
skipping: [localhost]

TASK [Ensure required local user and group exists.] ****************************

TASK [middleware_automation.wildfly.wildfly_install : Check arguments] *********
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Set wildfly group] *******
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Ensure group wildfly exists.] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_install : Ensure user wildfly exists.] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Set destination directory for configuration] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Set instance destination directory for configuration] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Check arguments] *********
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Set base directory for instance] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Check arguments] *********
ok: [localhost] => {
    "changed": false,
    "msg": "All assertions passed"
}

TASK [middleware_automation.wildfly.wildfly_systemd : Set instance name] *******
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Set instance name] *******
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Set bind address] ********
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Create basedir /opt/wildfly-22 for instance: wildfly-2] ***
changed: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Create deployment directories for instance: wildfly-2] ***
changed: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Deploy custom configuration] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Deploy configuration] ****
changed: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Include YAML configuration extension] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Check YAML configuration is disabled] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Set systemd envfile destination] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Determine JAVA_HOME for selected JVM] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Determine JAVA_HOME for selected JVM] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Set systemd unit file destination] ***
skipping: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Deploy service instance configuration: /etc/wildfly-2.conf] ***
changed: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Deploy Systemd configuration for service: /usr/lib/systemd/system/wildfly-2.service] ***
changed: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Perform daemon-reload to ensure the changes are picked up] ***
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Ensure service is started] ***
included: /root/.ansible/collections/ansible_collections/middleware_automation/wildfly/roles/wildfly_systemd/tasks/service.yml for localhost

TASK [middleware_automation.wildfly.wildfly_systemd : Check arguments] *********
ok: [localhost]

TASK [middleware_automation.wildfly.wildfly_systemd : Set instance wildfly-2 state to started] ***
changed: [localhost]

TASK [Wait for each instance HTTP ports to become available.] ******************
ok: [localhost] => (item=8080)
ok: [localhost] => (item=8180)
ok: [localhost] => (item=8280)

TASK [Checks that WildFly server is running and accessible.] *******************
changed: [localhost] => (item=8080)
changed: [localhost] => (item=8180)
changed: [localhost] => (item=8280)

PLAY RECAP *********************************************************************
localhost                  : ok=105  changed=25   unreachable=0    failed=0    skipped=46   rescued=0    ignored=0

Note that the playbook is not that long, but it does a lot for us. It performs almost 100 different tasks! Starting by automatically installing the dependencies, including the JVM required by WildFly, along with downloading its binaries. And the wildfly_systemd role does even more, effortlessly setting up three distinct services, each with its own set of ports and directory layout to store instance-specific data.

Even better, the WildFly installation is NOT duplicated. All of the binaries live under the /opt/wildfly-27.0.1 directory, but all the data files of each instance are stored in separate folders. This means that we just need to update the binaries, once, and then restart the instances, to deploy a patch or upgrade to a new version of WildFly.

On top of everything, we configured the instances to use the standalone-ha.xml configuration as the baseline, so they are already set up for clustering.
Check that everything worked as expected

The easiest way to confirm that the playbook did indeed install WildFly and started three instances of the appserver is to use the systemctl command to check the associate services state:

● wildfly-0.service - JBoss EAP (standalone mode)
   Loaded: loaded (/usr/lib/systemd/system/wildfly-0.service; enabled; vendor preset: disabled)
   Active: active (running) since Wed 2024-01-17 12:06:35 UTC; 2min 11s ago
 Main PID: 747 (standalone.sh)
   CGroup: /system.slice/wildfly-0.service
           ├─747 /bin/sh /opt/wildfly-30.0.1.Final/bin/standalone.sh -c wildfly-0.xml -b 0.0.0.0 -bmanagement 127.0.0.1 -Djboss.bind.address.private=127.0.0.1 -Djboss.default.multicast.address=230.0.0.4 -Djboss.server.config.dir=/opt/wildfly-30.0.1.Final/standalone/configuration/ -Djboss.server.base.dir=/opt/wildfly-00 -Djboss.tx.node.id=wildfly-0 -Djboss.socket.binding.port-offset=0 -Djboss.node.name=wildfly-0 -Dwildfly.statistics-enabled=false
           └─903 /etc/alternatives/jre_11/bin/java -D[Standalone] -Djdk.serialFilter=maxbytes=10485760;maxdepth=128;maxarray=100000;maxrefs=300000 -Xmx1024M -Xms512M --add-exports=java.desktop/sun.awt=ALL-UNNAMED --add-exports=java.naming/com.sun.jndi.ldap=ALL-UNNAMED --add-exports=java.naming/com.sun.jndi.url.ldap=ALL-UNNAMED --add-exports=java.naming/com.sun.jndi.url.ldaps=ALL-UNNAMED --add-exports=jdk.naming.dns/com.sun.jndi.dns=ALL-UNNAMED --add-opens=java.base/com.sun.net.ssl.internal.ssl=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.invoke=ALL-UNNAMED --add-opens=java.base/java.lang.reflect=ALL-UNNAMED --add-opens=java.base/java.io=ALL-UNNAMED --add-opens=java.base/java.net=ALL-UNNAMED --add-opens=java.base/java.security=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.util.concurrent=ALL-UNNAMED --add-opens=java.management/javax.management=ALL-UNNAMED --add-opens=java.naming/javax.naming=ALL-UNNAMED -Dorg.jboss.boot.log.file=/opt/wildfly-00/log/server.log -Dlogging.configuration=file:/opt/wildfly-30.0.1.Final/standalone/configuration/logging.properties -jar /opt/wildfly-30.0.1.Final/jboss-modules.jar -mp /opt/wildfly-30.0.1.Final/modules org.jboss.as.standalone -Djboss.home.dir=/opt/wildfly-30.0.1.Final -Djboss.server.base.dir=/opt/wildfly-00 -c wildfly-0.xml -b 0.0.0.0 -bmanagement 127.0.0.1 -Djboss.bind.address.private=127.0.0.1 -Djboss.default.multicast.address=230.0.0.4 -Djboss.server.config.dir=/opt/wildfly-30.0.1.Final/standalone/configuration/ -Djboss.server.base.dir=/opt/wildfly-00 -Djboss.tx.node.id=wildfly-0 -Djboss.socket.binding.port-offset=0 -Djboss.node.name=wildfly-0 -Dwildfly.statistics-enabled=false

Jan 17 12:06:38 299529bf09bb standalone.sh[903]: 12:06:38,601 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 84) MODCLUSTER000032: Listening to proxy advertisements on /224.0.1.105:23364
Jan 17 12:06:38 299529bf09bb standalone.sh[903]: 12:06:38,661 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0006: Undertow HTTPS listener https listening on [0:0:0:0:0:0:0:0]:8443
Jan 17 12:06:38 299529bf09bb standalone.sh[903]: 12:06:38,670 INFO  [org.jboss.as.ejb3] (MSC service thread 1-6) WFLYEJB0493: Jakarta Enterprise Beans subsystem suspension complete
Jan 17 12:06:38 299529bf09bb standalone.sh[903]: 12:06:38,718 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-8) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
Jan 17 12:06:38 299529bf09bb standalone.sh[903]: 12:06:38,752 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-7) WFLYDS0013: Started FileSystemDeploymentService for directory /opt/wildfly-00/deployments
Jan 17 12:06:38 299529bf09bb standalone.sh[903]: 12:06:38,814 INFO  [org.jboss.ws.common.management] (MSC service thread 1-1) JBWS022052: Starting JBossWS 7.0.0.Final (Apache CXF 4.0.0)
Jan 17 12:06:38 299529bf09bb standalone.sh[903]: 12:06:38,924 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
Jan 17 12:06:38 299529bf09bb standalone.sh[903]: 12:06:38,928 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
Jan 17 12:06:38 299529bf09bb standalone.sh[903]: 12:06:38,928 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
Jan 17 12:06:38 299529bf09bb standalone.sh[903]: 12:06:38,930 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 30.0.1.Final (WildFly Core 22.0.2.Final) started in 2736ms - Started 311 of 708 services (497 services are lazy, passive or on-demand) - Server configuration file in use: wildfly-0.xml

Deploy an application to the Wildlfy cluster

Now, our three WildFly are running, but the cluster has yet to form. Indeed, with no apps there is no reason for the cluster to exist. Let’s modify our Ansible playbook to deploy a simple application to all instances; this will allow us to check that the cluster is working as expected. To achieve this, we’ll leverage another role provided by the WildFly collection: wildfly_utils.

In our case, we will use the jboss_cli.yml task file, which encapsulates the running of JBoss command-line interface (CLI) queries:

…
  post_tasks:
      - name: "Ensures webapp {{ app.name }} has been retrieved from {{ app.url }}."
        ansible.builtin.get_url:
          url: "{{ app.url }}"
          dest: "{{ wildfly_install_workdir }}/{{ app.name }}"

      - name: "Deploy webapp"
        ansible.builtin.include_role:
          name: wildfly_utils
          tasks_from: jboss_cli.yml
        vars:
          jboss_home: "{{ wildfly_home }}"
          query: "'deploy --force {{ wildfly_install_workdir }}/{{ app.name }}'"
          jboss_cli_controller_port: "{{ item }}"
        loop:
          - 9990
          - 10090
          - 10190

Now, we will once again execute our playbook so that the web application is deployed on all instances. Once the automation completes successfully, the deployment will trigger the formation of the cluster.

Verify that the WildFly cluster is running and the app is deployed

You can verify the cluster formation by looking at the log files of any of the three instances:

…

2022-12-23 15:02:08,252 INFO  [org.infinispan.CLUSTER] (thread-7,ejb,jboss-eap-0) ISPN000094: Received new cluster view for channel ejb: [jboss-eap-0] (3) [jboss-eap-0, jboss-eap-1, jboss-eap-2]
…

Using the Ansible collection as an installer for Wildfly

Last remark: while the collection is designed to be used inside a playbook, you can also use the provided playbook to directly install Wildfly:

$ ansible-playbook -i inventory middleware_automation.wildfly.playbook

Conclusion

Here you go, with a short and simple playbook, we have fully automated the deployment of a WildFly cluster! This playbook can now be used against one, two, three remote machine or even hundreds of them! I hope this will post will have been informative and that it’ll have convinced you to use Ansible to set up your own WildFly servers!

Automate message queue deployment on JBoss EAP

Pelisse Romain — Thu, 04 Jan 2024 18:00:00 +0000

For decades now, software projects have relied on messaging APIs to exchange data. In the Java/Java EE ecosystem, this method of asynchronous communication has been standardized by the JMS specification. In many cases, individuals and organizations leverage Red Hat JBoss Enterprise Application Platform (JBoss EAP) to act as message-oriented middleware (MOM), which facilitates the management of message queues and topics.

Messaging ensures that no messages are lost as they are transmitted from the client and delivered to interested parties. On top of that, JBoss EAP provides authentication and other security-focused capabilities on top of the management functions.

In this article, we'll show how to fully automate the setup of JBoss EAP and a JMS queue using Ansible so that we can easily make this service available.

Prerequisites and installation

Install Ansible

First, we’ll set up our Ansible control machine, which is where the automation will be executed. On this system, we need to install Ansible as the first step:

$ sudo dnf install -y ansible-core

Note that the package name has changed recently from ansible to ansible-core.

Configure Ansible to use Red Hat Automation Hub

An extension to Ansible, an Ansible collection, dedicated to Red Hat JBoss EAP is available from Automation Hub. Red Hat customers need to add credentials and the location for Red Hat Automation Hub to their Ansible configuration file (ansible.cfg) to be able to install the content using the ansible-galaxy command-line tool.

Be sure to replace the with the API token you retrieved from Automation Hub. For more information about using Red Hat Automation Hub, please refer to the associated documentation.

#ansible.cfg:
[defaults]
host_key_checking = False
retry_files_enabled = False
nocows = 1

[inventory]
# fail more helpfully when the inventory file does not parse (Ansible 2.4+)
unparsed_is_failed=true

[galaxy]
server_list = automation_hub, galaxy
[galaxy_server.galaxy]
url=https://galaxy.ansible.com/
[galaxy_server.automation_hub]
url=https://cloud.redhat.com/api/automation-hub/
auth_url=https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token
token=<paste-your-token-here>

Install the Ansible collection for JBoss EAP

With this configuration, we can now install the Ansible collection for JBoss EAP (redhat.eap) available on Red Hat Ansible Automation Hub:

$ ansible-galaxy collection install redhat.eap
Starting galaxy collection install process
Process install dependency map
Starting collection install process
Downloading https://console.redhat.com/api/automation-hub/v3/plugin/ansible/content/published/collections/artifacts/redhat-eap-1.3.4.tar.gz to /root/.ansible/tmp/ansible-local-2529rs7zh7/tmps_4n2eyj/redhat-eap-1.3.4-lr8dvcxo
Installing 'redhat.eap:1.3.4' to '/root/.ansible/collections/ansible_collections/redhat/eap'
Downloading https://console.redhat.com/api/automation-hub/v3/plugin/ansible/content/published/collections/artifacts/redhat-runtimes_common-1.1.0.tar.gz to /root/.ansible/tmp/ansible-local-2529rs7zh7/tmps_4n2eyj/redhat-runtimes_common-1.1.0-o6qfkgju
redhat.eap:1.3.4 was installed successfully
Installing 'redhat.runtimes_common:1.1.0' to '/root/.ansible/collections/ansible_collections/redhat/runtimes_common'
Downloading https://console.redhat.com/api/automation-hub/v3/plugin/ansible/content/published/collections/artifacts/ansible-posix-1.5.4.tar.gz to /root/.ansible/tmp/ansible-local-2529rs7zh7/tmps_4n2eyj/ansible-posix-1.5.4-4pgukpuo
redhat.runtimes_common:1.1.0 was installed successfully
Installing 'ansible.posix:1.5.4' to '/root/.ansible/collections/ansible_collections/ansible/posix'
ansible.posix:1.5.4 was installed successfully

As we will describe a little later on, this extension for Ansible will manage the entire installation and configuration of the Java application server on the target systems.

Inventory file

Before we can start using our collection, we need to provide the inventory of targets to Ansible. There are several ways to provide this information to the automation tool, but for the purposes of this article, we elected to use a simple ini-formatted inventory file.

To easily reproduce this article's demonstration, you can use the same control node as the target. This also removes the need to deploy the required SSH key on all the systems involved. To do so, simply use the following inventory file by creating a file called inventory:

[all]
localhost ansible_connection=local

[messaging_servers]
localhost ansible_connection=local

Deploying JBoss EAP

JBoss EAP installation

Before we configure the JMS queues that will be configured by Ansible, we'll first deploy JBoss EAP. Once the server is successfully running on the target system, we'll adjust the automation to add the required configuration to set up the messaging layer. This is purely for didactic purposes.

Since we can leverage the content of the redhat.eap collection, the playbook to install EAP and set it up as systemd service on the target system is minimal. Create a file called eap_jms.yml with the following content:

---
- name: "Deploy a JBoss EAP"
  hosts: messaging_servers
  vars:
    eap_apply_cp: true
    eap_version: 7.4.0
    eap_offline_install: false
    eap_config_base: 'standalone-full.xml'
  collections:
    - redhat.eap
  roles:
    - eap_install
    - eap_systemd

Note that the Ansible collection for JBoss EAP will also take care of downloading the required assets from the Red Hat Customer Portal (the archive containing the Java app server files). However, one does need to provide the credentials associated with a service account. A Red Hat customer can manage service accounts using the hybrid cloud console. Within this portal, on the service accounts tab, you can create a new service account if one does not already exist.

**Note: **The values obtained from the hybrid cloud console are sensitive and should be managed accordingly. For the purpose of this article, the value is passed to the ansible-playbook command line. Alternatively, ansible-vault could be used to enforce additional defense mechanisms:

$ ansible-playbook -i inventory -e rhn_username=<client_id> -e rhn_password=<client_secret> eap_jms.yml

PLAY [Deploy a JBoss EAP] ******************************************************

TASK [Gathering Facts] *********************************************************
ok: [localhost]

TASK [redhat.eap.eap_install : Validating arguments against arg spec 'main'] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure prerequirements are fullfilled.] *********
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_install/tasks/prereqs.yml for localhost

TASK [redhat.eap.eap_install : Validate credentials] ***************************
ok: [localhost]

TASK [redhat.eap.eap_install : Validate existing zipfiles for offline installs] ***
skipping: [localhost]

TASK [redhat.eap.eap_install : Validate existing zipfiles for offline installs] ***
skipping: [localhost]

TASK [redhat.eap.eap_install : Check that required packages list has been provided.] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Prepare packages list] **************************
skipping: [localhost]

TASK [redhat.eap.eap_install : Add JDK package java-11-openjdk-headless to packages list] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Install required packages (4)] ******************
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure required local user exists.] *************
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_install/tasks/user.yml for localhost

TASK [redhat.eap.eap_install : Check arguments] ********************************
ok: [localhost]

TASK [redhat.eap.eap_install : Set eap group] **********************************
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure group eap exists.] ***********************
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure user eap exists.] ************************
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure workdir /opt/jboss_eap/ exists.] *********
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure archive_dir /opt/jboss_eap/ exists.] *****
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure server is installed] *********************
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_install/tasks/install.yml for localhost

TASK [redhat.eap.eap_install : Check arguments] ********************************
ok: [localhost]

TASK [redhat.eap.eap_install : Check local download archive path] **************
ok: [localhost]

TASK [redhat.eap.eap_install : Set download paths] *****************************
ok: [localhost]

TASK [redhat.eap.eap_install : Check target archive: /opt/jboss_eap//jboss-eap-7.4.0.zip] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Retrieve archive from website: https://github.com/eap/eap/releases/download] ***
skipping: [localhost]

TASK [redhat.eap.eap_install : Retrieve archive from RHN] **********************
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_install/tasks/install/rhn.yml for localhost

TASK [redhat.eap.eap_install : Check arguments] ********************************
ok: [localhost]

TASK [Download JBoss EAP from CSP] *********************************************

TASK [redhat.eap.eap_utils : Check arguments] **********************************
ok: [localhost]

TASK [redhat.eap.eap_utils : Retrieve product download using JBoss Network API] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Determine install zipfile from search results] ****
ok: [localhost]

TASK [redhat.eap.eap_utils : Download Red Hat Single Sign-On] ******************
ok: [localhost]

TASK [redhat.eap.eap_install : Install server using RPM] ***********************
skipping: [localhost]

TASK [redhat.eap.eap_install : Check downloaded archive] ***********************
ok: [localhost]

TASK [redhat.eap.eap_install : Copy archive to target nodes] *******************
changed: [localhost]

TASK [redhat.eap.eap_install : Check target archive: /opt/jboss_eap//jboss-eap-7.4.0.zip] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Verify target archive state: /opt/jboss_eap//jboss-eap-7.4.0.zip] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Read target directory information: /opt/jboss_eap/jboss-eap-7.4/] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Extract files from /opt/jboss_eap//jboss-eap-7.4.0.zip into /opt/jboss_eap/.] ***
changed: [localhost]

TASK [redhat.eap.eap_install : Note: decompression was not executed] ***********
skipping: [localhost]

TASK [redhat.eap.eap_install : Read information on server home directory: /opt/jboss_eap/jboss-eap-7.4/] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Check state of server home directory: /opt/jboss_eap/jboss-eap-7.4/] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Set instance name] ******************************
ok: [localhost]

TASK [redhat.eap.eap_install : Deploy custom configuration] ********************
skipping: [localhost]

TASK [redhat.eap.eap_install : Deploy configuration] ***************************
changed: [localhost]

TASK [redhat.eap.eap_install : Ensure required parameters for cumulative patch application are provided.] ***
skipping: [localhost]

TASK [Apply latest cumulative patch] *******************************************
skipping: [localhost]

TASK [redhat.eap.eap_install : Ensure required parameters for elytron adapter are provided.] ***
skipping: [localhost]

TASK [Install elytron adapter] *************************************************
skipping: [localhost]

TASK [redhat.eap.eap_install : Install server using Prospero] ******************
skipping: [localhost]

TASK [redhat.eap.eap_install : Check eap install directory state] **************
ok: [localhost]

TASK [redhat.eap.eap_install : Validate conditions] ****************************
ok: [localhost]

TASK [Ensure firewalld configuration allows server port (if enabled).] *********
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Validating arguments against arg spec 'main'] ***
ok: [localhost]

TASK [redhat.eap.eap_systemd : Check arguments] ********************************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Check current EAP patch installed] **************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Check arguments for yaml configuration] *********
skipping: [localhost]

TASK [Ensure required local user and group exists.] ****************************

TASK [redhat.eap.eap_install : Check arguments] ********************************
ok: [localhost]

TASK [redhat.eap.eap_install : Set eap group] **********************************
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure group eap exists.] ***********************
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure user eap exists.] ************************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Set destination directory for configuration] ****
ok: [localhost]

TASK [redhat.eap.eap_systemd : Set instance destination directory for configuration] ***
ok: [localhost]

TASK [redhat.eap.eap_systemd : Check arguments] ********************************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Set base directory for instance] ****************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Check arguments] ********************************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Set instance name] ******************************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Set instance name] ******************************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Set bind address] *******************************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Create basedir /opt/jboss_eap/jboss-eap-7.4//standalone for instance: eap] ***
ok: [localhost]

TASK [redhat.eap.eap_systemd : Create deployment directories for instance: eap] ***
ok: [localhost]

TASK [redhat.eap.eap_systemd : Deploy custom configuration] ********************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Deploy configuration] ***************************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Include YAML configuration extension] ***********
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Check YAML configuration is disabled] ***********
ok: [localhost]

TASK [redhat.eap.eap_systemd : Set systemd envfile destination] ****************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Determine JAVA_HOME for selected JVM RPM] *******
ok: [localhost]

TASK [redhat.eap.eap_systemd : Set systemd unit file destination] **************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Deploy service instance configuration: /etc//eap.conf] ***
changed: [localhost]

TASK [redhat.eap.eap_systemd : Deploy Systemd configuration for service: /usr/lib/systemd/system/eap.service] ***
changed: [localhost]

TASK [redhat.eap.eap_systemd : Perform daemon-reload to ensure the changes are picked up] ***
ok: [localhost]

TASK [redhat.eap.eap_systemd : Ensure service is started] **********************
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_systemd/tasks/service.yml for localhost

TASK [redhat.eap.eap_systemd : Check arguments] ********************************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Set instance eap state to started] **************
changed: [localhost]

PLAY RECAP *********************************************************************
localhost                  : ok=59   changed=6    unreachable=0    failed=0    skipped=22   rescued=0    ignored=0

Validating the installation

Before going any further with our automation, we will be thorough and add a validation step to double-check that the application server is not only running but also functional. This will ensure, down the road, that any JMS-related issue only affects this subsystem.

The Ansible collection for JBoss EAP comes with a handy role, called eap_validation, for this purpose, so it's fairly easy to add this step to our playbook:

---
- name: "Deploy a JBoss EAP"
  hosts: messaging_servers
  vars:
    eap_apply_cp: true
    eap_version: 7.4.0
    eap_offline_install: false
    eap_config_base: 'standalone-full.xml'
  collections:
    - redhat.eap
  roles:
    - eap_install
    - eap_systemd
    - eap_validation

Let's execute our playbook once again and observe the execution of this validation step:

$ ansible-playbook -i inventory -e rhn_username=<client_id> -e rhn_password=<client_secret> eap_jms.yml

PLAY [Deploy a JBoss EAP] ******************************************************

TASK [Gathering Facts] *********************************************************
ok: [localhost]

TASK [redhat.eap.eap_install : Validating arguments against arg spec 'main'] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure prerequirements are fullfilled.] *********
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_install/tasks/prereqs.yml for localhost

TASK [redhat.eap.eap_install : Validate credentials] ***************************
ok: [localhost]

TASK [redhat.eap.eap_install : Validate existing zipfiles for offline installs] ***
skipping: [localhost]

TASK [redhat.eap.eap_install : Validate existing zipfiles for offline installs] ***
skipping: [localhost]

TASK [redhat.eap.eap_install : Check that required packages list has been provided.] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Prepare packages list] **************************
skipping: [localhost]

TASK [redhat.eap.eap_install : Add JDK package java-11-openjdk-headless to packages list] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Install required packages (4)] ******************
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure required local user exists.] *************
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_install/tasks/user.yml for localhost

TASK [redhat.eap.eap_install : Check arguments] ********************************
ok: [localhost]

TASK [redhat.eap.eap_install : Set eap group] **********************************
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure group eap exists.] ***********************
changed: [localhost]

TASK [redhat.eap.eap_install : Ensure user eap exists.] ************************
changed: [localhost]

TASK [redhat.eap.eap_install : Ensure workdir /opt/jboss_eap/ exists.] *********
changed: [localhost]

TASK [redhat.eap.eap_install : Ensure archive_dir /opt/jboss_eap/ exists.] *****
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure server is installed] *********************
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_install/tasks/install.yml for localhost

TASK [redhat.eap.eap_install : Check arguments] ********************************
ok: [localhost]

TASK [redhat.eap.eap_install : Check local download archive path] **************
ok: [localhost]

TASK [redhat.eap.eap_install : Set download paths] *****************************
ok: [localhost]

TASK [redhat.eap.eap_install : Check target archive: /opt/jboss_eap//jboss-eap-7.4.0.zip] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Retrieve archive from website: https://github.com/eap/eap/releases/download] ***
skipping: [localhost]

TASK [redhat.eap.eap_install : Retrieve archive from RHN] **********************
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_install/tasks/install/rhn.yml for localhost

TASK [redhat.eap.eap_install : Check arguments] ********************************
ok: [localhost]

TASK [Download JBoss EAP from CSP] *********************************************

TASK [redhat.eap.eap_utils : Check arguments] **********************************
ok: [localhost]

TASK [redhat.eap.eap_utils : Retrieve product download using JBoss Network API] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Determine install zipfile from search results] ****
ok: [localhost]

TASK [redhat.eap.eap_utils : Download Red Hat Single Sign-On] ******************
ok: [localhost]

TASK [redhat.eap.eap_install : Install server using RPM] ***********************
skipping: [localhost]

TASK [redhat.eap.eap_install : Check downloaded archive] ***********************
ok: [localhost]

TASK [redhat.eap.eap_install : Copy archive to target nodes] *******************
changed: [localhost]

TASK [redhat.eap.eap_install : Check target archive: /opt/jboss_eap//jboss-eap-7.4.0.zip] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Verify target archive state: /opt/jboss_eap//jboss-eap-7.4.0.zip] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Read target directory information: /opt/jboss_eap/jboss-eap-7.4/] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Extract files from /opt/jboss_eap//jboss-eap-7.4.0.zip into /opt/jboss_eap/.] ***
changed: [localhost]

TASK [redhat.eap.eap_install : Note: decompression was not executed] ***********
skipping: [localhost]

TASK [redhat.eap.eap_install : Read information on server home directory: /opt/jboss_eap/jboss-eap-7.4/] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Check state of server home directory: /opt/jboss_eap/jboss-eap-7.4/] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Set instance name] ******************************
ok: [localhost]

TASK [redhat.eap.eap_install : Deploy custom configuration] ********************
skipping: [localhost]

TASK [redhat.eap.eap_install : Deploy configuration] ***************************
changed: [localhost]

TASK [redhat.eap.eap_install : Ensure required parameters for cumulative patch application are provided.] ***
skipping: [localhost]

TASK [Apply latest cumulative patch] *******************************************
skipping: [localhost]

TASK [redhat.eap.eap_install : Ensure required parameters for elytron adapter are provided.] ***
skipping: [localhost]

TASK [Install elytron adapter] *************************************************
skipping: [localhost]

TASK [redhat.eap.eap_install : Install server using Prospero] ******************
skipping: [localhost]

TASK [redhat.eap.eap_install : Check eap install directory state] **************
ok: [localhost]

TASK [redhat.eap.eap_install : Validate conditions] ****************************
ok: [localhost]

TASK [Ensure firewalld configuration allows server port (if enabled).] *********
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Validating arguments against arg spec 'main'] ***
ok: [localhost]

TASK [redhat.eap.eap_systemd : Check arguments] ********************************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Check current EAP patch installed] **************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Check arguments for yaml configuration] *********
skipping: [localhost]

TASK [Ensure required local user and group exists.] ****************************

TASK [redhat.eap.eap_install : Check arguments] ********************************
ok: [localhost]

TASK [redhat.eap.eap_install : Set eap group] **********************************
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure group eap exists.] ***********************
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure user eap exists.] ************************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Set destination directory for configuration] ****
ok: [localhost]

TASK [redhat.eap.eap_systemd : Set instance destination directory for configuration] ***
ok: [localhost]

TASK [redhat.eap.eap_systemd : Check arguments] ********************************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Set base directory for instance] ****************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Check arguments] ********************************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Set instance name] ******************************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Set instance name] ******************************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Set bind address] *******************************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Create basedir /opt/jboss_eap/jboss-eap-7.4//standalone for instance: eap] ***
ok: [localhost]

TASK [redhat.eap.eap_systemd : Create deployment directories for instance: eap] ***
ok: [localhost]

TASK [redhat.eap.eap_systemd : Deploy custom configuration] ********************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Deploy configuration] ***************************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Include YAML configuration extension] ***********
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Check YAML configuration is disabled] ***********
ok: [localhost]

TASK [redhat.eap.eap_systemd : Set systemd envfile destination] ****************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Determine JAVA_HOME for selected JVM RPM] *******
ok: [localhost]

TASK [redhat.eap.eap_systemd : Set systemd unit file destination] **************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Deploy service instance configuration: /etc//eap.conf] ***
changed: [localhost]

TASK [redhat.eap.eap_systemd : Deploy Systemd configuration for service: /usr/lib/systemd/system/eap.service] ***
changed: [localhost]

TASK [redhat.eap.eap_systemd : Perform daemon-reload to ensure the changes are picked up] ***
ok: [localhost]

TASK [redhat.eap.eap_systemd : Ensure service is started] **********************
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_systemd/tasks/service.yml for localhost

TASK [redhat.eap.eap_systemd : Check arguments] ********************************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Set instance eap state to started] **************
changed: [localhost]

TASK [redhat.eap.eap_validation : Validating arguments against arg spec 'main'] ***
ok: [localhost]

TASK [redhat.eap.eap_validation : Ensure required parameters are provided.] ****
ok: [localhost]

TASK [redhat.eap.eap_validation : Ensure user eap were created.] ***************
ok: [localhost]

TASK [redhat.eap.eap_validation : Validate state of user: eap] *****************
ok: [localhost]

TASK [redhat.eap.eap_validation : Ensure user eap were created.] ***************
ok: [localhost]

TASK [redhat.eap.eap_validation : Validate state of group: eap.] ***************
ok: [localhost]

TASK [redhat.eap.eap_validation : Wait for HTTP port 8080 to become available.] ***
ok: [localhost]

TASK [redhat.eap.eap_validation : Check if web connector is accessible] ********
ok: [localhost]

TASK [redhat.eap.eap_validation : Populate service facts] **********************
ok: [localhost]

TASK [redhat.eap.eap_validation : Check if service is running] *****************
ok: [localhost] => {
    "changed": false,
    "msg": "All assertions passed"
}

TASK [redhat.eap.eap_validation : Verify server's internal configuration] ******
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_validation/tasks/verify_with_cli_queries.yml for localhost => (item={'query': '/core-service=server-environment:read-attribute(name=start-gracefully)'})
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_validation/tasks/verify_with_cli_queries.yml for localhost => (item={'query': '/subsystem=undertow/server=default-server/http-listener=default:read-attribute(name=enabled)'})

TASK [redhat.eap.eap_validation : Ensure required parameters are provided.] ****
ok: [localhost]

TASK [Use CLI query to validate service state: /core-service=server-environment:read-attribute(name=start-gracefully)] ***

TASK [redhat.eap.eap_utils : Ensure required params for JBoss CLI have been provided] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Ensure server's management interface is reachable] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Execute CLI query '/core-service=server-environment:read-attribute(name=start-gracefully)'] ***
ok: [localhost]

TASK [redhat.eap.eap_validation : Validate CLI query was successful] ***********
ok: [localhost]

TASK [redhat.eap.eap_validation : Transform output to JSON] ********************
ok: [localhost]

TASK [redhat.eap.eap_validation : Display transformed result] ******************
skipping: [localhost]

TASK [redhat.eap.eap_validation : Check that query was successfully performed.] ***
ok: [localhost]

TASK [redhat.eap.eap_validation : Ensure required parameters are provided.] ****
ok: [localhost]

TASK [Use CLI query to validate service state: /subsystem=undertow/server=default-server/http-listener=default:read-attribute(name=enabled)] ***

TASK [redhat.eap.eap_utils : Ensure required params for JBoss CLI have been provided] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Ensure server's management interface is reachable] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Execute CLI query '/subsystem=undertow/server=default-server/http-listener=default:read-attribute(name=enabled)'] ***
ok: [localhost]

TASK [redhat.eap.eap_validation : Validate CLI query was successful] ***********
ok: [localhost]

TASK [redhat.eap.eap_validation : Transform output to JSON] ********************
ok: [localhost]

TASK [redhat.eap.eap_validation : Display transformed result] ******************
skipping: [localhost]

TASK [redhat.eap.eap_validation : Check that query was successfully performed.] ***
ok: [localhost]

TASK [redhat.eap.eap_validation : Ensure yaml setup] ***************************
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_validation/tasks/yaml_setup.yml for localhost

TASK [Check standard-sockets configuration settings] ***************************

TASK [redhat.eap.eap_utils : Ensure required params for JBoss CLI have been provided] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Ensure server's management interface is reachable] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Execute CLI query /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=mail-smtp:read-attribute(name=host)] ***
ok: [localhost]

TASK [redhat.eap.eap_validation : Display result of standard-sockets configuration settings] ***
ok: [localhost]

TASK [Check ejb configuration settings] ****************************************

TASK [redhat.eap.eap_utils : Ensure required params for JBoss CLI have been provided] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Ensure server's management interface is reachable] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Execute CLI query /subsystem=ejb3:read-attribute(name=default-resource-adapter-name)] ***
ok: [localhost]

TASK [redhat.eap.eap_validation : Display result of ejb configuration settings] ***
ok: [localhost]

TASK [Check ee configuration settings] *****************************************

TASK [redhat.eap.eap_utils : Ensure required params for JBoss CLI have been provided] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Ensure server's management interface is reachable] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Execute CLI query /subsystem=ee/service=default-bindings:read-attribute(name=jms-connection-factory)] ***
ok: [localhost]

TASK [redhat.eap.eap_validation : Display result of ee configuration settings] ***
ok: [localhost]

PLAY RECAP *********************************************************************
localhost                  : ok=98   changed=9    unreachable=0    failed=0    skipped=24   rescued=0    ignored=0

If the execution of the playbook completed without error, validation of the application server passed successfully.

Deploying JMS queues on JBoss EAP using Ansible

Changing EAP configuration

Because the JMS subsystem is not used in the default JBoss EAP server configuration (standalone.xml), we also need to use a different profile (standalone-alone.xml). This is why, in the playbook above, we are specifying the required configuration profile:

---
- name: "Deploy a JBoss EAP"
  hosts: messaging_servers
  vars:
      eap_apply_cp: true
      eap_version: 7.4.0
      eap_offline_install: false
      eap_config_base: 'standalone-full.xml'
  collections:
    - redhat.eap
  roles:
    - eap_install
    - eap_systemd
    - eap_validation

Leveraging the YAML config feature of EAP using Ansible

In the previous section, JBoss EAP was installed and configured as a systemd service on the target systems. Now, we will update this automation to change the configuration of the app server to ensure a JMS queue is deployed and made available.

In order to accomplish this goal, we just need to provide a YAML definition with the appropriate configuration for the JMS subsystem of JBoss EAP. This configuration file is used by the app server, on boot, to update its configuration.

To achieve this, we need to add another file to our project that we named jms_configuration.yml.j2. While the content of the file itself is YAML, the extension is .j2 because it's a jinja2 template, which allows us to take advantage of the advanced, dynamic capabilities provided by Ansible.

jms_configuration.yml.j2:
wildfly-configuration:
  subsystem:
    messaging-activemq:
      server:
        default:
          jms-queue:
            {{ queue.name }}:
              entries:
                - '{{ queue.entry }}'

Below, you'll see the playbook updated with all the required parameters to deploy the JMQ queue on JBoss EAP:

---
- name: "Deploy a Red Hat JBoss EAP server and set up a JMS Queue"
  hosts: messaging_servers
  vars:
    eap_apply_cp: true
    eap_version: 7.4.0
    eap_offline_install: false
    eap_config_base: 'standalone-full.xml'
    eap_enable_yml_config: True
    queue:
      name: MyQueue
      entry: 'java:/jms/queue/MyQueue'
    eap_yml_configs:
      - jms_configuration.yml.j2
  collections:
    - redhat.eap
  roles:
    - eap_install
    - eap_systemd
    - eap_validation

Let's execute this playbook again:

$ ansible-playbook -i inventory -e rhn_username=<client_id> -e rhn_password=<client_secret> eap_jms.yml

PLAY [Deploy a Red Hat JBoss EAP server and set up a JMS Queue] ****************

TASK [Gathering Facts] *********************************************************
ok: [localhost]

TASK [redhat.eap.eap_install : Validating arguments against arg spec 'main'] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure prerequirements are fullfilled.] *********
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_install/tasks/prereqs.yml for localhost

TASK [redhat.eap.eap_install : Validate credentials] ***************************
ok: [localhost]

TASK [redhat.eap.eap_install : Validate existing zipfiles for offline installs] ***
skipping: [localhost]

TASK [redhat.eap.eap_install : Validate existing zipfiles for offline installs] ***
skipping: [localhost]

TASK [redhat.eap.eap_install : Check that required packages list has been provided.] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Prepare packages list] **************************
skipping: [localhost]

TASK [redhat.eap.eap_install : Add JDK package java-11-openjdk-headless to packages list] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Install required packages (4)] ******************
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure required local user exists.] *************
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_install/tasks/user.yml for localhost

TASK [redhat.eap.eap_install : Check arguments] ********************************
ok: [localhost]

TASK [redhat.eap.eap_install : Set eap group] **********************************
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure group eap exists.] ***********************
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure user eap exists.] ************************
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure workdir /opt/jboss_eap/ exists.] *********
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure archive_dir /opt/jboss_eap/ exists.] *****
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure server is installed] *********************
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_install/tasks/install.yml for localhost

TASK [redhat.eap.eap_install : Check arguments] ********************************
ok: [localhost]

TASK [redhat.eap.eap_install : Check local download archive path] **************
ok: [localhost]

TASK [redhat.eap.eap_install : Set download paths] *****************************
ok: [localhost]

TASK [redhat.eap.eap_install : Check target archive: /opt/jboss_eap//jboss-eap-7.4.0.zip] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Retrieve archive from website: https://github.com/eap/eap/releases/download] ***
skipping: [localhost]

TASK [redhat.eap.eap_install : Retrieve archive from RHN] **********************
skipping: [localhost]

TASK [redhat.eap.eap_install : Install server using RPM] ***********************
skipping: [localhost]

TASK [redhat.eap.eap_install : Check downloaded archive] ***********************
ok: [localhost]

TASK [redhat.eap.eap_install : Copy archive to target nodes] *******************
skipping: [localhost]

TASK [redhat.eap.eap_install : Check target archive: /opt/jboss_eap//jboss-eap-7.4.0.zip] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Verify target archive state: /opt/jboss_eap//jboss-eap-7.4.0.zip] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Read target directory information: /opt/jboss_eap/jboss-eap-7.4/] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Extract files from /opt/jboss_eap//jboss-eap-7.4.0.zip into /opt/jboss_eap/.] ***
skipping: [localhost]

TASK [redhat.eap.eap_install : Note: decompression was not executed] ***********
ok: [localhost] => {
    "msg": "/opt/jboss_eap/jboss-eap-7.4/ already exists and version unchanged, skipping decompression"
}

TASK [redhat.eap.eap_install : Read information on server home directory: /opt/jboss_eap/jboss-eap-7.4/] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Check state of server home directory: /opt/jboss_eap/jboss-eap-7.4/] ***
ok: [localhost]

TASK [redhat.eap.eap_install : Set instance name] ******************************
ok: [localhost]

TASK [redhat.eap.eap_install : Deploy custom configuration] ********************
skipping: [localhost]

TASK [redhat.eap.eap_install : Deploy configuration] ***************************
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure required parameters for cumulative patch application are provided.] ***
ok: [localhost] => {
    "changed": false,
    "msg": "All assertions passed"
}

TASK [Apply latest cumulative patch] *******************************************

TASK [redhat.eap.eap_utils : Check installation] *******************************
ok: [localhost]

TASK [redhat.eap.eap_utils : Set patch directory] ******************************
ok: [localhost]

TASK [redhat.eap.eap_utils : Set download patch archive path] ******************
ok: [localhost]

TASK [redhat.eap.eap_utils : Set patch destination directory] ******************
ok: [localhost]

TASK [redhat.eap.eap_utils : Check download patch archive path] ****************
ok: [localhost]

TASK [redhat.eap.eap_utils : Check local download archive path] ****************
ok: [localhost]

TASK [redhat.eap.eap_utils : Check local downloaded archive: jboss-eap-7.4.9-patch.zip] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Retrieve product download using JBossNetwork API] ***
skipping: [localhost]

TASK [redhat.eap.eap_utils : Determine patch versions list] ********************
skipping: [localhost]

TASK [redhat.eap.eap_utils : Determine latest version] *************************
skipping: [localhost]

TASK [redhat.eap.eap_utils : Determine install zipfile from search results] ****
skipping: [localhost]

TASK [redhat.eap.eap_utils : Determine selected patch from supplied version: 7.4.9] ***
skipping: [localhost]

TASK [redhat.eap.eap_utils : Check remote downloaded archive: /opt/jboss-eap-7.4.9-patch.zip] ***
skipping: [localhost]

TASK [redhat.eap.eap_utils : Download Red Hat EAP patch] ***********************
skipping: [localhost]

TASK [redhat.eap.eap_utils : Set download patch archive path] ******************
ok: [localhost]

TASK [redhat.eap.eap_utils : Check remote download patch archive path] *********
ok: [localhost]

TASK [redhat.eap.eap_utils : Copy patch archive to target nodes] ***************
changed: [localhost]

TASK [redhat.eap.eap_utils : Check patch state] ********************************
ok: [localhost]

TASK [redhat.eap.eap_utils : Set checksum file path for patch] *****************
ok: [localhost]

TASK [redhat.eap.eap_utils : Check /opt/jboss_eap/jboss-eap-7.4//.applied_patch_checksum_f641b6de2807fac18d2a56de7a27c1ea3611e5f3.txt state] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Print when patch has been applied already] ********
skipping: [localhost]

TASK [redhat.eap.eap_utils : Check if management interface is reachable] *******
ok: [localhost]

TASK [redhat.eap.eap_utils : Set apply CP conflict default strategy to default (if not defined): --override-all] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Apply patch /opt/jboss-eap-7.4.9-patch.zip to server installed in /opt/jboss_eap/jboss-eap-7.4/] ***
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_utils/tasks/jboss_cli.yml for localhost

TASK [redhat.eap.eap_utils : Ensure required params for JBoss CLI have been provided] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Ensure server's management interface is reachable] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Execute CLI query 'patch apply --override-all /opt/jboss-eap-7.4.9-patch.zip'] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Display patching result] **************************
ok: [localhost] => {
    "msg": "Apply patch operation result: {\n    \"outcome\" : \"success\",\n    \"response-headers\" : {\n        \"operation-requires-restart\" : true,\n        \"process-state\" : \"restart-required\"\n    }\n}"
}

TASK [redhat.eap.eap_utils : Set checksum file] ********************************
changed: [localhost]

TASK [redhat.eap.eap_utils : Set latest patch file] ****************************
changed: [localhost]

TASK [redhat.eap.eap_utils : Restart server to ensure patch content is running] ***
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_utils/tasks/jboss_cli.yml for localhost

TASK [redhat.eap.eap_utils : Ensure required params for JBoss CLI have been provided] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Ensure server's management interface is reachable] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Execute CLI query 'shutdown --restart'] ***********
ok: [localhost]

TASK [redhat.eap.eap_utils : Wait for management interface is reachable] *******
ok: [localhost]

TASK [redhat.eap.eap_utils : Stop service if it was started for patching] ******
skipping: [localhost]

TASK [redhat.eap.eap_utils : Display resulting output] *************************
skipping: [localhost]

TASK [redhat.eap.eap_install : Ensure required parameters for elytron adapter are provided.] ***
skipping: [localhost]

TASK [Install elytron adapter] *************************************************
skipping: [localhost]

TASK [redhat.eap.eap_install : Install server using Prospero] ******************
skipping: [localhost]

TASK [redhat.eap.eap_install : Check eap install directory state] **************
ok: [localhost]

TASK [redhat.eap.eap_install : Validate conditions] ****************************
ok: [localhost]

TASK [Ensure firewalld configuration allows server port (if enabled).] *********
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Validating arguments against arg spec 'main'] ***
ok: [localhost]

TASK [redhat.eap.eap_systemd : Check arguments] ********************************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Check current EAP patch installed] **************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Check arguments for yaml configuration] *********
ok: [localhost]

TASK [Ensure required local user and group exists.] ****************************

TASK [redhat.eap.eap_install : Check arguments] ********************************
ok: [localhost]

TASK [redhat.eap.eap_install : Set eap group] **********************************
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure group eap exists.] ***********************
ok: [localhost]

TASK [redhat.eap.eap_install : Ensure user eap exists.] ************************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Set destination directory for configuration] ****
ok: [localhost]

TASK [redhat.eap.eap_systemd : Set instance destination directory for configuration] ***
ok: [localhost]

TASK [redhat.eap.eap_systemd : Check arguments] ********************************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Set base directory for instance] ****************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Check arguments] ********************************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Set instance name] ******************************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Set instance name] ******************************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Set bind address] *******************************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Create basedir /opt/jboss_eap/jboss-eap-7.4//standalone for instance: eap] ***
ok: [localhost]

TASK [redhat.eap.eap_systemd : Create deployment directories for instance: eap] ***
ok: [localhost]

TASK [redhat.eap.eap_systemd : Deploy custom configuration] ********************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Deploy configuration] ***************************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Include YAML configuration extension] ***********
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_systemd/tasks/yml_config.yml for localhost

TASK [redhat.eap.eap_systemd : Create YAML configuration directory] ************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Enable YAML configuration extension] ************
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Create YAML configuration directory] ************
changed: [localhost]

TASK [redhat.eap.eap_systemd : Enable YAML configuration extension] ************
changed: [localhost]

TASK [redhat.eap.eap_systemd : Deploy YAML configuration files] ****************
changed: [localhost] => (item=jms_configuration.yml.j2)

TASK [redhat.eap.eap_systemd : Check YAML configuration is disabled] ***********
skipping: [localhost]

TASK [redhat.eap.eap_systemd : Set systemd envfile destination] ****************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Determine JAVA_HOME for selected JVM RPM] *******
ok: [localhost]

TASK [redhat.eap.eap_systemd : Set systemd unit file destination] **************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Deploy service instance configuration: /etc//eap.conf] ***
changed: [localhost]

TASK [redhat.eap.eap_systemd : Deploy Systemd configuration for service: /usr/lib/systemd/system/eap.service] ***
ok: [localhost]

TASK [redhat.eap.eap_systemd : Perform daemon-reload to ensure the changes are picked up] ***
ok: [localhost]

TASK [redhat.eap.eap_systemd : Ensure service is started] **********************
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_systemd/tasks/service.yml for localhost

TASK [redhat.eap.eap_systemd : Check arguments] ********************************
ok: [localhost]

TASK [redhat.eap.eap_systemd : Set instance eap state to started] **************
ok: [localhost]

TASK [redhat.eap.eap_validation : Validating arguments against arg spec 'main'] ***
ok: [localhost]

TASK [redhat.eap.eap_validation : Ensure required parameters are provided.] ****
ok: [localhost]

TASK [redhat.eap.eap_validation : Ensure user eap were created.] ***************
ok: [localhost]

TASK [redhat.eap.eap_validation : Validate state of user: eap] *****************
ok: [localhost]

TASK [redhat.eap.eap_validation : Ensure user eap were created.] ***************
ok: [localhost]

TASK [redhat.eap.eap_validation : Validate state of group: eap.] ***************
ok: [localhost]

TASK [redhat.eap.eap_validation : Wait for HTTP port 8080 to become available.] ***
ok: [localhost]

TASK [redhat.eap.eap_validation : Check if web connector is accessible] ********
ok: [localhost]

TASK [redhat.eap.eap_validation : Populate service facts] **********************
ok: [localhost]

TASK [redhat.eap.eap_validation : Check if service is running] *****************
ok: [localhost] => {
    "changed": false,
    "msg": "All assertions passed"
}

TASK [redhat.eap.eap_validation : Verify server's internal configuration] ******
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_validation/tasks/verify_with_cli_queries.yml for localhost => (item={'query': '/core-service=server-environment:read-attribute(name=start-gracefully)'})
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_validation/tasks/verify_with_cli_queries.yml for localhost => (item={'query': '/subsystem=undertow/server=default-server/http-listener=default:read-attribute(name=enabled)'})

TASK [redhat.eap.eap_validation : Ensure required parameters are provided.] ****
ok: [localhost]

TASK [Use CLI query to validate service state: /core-service=server-environment:read-attribute(name=start-gracefully)] ***

TASK [redhat.eap.eap_utils : Ensure required params for JBoss CLI have been provided] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Ensure server's management interface is reachable] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Execute CLI query '/core-service=server-environment:read-attribute(name=start-gracefully)'] ***
ok: [localhost]

TASK [redhat.eap.eap_validation : Validate CLI query was successful] ***********
ok: [localhost]

TASK [redhat.eap.eap_validation : Transform output to JSON] ********************
ok: [localhost]

TASK [redhat.eap.eap_validation : Display transformed result] ******************
skipping: [localhost]

TASK [redhat.eap.eap_validation : Check that query was successfully performed.] ***
ok: [localhost]

TASK [redhat.eap.eap_validation : Ensure required parameters are provided.] ****
ok: [localhost]

TASK [Use CLI query to validate service state: /subsystem=undertow/server=default-server/http-listener=default:read-attribute(name=enabled)] ***

TASK [redhat.eap.eap_utils : Ensure required params for JBoss CLI have been provided] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Ensure server's management interface is reachable] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Execute CLI query '/subsystem=undertow/server=default-server/http-listener=default:read-attribute(name=enabled)'] ***
ok: [localhost]

TASK [redhat.eap.eap_validation : Validate CLI query was successful] ***********
ok: [localhost]

TASK [redhat.eap.eap_validation : Transform output to JSON] ********************
ok: [localhost]

TASK [redhat.eap.eap_validation : Display transformed result] ******************
skipping: [localhost]

TASK [redhat.eap.eap_validation : Check that query was successfully performed.] ***
ok: [localhost]

TASK [redhat.eap.eap_validation : Ensure yaml setup] ***************************
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_validation/tasks/yaml_setup.yml for localhost

TASK [Check standard-sockets configuration settings] ***************************

TASK [redhat.eap.eap_utils : Ensure required params for JBoss CLI have been provided] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Ensure server's management interface is reachable] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Execute CLI query /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=mail-smtp:read-attribute(name=host)] ***
ok: [localhost]

TASK [redhat.eap.eap_validation : Display result of standard-sockets configuration settings] ***
ok: [localhost]

TASK [Check ejb configuration settings] ****************************************

TASK [redhat.eap.eap_utils : Ensure required params for JBoss CLI have been provided] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Ensure server's management interface is reachable] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Execute CLI query /subsystem=ejb3:read-attribute(name=default-resource-adapter-name)] ***
ok: [localhost]

TASK [redhat.eap.eap_validation : Display result of ejb configuration settings] ***
ok: [localhost]

TASK [Check ee configuration settings] *****************************************

TASK [redhat.eap.eap_utils : Ensure required params for JBoss CLI have been provided] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Ensure server's management interface is reachable] ***
ok: [localhost]

TASK [redhat.eap.eap_utils : Execute CLI query /subsystem=ee/service=default-bindings:read-attribute(name=jms-connection-factory)] ***
ok: [localhost]

TASK [redhat.eap.eap_validation : Display result of ee configuration settings] ***
ok: [localhost]

RUNNING HANDLER [redhat.eap.eap_systemd : Restart Wildfly] *********************
included: /root/.ansible/collections/ansible_collections/redhat/eap/roles/eap_systemd/tasks/service.yml for localhost

RUNNING HANDLER [redhat.eap.eap_systemd : Check arguments] *********************
ok: [localhost]

RUNNING HANDLER [redhat.eap.eap_systemd : Set instance eap state to restarted] ***
changed: [localhost]

PLAY RECAP *********************************************************************
localhost                  : ok=127  changed=8    unreachable=0    failed=0    skipped=34   rescued=0    ignored=0

As illustrated in the output above, the YAML definition is now enabled and the configuration of the JBoss EAP running on the target host has been updated.

Validate the JMS queue deployment

As always, we are going to be thorough and verify that the playbook execution has, indeed, properly set up a JMS queue. To do so, we can simply use the JBoss CLI provided with JBoss EAP to confirm:

$ /opt/jboss_eap/jboss-eap-7.4/bin/jboss-cli.sh --connect --command="/subsystem=messaging-activemq/server=default/jms-queue=MyQueue:read-resource"
{
    "outcome" => "success",
    "result" => {
        "durable" => true,
        "entries" => ["queues/MyQueue"],
        "legacy-entries" => undefined,
        "selector" => undefined
    }
}

The output, as shown above, confirms that the server configuration has indeed been updated and that a brand new JMS queue is now available. Since this verification is fairly easy to automate, we will also add it to our playbook.

The Ansible collection for JBoss EAP comes with a handy wrapper allowing for the execution of the JBoss CLI within a playbook. So, all that is needed is the inclusion of the task and the desired command, as shown below:

post_tasks:
    - name: "Check that Queue {{ queue.name }} is available."
      ansible.builtin.include_role:
        name: eap_utils
        tasks_from: jboss_cli.yml
      vars:
        jboss_home: "{{ eap_home }}"
        jboss_cli_query: "/subsystem=messaging-activemq/server=default/jms-queue={{ queue.name }}:read-resource"

Conclusion

Thanks to the Ansible collection for JBoss EAP, we have a minimalistic playbook, spared of all the heavy lifting of managing the Java application server, fulfilling the role of MOM. All the configuration required by the automation concerns only the use case we tried to implement, not the inner working of the solution (JBoss EAP).

All the configuration required by the automation concerns only the use case we tried to implement, not the inner working of the solution (JBoss EAP). The resulting playbook is safely repeatable and can be used to install the software on any number of target systems. Using the collection for JBoss EAP also makes it easy to keep the deployment up to date.

Migrating to JWS 6 using Ansible

Pelisse Romain — Wed, 20 Dec 2023 23:00:00 +0000

In this article, we'll discuss how to use the redhat.jws Ansible collection to automate the upgrade of a JBoss Web Server instance from 5.7 to the version 6.0. First, we'll use Ansible to install JWS 5.7 on the target system and then we'll use another playbook to perform the migration, thus ensuring that the target JWS instance has been upgraded successfully.

Prerequisites

To support this demonstration you will first need to have a working Ansible environment. This involves having Ansible installed on the local (control) machine and one or several target hosts. As we are using the certified Ansible collection provided by Red Hat, Ansible needs to be configured to use Red Hat Ansible Automation Hub to retrieve content. Please refer to the official documentation on how to configure your machine.

Once complete, install the redhat.jws collection on the control node using ansible-galaxy:

    $ ansible-galaxy collection install redhat.jws
    Starting galaxy collection install process
    Process install dependency map
    Starting collection install process
    Downloading https://console.redhat.com/api/automation-hub/v3/plugin/ansible/content/published/collections/artifacts/redhat-jws-1.2.4.tar.gz to /root/.ansible/tmp/ansible-local-377j77fwws/tmpog8w22ut/redhat-jws-1.2.4-pi6vhlev
    Installing 'redhat.jws:1.2.4' to '/root/.ansible/collections/ansible_collections/redhat/jws'
    Downloading https://console.redhat.com/api/automation-hub/v3/plugin/ansible/content/published/collections/artifacts/redhat-runtimes_common-1.1.3.tar.gz to /root/.ansible/tmp/ansible-local-377j77fwws/tmpog8w22ut/redhat-runtimes_common-1.1.3-pg3nqnfm redhat.jws:1.2.4 was installed successfully
    Downloading https://console.redhat.com/api/automation-hub/v3/plugin/ansible/content/published/collections/artifacts/ansible-posix-1.5.4.tar.gz to /root/.ansible/tmp/ansible-local-377j77fwws/tmpog8w22ut/ansible-posix-1.5.4-kt8e4_oe Installing 'redhat.runtimes_common:1.1.3' to '/root/.ansible/collections/ansible_collections/redhat/runtimes_common' redhat.runtimes_common:1.1.3 was installed successfully
    Installing 'ansible.posix:1.5.4' to '/root/.ansible/collections/ansible_collections/ansible/posix' ansible.posix:1.5.4 was installed successfully

Note that the installation of the collection also ensures that the required dependencies are available.

Once all of the prerequisites have been completed, you can either download the zip files of JWS versions 5.7 and 6.0 from the Red Hat customer portal manually or provide details related to your Red Hat service account to Ansible. More information on how to create a service account can be found here:

    $ cat service_account.yml
    ---
    rhn_username: <service_account_id> 
    rhn_password: <password>

For simplicity’s sake, in this demonstration, we'll work with already downloaded zip files, placed in the main directory of the Ansible project. Note that it means the zip files are located on the controller, not the target systems.

Installation of JWS 5.7

In real life, there is a good chance that users will already have an existing deployment of JWS (or maybe Apache Tomcat) they want to migrate from. For the demonstration in this article to be easily reproducible, however, we'll install a JWS server from the beginning to simulate this situation.

Using the redhat.jws collection, you can easily install and set up a JWS server using the following playbook:

    ---
    - name: "Red Hat JBoss Web Server installation and configuration"
      hosts: all
      become: True
      vars_files:
        - jws5_vars.yml 
      collections:
        - redhat.jws roles:
        - redhat.jws.jws

The playbook is mostly self-explanatory, however, we'll provide additional commentary on the meaning of a few variables located in the jws5_vars.yml file:

    # version java used to run JWS jws_java_version: 11
    # name of the systemd service associated JWS jws_service_name: jws5
    # Path to directory containing the zip files retrieved from Red Hat Customer Portal jws_archive_repository: "{{ lookup('env', 'PWD') }}"
    # Version of JWS used jws_version: 5.7.0
    # Name of the zipfile on the controller zipfile_name: jws-5.7.0-application-server.zip

Let's run the playbook to install our "legacy" JWS server:

$ ansible-playbook -i inventory jws5.yml

PLAY [Red Hat JBoss Web Server installation and configuration] *****************

TASK [Gathering Facts] *********************************************************
ok: [localhost]

TASK [redhat.jws.jws : Validating arguments against arg spec 'main'] ***********
ok: [localhost]

TASK [redhat.jws.jws : Set default values] *************************************
skipping: [localhost]

TASK [redhat.jws.jws : Set default values (jws)] *******************************
ok: [localhost]

TASK [redhat.jws.jws : Set jws_home to /opt/jws-5.7/tomcat if not already defined] ***
ok: [localhost]

TASK [redhat.jws.jws : Check that jws_home has been defined.] ******************
ok: [localhost] => {
    "changed": false,
    "msg": "All assertions passed"
}

TASK [redhat.jws.jws : Add firewalld to dependencies list (if enabled).] *******
skipping: [localhost]

TASK [redhat.jws.jws : Install required dependencies] **************************
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/fastpackage.yml for localhost => (item=zip)
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/fastpackage.yml for localhost => (item=unzip)
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/fastpackage.yml for localhost => (item=tzdata)

TASK [redhat.jws.jws : Check arguments] ****************************************
ok: [localhost]

TASK [redhat.jws.jws : Test if package zip is already installed] ***************
ok: [localhost]

TASK [redhat.jws.jws : Check arguments] ****************************************
ok: [localhost]

TASK [redhat.jws.jws : Test if package unzip is already installed] *************
ok: [localhost]

TASK [redhat.jws.jws : Check arguments] ****************************************
ok: [localhost]

TASK [redhat.jws.jws : Test if package tzdata is already installed] ************
ok: [localhost]

TASK [redhat.jws.jws : Install required dependencies for natives] **************
skipping: [localhost] => (item=openssl)
skipping: [localhost] => (item=apr)
skipping: [localhost]

TASK [redhat.jws.jws : Ensure tomcatjss rpm is not installed] ******************
ok: [localhost]

TASK [redhat.jws.jws : Include tasks for java jvm installation] ****************
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/java_install.yml for localhost

TASK [redhat.jws.jws : Set rpm name with version] ******************************
ok: [localhost]

TASK [redhat.jws.jws : Install java-11-openjdk-headless] ***********************
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/fastpackage.yml for localhost

TASK [redhat.jws.jws : Check arguments] ****************************************
ok: [localhost]

TASK [redhat.jws.jws : Test if package java-11-openjdk-headless is already installed] ***
ok: [localhost]

TASK [redhat.jws.jws : Determine JAVA_HOME for selected JVM RPM] ***************
ok: [localhost]

TASK [redhat.jws.jws : Create group: tomcat] ***********************************
ok: [localhost]

TASK [redhat.jws.jws : Create user: tomcat] ************************************
changed: [localhost]

TASK [redhat.jws.jws : Check state of install_dir: /opt] ***********************
ok: [localhost]

TASK [redhat.jws.jws : Ensure install dir is created: /opt] ********************
skipping: [localhost]

TASK [redhat.jws.jws : Include install tasks] **********************************
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/install.yml for localhost

TASK [redhat.jws.jws : Check arguments] ****************************************
ok: [localhost]

TASK [redhat.jws.jws : Check working directory /work for local repository] *****
ok: [localhost]

TASK [redhat.jws.jws : Display install method] *********************************
ok: [localhost] => {
    "msg": "Install method: zipfiles"
}

TASK [redhat.jws.jws : Set defaults values based on facts (if values not provided)] ***
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/install/defaults.yml for localhost

TASK [redhat.jws.jws : Set filename for JWS zipfile] ***************************
skipping: [localhost]

TASK [redhat.jws.jws : Set native zipfile architecture (if not provided)] ******
ok: [localhost]

TASK [redhat.jws.jws : Set RHEL major version based on facts (if not provided).] ***
ok: [localhost]

TASK [redhat.jws.jws : Set filename for JWS native zipfile] ********************
ok: [localhost]

TASK [redhat.jws.jws : Include installation tasks using zipfiles method] *******
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/install/local.yml for localhost

TASK [redhat.jws.jws : Deploy jws-5.7.0-application-server.zip to target.] *****
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/install/deploy_archive.yml for localhost

TASK [redhat.jws.jws : Check that required parameters have been provided.] *****
ok: [localhost]

TASK [redhat.jws.jws : Check download archive path on target: /opt/jws-5.7.0-application-server.zip] ***
ok: [localhost]

TASK [redhat.jws.jws : Retrieve zipfiles, if missing, from RHN (if credentials provided)] ***
skipping: [localhost]

TASK [redhat.jws.jws : Retrieve zipfiles from URL (if provided).] **************
skipping: [localhost]

TASK [redhat.jws.jws : Copy archives /work/jws-5.7.0-application-server.zip to target nodes: /opt/jws-5.7.0-application-server.zip] ***
changed: [localhost]

TASK [redhat.jws.jws : Deploy jws-5.7.0-application-server-RHEL8-x86_64.zip to target.] ***
skipping: [localhost]

TASK [redhat.jws.jws : Include installation tasks for zip operations] **********
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/install/zipfiles.yml for localhost

TASK [redhat.jws.jws : Check arguments] ****************************************
ok: [localhost]

TASK [redhat.jws.jws : Add zipfile to unarchive list] **************************
ok: [localhost]

TASK [redhat.jws.jws : Add native zipfile to unarchive list] *******************
skipping: [localhost]

TASK [redhat.jws.jws : Install Jboss Web Server and required binaries from local zipfiles (install method: zipfiles) to /opt] ***
changed: [localhost] => (item={'src': 'jws-5.7.0-application-server.zip', 'creates': '/opt/jws-5.7/tomcat/bin'})

TASK [redhat.jws.jws : Move the zipfile extracted directory to custom jws_home] ***
skipping: [localhost]

TASK [redhat.jws.jws : Move the version.txt to custom jws_home] ****************
skipping: [localhost]

TASK [redhat.jws.jws : Include installation tasks for rpm method] **************
skipping: [localhost]

TASK [redhat.jws.jws : Include systemd tasks] **********************************
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/systemd/systemd.yml for localhost

TASK [redhat.jws.jws : Check arguments] ****************************************
ok: [localhost]

TASK [redhat.jws.jws : Ensure requirements for systemd] ************************
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/fastpackage.yml for localhost => (item=systemd)
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/fastpackage.yml for localhost => (item=procps-ng)

TASK [redhat.jws.jws : Check arguments] ****************************************
ok: [localhost]

TASK [redhat.jws.jws : Test if package systemd is already installed] ***********
ok: [localhost]

TASK [redhat.jws.jws : Check arguments] ****************************************
ok: [localhost]

TASK [redhat.jws.jws : Test if package procps-ng is already installed] *********
ok: [localhost]

TASK [redhat.jws.jws : Set required default for jws_service_conf if not provided.] ***
ok: [localhost]

TASK [redhat.jws.jws : Set required default for jws_service_conf if not provided.] ***
ok: [localhost]

TASK [redhat.jws.jws : Set required default for jws_service_conf if not provided.] ***
ok: [localhost]

TASK [redhat.jws.jws : Ensure service script is deployed] **********************
changed: [localhost]

TASK [redhat.jws.jws : Ensure service configurations files is deployed: /opt/jws-5.7/tomcat/conf/jws5.conf] ***
changed: [localhost]

TASK [redhat.jws.jws : Ensure systemd service is configured] *******************
changed: [localhost]

TASK [redhat.jws.jws : Include patch install tasks] ****************************
skipping: [localhost]

TASK [redhat.jws.jws : Ensure /opt/jws-5.7/tomcat/ directories have appropriate privileges] ***
ok: [localhost] => (item=conf)
ok: [localhost] => (item=temp)
ok: [localhost] => (item=logs)
ok: [localhost] => (item=webapps)
ok: [localhost] => (item=bin)

TASK [redhat.jws.jws : Ensure /opt/jws-5.7/tomcat/ files have the recommended priviliges, owner and group] ***
changed: [localhost] => (item=./conf/catalina.properties)
changed: [localhost] => (item=./conf/catalina.policy)
changed: [localhost] => (item=./conf/logging.properties)
changed: [localhost] => (item=./conf/jaspic-providers.xml)
changed: [localhost] => (item=conf/tomcat-users.xml)

TASK [redhat.jws.jws : Include ajp sanity check tasks] *************************
skipping: [localhost]

TASK [redhat.jws.jws : Include https sanity check tasks] ***********************
skipping: [localhost]

TASK [redhat.jws.jws : Deploy custom configuration files] **********************
changed: [localhost] => (item={'template': 'templates/server.xml.j2', 'dest': '/opt/jws-5.7/tomcat/./conf/server.xml'})
changed: [localhost] => (item={'template': 'templates/web.xml.j2', 'dest': '/opt/jws-5.7/tomcat/./conf/web.xml'})
changed: [localhost] => (item={'template': 'templates/context.xml.j2', 'dest': '/opt/jws-5.7/tomcat/./conf/context.xml'})
changed: [localhost] => (item={'template': 'templates/catalina.properties.j2', 'dest': '/opt/jws-5.7/tomcat/./conf/catalina.properties'})

TASK [redhat.jws.jws : Include selinux configuration tasks] ********************
skipping: [localhost]

TASK [redhat.jws.jws : Remove apps] ********************************************
ok: [localhost] => (item=examples)

TASK [redhat.jws.jws : Create vault configuration (if enabled)] ****************
skipping: [localhost]

TASK [redhat.jws.jws : Ensure firewalld, if enabled, allows communication over 8080.] ***
skipping: [localhost]

RUNNING HANDLER [redhat.jws.jws : Reload Systemd] ******************************
ok: [localhost]

RUNNING HANDLER [redhat.jws.jws : Ensure Jboss Web Server runs under systemd] ***
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/systemd/service.yml for localhost

RUNNING HANDLER [redhat.jws.jws : Check arguments] *****************************
ok: [localhost]

RUNNING HANDLER [redhat.jws.jws : Enable jws.service] **************************
changed: [localhost]

RUNNING HANDLER [redhat.jws.jws : Start jws.service] ***************************
changed: [localhost]

RUNNING HANDLER [redhat.jws.jws : Restart Jboss Web Server service] ************
changed: [localhost]

PLAY RECAP *********************************************************************

Let's verify that the server is, indeed, successfully installed and available:

$ systemctl status jws5 ● jws5.service - Jboss Web Server
    Loaded: loaded (/usr/lib/systemd/system/jws5.service; enabled; vendor preset: disabled)
    Active: active (running) since Wed 2023-11-29 16:23:54 UTC; 8s ago
    Process: 2137 ExecStop=/opt/jws-5.7/tomcat/bin/systemd-service.sh stop (code=exited, status=0/SUCCESS)
    Main PID: 2187 (java)
    CGroup: /system.slice/jws5.service └─2187 /etc/alternatives/jre_11/bin/java -Djava.util.logging.config.file=/opt/jws-5.7/tomcat/conf/logging.properties -Djava.>
    Nov 29 16:23:54 62bfd7b30ce4 systemd[1]: Started Jboss Web Server.
    Nov 29 16:23:54 62bfd7b30ce4 systemd-service.sh[2178]: Tomcat started.
    Nov 29 16:23:54 62bfd7b30ce4 systemd-service.sh[2177]: Tomcat runs with PID: 2187

Performing the migration to JWS 6

Now that we have a "legacy" system in place, we can focus on the migration. In order to migrate a system from JWS 5 to JWS 6, we'll first need to shut down the existing service (JWS 5) before performing the install of JWS 6. For this last part, we'll simply reuse the same role from the redhat.jws collection we used previously. We'll also use the same vars file to reuse the same configuration of the server, overriding only the few variables that differ for this new version of the server.

The following playbook could be written to accomplish migrating JWS from version 5 to 6:

    ---
    - name: "Migrate JWS5 to JWS6"
      hosts: all
      gather_facts: no
      serial:
        - 1
        - 30%
        - 60%
      vars_files:
        - vars.yml
      pre_tasks:
        - name: "Ensure JWS5 is no longer running"
        ansible.builtin.service:
            name: "{{ jws_service_name }}"
            state: stopped
      tasks:
        - name: "Migrate to JWS 6"
          ansible.builtin.include_role:
            name: redhat.jws.jws
          vars:
             # overriding only the vars required
              jws_version: 6.0.0
              jws_service_name: jws6
              zipfile_name: jws-6.0.0-application-server.zip

Now, let's run this new playbook:

$ ansible-playbook -i inventory jws5-to-6.yml

    PLAY [Migrate JWS5 to JWS6] ****************************************************

    TASK [Ensure JWS5 is no longer running] ****************************************
    ok: [localhost]

    TASK [Install JWS 6] ***********************************************************

    TASK [redhat.jws.jws : Validating arguments against arg spec 'main'] ***********
    ok: [localhost]

    TASK [redhat.jws.jws : Set default values] *************************************
    skipping: [localhost]

    TASK [redhat.jws.jws : Set default values (jws)] *******************************
    ok: [localhost]

    TASK [redhat.jws.jws : Set jws_home to /opt/jws-6.0/tomcat if not already defined] ***
    ok: [localhost]

    TASK [redhat.jws.jws : Check that jws_home has been defined.] ******************
    ok: [localhost] => {
        "changed": false,
        "msg": "All assertions passed"
    }

    TASK [redhat.jws.jws : Add firewalld to dependencies list (if enabled).] *******
    skipping: [localhost]

    TASK [redhat.jws.jws : Install required dependencies] **************************
    included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/fastpackage.yml for localhost => (item=zip)
    included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/fastpackage.yml for localhost => (item=unzip)
    included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/fastpackage.yml for localhost => (item=tzdata)

    TASK [redhat.jws.jws : Check arguments] ****************************************
    ok: [localhost]

    TASK [redhat.jws.jws : Test if package zip is already installed] ***************
    ok: [localhost]

    TASK [redhat.jws.jws : Check arguments] ****************************************
    ok: [localhost]

    TASK [redhat.jws.jws : Test if package unzip is already installed] *************
    ok: [localhost]

    TASK [redhat.jws.jws : Check arguments] ****************************************
    ok: [localhost]

    TASK [redhat.jws.jws : Test if package tzdata is already installed] ************
    ok: [localhost]

    TASK [redhat.jws.jws : Install required dependencies for natives] **************
    skipping: [localhost] => (item=openssl)
    skipping: [localhost] => (item=apr)
    skipping: [localhost]

    TASK [redhat.jws.jws : Ensure tomcatjss rpm is not installed] ******************
    ok: [localhost]

    TASK [redhat.jws.jws : Include tasks for java jvm installation] ****************
    included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/java_install.yml for localhost

    TASK [redhat.jws.jws : Set rpm name with version] ******************************
    ok: [localhost]

    TASK [redhat.jws.jws : Install java-11-openjdk-headless] ***********************
    included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/fastpackage.yml for localhost

    TASK [redhat.jws.jws : Check arguments] ****************************************
    ok: [localhost]

    TASK [redhat.jws.jws : Test if package java-11-openjdk-headless is already installed] ***
    ok: [localhost]

    TASK [redhat.jws.jws : Determine JAVA_HOME for selected JVM RPM] ***************
    ok: [localhost]

    TASK [redhat.jws.jws : Create group: tomcat] ***********************************
    ok: [localhost]

    TASK [redhat.jws.jws : Create user: tomcat] ************************************
    changed: [localhost]

    TASK [redhat.jws.jws : Check state of install_dir: /opt] ***********************
    ok: [localhost]

    TASK [redhat.jws.jws : Ensure install dir is created: /opt] ********************
    skipping: [localhost]

    TASK [redhat.jws.jws : Include install tasks] **********************************
    included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/install.yml for localhost

    TASK [redhat.jws.jws : Check arguments] ****************************************
    ok: [localhost]

    TASK [redhat.jws.jws : Check working directory /work for local repository] *****
    ok: [localhost]

    TASK [redhat.jws.jws : Display install method] *********************************
    ok: [localhost] => {
        "msg": "Install method: zipfiles"
    }

    TASK [redhat.jws.jws : Set defaults values based on facts (if values not provided)] ***
    included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/install/defaults.yml for localhost

    TASK [redhat.jws.jws : Set filename for JWS zipfile] ***************************
    skipping: [localhost]

    TASK [redhat.jws.jws : Set native zipfile architecture (if not provided)] ******
    ok: [localhost]

    TASK [redhat.jws.jws : Set RHEL major version based on facts (if not provided).] ***
    ok: [localhost]

    TASK [redhat.jws.jws : Set filename for JWS native zipfile] ********************
    ok: [localhost]

    TASK [redhat.jws.jws : Include installation tasks using zipfiles method] *******
    included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/install/local.yml for localhost

    TASK [redhat.jws.jws : Deploy jws-6.0.0-application-server.zip to target.] *****
    included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/install/deploy_archive.yml for localhost

    TASK [redhat.jws.jws : Check that required parameters have been provided.] *****
    ok: [localhost]

    TASK [redhat.jws.jws : Check download archive path on target: /opt/jws-6.0.0-application-server.zip] ***
    ok: [localhost]

    TASK [redhat.jws.jws : Retrieve zipfiles, if missing, from RHN (if credentials provided)] ***
    skipping: [localhost]

    TASK [redhat.jws.jws : Retrieve zipfiles from URL (if provided).] **************
    skipping: [localhost]

    TASK [redhat.jws.jws : Copy archives /work/jws-6.0.0-application-server.zip to target nodes: /opt/jws-6.0.0-application-server.zip] ***
    changed: [localhost]

    TASK [redhat.jws.jws : Deploy jws-6.0.0-application-server-RHEL8-x86_64.zip to target.] ***
    skipping: [localhost]

    TASK [redhat.jws.jws : Include installation tasks for zip operations] **********
    included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/install/zipfiles.yml for localhost

    TASK [redhat.jws.jws : Check arguments] ****************************************
    ok: [localhost]

    TASK [redhat.jws.jws : Add zipfile to unarchive list] **************************
    ok: [localhost]

    TASK [redhat.jws.jws : Add native zipfile to unarchive list] *******************
    skipping: [localhost]

    TASK [redhat.jws.jws : Install Jboss Web Server and required binaries from local zipfiles (install method: zipfiles)] ***
    changed: [localhost] => (item={'src': 'jws-6.0.0-application-server.zip', 'creates': '/opt/jws-6.0/tomcat/bin'})

    TASK [redhat.jws.jws : Move the zipfile extracted directory to custom jws_home] ***
    skipping: [localhost]

    TASK [redhat.jws.jws : Move the version.txt to custom jws_home] ****************
    skipping: [localhost]

    TASK [redhat.jws.jws : Include installation tasks for rpm method] **************
    skipping: [localhost]

    TASK [redhat.jws.jws : Include systemd tasks] **********************************
    included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/systemd/systemd.yml for localhost

    TASK [redhat.jws.jws : Check arguments] ****************************************
    ok: [localhost]

    TASK [redhat.jws.jws : Ensure requirements for systemd] ************************
    included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/fastpackage.yml for localhost => (item=systemd)
    included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/fastpackage.yml for localhost => (item=procps-ng)

    TASK [redhat.jws.jws : Check arguments] ****************************************
    ok: [localhost]

    TASK [redhat.jws.jws : Test if package systemd is already installed] ***********
    ok: [localhost]

    TASK [redhat.jws.jws : Check arguments] ****************************************
    ok: [localhost]

    TASK [redhat.jws.jws : Test if package procps-ng is already installed] *********
    ok: [localhost]

    TASK [redhat.jws.jws : Set required default for jws_service_conf if not provided.] ***
    ok: [localhost]

    TASK [redhat.jws.jws : Set required default for jws_service_conf if not provided.] ***
    ok: [localhost]

    TASK [redhat.jws.jws : Set required default for jws_service_conf if not provided.] ***
    ok: [localhost]

    TASK [redhat.jws.jws : Ensure service script is deployed] **********************
    changed: [localhost]

    TASK [redhat.jws.jws : Ensure service configurations files is deployed: /opt/jws-6.0/tomcat/conf/jws6.conf] ***
    changed: [localhost]

    TASK [redhat.jws.jws : Ensure systemd service is configured] *******************
    changed: [localhost]

    TASK [redhat.jws.jws : Include patch install tasks] ****************************
    skipping: [localhost]

    TASK [redhat.jws.jws : Ensure /opt/jws-6.0/tomcat/ directories have appropriate privileges] ***
    ok: [localhost] => (item=conf)
    ok: [localhost] => (item=temp)
    ok: [localhost] => (item=logs)
    ok: [localhost] => (item=webapps)
    ok: [localhost] => (item=bin)

    TASK [redhat.jws.jws : Ensure /opt/jws-6.0/tomcat/ files have the recommended priviliges, owner and group] ***
    changed: [localhost] => (item=./conf/catalina.properties)
    changed: [localhost] => (item=./conf/catalina.policy)
    changed: [localhost] => (item=./conf/logging.properties)
    changed: [localhost] => (item=./conf/jaspic-providers.xml)
    changed: [localhost] => (item=conf/tomcat-users.xml)

    TASK [redhat.jws.jws : Include ajp sanity check tasks] *************************
    skipping: [localhost]

    TASK [redhat.jws.jws : Include https sanity check tasks] ***********************
    skipping: [localhost]

    TASK [redhat.jws.jws : Deploy custom configuration files] **********************
    changed: [localhost] => (item={'template': 'templates/server.xml.j2', 'dest': '/opt/jws-6.0/tomcat/./conf/server.xml'})
    changed: [localhost] => (item={'template': 'templates/web.xml.j2', 'dest': '/opt/jws-6.0/tomcat/./conf/web.xml'})
    changed: [localhost] => (item={'template': 'templates/context.xml.j2', 'dest': '/opt/jws-6.0/tomcat/./conf/context.xml'})
    changed: [localhost] => (item={'template': 'templates/catalina.properties.j2', 'dest': '/opt/jws-6.0/tomcat/./conf/catalina.properties'})

    TASK [redhat.jws.jws : Include selinux configuration tasks] ********************
    skipping: [localhost]

    TASK [redhat.jws.jws : Remove apps] ********************************************
    ok: [localhost] => (item=examples)

    TASK [redhat.jws.jws : Create vault configuration (if enabled)] ****************
    skipping: [localhost]

    TASK [redhat.jws.jws : Ensure firewalld, if enabled, allows communication over 8080.] ***
    skipping: [localhost]

    RUNNING HANDLER [redhat.jws.jws : Reload Systemd] ******************************
    ok: [localhost]

    RUNNING HANDLER [redhat.jws.jws : Ensure Jboss Web Server runs under systemd] ***
    included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/systemd/service.yml for localhost

    RUNNING HANDLER [redhat.jws.jws : Check arguments] *****************************
    ok: [localhost]

    RUNNING HANDLER [redhat.jws.jws : Enable jws.service] **************************
    changed: [localhost]

    RUNNING HANDLER [redhat.jws.jws : Start jws.service] ***************************
    changed: [localhost]

    RUNNING HANDLER [redhat.jws.jws : Restart Jboss Web Server service] ************
    changed: [localhost]

    PLAY RECAP *********************************************************************
    localhost               : ok=65   changed=11   unreachable=0    failed=0    skipped=18   rescued=0  ignored=0

Verify that the new jws6 service is indeed up and running:

    # systemctl status jws6 ● jws6.service - Jboss Web Server
    Loaded: loaded (/usr/lib/systemd/system/jws6.service; enabled; vendor preset: disabled)
    Active: active (running) since Thu 2023-11-30 08:56:13 UTC; 36s ago
    Process: 2220 ExecStop=/opt/jws-6.0/tomcat/bin/systemd-service.sh stop (code=exited, status=0/SUCCESS)
    Main PID: 2261 (java)
    Tasks: 42 (limit: 1638)
    Memory: 213.1M
    CGroup: /system.slice/jws6.service └─2261 /etc/alternatives/jre_11/bin/java -Djava.util.logging.config.file=/opt/jws-6.0/tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djdk.tls.ephemeralDHKeySize=2048 -Djava.pr>
    Nov 30 08:56:13 5e179d9cdf66 systemd[1]: Started Jboss Web Server.
    Nov 30 08:56:13 5e179d9cdf66 systemd-service.sh[2252]: Tomcat started.
    Nov 30 08:56:13 5e179d9cdf66 systemd-service.sh[2251]: Tomcat runs with PID: 2261

Configuration of the JWS server

Again, for simplicity's sake, the configuration of the JWS server is rather straightforward. We only needed to define a few parameters, such as the version of the OpenJDK required to run the server and the name of the systemd service. It is, however important, to note that because both installation playbooks (JWS 5 and JWS 6) use the same vars file, their configuration will be the same. The Ansible collection for JWS supports additional features including enabling HTTPS, using Tomcat Vault, and deploying and managing native libraries. Please refer to the official documentation of the Ansible collection for Red Hat JWS.

Even if the legacy system had a more finer-grained configuration (changes in the server.xml), this can be carried over the new version as the collection supports overriding the default template used to generate for the server's configuration files:

    jws_conf_properties: './conf/catalina.properties' 
    jws_conf_policy: './conf/catalina.policy' 
    jws_conf_loggging: './conf/logging.properties'
    jws_conf_context: './conf/context.xml' 
    jws_conf_server: './conf/server.xml' 
    jws_conf_web: './conf/web.xml' 
    jws_conf_users: 'conf/tomcat-users.xml' 
    jws_conf_jaspic_providers: './conf/jaspic-providers.xml' jws_conf_templates_context: 'templates/context.xml.j2' 
    jws_conf_templates_server: 'templates/server.xml.j2'

The variables above were provided as a reference to showcase how configurations can be provided. But, for our purposes, we can omit their use.

Handling failure during migration

There is another benefit of using Ansible to automate the migration to JWS 6. Ansible can also be used to ensure that the legacy system is still operational in the event of a failure at some point during the migration. Let's modify our playbook to handle such scenario:

        - name: "Migrate to JWS 6"
        block:
          - name: "Install and run JWS 6"
            ansible.builtin.include_role:
              name: redhat.jws.jws
            vars:
              # overriding only the vars required
              jws_version: 6.0.0
              jws_service_name: jws6
              zipfile_name: jws-6.0.0-application-server.zip
        rescue:
          - name: "Restart JWS5 as migration to JWS6 failed."
            ansible.builtin.service:
              name: jws5
              state: started

Upgrade strategy

Remediation is not the only area where Ansible's feature can help the migration. Indeed, if you are migrating a large set of servers, you may not want to stop all of them at the same time. Especially, if there is a chance the migration does not always run smoothly. You may prefer to instead operate on a subset of instances, first one or two servers, to check the migration works as expected, and then another subset afterward.

Let's modify our playbook to specify the value of the serial attribute in Ansible which will implement this strategy when the the playbook runs:

    ---
    - name: "Migrate JWS5 to JWS6" hosts: all gather_facts: 
      no serial:
        - 1
        - 30%
        - 60%
      vars_files:
        - vars.yml pre_tasks: …

Summary

In this article, we hope to have demonstrated how Ansible can both aid in the migration from one version of Red Hat JWS to another, but additionally provide an excellent framework for managing automation at scale. We have also illustrated several features of Ansible (including handling errors and execution strategy) that can be the key to a successful, smooth migration, of a large set of servers.

How Ansible automates JBoss Web Server updates and upgrades

Pelisse Romain — Thu, 07 Dec 2023 18:00:00 +0000

In the previous article, Automate Red Hat JBoss Web Server deployments with Ansible, I discussed how to fully automate the deployment of Red Hat JBoss Web Server with Red Hat Ansible Automation Platform. However, this initial installation and configuration is only the beginning. Once the Java server is in use, it must be maintained and updated. Otherwise, critical bugs could affect its operation, or a security vulnerability might expose it to bad actors.

Fortunately, we can utilize Ansible and the JWS collection to mitigate these concerns, enabling it to fully patch your deployment by automation and to upgrade the server itself. In this article, we will cover, in detail, how to implement such automation.

Note: Before you begin the steps in this article, install JBoss Web Server using the Ansible collections described in my previous article.

Update versus upgrade

First, let's define update and upgrade. Updating and upgrading the JBoss Web Server entail very different processes and implementations.

What does an update entail?

An update to the JBoss Web Server deploys a set of minor fixes provided by Red Hat via the Red Hat Customer portal. This update to the Java server code fixes an issue or addresses a security problem (or both). These modifications are packaged into one archive (zip) file in a layout that matches the JBoss Web Server directory structure.

To deploy this update, you must decompress the archive into the Java server root directory (typically referred to as TOMCAT_HOME). Once the archive decompresses, you must restart the software to ensure the running code uses the changes.

It is important to note that an update only introduces fixes to the server. There is no functionality (unless required to address the problem) or API changes. Therefore, an update increases only the minor version number, not the major version number of the JBoss Web Server. For instance, a patch to JBoss Web Server 5.6.0 may bring it to version 5.6.4 but not 5.7.0.

Updates to a more recent minor version rarely require modification to deployed web applications because they only introduce small changes. Updates should be checked regularly and applied as soon as possible to reduce the time a server may be susceptible to a known security issue.
What does an upgrade entail?

An upgrade is a more involved operation. It comes with API changes and new features. Before an upgrade executes in production, the web applications hosted by JBoss Web Server should be tested with the latest version and may need to be adapted. It is also important to keep in mind that an upgrade to JBoss Web Server represents a change of major version (i.e., shifting from 5.5 to 5.6). We cannot achieve this change by updating the files of the currently installed software. We must perform a completely new installation and migrate the configuration and hosted apps to this new instance.

In this context, automating the installation of the JBoss Web Server using Ansible brings substantial value. The same combination of tools used for setting up the server can be applied once again to perform an upgrade, ensuring that the software runs in the same configuration as before but with the appropriate upgrades.

Note: JBoss Web Server is stable software, so changes are unlikely to break backward compatibility even between major versions. That being said, unlikely is not the same as a guarantee. You may need to apply some changes to the server configuration before upgrading. Before promoting an upgrade to production, you should perform testing in non-production environments.

Now that you know what performing an update and upgrade to a JBoss Web Server installation entails, you are ready to learn how to employ Ansible for these tasks.

Automate the JBoss Web Server update with Ansible

Let's consider the following scenario:

Red Hat has provided a new update. This update contains a security issue fix and must deploy on all your instances of the JBoss Web Server. Those instances have been set up using the JWS Ansible collection and are running as systemd services. Each provisioned with a few web applications, you can restart it anytime if needed.

For this article, we will start with the following playbook (quite similar to the one we assembled in the previous article):

---
- name: "Red Hat JBoss Web Server installation and configuration"
  hosts: all
  become: true
  vars:
    jws_setup: true
    jboss_web_version: '5.5'
    jws_home: "/opt/jws-{{ jboss_web_version }}/tomcat/"
    jws_install_method: local_zipfiles
    jws_install_dir: /opt
    jws_zipfile: "jws-{{ jboss_web_version }}.0-application-server.zip"
    jws_java_version: 1.8.0
    jws_listen_http_bind_address: 127.0.0.1
    jws_systemd_enabled: True
    jws_service_name: jws
  collections:
    - redhat.jws
  tasks:
    - ansible.builtin.include_role:
        name: jws

The playbook above employs the redhat.jws collection provided by Red Hat on the Ansible Automation Hub. However, you can use the content of this article with the upstream version of middleware_automation.jws available on Ansible Galaxy.

The JWS collection for Ansible offers a nifty role to help apply the update. We need only to supply it with the path to the update's archive, and it will decompress the file and restart JBoss Web Server:

...
  post_tasks:
    - ansible.builtin.include_role:
        name: jws
        tasks_from: apply_cp.yml
      when:
        - jws_patch_bundle is defined 
...

Add a variable specifying the location of the updated file on the control host to run the playbook and perform the update:

$ ansible-playbook -e jws_patch_bundle=jws-5.5.1-application-server.zip -i inventory playbook.yml

We can verify that the server has indeed been updated by checking the JBoss Web Server version in the file:

# cat /opt/jws-5.6/version.txt | grep SP
Red Hat JBoss Web Server - Version 5.5 SP1

Needless to say, when the next update is released, it will require minimal effort. All that's left is updating the path to the updated archive and rerunning the same playbook.

Automate the JBoss Web Server upgrade with Ansible

Now that we have fully automated our JBoss Web Server update, let's consider another scenario:

Our JBoss Web Servers are still running with version 5.4 in production. The application teams have greenlit the upgrade to version 5.5.x with the operations team since it requires no changes within the web applications to accommodate that upgrade. All that remains is completely automating the upgrade process so that Ansible can simultaneously execute the upgrade over all the servers.

To install the new version, run the previous playbook with the correct JBoss Web Server version.

$ ansible-playbook -i inventory -e  jboss_web_version='5.6' playbook.yml

Once Ansible has finished executing, the new JWS server will be up (5.6) with the same configuration as the previous version (5.5), and the server deploys the same web applications.

This is the beauty of automation. All the heavy lifting was already done when we automated the installation of the JBoss Web Server in our previous article. Now, we can simply reuse this work to easily set up an upgraded server version. The JBoss Web Server configuration upgrade using Ansible is trivial because we fully automated the deployment (despite the upgrade scenario being more complex than the update).

The benefits of Ansible and automation

By fully automating the installation of the JBoss Web Server using Ansible, we have made the deployment of new instances easy, repeatable, and efficient. We can now easily maintain those systems, keeping them up to date. We can even perform automated upgrades, ensuring the configuration remains in sync with the previous installation by leveraging even more JWS collection features.

How to change an Ansible namespace with FQCN migration tool

Pelisse Romain — Thu, 23 Nov 2023 17:00:00 +0000

Packaging Ansible Playbooks within a collection is the best way to distribute reusable automation content. To avoid naming conflicts, developers organize collections inside namespaces. Sometimes situations arise where you need to migrate a collection from one namespace to another, such as a personal or community collection graduating to a more well known or certified namespace.

Altering the namespace can be a tedious task. However, the Fully Qualified Collection Name (FQCN) migration tool simplifies this process by utilizing the fqcn_migration command. Employing a straightforward configuration file transforms an entire collection from one namespace to another. This article introduces the tool and demonstrates how to use it.

Case story

Let’s assume we have a collection called useful_stuff living in a community namespace. It has proven valuable to the Ansible community for several years, so there was a decision to move its content from the community namespace to the ansible namespace. The migration also presents the opportunity to rename the collection, as its current one was deemed not applicable in the destination namespace.

The content of useful_stuff adheres to the best practices and conventions associated with Ansible collections, which means that all the roles it contains are prefixed by the collection name (useful_stuff_role_name) and all variables inside the role are also prefixed with the role name (useful_stuff_varname).

On top of the runnable Ansible content, the name of the collection and its namespace appears in other files, such as the galaxy.yml metadata file as well as within the included documentation resource. Also, as a result of the namespace change, a few URLs will need to be updated.

Using FQCN migration to alter the collection content

To ease the migration from community.useful_stuff to ansible.helpful_things, we are going to use the FQCN migration tool. First, we’ll need to install it. The tool is packaged as a collection and requires to be available on the system that we will utilize to perform the migration:

$ ansible-galaxy collection install community.fqcn_migration

Once the collection is installed on the system, use the included playbook from within the collection and set several variables properly. Let’s create a playbook called playbook.yml with the following content:

---
- ansible.builtin.import_playbook: community.fqcn_migration.fqcn_migration
  vars:
    upstream_name: useful_stuff
    downstream_name: helpful_things
    upstream_namespace: 'community'
    downstream_namespace: 'ansible'
    project_git_url: https://github.com/ansible-collections/useful_stuff.git
    project_git_version: main
    galaxy:
      documentation:  https://docs.ansible.com/ansible/latest/collections/ansible/helpfull_things/index.html
      homepage: https://docs.ansible.com/ansible/latest/collections/ansible/helpfull_things/index.html

This playbook can then be run like any other one:

$ ansible-playbook playbook.yml

The playbook will first perform a Git clone of the project’s repository of the collection to migrate and alter its content to match the new naming convention required. All that remains is to use git diff to review the modifications, test that the collection still works as expected, and then commit the changes back to the existing repository (or import the resulting content into another repository).

Note that because fqcn_migration is a development tool, the provided playbook is designed to target the local instance (Ansible controller) rather than on a target (remote) system. As a result, no inventory file is required.

Generating a downstream collection

As demonstrated, fqcn_migration is already quite helpful for migrating collections from one namespace to another. However, the tool was also developed to support creating downstream collections. Before explaining how to use the tool for such a purpose, let’s briefly clarify what we mean by downstream content. This is a topic that is somewhat specific for providing commercial support over an open source solution.

Most Red Hat Ansible Automation Platform users are familiar with the Red Hat Enterprise Linux distribution, as a supported and certified version based on the community project Fedora. The same logic applies with JBoss Enterprise Platform being the supported and certified version of the community supported Java/JEE application WildFly. In this context, the community project is often referred to as upstream, while the code base of the Red Hat products is the downstream. Naturally, downstream source derives from the upstream. But, for many reasons, it is frequently transformed (to add files specific content related to the certified product) and then resides in its separate source code repository. Fixes and enhancements in the upstream project are selected afterward and back-ported to the downstream.

The Ansible Middleware collections are a set of collections designed to help manage Red Hat Runtimes solutions (RH JBoss EAP, RH SSO, RH JBoss Web Server, RH Data Grid, RH AMQ and RH AMQ Streams). Therefore, the upstream collections target the community project (upstream) of each of those projects and each has a downstream version targeting the products provided by Red Hat.

However, functionally, those collections are the same. The only technical difference is the naming convention and the supportability options. Consequently, to generate the downstream collection of one of those collections, for release purposes, fqcn_migration is also used. Naturally, the transformation performed on the collection is a bit more extensive, as there are extra requirements for documentation along with those that become Ansible certified content published on Ansible automation hub.

All of these considerations are handled within the fqcn_migration logic so that no manual change is required during a release of the downstream collection. For example, the following is the transformation rule used to convert the middleware_automation.wildfly collection into the redhat.eap collection: see this configuration file.

This configuration of fqcn_migration is richer than the previous one. We leverage some advanced features that allow us to add or replace content to the collection. Based on a simple placeholder, this capacity allows the user to change the documentation of the downstream collection, so that it matches the documentation requirements of Ansible certified content.

Once we have generated the downstream collection, we can validate that the result is functional simply by running its transformed molecule test suite:

$ cd downstream/eap/
$ molecule test
…

Summary

In summary, altering a namespace requires a lot of changes because Ansible collections live inside namespaces, and it is best to use it in variables and role names. However, thanks to the fqcn_migration tool, we can easily migrate a collection’s content from one namespace to another, but also transform its roles and playbooks to generate a fully functional downstream version of the Ansible extension.

Automate JBoss Web Server deployment with the Red Hat Certified Content Collection for JWS

Pelisse Romain — Wed, 01 Nov 2023 23:00:00 +0000

According to several sources we queried, more than 33 percent of the world's web servers are running Apache Tomcat, while other sources show that it's 48 percent of application servers. Some of these instances have been containerized over the years, but many still run in the traditional setup of a virtual machine with Linux.

Red Hat JBoss Web Server (JWS) combines a web server (Apache HTTPD), a servlet engine (Apache Tomcat), and modules for load balancing (mod_jk and mod_cluster). Ansible is an automation engine that provides a suite of tools for managing an enterprise at scale. In this article, we'll show how 1+1 becomes 11 by using Ansible to completely automate the deployment of a JBoss Web Server instance on a Red Hat Enterprise Linux 8 server.

A prior article covered this subject, but now you can use the Red Hat certified content collection for JBoss Web Server, which has been available since the 5.7 release.

In this article, you will automate a JBoss Web Server deployment through the following tasks:

Retrieve the archive containing the JBoss Web Server from a repository and install the files on the system.
Configure the Red Hat Enterprise Linux operating system, creating of users, groups, and the required setup files to enable JBoss Web Server as a systemd service.
Fine-tune the configuration of the JBoss Web Server server, such as binding it to the appropriate interface and port.
Deploy a web application and start the systemd service.
Perform a health check to ensure that the deployed application is accessible.

Ansible fully automates all those operations, so no manual steps are required.

Preparing the target environment

Before you start the automation, you need to specify your target environment. In this case, you'll be using Red Hat Enterprise Linux 8 with Python 3.6. You'll use this setup on both the Ansible control node (where Ansible is executed) and the Ansible target (the system being configured).

On the control node, confirm the following requirements:

$ cat /etc/redhat-release

Red Hat Enterprise Linux release 8.7 (Ootpa)

$ ansible --version
ansible [core 2.13.3]
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/root/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.9/site-packages/ansible
  ansible collection location = /root/.ansible/collections:/usr/share/ansible/collections
  executable location = /usr/bin/ansible
  python version = 3.9.13 (main, Nov  9 2022, 13:16:24) [GCC 8.5.0 20210514 (Red Hat 8.5.0-15)]
  jinja version = 3.1.2
  libyaml = True

Note: The procedure in this article might not execute successfully if you use a different Python version or target operating system.

Installing the Red Hat Ansible Certified Content Collection

Once you have Red Hat Enterprise Linux 8 set up and Ansible ready to go, you need to install the Red Hat Ansible Certified Content Collection 1.2 for Red Hat JBoss Web Server. Ansible uses the collection to perform the following tasks on JBoss Web Server:

Ensure that the required system dependencies (e.g., unzip) are installed.
Install Java (if it is missing and requested).
Install the web server binaries and integrate the software into the system (setting the user, group, etc.).
Deploy the configuration files.
Start and enable JBoss Web Server as a systemd service.

To install the certified collection for JBoss Web Server, you'll have to configure Ansible to use Red Hat Automation Hub as a Galaxy server. Follow the instructions on Automation Hub to retrieve your token and update the ansible.cfg configuration file in your project directory. Update the <your-token> field with the token obtained from Automation Hub:

[galaxy]
server_list = automation_hub, galaxy

[galaxy_server.galaxy]
url=https://galaxy.ansible.com/

[galaxy_server.automation_hub]
url=https://cloud.redhat.com/api/automation-hub/api/galaxy/
auth_url=https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token

token=<your-token>

Install the certified collection:

# ansible-galaxy collection install redhat.jws
Starting galaxy collection install process
Process install dependency map
Starting collection install process
Downloading https://console.redhat.com/api/automation-hub/v3/plugin/ansible/content/published/collections/artifacts/redhat-jws-1.2.4.tar.gz to /root/.ansible/tmp/ansible-local-302vpskp5wg/tmp2t223yjz/redhat-jws-1.2.4-nrnqzn5k
Downloading https://console.redhat.com/api/automation-hub/v3/plugin/ansible/content/published/collections/artifacts/redhat-runtimes_common-1.1.3.tar.gz to /root/.ansible/tmp/ansible-local-302vpskp5wg/tmp2t223yjz/redhat-runtimes_common-1.1.3-mwgt5h9r
Installing 'redhat.jws:1.2.4' to '/root/.ansible/collections/ansible_collections/redhat/jws'
redhat.jws:1.2.4 was installed successfully
'ansible.posix:1.5.4' is already installed, skipping.
Installing 'redhat.runtimes_common:1.1.3' to '/root/.ansible/collections/ansible_collections/redhat/runtimes_common'
redhat.runtimes_common:1.1.3 was installed successfully

Ansible Galaxy fetches and downloads the collection's dependencies. These dependencies include the redhat_csp_download collection, which helps facilitate the retrieval of the archive containing the JBoss Web Server server from either the Red Hat customer portal or a specified local or remote location. For more information about this step, please refer to the official documentation for Red Hat.

Installing the Red Hat JBoss Web server

The configuration steps in this section include downloading JBoss Web Server, installing Java, and enabling JBoss Web Server as a system service (systemd).

Downloading the archive

First, you need to download the archive for JBoss Web Server from the Red Hat Customer Portal. By default, the collection expects the archive to be in the root folder of the Ansible project. The only remaining requirement is to specify the version of JBoss Web Server being used (5.7) in the playbooks. Based upon this information, the collection determines the path and the full name of the archive.

Therefore, update the value of jws_version in the jws-article.yml playbook:

---
- name: "Red Hat JBoss Web Server installation and configuration"
  hosts: all
  vars:
    jws_setup: True
    jws_version: 5.7.0
    jws_home: /opt/jws-5.7/tomcat
  …

Installing Java

JBoss Web Server is a Java-based server, so the target system must have a Java Virtual Machine (JVM) installed. Although Ansible primitives can perform such tasks natively, the redhat.jws collection can also take care of this task, provided that the jws_java_version variable is defined:

jws_home: /opt/jws-5.7/tomcat
jws_java_version: 1.8.0
…

Note: This feature works only if the target system's distribution belongs to the Red Hat family.

Enabling JBoss Web Server as a system service (systemd)

The JBoss Web Server server on the target system should run as a service system. The collection can also take care of this task, if the jws_systemd_enabled variable is defined as True:

jws_java_version: 1.8.0
jws_systemd_enabled: True
jws_service_name: jws

Note: This configuration works only when systemd is installed and the system belongs to the Red Hat family.

Now that you have defined all the required variables to deploy JBoss Web Server, finish the playbook:

...
jws_service_name: jws
  collections:
    - redhat.jws
  roles:
    - role: jws

Running the playbook

Run the playbook to see whether it works as expected:

$ ansible-playbook -i inventory jws_devto_article.yml

PLAY [Red Hat JBoss Web Server installation and configuration] *****************

TASK [Gathering Facts] *********************************************************
ok: [localhost]

TASK [redhat.jws.jws : Validating arguments against arg spec 'main'] ***********
ok: [localhost]

TASK [redhat.jws.jws : Set default values] *************************************
skipping: [localhost]

TASK [redhat.jws.jws : Set default values (jws)] *******************************
ok: [localhost]

TASK [redhat.jws.jws : Set jws_home to /opt/jws-5.7/tomcat if not already defined] ***
skipping: [localhost]

TASK [redhat.jws.jws : Check that jws_home has been defined.] ******************
ok: [localhost] => {
    "changed": false,
    "msg": "All assertions passed"
}

TASK [redhat.jws.jws : Add firewalld to dependencies list (if enabled).] *******
skipping: [localhost]

TASK [redhat.jws.jws : Install required dependencies] **************************
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/fastpackage.yml for localhost => (item=zip)
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/fastpackage.yml for localhost => (item=unzip)
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/fastpackage.yml for localhost => (item=tzdata)

TASK [redhat.jws.jws : Check arguments] ****************************************
ok: [localhost]

TASK [redhat.jws.jws : Test if package zip is already installed] ***************
ok: [localhost]

TASK [redhat.jws.jws : Check arguments] ****************************************
ok: [localhost]

TASK [redhat.jws.jws : Test if package unzip is already installed] *************
ok: [localhost]

TASK [redhat.jws.jws : Check arguments] ****************************************
ok: [localhost]

TASK [redhat.jws.jws : Test if package tzdata is already installed] ************
ok: [localhost]

TASK [redhat.jws.jws : Install required dependencies for natives] **************
skipping: [localhost] => (item=openssl) 
skipping: [localhost] => (item=apr) 
skipping: [localhost]

TASK [redhat.jws.jws : Ensure tomcatjss rpm is not installed] ******************
ok: [localhost]

TASK [redhat.jws.jws : Include tasks for java jvm installation] ****************
skipping: [localhost]

TASK [redhat.jws.jws : Create group: tomcat] ***********************************
changed: [localhost]

TASK [redhat.jws.jws : Create user: tomcat] ************************************
changed: [localhost]

TASK [redhat.jws.jws : Check state of install_dir: /opt] ***********************
ok: [localhost]

TASK [redhat.jws.jws : Ensure install dir is created: /opt] ********************
skipping: [localhost]

TASK [redhat.jws.jws : Include install tasks] **********************************
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/install.yml for localhost

TASK [redhat.jws.jws : Check arguments] ****************************************
ok: [localhost]

TASK [redhat.jws.jws : Check working directory /work for local repository] *****
ok: [localhost]

TASK [redhat.jws.jws : Display install method] *********************************
ok: [localhost] => {
    "msg": "Install method: zipfiles"
}

TASK [redhat.jws.jws : Set defaults values based on facts (if values not provided)] ***
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/install/defaults.yml for localhost

TASK [redhat.jws.jws : Set filename for JWS zipfile] ***************************
ok: [localhost]

TASK [redhat.jws.jws : Set native zipfile architecture (if not provided)] ******
ok: [localhost]

TASK [redhat.jws.jws : Set RHEL major version based on facts (if not provided).] ***
ok: [localhost]

TASK [redhat.jws.jws : Set filename for JWS native zipfile] ********************
ok: [localhost]

TASK [redhat.jws.jws : Include installation tasks using zipfiles method] *******
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/install/local.yml for localhost

TASK [redhat.jws.jws : Deploy jws-5.7.0-application-server.zip to target.] *****
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/install/deploy_archive.yml for localhost

TASK [redhat.jws.jws : Check that required parameters have been provided.] *****
ok: [localhost]

TASK [redhat.jws.jws : Check download archive path on target: /opt/jws-5.7.0-application-server.zip] ***
ok: [localhost]

TASK [redhat.jws.jws : Retrieve zipfiles, if missing, from RHN (if credentials provided)] ***
skipping: [localhost]

TASK [redhat.jws.jws : Retrieve zipfiles from URL (if provided).] **************
skipping: [localhost]

TASK [redhat.jws.jws : Copy archives /work/jws-5.7.0-application-server.zip to target nodes: /opt/jws-5.7.0-application-server.zip] ***
changed: [localhost]

TASK [redhat.jws.jws : Deploy jws-5.7.0-application-server-RHEL8-x86_64.zip to target.] ***
skipping: [localhost]

TASK [redhat.jws.jws : Include installation tasks for zip operations] **********
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/install/zipfiles.yml for localhost

TASK [redhat.jws.jws : Check arguments] ****************************************
ok: [localhost]

TASK [redhat.jws.jws : Add zipfile to unarchive list] **************************
ok: [localhost]

TASK [redhat.jws.jws : Add native zipfile to unarchive list] *******************
skipping: [localhost]

TASK [redhat.jws.jws : Install Jboss Web Server and required binaries from local zipfiles (install method: zipfiles)] ***
changed: [localhost] => (item={'src': 'jws-5.7.0-application-server.zip', 'creates': '/opt/jws-5.7/tomcat/bin'})

TASK [redhat.jws.jws : Move the zipfile extracted directory to custom jws_home] ***
skipping: [localhost]

TASK [redhat.jws.jws : Move the version.txt to custom jws_home] ****************
skipping: [localhost]

TASK [redhat.jws.jws : Include installation tasks for rpm method] **************
skipping: [localhost]

TASK [redhat.jws.jws : Include systemd tasks] **********************************
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/systemd/systemd.yml for localhost

TASK [redhat.jws.jws : Check arguments] ****************************************
ok: [localhost]

TASK [redhat.jws.jws : Ensure requirements for systemd] ************************
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/fastpackage.yml for localhost => (item=systemd)
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/fastpackage.yml for localhost => (item=procps-ng)

TASK [redhat.jws.jws : Check arguments] ****************************************
ok: [localhost]

TASK [redhat.jws.jws : Test if package systemd is already installed] ***********
ok: [localhost]

TASK [redhat.jws.jws : Check arguments] ****************************************
ok: [localhost]

TASK [redhat.jws.jws : Test if package procps-ng is already installed] *********
ok: [localhost]

TASK [redhat.jws.jws : Set required default for jws_service_conf if not provided.] ***
ok: [localhost]

TASK [redhat.jws.jws : Set required default for jws_service_conf if not provided.] ***
ok: [localhost]

TASK [redhat.jws.jws : Set required default for jws_service_conf if not provided.] ***
ok: [localhost]

TASK [redhat.jws.jws : Ensure service script is deployed] **********************
changed: [localhost]

TASK [redhat.jws.jws : Ensure service configurations files is deployed: /opt/jws-5.7/tomcat/conf/jws.conf] ***
changed: [localhost]

TASK [redhat.jws.jws : Ensure systemd service is configured] *******************
changed: [localhost]

TASK [redhat.jws.jws : Include patch install tasks] ****************************
skipping: [localhost]

TASK [redhat.jws.jws : Ensure /opt/jws-5.7/tomcat/ directories have appropriate privileges] ***
ok: [localhost] => (item=conf)
ok: [localhost] => (item=temp)
ok: [localhost] => (item=logs)
ok: [localhost] => (item=webapps)
ok: [localhost] => (item=bin)

TASK [redhat.jws.jws : Ensure /opt/jws-5.7/tomcat/ files have the recommended priviliges, owner and group] ***
changed: [localhost] => (item=./conf/catalina.properties)
changed: [localhost] => (item=./conf/catalina.policy)
changed: [localhost] => (item=./conf/logging.properties)
changed: [localhost] => (item=./conf/jaspic-providers.xml)
changed: [localhost] => (item=conf/tomcat-users.xml)

TASK [redhat.jws.jws : Include ajp sanity check tasks] *************************
skipping: [localhost]

TASK [redhat.jws.jws : Include https sanity check tasks] ***********************
skipping: [localhost]

TASK [redhat.jws.jws : Deploy custom configuration files] **********************
changed: [localhost] => (item={'template': 'templates/server.xml.j2', 'dest': '/opt/jws-5.7/tomcat/./conf/server.xml'})
changed: [localhost] => (item={'template': 'templates/web.xml.j2', 'dest': '/opt/jws-5.7/tomcat/./conf/web.xml'})
changed: [localhost] => (item={'template': 'templates/context.xml.j2', 'dest': '/opt/jws-5.7/tomcat/./conf/context.xml'})
changed: [localhost] => (item={'template': 'templates/catalina.properties.j2', 'dest': '/opt/jws-5.7/tomcat/./conf/catalina.properties'})

TASK [redhat.jws.jws : Include selinux configuration tasks] ********************
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/systemd/selinux.yml for localhost

TASK [redhat.jws.jws : Ensure required parameters are provided.] ***************
ok: [localhost]

TASK [redhat.jws.jws : Check if archive contains a selinux policy] *************
ok: [localhost]

TASK [redhat.jws.jws : Install selinux-policy-devel] ***************************
skipping: [localhost]

TASK [redhat.jws.jws : Check if archive contains a selinux policy] *************
skipping: [localhost]

TASK [redhat.jws.jws : Create selinux policy] **********************************
skipping: [localhost]

TASK [redhat.jws.jws : Allow jws.to listen to port] ****************************
skipping: [localhost] => (item=8080) 
skipping: [localhost] => (item=8443) 
skipping: [localhost] => (item=8009) 
skipping: [localhost] => (item=8005) 
skipping: [localhost]

TASK [redhat.jws.jws : Remove apps] ********************************************
ok: [localhost] => (item=examples)

TASK [redhat.jws.jws : Create vault configuration (if enabled)] ****************
skipping: [localhost]

TASK [redhat.jws.jws : Ensure firewalld, if enabled, allows communication over 8080.] ***
skipping: [localhost]

RUNNING HANDLER [redhat.jws.jws : Reload Systemd] ******************************
ok: [localhost]

RUNNING HANDLER [redhat.jws.jws : Ensure Jboss Web Server runs under systemd] ***
included: /root/.ansible/collections/ansible_collections/redhat/jws/roles/jws/tasks/systemd/service.yml for localhost

RUNNING HANDLER [redhat.jws.jws : Check arguments] *****************************
ok: [localhost]

RUNNING HANDLER [redhat.jws.jws : Enable jws.service] **************************
changed: [localhost]

RUNNING HANDLER [redhat.jws.jws : Start jws.service] ***************************
changed: [localhost]

RUNNING HANDLER [redhat.jws.jws : Restart Jboss Web Server service] ************
changed: [localhost]

PLAY RECAP *********************************************************************
localhost                  : ok=62   changed=12   unreachable=0    failed=0    skipped=22   rescued=0    ignored=0

As you can see, quite a lot happened during this execution. Indeed, the redhat.jws role took care of the entire setup:

Deploying a base configuration
Removing unused applications
Starting the web server

Deploying a web application

Now that JBoss Web Server is running, modify the playbook to facilitate the deployment of a web application:

...
roles:
- role: jws
tasks:
  - name: " Checks that server is running"
    ansible.builtin.uri:
      url: "http://localhost:8080/"
      status_code: 404
      return_content: no

  - name: "Deploy demo webapp"
    ansible.builtin.get_url:
      url: 'https://people.redhat.com/~rpelisse/info-1.0.war'
      dest: "{{ jws_home }}/webapps/info.war"
    notify:
      - "Restart Jboss Web Server service"

The configuration uses a handler, provided by the redhat.jws collection, to ensure that the JBoss Web Server is restarted once the application is downloaded.

Automation saves time and reduces the chance of error

The Red Hat Ansible Certified Content Collection encapsulates, as much as possible, the complexities and the inner workings of Red Hat JBoss Web Server deployment. With the help of the collection, you can focus on your business use case, such as deploying applications, instead of establishing the underlying application server. The result is reduced complexity and faster time to value. The automated process is also repeatable and can be used to set up as many systems as needed.

Automate your SSO with Ansible and Keycloak

Pelisse Romain — Thu, 19 Oct 2023 16:00:00 +0000

The article Deploy Keycloak single sign-on with Ansible discussed how to automate the deployment of Keycloak. In this follow-up article, we’ll use that as a baseline and explore how to automate the configuration of the Keycloak single sign-on (SSO) server, including setting up users, specifying LDAP connection details, and so on.

Here again, to facilitate our automation, we will leverage an Ansible collection named middleware_automation.keycloak, specifically designed for this endeavor.

Install Keycloak with Ansible

In the previous article, we saw in detail how to automate the installation of Keycloak. For this new installment, we’ll start from there using the following playbook:

---
- name: Playbook for Keycloak Hosts
  hosts: keycloak
  vars:
    keycloak_admin_password: "remembertochangeme"
  collections:
    - middleware_automation.keycloak
  roles:
    - keycloak

This short playbook will take care of the installation of the single sign-on server itself, which already includes quite a few tasks to perform on the target system, including:

Creating appropriate operating system user and group accounts (the name is keycloak for both)
Downloading the installation archive from the Keycloak website
Unarchiving the content while ensuring that all the files are associated with the appropriate user and groups along with the correct privileges
Ensuring that the required version of the Java Virtual Machine (JVM) is installed
Integrating the software into the host service management system (in our case, the Linux systemd daemon).

However, prior to running the playbook, we are going to enhance it even further to perform day two configurations of the Keycloak server, including the configuration of the SSO realm, clients, and users.

Configure single sign-on

The Ansible collection for Keycloak allows defining the realm, client, and users without adding a single, extra task. All that is needed is to define a few extra variables. Of course, those variables are quite structured and need to be formatted correctly for Ansible to be able to configure Keycloak appropriately. The following is a complete, working example of such a configuration:

---
- name: Playbook for Keycloak Hosts
  hosts: all
  vars:
    keycloak_admin_password: "remembertochangeme"
    keycloak_realm: TestRealm
  collections:
    - middleware_automation.keycloak
  roles:
    - keycloak
  tasks:
 - name: Keycloak Realm Role
    ansible.builtin.include_role:
        name: keycloak_realm
    vars:
        keycloak_client_default_roles:
        - TestRoleAdmin
        - TestRoleUser
        keycloak_client_users:
        - username: TestUser
            password: password
            client_roles:
            - client: TestClient
                role: TestRoleUser
                realm: "{{ keycloak_realm }}"
        - username: TestAdmin
            password: password
            client_roles:
            - client: TestClient
                role: TestRoleUser
                realm: "{{ keycloak_realm }}"
            - client: TestClient
                role: TestRoleAdmin
                realm: "{{ keycloak_realm }}"
        keycloak_realm: TestRealm
        keycloak_clients:
        - name: TestClient
            roles: "{{ keycloak_client_default_roles }}"
            realm: "{{ keycloak_realm }}"
            public_client: "{{ keycloak_client_public }}"
            web_origins: "{{ keycloak_client_web_origins }}"
            users: "{{ keycloak_client_users }}"
            client_id: TestClient

Note that this example, purposely, does not rely on any external sources (such as an LDAP server) so that it can be used easily, to test the collection without requiring the setup of any extra resources.

Because the SSO configuration is quite dense, we are going to break down each portion to not only provide additional insight, but to illustrate its significance in the SSO configuration.

Define the realm

The very first step is to define a realm, which, for the purpose of this article, contains the desired user and role details, but other capabilities provided by Keycloak that will be explored throughout the article. To create the realm, we just need to add one variable to our playbook:

…
            - client: TestClient
             role: TestRoleAdmin
             realm: "{{ keycloak_realm }}"
     keycloak_realm: TestRealm
     keycloak_clients:
…

Configure roles and users

The next portion of the variables provided populates the realm with the appropriate details related to users and roles. For the demonstration of this article, we added two users (and two roles) to the realm we are defining:

TestAdmin: An admin user who can connect to the SSO server and configure the realm. This user belongs to both roles we defined above.
TestClient: A user belonging to the realm and thus belongs only in the TestRoleUser.

…
        keycloak_client_default_roles:
         - TestRoleAdmin
         - TestRoleUser
     keycloak_client_users:
         - username: TestUser
         password: password
         client_roles:
             - client: TestClient
             role: TestRoleUser
             realm: "{{ keycloak_realm }}"
         - username: TestAdmin
         password: password
         client_roles:
             - client: TestClient
             role: TestRoleUser
             realm: "{{ keycloak_realm }}"
             - client: TestClient
             role: TestRoleAdmin
             realm: "{{ keycloak_realm }}"
…

Define Keycloak clients

The last portion of the variables defines the client associated with the roles so that their users can use the SSO service:

…
        keycloak_clients:
        - name: TestClient
            roles: "{{ keycloak_client_default_roles }}"
            realm: "{{ keycloak_realm }}"
            public_client: "{{ keycloak_client_public }}"
            web_origins: "{{ keycloak_client_web_origins }}"
            users: "{{ keycloak_client_users }}"

…

Run the playbook

That’s it! With these details provided, we can now run the playbook to deploy Keycloak and fully configure our SSO instance (based on the user's information inside the TestRealm). Execute the following command to execute the automation:

# systemctl status keycloak
● keycloak.service - keycloak Server
   Loaded: loaded (/etc/systemd/system/keycloak.service; enabled; vendor preset: disabled)
   Active: active (running) since Wed 2022-12-28 14:24:28 UTC; 26min ago
  Process: 1607 ExecStop=/opt/keycloak/keycloak-service.sh stop (code=exited, status=0/SUCCESS)
  Process: 1627 ExecStart=/opt/keycloak/keycloak-service.sh start (code=exited, status=0/SUCCESS)
 Main PID: 1742 (java)
   CGroup: /system.slice/keycloak.service
        ├─1630 /bin/sh /opt/keycloak/keycloak-18.0.2/bin/standalone.sh -Djboss.bind.address=0.0.0.0 -Djboss.http.port=8080 -Djboss.https.port=8443 -Djboss.management.http.port=9990 -Djbo>
        └─1742 /usr/lib/jvm/java-11-openjdk-11.0.17.0.8-2.el8_6.x86_64/bin/java -D[Standalone] -server -Xms1024m -Xmx2048m --add-exports=java.desktop/sun.awt=ALL-UNNAMED --add-exports=ja>

Dec 28 14:24:35 515ef9b313a5 keycloak-service.sh[1742]: 14:24:35,360 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 59) RESTEASY002220: Adding singleton resour>
Dec 28 14:24:35 515ef9b313a5 keycloak-service.sh[1742]: 14:24:35,360 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 59) RESTEASY002220: Adding singleton resour>
Dec 28 14:24:35 515ef9b313a5 keycloak-service.sh[1742]: 14:24:35,360 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 59) RESTEASY002220: Adding singleton resour>
Dec 28 14:24:35 515ef9b313a5 keycloak-service.sh[1742]: 14:24:35,360 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 59) RESTEASY002210: Adding provider singlet>
Dec 28 14:24:35 515ef9b313a5 keycloak-service.sh[1742]: 14:24:35,428 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 59) WFLYUT0021: Registered web context: '/auth' for>
Dec 28 14:24:35 515ef9b313a5 keycloak-service.sh[1742]: 14:24:35,487 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 42) WFLYSRV0010: Deployed "keycloak-server.war" (runtime-name >
Dec 28 14:24:35 515ef9b313a5 keycloak-service.sh[1742]: 14:24:35,522 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
Dec 28 14:24:35 515ef9b313a5 keycloak-service.sh[1742]: 14:24:35,524 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: Keycloak 18.0.2 (WildFly Core 18.1.1.Final) started in 8112ms>
Dec 28 14:24:35 515ef9b313a5 keycloak-service.sh[1742]: 14:24:35,526 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/>
Dec 28 14:24:35 515ef9b313a5 keycloak-service.sh[1742]: 14:24:35,527 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990

To go even further, we can add a check to our playbook that will use the Keycloak admin credentials to get a token from the SSO server. This emulates what will happen when a user tries to access an application using the SSO service. Thus, if it works fine, it confirms the service is functional:

- name: Verify token api call
  ansible.builtin.uri:
    url: "{{ keycloak_port }}/auth/realms/master/protocol/openid-connect/token"
    method: POST
    body: "client_id=admin-cli&username=admin&password={{ keycloak_admin_password }}&grant_type=password"
    validate_certs: no
    register: keycloak_auth_response
    until: keycloak_auth_response.status == 200
    retries: 2
    delay: 2

Conclusion

On top of deploying the Keycloak server, we have fully automated the configuration of our SSO. We can deploy a fully functional instance, in any environment, without any manual intervention. Most importantly, it is accomplished in a secure and repeatable fashion. With just this playbook, you can set up the entire infrastructure for SSO in a matter of minutes using the tooling provided by the Ansible Middleware project.

Cover Image by pvproductions on Freepik

Deploy Keycloak single sign-on with Ansible

Pelisse Romain — Thu, 05 Oct 2023 16:00:00 +0000

This article is the fourth installment in our series on Ansible for middleware. In this article, you'll use Ansible to simplify and automate the installation of Keycloak, a popular open source tool to implement single sign-on for Web applications. The previous articles in this series are:

The tutorial in this article builds on an Ansible Collection named middleware_automation.keycloak, which has been specifically designed for this endeavor.

Prerequisites

To make use of this tutorial, you need a Red Hat Enterprise Linux or Fedora system, along with version 2.9 or higher of Ansible (preferably the latest version).

Install the collection

The very first step, of course, is to install the collection itself, so that Ansible can use its content inside playbooks:

$ ansible-galaxy collection install middleware_automation.keycloak
Starting galaxy collection install process
Process install dependency map
Starting collection install process
Downloading https://galaxy.ansible.com/download/middleware_automation-keycloak-1.0.0.tar.gz to /root/.ansible/tmp/ansible-local-24nzydu97b/tmpaql0qbek/middleware_automation-keycloak-1.0.0-8yma1_vi
Installing 'middleware_automation.keycloak:1.0.0' to '/root/.ansible/collections/ansible_collections/middleware_automation/keycloak'
Downloading https://galaxy.ansible.com/download/middleware_automation-redhat_csp_download-1.2.1.tar.gz to /root/.ansible/tmp/ansible-local-24nzydu97b/tmpaql0qbek/middleware_automation-redhat_csp_download-1.2.1-4po4eg4w
middleware_automation.keycloak:1.0.0 was installed successfully
Installing 'middleware_automation.redhat_csp_download:1.2.1' to '/root/.ansible/collections/ansible_collections/middleware_automation/redhat_csp_download'
Downloading https://galaxy.ansible.com/download/middleware_automation-wildfly-1.0.1.tar.gz to /root/.ansible/tmp/ansible-local-24nzydu97b/tmpaql0qbek/middleware_automation-wildfly-1.0.1-ayf0n_nq
middleware_automation.redhat_csp_download:1.2.1 was installed successfully
Installing 'middleware_automation.wildfly:1.0.1' to '/root/.ansible/collections/ansible_collections/middleware_automation/wildfly'
middleware_automation.wildfly:1.0.1 was installed successfully

The collection has the following dependencies:

middleware_automation.redhat_csp: This collection allows Ansible to connect to the Red Hat Customer Portal to download Red Hat's single sign-on technology, which is a productized and supported version of Keycloak. We won't use this feature in this article.
middleware_automation.wildfly: Keycloak runs on top of the Wildfly application server, including Red Hat JBoss Enterprise Application Platform (JBoss EAP), which is the version of Wildfly supported by Red Hat. For more details about this collection, please refer to the second article in this series, Automate and deploy a JBoss EAP Cluster with Ansible.

Depending on the configuration of the machine used as the Ansible controller, you might need to add some Python dependencies so that Ansible will have the libraries required to make use of the collection. Install them by running the following command:

# pip3 install lxml jmespath
Collecting lxml
  Downloading lxml-4.7.1-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.manylinux_2_24_x86_64.whl (6.9 MB)
     |████████████████████████████████| 6.9 MB 1.9 MB/s
Collecting jmespath
  Downloading jmespath-0.10.0-py2.py3-none-any.whl (24 kB)
Installing collected packages: lxml, jmespath
Successfully installed jmespath-0.10.0 lxml-4.7.1

Now that the collection and its dependencies are installed, you can use it in an automation:

---
- name: Playbook for keycloak Hosts
  hosts: keycloak
  collections:
    - middleware_automation.keycloak
  tasks:

Note: In order for this playbook to perform the installation outlined here, Ansible must have sudo or root privileges on the target hosts.
Install Keycloak with Ansible

Thanks to the dedicated collection you just installed, automating the installation and configuration of Keycloak is easy. However, before you implement this inside your playbook, we should recap what we mean here by installing Keycloak. Indeed, this task encompasses quite a few operations that are performed on the target system:

Creating appropriate operating system user and group accounts (the name is keycloak for both)
Downloading the installation archive from the Keycloak website
Unarchiving the content while ensuring that all the files are associated with the appropriate user and groups along with the correct privileges
Ensuring that the required version of the Java Virtual Machine (JVM) is installed
Integrating the software into the host service management system (in our case, the Linux systemd daemon).

All of this is achieved and is fully automated by the following short playbook:

- name: Playbook for Keycloak Hosts
  hosts: keycloak
  collections:
    - middleware_automation.keycloak
  tasks:
    - name: Include keycloak role
      ansible.builtin.include_role:
        name: middleware_automation.keycloak.keycloak
      vars:
        keycloak_admin_password: "changeme"

The playbook begins by defining a variable for the Keycloak server administrative user. Note that, because this variable is a password, it should really be secured using Ansible Vault or some other secrets management system. However, that task is beyond the scope of this article.

The configuration then adds the Ansible collection for Keycloak to the list used by the playbook and adds the associated middleware_automation.keycloak.keycloak role to the list of roles that the playbook uses.

Run this playbook as follows:

# ansible-playbook -i inventory playbook.yml

PLAY [Playbook for Keycloak Hosts] ***************************************************************************************************************************

TASK [Gathering Facts] ***************************************************************************************************************************************
ok: [localhost]

TASK [middleware_automation.keycloak.keycloak : Validating arguments against arg spec 'main'] ****************************************************************
ok: [localhost]

TASK [middleware_automation.keycloak.keycloak : Check prerequisites] *****************************************************************************************
included: /root/.ansible/collections/ansible_collections/middleware_automation/keycloak/roles/keycloak/tasks/prereqs.yml for localhost

TASK [middleware_automation.keycloak.keycloak : Validate configuration]
…
TASK [middleware_automation.keycloak.keycloak : Create keycloak admin user] **********************************************************************************
changed: [localhost]

TASK [middleware_automation.keycloak.keycloak : Restart keycloak] ********************************************************************************************
included: /root/.ansible/collections/ansible_collections/middleware_automation/keycloak/roles/keycloak/tasks/restart_keycloak.yml for localhost

TASK [middleware_automation.keycloak.keycloak : Restart and enable keycloak service] ************************************************************************
changed: [localhost]

TASK [middleware_automation.keycloak.keycloak : Wait until keycloak becomes active http://localhost:9990/health] *********************************************
FAILED - RETRYING: [localhost]: Wait until keycloak becomes active http://localhost:9990/health (25 retries left).
ok: [localhost]

PLAY RECAP ***************************************************************************************************************************************************
localhost                  : ok=44   changed=2    unreachable=0    failed=0    skipped=14   rescued=1    ignored=0

More than forty tasks from the included role have been executed, taking care of all the requirements mentioned earlier: user and group creation, the software download, installing the required JVM, etc.

Check for successful installation

Once the playbook finishes its execution, you can confirm that Keycloak is now running as a service by verifying the status of the service:

# ● keycloak.service - Keycloak Server
   Loaded: loaded (/etc/systemd/system/keycloak.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2022-03-21 08:06:08 UTC; 3min 36s ago
  Process: 1553 ExecStop=/opt/keycloak/keycloak-service.sh stop (code=exited, status=0/SUCCESS)
  Process: 1571 ExecStart=/opt/keycloak/keycloak-service.sh start (code=exited, status=0/SUCCESS)
 Main PID: 1636 (java)
    Tasks: 79 (limit: 1638)
   Memory: 1012.8M
   CGroup: /system.slice/keycloak.service
           ├─1574 /bin/sh /opt/keycloak/keycloak-15.0.2/bin/standalone.sh -Djboss.bind.address=0.0.0.0 -Djboss.http.port=8080 -Djboss.https.port=8443 -Djboss.management.http.port=9990 -Djboss.management.https.port=9993 -Djboss.node.name=>
           └─1636 java -D[Standalone] -server -Xms1024m -Xmx2048m -Dorg.jboss.boot.log.file=/opt/keycloak/keycloak-15.0.2/standalone/log/server.log -Dlogging.configuration=file:/opt/keycloak/keycloak-15.0.2/standalone/configuration/loggi>

Mar 21 08:06:17 7efa2c53bfe8 keycloak-service.sh[1571]: 08:06:17,566 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 65) RESTEASY002220: Adding singleton resource org.keycloak.services.resources.RobotsResourc>
Mar 21 08:06:17 7efa2c53bfe8 keycloak-service.sh[1571]: 08:06:17,567 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 65) RESTEASY002210: Adding provider singleton org.keycloak.services.util.ObjectMapperResolv>
Mar 21 08:06:17 7efa2c53bfe8 keycloak-service.sh[1571]: 08:06:17,567 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 65) RESTEASY002220: Adding singleton resource org.keycloak.services.resources.WelcomeResour>
Mar 21 08:06:17 7efa2c53bfe8 keycloak-service.sh[1571]: 08:06:17,567 INFO  [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 65) RESTEASY002220: Adding singleton resource org.keycloak.services.resources.RealmsResourc>
Mar 21 08:06:17 7efa2c53bfe8 keycloak-service.sh[1571]: 08:06:17,650 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 65) WFLYUT0021: Registered web context: '/auth' for server 'default-server'
Mar 21 08:06:17 7efa2c53bfe8 keycloak-service.sh[1571]: 08:06:17,728 INFO  [org.jboss.as.server] (ServerService Thread Pool -- 43) WFLYSRV0010: Deployed "keycloak-server.war" (runtime-name : "keycloak-server.war")
Mar 21 08:06:17 7efa2c53bfe8 keycloak-service.sh[1571]: 08:06:17,764 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
Mar 21 08:06:17 7efa2c53bfe8 keycloak-service.sh[1571]: 08:06:17,766 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: Keycloak 15.0.2 (WildFly Core 15.0.1.Final) started in 9864ms - Started 596 of 873 services (584 services are>
Mar 21 08:06:17 7efa2c53bfe8 keycloak-service.sh[1571]: 08:06:17,768 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
Mar 21 08:06:17 7efa2c53bfe8 keycloak-service.sh[1571]: 08:06:17,768 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990/code>

Note that the playbook execution itself verifies that the service is running and that the Keycloak server itself is also available:

… 
TASK [middleware_automation.keycloak.keycloak : Restart and enable keycloak service] **************************************************
changed: [localhost]

TASK [middleware_automation.keycloak.keycloak : Wait until keycloak becomes active http://localhost:9990/health] ***********************
ok: [localhost]

However, for the sake of being thorough, you should double-check that the Keycloak port is indeed accessible:

# curl -I http://localhost:9990/health
HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: application/json
Content-Length: 283
Date: Fri, 18 Mar 2022 09:38:00 GMT

If you navigate to http://localhost:8080/, you will have access to your fully ready installation of Keycloak (Figure 1).

Figure 1: The Keycloak administrative site should be running on your local computer.

To summarize, at the end of this playbook execution, you'll have a running systemd service managing an instance of Keycloak.

Conclusion

By using Ansible and the Ansible Collection for Keycloak as outlined in this article, you can fully automate the deployment of a single sign-on server. In this article, Ansible has performed all the heavy lifting: downloading software, preparing the operating system (user, group, firewall), deploying the binary files and the configuration, setting up the service (systemd), and even preparing the required administrative account. The Ansible Collection for Keycloak allows you to streamline the installation and configuration of Keycloak, thus enabling you to scale deployments as necessary and ensure repeatability across them all.

In an upcoming article, we'll discuss how to further automate Keycloak's single sign-on service by creating realms and their members using Ansible.

Update and upgrade JBoss EAP with Ansible

Pelisse Romain — Thu, 21 Sep 2023 15:00:00 +0000

In this follow-up to Automate and deploy a JBoss EAP cluster with Ansible, we will explain how to maintain and keep those instances updated, again in a fully automated manner, leveraging Ansible and the Ansible collection for Red Hat JBoss Enterprise Application Platform (EAP).

Indeed, it is critical to ensure that all JEE application server instances always be up to date, especially in regard to security fixes. Therefore, we’ll discuss not only how to apply patches to update the server but also how to perform an upgrade to migrate to a new major version.

Prerequisites

In the previous article, we used the following playbook to install the WildFly cluster using Ansible on one single host. However, in this article, we’ll use only one instance of JBoss EAP (and no longer WildFly) for simplicity's sake.

You can use the following playbook to install an instance of JBoss EAP:

---
- name: Install EAP 7
  hosts: all
  collections:
    - redhat.eap
  roles:
    - eap_install
    - eap_systemd

Note: The playbook above uses the redhat.eap certified collection instead of the upstream middleware_automation.wildfly instance. The previous article used WildFly (the community version of the JEE application server) instead of JBoss EAP (the product supported by Red Hat). However, as updates are rarely produced for the upstream version (because of the fast release cycle, it’s easier to update to the next version), this article will focus on JBoss EAP, as product users often have to manage such updates.
For the playbook above to function as expected, you will need to install the collections redhat.eap on the Ansible controller:

# ansible-galaxy collection install redhat.eap
Starting galaxy collection install process
Process install dependency map
Starting collection install process
Downloading https://console.redhat.com/api/automation-hub/v3/plugin/ansible/content/published/collections/artifacts/redhat-eap-1.3.1.tar.gz to /root/.ansible/tmp/ansible-local-344ezcdnc0/tmpc0c7yq1u/redhat-eap-1.3.1-b5h7g9vf
Downloading https://console.redhat.com/api/automation-hub/v3/plugin/ansible/content/published/collections/artifacts/redhat-redhat_csp_download-1.2.2.tar.gz to /root/.ansible/tmp/ansible-local-344ezcdnc0/tmpc0c7yq1u/redhat-redhat_csp_download-1.2.2-2kmr5p0m
Installing 'redhat.eap:1.3.1' to '/root/.ansible/collections/ansible_collections/redhat/eap'
redhat.eap:1.3.1 was installed successfully
Installing 'redhat.redhat_csp_download:1.2.2' to '/root/.ansible/collections/ansible_collections/redhat/redhat_csp_download'
redhat.redhat_csp_download:1.2.2 was installed successfully

As redhat.eap is a certified collection only available to Red Hat customers, you need to configure the ansible.cfg file to use Ansible Automation Hub so that the collection can be retrieved:

# cat ansible.cfg
[defaults]
host_key_checking = False
retry_files_enabled = False
nocows = 1

[inventory]
# fail more helpfully when the inventory file does not parse (Ansible 2.4+)
unparsed_is_failed=true

[galaxy]
server_list = automation_hub, galaxy

[galaxy_server.galaxy]
url=https://galaxy.ansible.com/

[galaxy_server.automation_hub]
url=https://cloud.redhat.com/api/automation-hub/

auth_url=https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token

token=<your-token>

A bit of context first

Before we continue, let's define what we mean (in this article) by update versus upgrade.

Updates

An update to an existing JBoss EAP instance consists of the deployment of a series of fixes to the product’s code. Updates are provided to Red Hat customers through the Red Hat Customer Portal. They contain a set of changes made against the JEE server code, either to fix an issue or address a security concern (or both). You need to use the JBoss CLI tool to deploy an update. However, as we’ll see soon, the redhat.eap collection will take care of this for us.

It’s important to note that such an update only brings fixes to the server. No functionality changes (unless required to resolve a problem) nor API changes are performed. Therefore, an update does not change the major version of JBoss EAP—only the minor version. For instance, bringing JBoss EAP 7.4.0 to 7.4.6 (but not to 7.5).

Because an update to a more recent minor version only includes small changes, they rarely require modification to the applications hosted by JBoss EAP. They should be performed as quickly as possible in order to ensure the server can not be compromised by a known security issue.

Upgrades

An upgrade is a more involved operation. Indeed, it comes with API changes and new features, meaning that, before being performed, the applications hosted by JBoss EAP should be tested against the new version and potentially adapted to work in this new context.

Also, an upgrade to JBoss EAP is a change of major version (EAP 7.3 to 7.4). This cannot be achieved by updating the files of the currently installed software. A complete, new installation needs to be performed, and the configuration, along with the hosted apps, needs to be migrated to this new root folder.

Note: This article focuses on the update and upgrade of the app server itself and, purposely, does not discuss configuration changes and application migration. On this front, too, the collection redhat.eap provides some help by leveraging the JBoss migration tool. This scenario will be the topic of a follow-up article.

Applying a cumulative patch

Let’s consider the following scenario:

A series of JBoss EAP 7.3.0 instances were freshly installed in order to perform tests before production. The tests were successful, and the team now wants to promote those servers from testing to preprod. The main requirement (regarding JBoss EAP) is to run the latest version of the server (7.3.10).

Here is the playbook used to fully automate the installation process:

---
- name: "Update EAP to latest {{ eap_patch_version }}"
  hosts: eap_servers
  vars:
    eap_version: 7.3.0
    eap_apply_cp: True
    eap_patch_version: 7.3.10
    eap_instance_name: eap73
  collections:
    - redhat.eap
  roles:
    - eap_install
    - eap_systemd

This playbook relies entirely on the two roles provided by the redhat.eap collection, to install EAP and start the associated service. The only information required is the server (major) version provided by the variable eap_version. We also configured the collection to update this minor version (eap_patch_apply set to true) to the latest available minor version (7.3.10). We also added a variable to change the name of the service running the server to eap73.

Once this playbook has run successfully and Ansible has started the server, we can see that we are now running the latest version available of JBoss EAP 7.3, as proven by the following line of the server.log:

# tail -f /opt/jboss_eap/jboss-eap-7.3/standalone/log/server.log
2023-03-01 11:25:29,413 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-6) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
2023-03-01 11:25:29,483 INFO  [org.jboss.as.patching] (MSC service thread 1-2) WFLYPAT0050: JBoss EAP cumulative patch ID is: jboss-eap-7.3.10.CP, one-off patches include: none
2023-03-01 11:25:29,494 WARN  [org.jboss.as.domain.management.security] (MSC service thread 1-2) WFLYDM0111: Keystore /opt/jboss_eap/jboss-eap-7.3/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost
2023-03-01 11:25:29,499 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-7) WFLYDS0013: Started FileSystemDeploymentService for directory /opt/jboss_eap/jboss-eap-7.3/standalone/deployments
2023-03-01 11:25:29,544 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0006: Undertow HTTPS listener https listening on [0:0:0:0:0:0:0:0]:8443
2023-03-01 11:25:29,593 INFO  [org.jboss.ws.common.management] (MSC service thread 1-5) JBWS022052: Starting JBossWS 5.3.0.Final-redhat-00001 (Apache CXF 3.3.12.redhat-00001)
2023-03-01 11:25:29,674 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
2023-03-01 11:25:29,676 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.3.10.GA (WildFly Core 10.1.25.Final-redhat-00001) started in 2300ms - Started 306 of 560 services (355 services are lazy, passive or on-demand)
…

Notes:

By default, the collection installs the latest major version of JBoss EAP (7.4.0). As we will discuss upgrading to the next major version in the second part of this article, we have purposely installed the previous major version of the JEE server.
If the playbook is run again, no changes are reported, as the collection ensures that the setup of JBoss EAP is idempotent.

Upgrading to the next major version of JBoss EAP

Minor upgrades contain only fixes. The actual changes are minimal. Features themselves are not modified, and no new ones are added unless a security fix requires it. In short, this means users can perform such updates on their system without fearing side effects or issues for the hosted applications. However, upgrading JBoss EAP to the next major version is a completely different scenario.

Let’s consider the following requirement. The JBoss EAP instances previously installed using Ansible have been targeted to be upgraded to 7.4 with the latest available minor version (7.4.10). Teams behind the hosted apps have tested and confirmed that no code changes are required; however, a plan is already in place if something goes wrong during the upgrade. Any instance having issues during the upgrade needs to downgrade and resume running the previous version.

Let’s build a playbook implementing such a strategy. First, it will stop the currently running instance of JBoss EAP on the target, then install and start the new version, using the same configuration template as the previous server. And, if anything goes wrong during this process, the existing service will be started.

Here is the playbook we will use to perform this migration:

---
- name: "Update EAP to latest {{ eap_patch_version }}"
  hosts: eap_servers
  vars:
    eap_offline_install: True
    eap_apply_cp: True
    eap_patch_version: 7.4.9
    eap_config_base: 'standalone.xml'
    eap_instance_name: eap74
  collections:
    - redhat.eap
  roles:
    - eap_systemd
  pre_tasks:
    - name: "Ensure previous version of EAP is not running"
      ansible.builtin.service:
        name: eap73
       state: stopped
  tasks:

    - block:
     - name: "Perform EAP {{ eap_patch_version }} installation"
       ansible.builtin.include_role:
         name: eap_install

     - name: "Ensure EAP service is deployed and running."
       ansible.builtin.include_role:
         name: eap_systemd

     - name: "Ensure EAP service is functional"
       ansible.builtin.include_role:
         name: eap_validation

     rescue:

     - name: "EAP upgrade failed, fallback to previous version"
       ansible.builtin.service:
         name: eap73
         state: running

The playbook above implements the migration process we described above. First, it stops the existing JBoss EAP server running on the target. Then, it leverages the redhat.eap collection again to install the new version and start it as a service. To ensure that this instance is functional, it runs the eap_validation role, also provided by the collection, that performs some basic sanity checks against the service.

Assuming nothing has failed during those three steps, the new server is running, and the migration has been completed successfully. If anything goes wrong, the new server is shut down, and the previous instance is restarted.

Note: This playbook is not idempotent and is aimed at being run only for migration purposes. This is both for the sake of simplicity and readability.

Performing the upgrade and update without downtime

Most of the time, updating and upgrading JBoss EAP will require restarting the service, which implies some downtime. However, if there is more than one instance of JBoss EAP to update, it is possible to use a powerful Ansible feature to avoid any downtime (assuming there is a smart proxy in front of the JBoss EAP farm, such as httpd using mod_cluster).

By default, Ansible will try to connect to any hosts belonging to the eap_servers group and perform the update and the upgrade in parallel. If everything goes according to plan, there is still a risk of downtime, as the server might be restarting at the same time. If anything goes wrong, most, if not all, will need to roll back to the previous version, leading to even more chances of downtime.

However, this execution strategy can be configured by adding the keyword serial to the playbook. This will configure how Ansible will operate on the list of servers to connect and execute by batch, only a subset of them at once. With this feature, we can implement the following approach:

Update (or upgrade) on target;
Update (or upgrade) one-third of the entire farm;
Update (or upgrade) the rest of the targets.

Such a strategy offers a lot of peace of mind; if the first machine to be targeted fails to update or upgrade, you can stop the process here and investigate what went wrong. The rest of the servers are still running without any risk of downtime. The same applies to the next batch. If something goes wrong with the first third of the servers, then most of the farm is still running the old version, uninterrupted.

To implement this strategy in our upgrade playbook, we only need to add the attribute serial. We valorize it using a list containing three values, as shown below:

---
- name: "Update EAP to latest {{ eap_patch_version }}"
  hosts: all
  serial:
    - 1
    - 30%
    - 70%
  vars:
    eap_offline_install: True
    eap_apply_cp: True
    eap_patch_version: 7.4.9
    eap_instance_name: eap74
  collections:
    - redhat.eap
  roles:
    - eap_install
    - eap_systemd
  pre_tasks:
    - name: "Ensure previous version of EAP is not running"
      ansible.builtin.service:
        name: eap73
      state: stopped
  tasks:
    - block:
        - name: "Perform EAP {{ eap_patch_version }} installation"
          ansible.builtin.include_role:
            name: eap_install
        - name: "Ensure EAP service is deployed and running."
          ansible.builtin.include_role:
            name: eap_systemd
        - name: "Ensure EAP service is functional"
          ansible.builtin.include_role:
            name: eap_validation
      rescue:
        - name: "EAP upgrade failed, fallback to previous version"
          ansible.builtin.service:
            name: eap73
            state: running

Note that the values within the serial property can indeed be a mix of integers (1) and percentages.

Conclusion

With the heavy lifting of the server installation managed by the redhat.eap collection and the primitives provided by Ansible, we have implemented a sound strategy to perform updates and upgrades on a potentially very large farm of instances.

The two playbooks we displayed in this article are both short and simple to understand. Their content focuses only on the environment specificity (version executed, execution strategy), and the inner workings of EAP are fully encapsulated inside the collection, which provides peace of mind in what would typically be a complex operation and process.