Cheat sheet: Wildfly Application Server

Abstract

This article contains information about the Wildfly Java Application Server in a compact format.

Enable SSL/HTTPS communication

Precondition

Provided: A PKCS12 Truststore file named truststore.pkcs12 with a domain certificate (you actually can use JKS as well) within the {$WILDFLY}/standalone/configuration directory.

Procedure

Using Wildfly 18 (and before) you can and should use the jboss-cli tool to configure the application server. You should actually avoid to manipulate the standalone*.xml or domain*.xml (for domain mode) file directly for a running instance, due to file corruption issues that might occur.

#cd {$WILDFLY_BASE}/bin
#./jboss-cli.sh (Use the .bat for Windows)

Connect jboss-cli to the local Wildfly instance:

[disconnected /] connect

Check the associated realm for the https-listener (here default “ApplicationRealm”):

[standalone@localhost:9990 /] /subsystem=undertow/server=default-server/https-listener=https:read-attribute(name=security-realm)

{
"outcome" => "success",
"result" => "ApplicationRealm"
}

Configure the elytron security subsystem via a batch process:

[standalone@localhost:9990 /] batch
[standalone@localhost:9990 / #] /subsystem=elytron/key-store=demoKeyStore:add(path=truststore.pkcs12,relative-to=jboss.server.config.dir, credential-reference={clear-text=<Truststore Password>},type=PKCS12)
[standalone@localhost:9990 / #] /subsystem=elytron/key-manager=demoKeyManager:add(key-store=demoKeyStore,credential-reference={clear-text=<KeyManager Password>})
[standalone@localhost:9990 / #] /subsystem=elytron/server-ssl-context=demoSSLContext:add(key-manager=demoKeyManager,protocols=["TLSv1.2"])
[standalone@localhost:9990 / #] /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
[standalone@localhost:9990 / #] /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=demoSSLContext)

Run the batch:

[standalone@localhost:9990 / #] run-batch

Reload the configuration:

[standalone@localhost:9990 /] reload

Servercluster: Using a Load Balancer and Working Nodes

Wildfly (since 10) comes with a preconfigured load-balancer profile, that we can actually use to distribute requests in a round-robin mechanism towards the working nodes. Wildfly’s load balancing subsystem is based on the mod_cluster load balancing system and uses its own distributed session manager component on top. This will make sure that the session state isn’t lost during delegation.

Load balancer

For standalone instances you can use the standalone-load-balancer.xml profile that is located under $WILDFLY/standalone/configuration.

Example usage for a private network:

./$WILDFLY/bin/standalone.sh -b $HOST_IP -bprivate $HOST_IP -c standalone-load-balancer.xml

Worker nodes

The worker nodes must run using the HA (or Full HA ) profile. I recommend the Full HA profile. The propagation takes place using UDP multicast, so actually no setup is required. The auto-discovery functionality will only work if load balancer node and worker nodes are in the same sub-net, otherwise you have to configure their network-addresses manually.

Example usage for a private network (for each node):

./$WILDFLY/bin/standalone.sh -c standalone-full-ha.xml -b $HOST_IP -bprivate $HOST_IP

Example configuration for worker nodes if UDP discovery doesn’t work:

export LOAD_BALANCER_IP=xxx.xxx.xxx.xxx

$WILDFLY/bin/jboss-cli.sh <<EOT
embed-server -c=standalone-full-ha.xml
/subsystem=modcluster/mod-cluster-config=configuration:write-attribute(name=advertise,value=false)
/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=proxy1:add(host=$LOAD_BALANCER_IP,port=8090)
/subsystem=modcluster/mod-cluster-config=configuration:list-add(name=proxies,value=proxy1)
EOT

./$WILDFLY/bin/standalone.sh -c standalone-full-ha.xml -b $HOST_IP -bprivate $HOST_IP

Distributable WebApp

Your WebApp should be marked as being distributable. You only have to put a simple line in the web.xml to make sure that the Wildfly instances are aware of its intention:

<distributable />

That’s it. Then you have to deploy the WebApp to the elected master node of the cluster using the management console.