Using Ansible to install and configure Wildfly - Status Report

[John W. Himpel]

I have chosen to address this effort in the mailing list, so as not to consume all of the
oxygen during our IRC
meetings.

I started this effort by cloning https://github.com:KAMI911/ansible-role-wildfly .

It soon became apparent the cloned role supported RHEL 6 (currently no longer receiving
updates) and older versions of
Wildfly no longer supported by the Wildfly Project.  Also the support for server
startup/shutdown using systemd did not
function properly.

The cloned project also used the legacy security system provided by Picketbox.  This
security system was dropped from
Wildfly 25 which was released on October 05, 2021.  The new security system is provided by
Elytron.

As a result of all of the above, I decided to refactor ansible-role-wildfly into more
manageable pieces (the old version
has some very long and complex task files).  I also removed all of the code that supported
RHEL 6. I have updated the
minimum requirements for RHEL to 7 and Wildfly to release 25.  I have removed the support
for init.d (SYSV)
startup/shutdown and fixed the issues with using systemd for startup/shutdown.

Currently, the refactoring only supports "standalone" server configuration.  The
cloned "domain" server configurations
(master/slave) seems to have fallen out of favor and the Wildfly Project now supports
HostControllers (one of which acts
as a DomainController) along with Server instances (and optional Server Groups).  As soon
as I complete the efforts to
enable SSL and Elytron (as described below), I plan to circle back and work on supporting
this new "domain"
configuration architecture.

The refactored module currently installs, configures, starts and stops Wildfly 25 in
standalone mode.
I propose configuring Wildfly's SSL capabilities in a separate Ansible role.  That is
my plan unless someone with more
Wildfly experience that I possess, suggests otherwise.

The new Elytron security system supports a single unified front-end interface.  The
storage mechanism can be provided by
several different backend storage methods.  Those methods include properties files,
filesystem directories and files,
LDAP, database, and Kerberos.  Rather than develop a single complicated Elytron role, I
propose implementing each
storage mechanism in it's own Ansible role.

Questions:
1) Does my plan for SSL and Elytron make sense?

2) Which Elytron storage mechanism should be the "recommended" for sites new to
Wildfly?

3) Is there a need to provide for configuring multiple standalone instances on the same
server?  This would require some
reworking of port number assignments inside the Ansible role.

4) Is Fedora's pagure mature enough to host an effort like this?  If so, would someone
kindly provide a pointer for a
novice to begin learning how to access and use it?  Or should we use github or gitlab
instead?

5) The Wildfly Project provides several different configuration files (full, full-ha, ha,
load-balancer, microprofile,
and microprofile-ha) in addition to standalone.xml for standalone servers.  I have chosen
to only update and support
standalone.xml.  Is there a significant demand to support any of the others standalone
configurations?

6) Should support for third party certificates and Lets Encrypt certificates be separated
into separate Ansible roles or
just have a single role for installing certificates?

7) Does anyone have experience using JCliff to configure Wildfly instances?

PS: The work progresses slowly because Wildfly documentation often assumes configuration
and operational support via a
GUI or via jboss-cli.sh commands (which are often difficult to make imdepotent). 
Hopefully, by doing some reverse-
engineering, I can figure out how to use the community.general.xml module to update the
standalone.xml file.