Automating JBoss EAP: Update and upgrade for versions 7 & 8

September 12, 2024
Romain Pelisse
Related topics:
DevOpsJavaLinuxRuntimes
Related products:
Red Hat Ansible Automation PlatformRed Hat Enterprise LinuxRed Hat JBoss Enterprise Application Platform

The release of Red Hat JBoss Enterprise Application Platform (JBoss EAP) 8 brought an important change on how the server is kept up to date. In essence, in the previous major version of the Java application server, updates were provided as a series of modifications that were applied by a capability embedded into the server itself. 

Now, in JBoss EAP version 8, updates are performed  by a separate dedicated tool: the JBoss Installation Manager. Of course, this has an impact on how to manage the automation around JBoss EAP and especially how to handle upgrading, using Red Hat Ansible Automation Platform, from version 7 to 8.

A bit of context first

Before we begin, let’s define what update, upgrade, and change of version refers to in the context of this article.

Updates

An update to an existing JBoss EAP instance consists of the deployment of a series of fixes to the product’s code. The modifications to the Java Enterprise Edition (JEE) server code are to either correct an issue or address a security concern (or both). 

It’s important to note that such an update only includes fixes to the server. Little to no functionality changes (unless necessary to resolve a problem or CVE), nor API evolutions are performed. Therefore, an update does not change the major or minor version of JBoss EAP—only the micro version. For instance, bringing JBoss EAP from 7.4.0 to 7.4.6 (but not to 7.5).

Because an update to a more recent minor version only includes small alterations, only in rare instances is there a need to modify applications hosted by JBoss EAP. Thus, updates should be applied as quickly as possible in order to ensure the server cannot be compromised by a known security issue or a fixed defect.

Upgrades

An upgrade is a more involved operation as it includes API modifications and new features. Before being applied, applications hosted by JBoss EAP should be tested and potentially adapted to work with the changes present in the new version.

Also, an upgrade to JBoss EAP is a change of major (JBoss EAP 7 to JBoss EAP 8) or minor version (EAP 7.3 to 7.4). This cannot be achieved by just updating the files of the currently deployed software on the targets. A complete, new installation must be completed, and the configuration, along with the hosted apps, needs to be migrated to this new root folder.

Change of major version

The final option is similar to an upgrade, but in this case, the version of the server itself is changed (such as, from JBoss EAP 7 to JBoss EAP 8). A change of version is a far more drastic alteration of the internal structure of the application server. 

JBoss EAP 8 is built to support an entirely different version of the Jakarta EE API. The number of modifications of the server files is, like for an upgrade, way too radical to be handled like an update. 

Note

This article focuses on the update and upgrade of the application 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 Server Migration tool. This use case will be the topic of a separate article.

Install and update JBoss EAP 7 with Ansible

 With these definitions in mind, let's discuss how we can put these terms into practice with JBoss EAP 7 and Ansible.

Updating to a specific version

Let’s consider the following scenario: for a new project, the application developers are using JBoss EAP 7.4.12. To ensure changes to the server do not interfere with their work, they have decided to freeze this version and perform all the development on JBoss EAP 7.4.12, without applying any updates to the server. 

The following is the playbook they created to provision their development instances:

---
- name: "Update EAP to latest {{ eap_patch_version }}"
 hosts: all
 vars:
    eap_version: 7.4.0
    eap_apply_cp: True
    eap_patch_version: 7.4.12
 collections:
    - redhat.eap
 roles:
    - eap_install
    - eap_systemd

Let's run this playbook:

$ ansible-playbook -i inventory eap.yml

Ansible run of the playbook above.

Note

The playbook above uses the redhat.eap certified collection. For the playbook above to function as expected, this collection (extension) for Ansible needs to be installed on the control node using the ansible-galaxy command line tool. As this collection is provided by Red Hat Automation Hub, Ansible must also be configured to use this server as a source of the collection (see online documentation to learn how to retrieve the required token and add the retrieved value to the ansible.cfg file).

Once the playbook has run successfully, we can verify that the version of JBoss EAP installed is indeed 7.4.12 by simply querying the status of the eap service:

# systemctl status eap
● eap.service - JBoss EAP (standalone mode)
  Loaded: loaded (/etc/systemd/system/eap.service; enabled; preset: disabled)
  Active: active (running) since Mon 2024-07-29 14:47:56 UTC; 6min ago
   Main PID: 2276 (standalone.sh)
   Tasks: 90 (limit: 1638)
  Memory: 366.2M
     CPU: 14.903s
  CGroup: /system.slice/eap.service
          ├─2276 /bin/sh /opt/jboss_eap/jboss-eap-7.4/bin/standalone.sh -c eap.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/jboss_eap/jboss-eap-7.4//standalone/configuration/ -Djboss.server.base.dir=/opt/jboss_eap/jboss-eap-7.4//standalone -Djboss.tx.node.id=localhost -Djboss.node.name=eap -Djboss.socket.binding.port-offset=0 -Dwildfly.statistics-enabled=false
          └─2437 /etc/alternatives/jre_11/bin/java "-D[Standalone]" -server "-Xlog:gc*:file=/opt/jboss_eap/jboss-eap-7.4/standalone/log/gc.log:time,uptimemillis:filecount=5,filesize=3M" -Xmx1024M -Xms512M --add-exports=java.base/sun.nio.ch=ALL-UNNAMED --add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED --add-exports=jdk.unsupported/sun.reflect=ALL-UNNAMED --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-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.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/jboss_eap/jboss-eap-7.4/standalone/log/server.log -Dlogging.configuration=file:/opt/jboss_eap/jboss-eap-7.4/standalone/configuration/logging.properties -jar /opt/jboss_eap/jboss-eap-7.4/jboss-modules.jar -mp /opt/jboss_eap/jboss-eap-7.4/modules org.jboss.as.standalone -Djboss.home.dir=/opt/jboss_eap/jboss-eap-7.4 -Djboss.server.base.dir=/opt/jboss_eap/jboss-eap-7.4/standalone -c eap.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/jboss_eap/jboss-eap-7.4//standalone/configuration/ -Djboss.server.base.dir=/opt/jboss_eap/jboss-eap-7.4//standalone -Djboss.tx.node.id=localhost -Djboss.node.name=eap -Djboss.socket.binding.port-offset=0 -Dwildfly.statistics-enabled=false
Jul 29 14:47:59 a86df93a3fcc standalone.sh[2437]: 14:47:59,377 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
Jul 29 14:47:59 a86df93a3fcc standalone.sh[2437]: 14:47:59,445 INFO  [org.jboss.as.patching] (MSC service thread 1-2) WFLYPAT0050: JBoss EAP cumulative patch ID is: jboss-eap-7.4.12.CP, one-off patches include: none
Jul 29 14:47:59 a86df93a3fcc standalone.sh[2437]: 14:47:59,466 WARN  [org.jboss.as.domain.management.security] (MSC service thread 1-8) WFLYDM0111: Keystore /opt/jboss_eap/jboss-eap-7.4/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost
Jul 29 14:47:59 a86df93a3fcc standalone.sh[2437]: 14:47:59,471 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-4) WFLYDS0013: Started FileSystemDeploymentService for directory /opt/jboss_eap/jboss-eap-7.4/standalone/deployments
Jul 29 14:47:59 a86df93a3fcc standalone.sh[2437]: 14:47:59,486 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0006: Undertow HTTPS listener https listening on [0:0:0:0:0:0:0:0]:8443
Jul 29 14:47:59 a86df93a3fcc standalone.sh[2437]: 14:47:59,531 INFO  [org.jboss.ws.common.management] (MSC service thread 1-1) JBWS022052: Starting JBossWS 5.4.8.Final-redhat-00001 (Apache CXF 3.4.10.redhat-00001)
Jul 29 14:47:59 a86df93a3fcc standalone.sh[2437]: 14:47:59,621 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
Jul 29 14:47:59 a86df93a3fcc standalone.sh[2437]: 14:47:59,623 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.4.12.GA (WildFly Core 15.0.29.Final-redhat-00001)

As long as we leave the version of the JBoss EAP server hardcoded in the playbook, Ansible will ensure each time it runs that the targets are using this specific version of the server.

Updating to the latest available version

The previous strategy (using a fixed version of JBoss EAP) has worked fine for the initial development cycle. Now, however, the application is moving to staging and the associated DevOps team wants to ensure that the automation will keep the server up to date. 

The playbook is thus adjusted accordingly, to ensure that Ansible will always check if the version deployed is the latest available one:

---
- name: "Update EAP to latest {{ eap_patch_version }}"
  hosts: all
  vars:
    eap_version: 7.4.0
  collections:
    - redhat.eap
  roles:
    - name: eap_install
    - name: eap_systemd

Let's run the playbook:

$ ansible-playbook -i inventory eap.yml

Ansible run of the playbook above.

Here again, we can verify that the version of JBoss EAP installed is the latest available by checking the status of the eap service:

# systemctl status eap
● eap.service - JBoss EAP (standalone mode)
  Loaded: loaded (/etc/systemd/system/eap.service; enabled; preset: disabled)
  Active: active (running) since Mon 2024-07-29 15:26:20 UTC; 52min ago
   Main PID: 6611 (standalone.sh)
   Tasks: 91 (limit: 1638)
  Memory: 643.9M
     CPU: 41.842s
  CGroup: /system.slice/eap.service
          ├─6611 /bin/sh /opt/jboss_eap/jboss-eap-7.4/bin/standalone.sh -c eap.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/jboss_eap/jboss-eap-7.4//standalone/configuration/ -Djboss.server.base.dir=/opt/jboss_eap/jboss-eap-7.4//standalone -Djboss.tx.node.id=localhost -Djboss.node.name=eap -Djboss.socket.binding.port-offset=0 -Dwildfly.statistics-enabled=false
          └─7725 /etc/alternatives/jre_11/bin/java "-D[Standalone]" -server "-Xlog:gc*:file=/opt/jboss_eap/jboss-eap-7.4/standalone/log/gc.log:time,uptimemillis:filecount=5,filesize=3M" -Xmx1024M -Xms512M --add-exports=java.base/sun.nio.ch=ALL-UNNAMED --add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED --add-exports=jdk.unsupported/sun.reflect=ALL-UNNAMED --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-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.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/jboss_eap/jboss-eap-7.4/standalone/log/server.log -Dlogging.configuration=file:/opt/jboss_eap/jboss-eap-7.4/standalone/configuration/logging.properties -jar /opt/jboss_eap/jboss-eap-7.4/jboss-modules.jar -mp /opt/jboss_eap/jboss-eap-7.4/modules org.jboss.as.standalone -Djboss.home.dir=/opt/jboss_eap/jboss-eap-7.4 -Djboss.server.base.dir=/opt/jboss_eap/jboss-eap-7.4/standalone -c eap.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/jboss_eap/jboss-eap-7.4//standalone/configuration/ -Djboss.server.base.dir=/opt/jboss_eap/jboss-eap-7.4//standalone -Djboss.tx.node.id=localhost -Djboss.node.name=eap -Djboss.socket.binding.port-offset=0 -Dwildfly.statistics-enabled=false
Jul 29 15:31:32 a86df93a3fcc standalone.sh[7725]: 15:31:32,218 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
Jul 29 15:31:32 a86df93a3fcc standalone.sh[7725]: 15:31:32,287 INFO  [org.jboss.as.patching] (MSC service thread 1-4) WFLYPAT0050: JBoss EAP cumulative patch ID is: jboss-eap-7.4.17.CP, one-off patches include: none
Jul 29 15:31:32 a86df93a3fcc standalone.sh[7725]: 15:31:32,307 WARN  [org.jboss.as.domain.management.security] (MSC service thread 1-1) WFLYDM0111: Keystore /opt/jboss_eap/jboss-eap-7.4/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost
Jul 29 15:31:32 a86df93a3fcc standalone.sh[7725]: 15:31:32,312 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-7) WFLYDS0013: Started FileSystemDeploymentService for directory /opt/jboss_eap/jboss-eap-7.4/standalone/deployments
Jul 29 15:31:32 a86df93a3fcc standalone.sh[7725]: 15:31:32,329 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006: Undertow HTTPS listener https listening on [0:0:0:0:0:0:0:0]:8443
Jul 29 15:31:32 a86df93a3fcc standalone.sh[7725]: 15:31:32,371 INFO  [org.jboss.ws.common.management] (MSC service thread 1-7) JBWS022052: Starting JBossWS 5.4.9.Final-redhat-00001 (Apache CXF 3.5.8.redhat-00001)
Jul 29 15:31:32 a86df93a3fcc standalone.sh[7725]: 15:31:32,453 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
Jul 29 15:31:32 a86df93a3fcc standalone.sh[7725]: 15:31:32,456 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.4.17.GA (WildFly Core 15.0.36.Final-redhat-00001) started in 2350ms - Started 319 of 558 services (343 services are lazy, passive or on-demand)

Note that when this article was written, the latest available version of JBoss EAP 7 was 7.4.17.

Upgrade to EAP 8

Important note

Upgrading a target system from JBoss EAP 7 to JBoss EAP 8 is an unlikely scenario, as it will require updating all applications hosted on the application server to be migrated to Jakarta 9. In fact, the procedure documented below performs a new install, from scratch, of the JBoss EAP 8 server on the target, which is not a real upgrade. 

Minor updates, such as from 7.4.16 to 7.4.17, contain only fixes. The actual changes to the code are minimal. Features and API behavior themselves are not modified, short of correcting a defect and new capabilities are rarely added, unless required by a security fix. As a result, users can perform updates on their systems without fear of side effects from their hosted applications.

Upgrading JBoss EAP to the next major version is, however, a completely different scenario. In this section, we will see how to upgrade our target instances, so that they are employing the latest available release of JBoss EAP 8.

The JBoss EAP instances previously installed by Ansible have been using JBoss EAP 7.4 and the project team just informed the DevOps team that the next version of their application will require JBoss EAP 8. The transition between JBoss EAP 7 and JBoss EAP 8 is expected to be smooth as the application has been thoroughly tested with this new version of the application server. Of course, the applications will need a fresh install of JBoss EAP 8, and the following playbook has been implemented to facilitate the migration to the new major version of the application server:

  1. The playbook will stop the currently running instance of JBoss EAP on the target
  2. Install and start the new version using the same configuration template as the previous server, but in a different folder:
---
- name: "Disable EAP7 and deploy EAP8"
  hosts: all
  vars:
    eap_version: 8.0.0
    eap_install_workdir: /opt/jboss_eap8/
    eap_home: "{{ eap_install_workdir }}/jboss-eap8"
  collections:
    - redhat.eap
  roles:
    - name: eap_systemd
    - name: eap_validation
  pre_tasks:
    - name: "Ensure previous version of EAP is not running"
      ansible.builtin.service:
       name: eap
       state: stopped
    - name: "Perform EAP {{ eap_patch_version }} installation"
      ansible.builtin.include_role:
        name: eap_install

Let's run the playbook:

$ ansible-playbook -i inventory eap8.yml

Ansible run of the playbook above.

We can again verify that the target is now running the appropriate version of JBoss EAP by simply checking that status of the eap service:

# systemctl status eap
● eap.service - JBoss EAP (standalone mode)
  Loaded: loaded (/etc/systemd/system/eap.service; enabled; preset: disabled)
  Active: active (running) since Fri 2024-08-02 13:00:28 UTC; 1h 1min ago
   Main PID: 4857 (standalone.sh)
     CPU: 22.503s
  CGroup: /system.slice/eap.service
          ├─4857 /bin/sh /opt/jboss_eap8/jboss-eap8/bin/standalone.sh -c eap.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/jboss_eap8//jboss-eap8/standalone/configuration/ -Djboss.server.base.dir=/opt/jboss_eap8//jboss-eap8/standalone -Djboss.tx.node.id=localhost -Djboss.node.name=eap -Djboss.socket.binding.port-offset=0 -Dwildfly.statistics-enabled=false
          └─5045 /etc/alternatives/jre_11/bin/java "-D[Standalone]" "-Xlog:gc*:file=/opt/jboss_eap8/jboss-eap8/standalone/log/gc.log:time,uptimemillis:filecount=5,filesize=3M" "-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/jboss_eap8/jboss-eap8/standalone/log/server.log -Dlogging.configuration=file:/opt/jboss_eap8/jboss-eap8/standalone/configuration/logging.properties -jar /opt/jboss_eap8/jboss-eap8/jboss-modules.jar -mp /opt/jboss_eap8/jboss-eap8/modules org.jboss.as.standalone -Djboss.home.dir=/opt/jboss_eap8/jboss-eap8 -Djboss.server.base.dir=/opt/jboss_eap8/jboss-eap8/standalone -c eap.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/jboss_eap8//jboss-eap8/standalone/configuration/ -Djboss.server.base.dir=/opt/jboss_eap8//jboss-eap8/standalone -Djboss.tx.node.id=localhost -Djboss.node.name=eap -Djboss.socket.binding.port-offset=0 -Dwildfly.statistics-enabled=false
Aug 02 13:00:31 f395065f1d5e standalone.sh[5045]: 13:00:31,594 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0006: Undertow HTTP listener default listening on [0:0:0:0:0:0:0:0]:8080
Aug 02 13:00:31 f395065f1d5e standalone.sh[5045]: 13:00:31,704 INFO  [org.jboss.as.ejb3] (MSC service thread 1-1) WFLYEJB0493: Jakarta Enterprise Beans subsystem suspension complete
Aug 02 13:00:31 f395065f1d5e standalone.sh[5045]: 13:00:31,759 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0006: Undertow HTTPS listener https listening on [0:0:0:0:0:0:0:0]:8443
Aug 02 13:00:31 f395065f1d5e standalone.sh[5045]: 13:00:31,775 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
Aug 02 13:00:31 f395065f1d5e standalone.sh[5045]: 13:00:31,906 INFO  [org.jboss.ws.common.management] (MSC service thread 1-7) JBWS022052: Starting JBossWS 7.0.0.Final-redhat-00001 (Apache CXF 4.0.0.redhat-00002)
Aug 02 13:00:31 f395065f1d5e standalone.sh[5045]: 13:00:31,908 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-1) WFLYDS0013: Started FileSystemDeploymentService for directory /opt/jboss_eap8/jboss-eap8/standalone/deployments
Aug 02 13:00:32 f395065f1d5e standalone.sh[5045]: 13:00:32,003 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
Aug 02 13:00:32 f395065f1d5e standalone.sh[5045]: 13:00:32,007 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
Aug 02 13:00:32 f395065f1d5e standalone.sh[5045]: 13:00:32,007 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
Aug 02 13:00:32 f395065f1d5e standalone.sh[5045]: 13:00:32,011 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 8.0 Update 2.1 (WildFly Core 21.0.9.Final-redhat-00001) started in 3047ms - Started 282 of 524 services (318 services are lazy, passive or on-demand) - Server configuration file in use: eap.xml

Note also that, for obvious reasons, the new instance of the Java/JEE server is also up to date. Ansible ensured that the latest available version of the JBoss EAP 8 was used. This ensures that any security fixes already available for the Java/JEE server have been applied.

As introduced previously and on the contrary to prior major releases, this update did not use the Java/JEE patching mechanism, but instead, using a new tool, shipped with the application server, called JBoss Installation Manager. Under the hood, the Ansible collection for WildFly has automatically used this tool transparently to install and set up the server on the targets, as  it’s the default mechanism for JBoss EAP8 installation.

Note

It is possible to install JBoss EAP 8 using the zip file rather than JBoss Installation Manager. Once the software is installed, however, use of the JBoss Installation Manager tool tool is required in order to keep the instance up to date. Thus, for this reason, it is recommended that the JBoss Installation Manager be used exclusively as the underlying tool for setting up and maintaining any instance of JBoss EAP 8 which can be driven by Ansible.

Summary

As this article demonstrated, it is fairly easy to automate the deployment and maintenance of JBoss EAP servers using Ansible, thanks to the content collection dedicated to the Java/JEE application server. Having Ansible maintain and update instances of either of the latest major releases (JBoss EAP 7 and JBoss EAP 8) requires minimal effort, as, by default, the collection will always ensure that the software is up to date. 

Upgrading an instance from JBoss EAP 7 to JBoss EAP 8 simply requires using a different target folder (or renaming the existing directory) to ensure that files of both application servers are not interspersed with each other. Otherwise, the automation process is identical and entirely encapsulated thanks to the Ansible collection for JBoss EAP.