Overview

• 1: Getting started
• 1.1: Wildfly Collection
• 2: Contribution Guidelines

1 - Getting started

Overview

Welcome! We are excited that you would like to learn more about the capabilities provided by Ansible Middleware. This tutorial will walk you through the steps to get up to speed quickly including

• Setting up the required tooling on a local machine.
• Getting familiar with Execution Environments.
• Setting up an inventory
• Deploying an instance of Wildfly
• Validating the deployment

Before you get to the hands-on part of the guide, you should become familiar with Ansible constructs, such as collections, controller nodes and Execution Environments.

What is a control node?

A control node is a machine from which we would like to push the configurations to the managed nodes/hosts. Managed nodes are target instances that we would like to configure and can be defined under inventory. An inventory is a list of nodes provided by one or more sources. It can be in INI or YAML formats. An example of inventory with hosts with multiple groups.

What is an ansible collection?

Collections are a distribution format for Ansible content that can include playbooks, roles, modules, and plugins. By default while installing collections using ansible-galaxy collection install we are referring to the public Galaxy server . However, we can configure a different galaxy server, like Ansible Automation Hub , by providing the details of the server in the ansible.cfg file. You can follow this guide which describes the process.

What is an Execution Environment?

An Execution Environment is a container image that is preloaded with system-level dependencies and collections that allow users to run jobs without actually setting them up. These execution environments are created using ansible-navigator .

1.1 - Wildfly Collection

Local machine setup:

First, let’s set up the required dependencies on the local machine. Start by installing Ansible on the local machine using your preferred method. See the Installing Ansible section of the documentation for the available options.

For this guide, we are using 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 Ansible Middleware team includes all of the Ansible Middleware collections and their dependencies, so there is no need to install any additional components on the control node. We would be using this execution environment as it already includes all of our latest collections so we don’t have to set it up again.

Once ansible-navigator is installed, we can pass parameters –eei or –execution-environment-image with the name of the image to the ansible-navigator to specify the image we would like to use. 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

Setting up the inventory:

A target node running RHEL 8 Virtual Machine is required as the destination for whichWildfly can be deployed. Create an inventory file on the local machine, which includes the hostname of the RHEL 8 instance, the IP address, and login information for Ansible to connect. SSH authentication is being used to communicate with the target node and the location of the SSH private key on the controller node must be specified in the inventory. The inventory should look similar to the following:

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

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"

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.

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 .

2 - Contribution Guidelines

Contribution Guidelines

• All YAML files named with ‘.yml’ extension
• Use spaces around jinja variables. {{ var }} over {{var}} Variables that are internal to the role should be lowercase and start with the role name
• Keep roles self contained - Roles should avoid including tasks from other roles when possible
• Plays should do nothing more than include a list of roles except where pre_tasks and post_tasks are required when possible
• Separators - Use valid name, ie. underscores (e.g. my_role my_playbook) not dashes (my-role) Paths - When defining paths, do not include trailing slashes (e.g. my_path: /foo not my_path: /foo/). When concatenating paths, follow the same convention (e.g. {{ my_path }}/bar not {{ my_path }}bar)
• Indentation - Use 2 spaces for each indent vars/ vs defaults/ - internal or interpolated variables that don’t need to change or be overridden by users go in vars/, those that a user would likely override, go under defaults/ directory
• All arguments have a specification in meta/argument_specs.yml
• All playbooks/roles should be focused on compatibility with Ansible Automation Platform controller

Interested in contributing to the Ansible Middleware project? Navigate to the ansible-middleware GitHub organization and join the community!