WildFly is a modular & lightweight application server based on the Jakarta EE standard.
You can start a Wildfly Sever with the help of Docker quite simple. To start a blank wildfly server in its standard configuration run:
$ docker run -it quay.io/wildfly/wildfly
Bundle Your Application
If you want to bundle your own application you just need a simple Docker file like this:
FROM quay.io/wildfly/wildfly:26.0.0.Final
COPY ./target/*.war /opt/jboss/wildfly/standalone/deployments/
This will copy your web application or microservice from a maven project into the Wildfly deployment directory. The applicaton will be be automatically deployed during startup.
Wildfly & Microprofile
Wildfly comes with different configuration profiles (e.g. cluster mode, full version, microprofile). These configuration files are located in the server directory /opt/jboss/wildfly/standalone/configuration
To start your Wildfly container with one of these configurations – for example with the Eclipse Microprofiles you just need to add a parameter to the startup command, specifying the configuration profile:
FROM quay.io/wildfly/wildfly:26.0.0.Final
COPY ./target/*.war /opt/jboss/wildfly/standalone/deployments/
# Run with microprofiles
CMD ["/opt/jboss/wildfly/bin/standalone.sh", "-b", "0.0.0.0", "-bmanagement", "0.0.0.0", "-c","standalone-microprofile.xml"]
This Dockerfile will now activate the standalone-microprofile.xml configuration during next startup.
Custom Configurations
Of course you can also customize your configuration. For this purpose just copy one of the standalone-*.xml Files form a running container to your host:
$docker cp [CONTAINER_ID]:/opt/jboss/wildfly/standalone/configuration/standalone.xml ./my-standalone.xml
Replace [CONTAINER_ID] with the ID of your running wildfly container.
Next you can edit the standalone.xml file and add your project specific configurations. Finally add you custom file to the container Image via the COPY
command in your Dockerfile:
FROM quay.io/wildfly/wildfly:26.0.0.Final
COPY .my-standalone.xml /opt/jboss/wildfly/standalone/configuration/
COPY ./target/*.war /opt/jboss/wildfly/standalone/deployments/
# Run with custom configuration
CMD ["/opt/jboss/wildfly/bin/standalone.sh", "-b", "0.0.0.0", "-bmanagement", "0.0.0.0", "-c","my-standalone.xml"]
That’s it!
I believe that for enterprise applications that don’t need a lot of scalability, a cluster with multiple Wildfly (HA) on the same private network is a great option. But what about applications that need to migrate to Kubernetes, is it possible to take full advantage of the application server or is it better to migrate to Quarkus in this case?
The HA variants are exactly for that – a distributed setup in a cloud environment like kubernetes. So don’t worry about that point. But HA is also only necessary if you need synchronisation. For example for stateful session beans or session scoped web CDI beans in web applications. For a typical microservice (not holding any state) you can go with the standalone.xml variant and simply increase your deployments in Kubernetes if you need more and more nodes.