WildFly Docker image
This is an example Dockerfile with WildFly application server.
To boot in standalone mode
docker run -it jboss/wildfly
To boot in domain mode
docker run -it jboss/wildfly /opt/jboss/wildfly/bin/domain.sh -b 0.0.0.0 -bmanagement 0.0.0.0
With the WildFly server you can deploy your application in multiple ways:
- You can use CLI
- You can use the web console
- You can use the management API directly
- You can use the deployment scanner
The most popular way of deploying an application is using the deployment scanner. In WildFly this method is enabled by default and the only thing you need to do is to place your application inside of the
deployments/ directory. It can be
/opt/jboss/wildfly/domain/deployments/ depending on which mode you choose (standalone is default in the
jboss/wildfly image -- see above).
The simplest and cleanest way to deploy an application to WildFly running in a container started from the
jboss/wildfly image is to use the deployment scanner method mentioned above.
To do this you just need to extend the
jboss/wildfly image by creating a new one. Place your application inside the
deployments/ directory with the
ADD command (but make sure to include the trailing slash on the deployment folder path, more info). You can also do the changes to the configuration (if any) as additional steps (
A simple example was prepared to show how to do it, but the steps are following:
Dockerfilewith following content:
FROM jboss/wildfly ADD your-awesome-app.war /opt/jboss/wildfly/standalone/deployments/
- Place your
your-awesome-app.warfile in the same directory as your
- Run the build with
docker build --tag=wildfly-app .
- Run the container with
docker run -it wildfly-app. Application will be deployed on the container boot.
This way of deployment is great because of a few things:
- It utilizes Docker as the build tool providing stable builds
- Rebuilding image this way is very fast (once again: Docker)
- You only need to do changes to the base WildFly image that are required to run your application
Logging can be done in many ways. This blog post describes a lot of them.
Sometimes you need to customize the application server configuration. There are many ways to do it and this blog post tries to summarize it.
Extending the image
To be able to create a management user to access the administration console create a Dockerfile with the following content
FROM jboss/wildfly RUN /opt/jboss/wildfly/bin/add-user.sh admin Admin#70365 --silent
Then you can build the image:
docker build --tag=jboss/wildfly-admin .
docker run -it -p 9990:9990 jboss/wildfly-admin
The administration console should be available at http://localhost:9990.
Building on your own
You don't need to do this on your own, because we prepared a trusted build for this repository, but if you really want:
docker build --rm=true --tag=jboss/wildfly .
Image internals [updated Oct 14, 2014]
The server is run as the
jboss user which has the uid/gid set to
WildFly is installed in the
The source is available on GitHub.
Please report any issues or file RFEs on GitHub.
docker run -d -p 8080:8080 jboss/wildfly bash
docker exec -it jboss/wildfly bash
then i cannot access the 8080 port.why?
In the wildfly-admin Dockerfile of the above description last line is missing:
CMD ["/opt/jboss/wildfly/bin/standalone.sh", "-b", "0.0.0.0", "-bmanagement", "0.0.0.0"]
(however it's correct on the github documentation)
To clear up some confusions I read here in the comments and seeing everywhere. I made an example Docker Container based on jboss/wildfly. Including the mentions blogpost about configurations and logging, using the best practice guide from docker, too.
You can find it here:
Hope that helps to speed up wildfly app deployment.
@stuartgmilton Hi Stuart, You are more likely to find community help over at the Wildfly User Forum . Considering this error is a Wildfly subsystem. There are some solutions on the user forum I found useful.
I have issues deploying to the appserver using the wildfly-maven-plugin - any ideas?
"JBAS012174: Could not connect to http-remoting://127.0.0.1:40320. The connection failed: XNIO000812: Connection closed unexpectedly"
I had a look at the standalone.xml and I noticed the logs are being written to the console and to a file inside the container. Shouldn't the logs be written only to the console or, alternatively, to a volume? Is this image production ready?
how can i remove welcome page?
i know i should edit standalone.xml, but how in docker?
As the workaround (= issue ticket is not longer here : https://github.com/jboss/dockerfiles/issues/14 ) what is the workaround to resolve this issue ?
yum -y update && yum clean all Failed: systemd.x86_64 0:208-21.fc20 systemd.x86_64 0:208-22.fc20
Would it be possible to use some basic security protections while downloading the wildfly tarballs in the Dockerfiles, such as use of https:// URLs and/or tarball signature checking?