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.
Learn more about automation when you download An IT executive's guide to automation. Visit the Red Hat Customer portal for more information about updates, upgrades, and support. Please feel free to comment below. We welcome your feedback.
