Some guideline for installing services on Fedora Server from WG provided ansible roles

[John W. Himpel]

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.

[Kevin Fenzi]

On Wed, Aug 18, 2021 at 09:45:40AM -0500, John W. Himpel wrote:
> 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.

I suppose it might make sense to make a collection for fedora specific
things. That said, it would be better if we could just contribute to
existing collections and get it to work more generically...
> 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

I've not been active lately and I don't want to tell the people doing
the work what to do, but that said, perhaps wildfly is a bit large of a
thing to start with?

In the previous iteration of fedora server, we had a custom thing called
'rolekit' that would deploy a few things on fedora server, but I think
the only ones we had working/testable were: database server (postgres)
and freeipa server.

I wonder if it might be easier to start with to try and get deployments
of those working and testable.

But thats just my thought on it, don't let me block anyone from what
they want to work on!

kevin

[John W. Himpel]

On Thu, 2021-08-19 at 12:54 -0700, Kevin Fenzi wrote:
> On Wed, Aug 18, 2021 at 09:45:40AM -0500, John W. Himpel wrote:
> > 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.
>
> I suppose it might make sense to make a collection for fedora specific
> things. That said, it would be better if we could just contribute to
> existing collections and get it to work more generically...
> > 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
>
> I've not been active lately and I don't want to tell the people doing
> the work what to do, but that said, perhaps wildfly is a bit large of a
> thing to start with?
>
> In the previous iteration of fedora server, we had a custom thing called
> 'rolekit' that would deploy a few things on fedora server, but I think
> the only ones we had working/testable were: database server (postgres)
> and freeipa server.
>
> I wonder if it might be easier to start with to try and get deployments
> of those working and testable.
>
> But thats just my thought on it, don't let me block anyone from what
> they want to work on!
>
> kevin

Kevin,

Upstream does not seem to have a way to communicate with him.  So I am forking his efforts.  I am more than glad to keep
the existing RHEL configuration intact.

I can get the role to install standalone, domain controller and domain slave instances.  I have been testing quickstarts
against the resulting instances, it they all work fine so far.

But my knowledge of Wildfly is very limited.  I am familiar with Websphere and Weblogic.  So I need to find a subject
matter expert on configuring Wildfly.  Questions that I have:
1)  There are lots of when statements that check the version of RHEL.  Is there any reason to try and support RHEL
versions prior to RHEL 7?
2)  The ansible tasks that connects to Wildfly and tries to establish Wildfly Vault, fails to connect.  It appears as
though wildfly is not opening the requested port.  I assume it's a configuration error in Wildfly, but I have no idea
where to look.
3)  Wildfly Vault has been depreciated and will go away in the next major release of Wildfly.  It is being replaced by
Elytron. I get very lost trying to decipher the installation docs for Elytron.  I'm not a security expert and get lost
in the jargon.
4)  The ansible role assumes dedicated log files for wildfly.  Should I migrate the logging to use systemd-journal?

I'm afraid these types of questions are above my knowledge of wildfly.  Any pointers on where a newbie to wildfly can go
to seek help on these types of issues would be greatly appreciated.  Or better yet, a living and breathing mentor would
be greatly appreciated.

If you have any pointers to the repository of previous efforts to install postgresql server roles, please pass them
along.  I would like any work that I do to follow any "best practices" that may be exhibited by this earlier work.

Thanks.

John