Provisioning WildFly with Galleon

by

No doubt the simplest way to install WildFly is by unzipping the zip files from the distribution and run it. On the other hand, if you want to be able to provision, update and customize your WildFly server distribution, keep reading this article we will talk about Galleon!

Galleon is the latest tool which you can use to provision WildFly. By “provision” we mean a more advanced type of installation, with more options and with an eye on maintenance. Let’s start!. Galleon tool can be downloaded from https://github.com/wildfly/galleon/releases

Just download the latest release of it and, from the /bin/ folder of it, launch the script:

$ ./galleon.sh
[bin]$

You will enter into the Galleon shell. From there you can have an initial look at the available commands, just typing ‘help’:

[bin]$ help

The core commands available are:

  • check-updates: Get available updates for a full installation or an identified feature pack
  • find: Find feature pack locations that match the pattern
  • get-changes: Display the files modified, added or removed from an installation
  • get-info: Display information on an installation directory
  • install: Installs specified feature pack
  • list-feature-packs: List latest available feature packs for the default frequency
  • persist-changes: Persist the configuration changes into the provisioning configuration
  • provision: Provision an installation from a provisioning file
  • undo: Undo the last provisioning command
  • uninstall: Un-install a feature pack from an installation
  • update: Update the installation to the latest available updates and patches

Let’s start from the simplest use case, that is to say, we want to install WildFly 17.0.0.Final in the folder /home/francesco/wildfly. Here is how to do it from the Galleon CLI:

install wildfly:17.0#17.0.0.Final --dir=/home/francesco/wildfly

In a couple of minutes, the WildFly installation will be provisioned

Feature pack installed.
======= ============ ============== 
Product Build        Update Channel 
======= ============ ============== 
wildfly 17.0.0.Final 17.0

Later, some updates might be available. First, we move to the folder where we installed WildFly, then we run the command “check-updates” to verify if any update is available:

[bin]$ cd /home/francesco/wildfly 

[wildfly]$ check-updates
Feature-packs resolved. 
Some updates and/or patches are available.
======= ============= ============ ============== 
Product Current Build Update       Update Channel 
======= ============= ============ ============== 
wildfly 17.0.0.Final  17.0.1.Final 17.0

So the Update 17.0.1.Final is available. Let’s update our installation:

[wildfly]$ update
Feature-packs resolved. 
Some updates and/or patches are available.
======= ============= ============ ============== 
Product Current Build Update       Update Channel 
======= ============= ============ ============== 
wildfly 17.0.0.Final  17.0.1.Final 17.0

Customizing WildFly installation

That being said for the standard installation, let’s see now how to customize WildFly installation. The first variation we can apply, is installing a different feature-pack, instead of the current/final. Just type list-feature-packs:

[bin]$ list-feature-packs 
=============== ============== ============ 
Product         Update Channel Latest Build 
=============== ============== ============ 
wildfly         current/final  17.0.1.Final 
wildfly         17.0/final     17.0.1.Final 
wildfly-core    current/final  9.0.2.Final  
wildfly-core    9.0/final      9.0.2.Final  
wildfly-servlet current/final  17.0.1.Final 
wildfly-servlet 17.0/final     17.0.1.Final

As you can see, a feature pack is substantially a collection of layers which are already packaged to provide a distribution of WildFly. There are mainly 3 feature packs available:

  • A wildfly feature pack, featuring the full distribution of WildFly
  • A core feature pack, with just the core server functionalities (i.e. WildFly without any Enterprise subsystem)
  • A wildfly-servlet feature pack which is substantially an Undertow only server

You can choose to install any of these feature packs instead of the default wildfly. For example, here’s how to install the current servlet feature pack:

[bin]$ install wildfly-servlet:current

Then, let’s see how to define which layers will be part of your installation. A layer means a combination of configuration and modules that can be included in your installation. Layers vary depending on the feature pack you are using:

WildFly layers

  • cdi: Support for cdi.
  • jaxrs: Support for jaxrs.
  • jms-activemq: Support for connections to a remote jms broker.
  • jpa: Support for jpa (latest WildFly supported hibernate release).
  • observability: Support for microprofile monitoring and configuration features (config, health, metrics, open-tracing).
  • resource-adapters: Support for deployment of JCA adapters.
  • h2-database: Support for h2 database.
  • cloud-profile: an aggregation of the basic layers (except h2-database).

WildFly servlet layers:

  • ee: Support for common functionality in the Java EE platform.
  • legacy-security: Support for legacy web security.
  • naming: Support for JNDI.
  • undertow: Support for the Undertow HTTP server.
  • undertow-load-balancer: Support for Undertow configured as a load balancer.
  • vault: Support Picketbox security vaults.
  • web-server: A servlet container composed of ee, naming, deployment-scanner (from WildFly core feature-pack) and undertow configured as a servlet container.

WildFly core layers

  • base-server: Empty runnable server.
  • core-management: Support for server management services.
  • deployment-scanner: Support for deployment directory scanning.
  • discovery: Support for discovery.
  • elytron: Support for Elytron security.
  • io: Support for XNIO workers and buffer pools.
  • jmx: Support for registration of Management Model MBeans.
  • jmx-remoting: Support for registration of Management Model MBeans and a JMX remoting connector.
  • logging: Support for logging subsystem.
  • management: Support for remote access to management interfaces.
  • remoting: Support for inbound and outbound JBOSS Remoting connections.
  • request-controller: Support for request management.
  • secure-management: Support for remote access secured thanks to Elytron to management interfaces.
  • security-management: Support for security manager.

So, for example, here’s how to install a skimmed version of WildFly which just contains jaxrs, jpa and cdi:

install wildfly:17.0 --layers=cdi,jaxrs,jpa --dir=/home/francesco/wildfly

If you check the standalone.xml file created for this installation, you will see that just the basic wildfly and wildfly-core modules (and their dependencies) have been installed:

    <extensions>
        <extension module="org.jboss.as.clustering.infinispan"/>
        <extension module="org.jboss.as.connector"/>
        <extension module="org.jboss.as.deployment-scanner"/>
        <extension module="org.jboss.as.ee"/>
        <extension module="org.jboss.as.jaxrs"/>
        <extension module="org.jboss.as.jpa"/>
        <extension module="org.jboss.as.naming"/>
        <extension module="org.jboss.as.transactions"/>
        <extension module="org.jboss.as.weld"/>
        <extension module="org.wildfly.extension.bean-validation"/>
        <extension module="org.wildfly.extension.elytron"/>
        <extension module="org.wildfly.extension.io"/>
        <extension module="org.wildfly.extension.undertow"/>
    </extensions>

Finally, it’s worth mentioning that you can use Galleon also in non-interactive mode, by passing the commands to the galleon.sh shell as follows:

$ galleon.sh install wildfly:17.0 --layers=cdi,jaxrs,jpa --dir=/home/francesco/wildfly
Found the article helpful? if so please follow us on Socials