You can use the Ansible collections to automate the installation and configuration of upstream middleware (Runtimes) and Red Hat Application Services (Red Hat Runtimes
).
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 - Wildfly Collection
Getting started with Ansible Middileware’s 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:
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:
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:
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
.