Jira Release Notes
Using Galleon to Update a WildFly Installation
As discussed in the WildFly 16 release announcement, you can use the Galleon tool to create a customized WildFly installation. Once you’ve done that, if a new WildFly release comes out you can use Galleon to update your installation. In this post I’ll walk through the basics of doing that.
If you want to follow along with the examples, download the latest Galleon command line tool, unzip it and add the bin dir to your PATH.
Feature Packs and Channels
The simplest command to install the latest version of WildFly into the directory my-wildfly is to call:
$ galleon.sh install wildfly:current --dir=my-wildfly
Most of that command is self-explanatory, but what about the
wildfly:current part? That’s a feature-pack location or FPL. An FPL has a rich possible syntax, but most commonly you’ll see something simple like
wildfly:current. This consists of two parts:
wildfly— the name of the feature pack
current— the name of a channel from which the feature pack should be consumed. A channel represents a source of backward compatible releases. A feature pack may be available over numerous channels, with different channels restricting which versions of the channel are available. The
currentchannel for WildFly feature packs includes all versions.
list-feature-packs command to see what packs and channels are available:
$ galleon.sh 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
Feature packs for
wildfly-servlet are available, with
wildfly-servlet providing subsets of the traditional functionality of the WildFly application server. There are two channels for each, the
current channel, which will have the latest release available, regardless of major/minor version, and then the
9.0 channels for
wildfly-core respectively. The
final in the Update Channel column for each channel indicates that the default frequency for the channel is final releases. This means that unless instructed otherwise by the user the Galleon tool when looking for releases from the channel will limit itself to final releases.
When provisioning a new server to which you anticipate applying updates when new versions come out, it’s good to consider which channel you want, as that will become the default place the Galleon tool looks for future updates. When doing an update you can specify the channel to use, but if you don’t do that, the channel associated with the installation will be used. So, if you don’t want your WildFly 17 installation accidentally updated to WildFly 18, use the
Installing and updating from the 17.0 Channel
This blog is about updating an installation to 17.0.1.Final, so first we want to install 17.0.0. I’m going to install a customized build that uses the cloud-profile plus standard management functionality.
$ galleon.sh install wildfly:17.0#17.0.0.Final --dir=my-wildfly --layers=cloud-profile,core-server,core-tools
#17.0.0.Final in the FPL. I included this because by default Galleon would install the latest final version in the channel, i.e. 17.0.1.Final. Since this post is about updating to 17.0.1 I didn’t want to start there, so I added a specific feature pack version to the FPL. Normally you wouldn’t need to include that when provisioning a server.
get-info command tells us the status of the installation:
$ galleon.sh get-info --dir=my-wildfly ======= ============ ============== Product Build Update Channel ======= ============ ============== wildfly 17.0.0.Final 17.0
If I’m working inside a Galleon-provisioned installation, then I don’t need the
--dir=my-wildfly in all the commands:
$ cd my-wildfly $ galleon.sh get-info ======= ============ ============== Product Build Update Channel ======= ============ ============== wildfly 17.0.0.Final 17.0
check-updates to find out if updates are available for an installation:
$ galleon.sh 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
update to do the upgrade:
$ galleon.sh update
Galleon will prompt you with a y/n prompt to confirm. You can pass a
--yes param to the
update command to suppress this confirmation prompt.
I’ve observed that if I’m inside an installation directory and update it, for subsequent commands Galleon throws exceptions, until I maneuver out of the directory and back in.
If for some reason you don’t like the result of a provisioning step, use the
undo command to revert the most recent provisioning change (i.e. the update):
$ galleon.sh undo $ cd ../my-wildfly/ $ galleon.sh get-info ======= ============ ============== Product Build Update Channel ======= ============ ============== wildfly 17.0.0.Final 17.0
Finally, same as with the
install command, you can provide the FPL of the feature pack to update. (Its dependencies will also be updated.) This can be useful, for example, if an installation was associated with the
current channel but you want to be sure to only update to a WildFly 17 release.
$ galleon.sh update wildlfy:17.0 --yes
In that example I included the
--yes param to tell Galleon to skip the y/n confirmation prompt.
Dealing with a modified installation
Of course in the real world you probably don’t provision a server, do nothing with it, and then update it. Instead, you probably modify the installation in some way after the initial install; e.g. add a deployment or use the CLI to change a configuration value. If you’ve done this, when you do an update, Galleon tracks the changes you have made and reapplies them.
This asciinema recording shows this kind of workflow in action. It also demonstrates the Galleon CLI’s interactive shell, where you can provide a series of commands without having to type
galleon.sh all the time.
I start the recording after the initial provisioning.
Enjoy, and as always, thank you so much for your support of WildFly! And many thanks to Jean-Francois Denise for his help with this post!