Get started with the Wildfly collection

Getting up to speed with Ansible Middleware Collections is easy, and installing the Red Hat Ansible Automation Platform only requires a few steps. This tutorial demonstrates six steps to configure a WildFly instance using Ansible by preparing a local machine with the necessary tooling and then deploying an instance of WildFly using the WildFly collection provided by the Ansible Middleware.

Step 1: Install Ansible Automation Platform

First, let’s get Ansible Automation Platform installed on the control node. A control node is a machine from which we will push the configurations to the managed nodes/hosts. Managed nodes are the ones we would like to configure and they can be defined under inventory. You can install Ansible Automation Platform using your preferred method. Refer to the installing Ansible documentation for details.

Step 2: Install the galaxy server

Ansible Content Collections is a distribution format for content that can include playbooks, roles, modules, and plugins. By default, while installing collections using ansible-galaxy collection, we are referring to the Galaxy server. But we can configure a different galaxy server like the Ansible automation hub by providing the details of the server on ansible.cfg. You can follow the guide to do so. In this tutorial, we would be using the Galaxy server to install and configure using the middleware_automation.wildfly collection.

Step 3: Installing the ansible-navigator utility

We will use an execution environment and the ansible-navigator utility to perform the automation and provisioning of the WildFly instance. Install and configure ansible-navigator based on the documentation for your target operating system. To perform the execution of the automation, the ansible-middleware-ee execution environment provided by the team includes all of the Ansible Content Collections and their dependencies. So there is no need to install any additional components on the control node. We would be using our execution environment as it already includes all of our latest collections so we don’t have to set it up again.

Once ansible-navigator has been installed, execute the following command to browse all of the collections that are included within the execution environment image:

$ ansible-navigator --eei quay.io/ansible-middleware/ansible-middleware-ee:latest collections

In the following output, we see the list of all the collections available in our execution environment.

   Name                                      Version      Shadowed Type      Path
 0│ansible.builtin                           2.12.5.post0 False    contained /usr/local/lib/python3.8/site-packages/ansible
 1│ansible.netcommon                         3.0.0        False    contained /usr/share/ansible/collections/ansible_collections/ansible
 2│ansible.posix                             1.4.0        False    contained /usr/share/ansible/collections/ansible_collections/ansible
 3│ansible.utils                             2.6.1        False    contained /usr/share/ansible/collections/ansible_collections/ansible
 4│community.general                         5.0.0        False    contained /usr/share/ansible/collections/ansible_collections/communi
 5│middleware_automation.amq                 0.0.2        False    contained /usr/share/ansible/collections/ansible_collections/middlew
 6│middleware_automation.infinispan          1.0.3        False    contained /usr/share/ansible/collections/ansible_collections/middlew
 7│middleware_automation.jcliff              0.0.21       False    contained /usr/share/ansible/collections/ansible_collections/middlew
 8│middleware_automation.jws                 0.0.3        False    contained /usr/share/ansible/collections/ansible_collections/middlew
 9│middleware_automation.keycloak            1.0.4        False    contained /usr/share/ansible/collections/ansible_collections/middlew
10│middleware_automation.redhat_csp_download 1.2.2        False    contained /usr/share/ansible/collections/ansible_collections/middlew
11│middleware_automation.wildfly             1.0.2        False    contained /usr/share/ansible/collections/ansible_collections/middlew

Step 4: Setting up the inventory

Let's now set up a WildFly instance. Create an inventory file that includes a Red Hat Enterprise Linux 8 instance, the IP address of the instance, and login information for ansible to access it. We are using SSH keys instead of passwords. So these SSH keys are created on the controller node and we provide the path of the private key in the inventory file. Our inventory file looks like this:

[wildfly]
wildfly-0 ansible_host=10.0.148.43 ansible_user=root ansible_ssh_private_key_file=”path to your private key”

Step 5: Installing and configuring WildFly

Here is our Ansible Playbook wildfly.yml for installing and configuring WildFly:

---
- name: "Installation and configuration"
  hosts: wildfly
  vars:
   wildfly_install_workdir: '/opt'
   install_name: "wildfly"
   wildfly_user: "{{ install_name }}"
   wildfly_config_base: standalone-ha.xml
   wildfly_version: "26.0.0.Final"
   wildfly_home: "{{ wildfly_install_workdir }}/{{ install_name }}-{{ wildfly_version }}"
  collections:
   - middleware_automation.wildfly
  tasks:
   - name: Include wildfly role
     ansible.builtin.include_role:
       name: middleware_automation.wildfly.wildfly_install
   - name: "Set up for Wildfly instance"
     include_role:
       name: middleware_automation.wildfly.wildfly_systemd
     vars:
       wildfly_config_base: 'standalone-ha.xml'
       wildfly_basedir_prefix: "/opt/{{ install_name }}"
       wildfly_config_name: "{{ install_name }}"
       wildfly_instance_name: "{{ install_name }}"
       service_systemd_env_file: "/etc/{{ install_name }}.conf"
       service_systemd_conf_file: "/usr/lib/systemd/system/{{ install_name }}.service"

Step 6: Run the Ansible Playbook

Now, run the Ansible Playbook using ansible-navigator and the execution environment to configure WildFly on the remote node as follows:

$ ansible-navigator --eei quay.io/ansible-middleware/ansible-middleware-ee:latest run wildfly.yml -i inventory -m stdout --become

Once the playbook has completed executing, ssh into the instance and check the status and health check of the deployed WildFly service. We can do so with the following command:

$ ssh root@10.0.148.43 curl http://127.0.0.1:9990/health

The following code snippet shows the output:

[{"name" : "boot-errors", "outcome" : true},{"name" : "deployments-status", "outcome" : true},{"name" : "server-state", "outcome" : true, "data" : [{ "value" : "running" }]},{"name" : "live-server", "outcome" : true},{"name" : "started-server", "outcome" : true},{ "outcome" : true }]

Check the status of the WildFly service using the following command:

$ ssh root@10.0.148.43 systemctl status wildfly

In the following output, we can see the WildFly service is running without any errors:

● wildfly.service - JBoss EAP (standalone mode)
   Loaded: loaded (/usr/lib/systemd/system/wildfly.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2023-03-02 18:02:44 EST; 4 days ago
 Main PID: 52667 (standalone.sh)
    Tasks: 45 (limit: 23417)
   Memory: 263.6M
   CGroup: /system.slice/wildfly.service
           ├─52667 /bin/sh /opt/wildfly-26.0.0.Final/bin/standalone.sh -c wildfly.xml -b 0.0.0.0 -Djboss.server.config.dir=/opt/wildfly>
           └─52741 java -D[Standalone] -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4St>

Mar 02 18:02:47 wildfly-0 standalone.sh[52741]: 18:02:47,802 INFO  [org.jboss.modcluster] (ServerService Thread Pool -- 84) MODCLUSTER0>
Mar 02 18:02:47 wildfly-0 standalone.sh[52741]: 18:02:47,829 INFO  [org.wildfly.extension.undertow] (MSC service thread 1-1) WFLYUT0006>
Mar 02 18:02:47 wildfly-0 standalone.sh[52741]: 18:02:47,864 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread >
Mar 02 18:02:47 wildfly-0 standalone.sh[52741]: 18:02:47,953 INFO  [org.jboss.as.patching] (MSC service thread 1-2) WFLYPAT0050: WildFl>
Mar 02 18:02:47 wildfly-0 standalone.sh[52741]: 18:02:47,988 INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-1) WF>
Mar 02 18:02:48 wildfly-0 standalone.sh[52741]: 18:02:48,002 INFO  [org.jboss.ws.common.management] (MSC service thread 1-3) JBWS022052>
Mar 02 18:02:48 wildfly-0 standalone.sh[52741]: 18:02:48,179 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming>
Mar 02 18:02:48 wildfly-0 standalone.sh[52741]: 18:02:48,182 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 26>
Mar 02 18:02:48 wildfly-0 standalone.sh[52741]: 18:02:48,183 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management>
Mar 02 18:02:48 wildfly-0 standalone.sh[52741]: 18:02:48,183 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console l>
lines 1-20/20 (END)

We can also validate the instance using our validate.yml. This will check if the instance is running and if the WildFly port is accessible for use.

Explore other tutorials and resources

In this tutorial, we demonstrated how to set up and provision an instance of WildFly using the Ansible Content Collections for WildFly. We can also deploy JBoss EAP instead of the open-source WildFly using the same collection. For more information on deploying JBoss EAP refer to Automate and deploy a JBoss EAP cluster with Ansible. To deploy WildFly or JBoss EAP on multiple instances, you can refer to our wildfly-cluster-demo.

For a more complex scenario, check out our Flange project demo, which uses the JBoss EAP, Red Hat Single Sign-On, and Red Hat Data Grid as a cache and Red Hat Middleware Core Services Collection as a load balancer. Also, our redhat.jboss_eap collection is available on Ansible automation hub. Note that this collection is a Beta release and for Technical Preview.

You can check out the other collections and demos within the GitHub organization: ansible-middleware and the Middleware Automation Collections website.