All,
I am putting this out there as a strawman for discussion purposes. It does reflect my
current efforts to install
Wildfly which is not available via rpm.
Comments and criticisms are welcome:
I would propose the following:
1. Ansible Repository.
1. The Fedora Server Working Group create and maintain a repository of Ansible
playbooks to download and install
various applications that are specifically aimed at the server community.
2. Investigate possible use of ansible-galaxy.
2. The playbooks should use Fedora provided rpms for applications and their components
wherever possible.
3. The use of ansible roles is strongly encouraged.
4. In the case of certain java applications, downloading of sources/binaries/jars from
trusted repositories (i.e.
wildfly.org,
mvnrepository.com, etc) inside of Ansible playbooks be allowed when Fedora
rpms are not available.
5. In accordance with Fedora Open Source policy, only software with Fedora approved
licenses may be downloaded.
6. Unless dictated by Fedora policy, the playbook should install non-rpm artifacts
under the /opt directory.
7. Where possible, services should be controlled via systemd.
8. Playbooks should be developed to install, configure, start, stop, enable, disable,
open firewall, close firewall
and remove (with or without application data) an application or service.
9. Applications with many add-ons, extensions or cooperating services should have each
add-on, extension or
cooperating service managed in a separate playbook.
Use case:
1. Wildfly
1. Install the most recent LTS version of java from rpm.
2. Download the most recent LTS wildfly application from
https://download/jboss.org.
3. Install the new wildfly application binaries.
1. under the /opt directory (directory structure TBD).
2. versioned to allow for simultaneous versions being installed.
4. Make any necessary modifications to the configuration files.
5. The following could be one playbook with multiple “tags”.
1. Install any necessary service/timer/etc files used by systemd to manage the
application.
2. Remove any necessary service/timer/etc files used by systemd to manage the
application.
3. Start the application via systemd.
4. Enable the application via systemd.
5. Stop the application via systemd.
6. Disable the application via systemd.
7. Mask the application via systemd.
8. Unmask the application via systemd.
6. The following could be one playbook with multiple “tags”.
1. Define service to be managed by firewalld.
2. Open ports for the service via firewalld.
3. Close ports for the service via firewalld.
7. Allow for standalone and domain versions of wildfly
8. CI to verify starting of a working instance of Wildfly
9. Simplify user documentation:
1. Ansible installation
2. Ansible inventory configuration
3. Required changes in vars and default directories
I did a few searches and found an ansible playbook on github called
KAMI911/ansible-role-wildfly.
Ansible-role-wildfly is currently architected to run on either RedHat Enterprise Linux
(v6 & v7). It also uses Java 8
instead of Java 11 (current LTS of java) and it uses wildfly v20.0.1 and the current
version of wildfly is 24.0.1. It
does not fully support systemd. Since Fedora 34 is newer than RHEL v6 & v7, it is my
uninformed opinion the playbook
needs some work to eliminate some of the no-longer-supported features of Wildfly and RHEL.
Fortunately all of these
things are fixable.
Ansible-role-wildfly is licensed under the terms of the MIT / BSD, so it is freely
redistributable with Fedora.
Ansible-role-wildfly also contains tasks and configuration that allow for Continuous
Integration testing. I’ve never
attempted that before, so I will leave evaluation of that functionality to someone better
qualified than I.
After some modifications to the playbook, I have installed a wildfly “standalone” instance
on a Fedora 34 Server
(netinstall). Almost all of the changes that I have made so far, are to allow wildfly
to run under the control of
systemd. Wildfly will start. All my experience with JEE is based upon WebLogic and/or
WebSphere.
Unfortunately, my web app is configured to run under Weblogic, and would need considerable
work to migrate to Wildfly.
During the next week or so, I will attempt go get a proof-of-concept application deployed
and running.
I could use assistance from someone familiar with configuring Wildfly to advise me about a
good way to configure Wildfly
for a very basic setup and what configuration of older functionality can be removed from
the playbook.