WildFly Managed Domain on PaaS: One Admin Console, Worker Hosts That Provision Themselves

Jakarta EE shops that run several WildFly servers know the failure mode: each server was configured by hand at a different time, the configurations drift, and a deployment means logging into six consoles. WildFly's managed domain mode was designed to end that, and containers make it practical. This post follows an operations lead adopting the WildFly Managed Domain Cluster on MassiveGRID PaaS, which is built on Virtuozzo Application Platform, formerly Jelastic.

The organisation is a regional health insurer we will call Beacon Mutual, with a claims-processing application on Jakarta EE, currently on six standalone WildFly servers. The WildFly Managed Domain Cluster deploys a domain controller holding configuration and deployments, worker hosts running the application in a cluster-enabled profile, and a load balancer in front, with new hosts registering to the controller automatically.

Standalone versus managed domain, in one paragraph

In standalone mode each WildFly server has its own configuration file and its own deployments, and you manage each separately. In managed domain mode a domain controller holds the configuration for every server, organised into server groups that share a profile and a socket binding group, and holds the deployments too. Host controllers on each machine start the servers assigned to them with the configuration the domain controller hands down. Deploy a WAR to a server group and every server in it receives it. Change a datasource in the profile and every server gets the change. Drift becomes impossible by construction.

What the package builds

The package creates the domain controller as its own container with the management console exposed over HTTPS, a layer of worker host containers each running a host controller and server instances in a cluster-enabled (HA) profile, and an NGINX load balancer with sticky sessions and health checks. The part the operations lead cares about most is auto-scaling: when the platform adds a worker host on a trigger, it registers with the domain controller, receives the profile and the current deployments, starts its servers and joins the balancer, with no one touching a console. Removing a host is the reverse.

Migrating six standalones into one domain

The lead's migration is a configuration exercise, not a code change.

1. Diff the six standalone configurations. Four differences turn out to be accidents (a timeout set on two servers only, a logging level left at DEBUG on one) and one is real: two servers had a larger connection pool because they took batch traffic.
2. Build one profile on the domain controller with the correct values, and two server groups: web with the standard pool and batch with the larger one, both using the HA profile so sessions and caches replicate within the group.
3. Deploy the claims application WAR to both server groups from the console. Each host's servers receive it.
4. Point the balancer at the web group; the batch group takes scheduled jobs from a queue and does not need to be in the balancer.
5. Rehearse it all on a cloned environment first, which for a domain that is entirely configuration is the natural place to iterate.

Deployments: console, CLI or Git

The domain controller's console and the jboss-cli both deploy to server groups; the lead scripts releases with the CLI from the CI pipeline, connecting to the controller's management port over the internal network. For teams that prefer a push, the marketplace's WildFly Continuous Deployment package adds a Maven build node that builds from a Git repository and deploys to the domain. Either way the deployment lands on every server in the group, and WildFly's rolling deployment across the group, combined with the balancer's health checks, keeps the application available during the roll.

Sizing Java in cloudlets

The domain controller does no application work and sits at a few cloudlets. Each worker host runs a JVM per server instance; Beacon's hosts run one web server each at a 32-cloudlet limit (a cloudlet is 128 MiB of RAM plus 400 MHz of CPU), with the JVM heap following the container's allocation and vertical scaling billing the hour's actual use. Three web hosts and one batch host during the day, two web hosts at night, average about 90 cloudlets an hour across the environment, roughly $220 a month before discounts at MassiveGRID's published $0.003372 per cloudlet-hour, against six always-on VMs whose licences for a supported application server had been a separate line entirely. WildFly is LGPL-licensed; there is none.

What changed operationally

Releases went from an evening to a lunchtime. The DEBUG logging level that had been filling one server's disk for a year disappeared with the profile. And when the platform's load alert reported the batch host hot at month-end, the lead raised its cloudlet limit from the dashboard rather than building a seventh server. The domain controller is the one stateful component and is backed up nightly with its configuration and deployments directory; a clone of the environment is the disaster-recovery rehearsal, taken quarterly.

Frequently Asked Questions

Is the domain controller a single point of failure?

For management operations, yes: if it is down you cannot deploy or change configuration until the platform restores it, which it does automatically on a healthy host. Running servers keep serving without it, because host controllers cache the configuration they were given. WildFly also supports a backup domain controller for environments that need continuous management.

Can worker hosts run several server instances?

Yes. A host controller can run multiple servers assigned to different server groups, for example one web and one batch server per host. On the platform it is usually simpler to give each server group its own host layer so they scale independently.

Which WildFly version does the package install?

A current stable WildFly with a matching LTS JDK, both changeable from the dashboard. Upgrade by redeploying the containers to a newer version tag, rehearsed on a clone first as with any domain change.