Check this blog post and combine the mentioned jboss-cli approach with the 2nd approach terpz suggested!
Build a new image with the upgraded wildfly server version, make use of the jboss-cli and declare a dedicated folder where you map a volume with your jboss-cli scripts inside the container, then adjust the entrypoint script to actualy run all these jboss-cli scripts one by one. This will provide a great flexiblity.
Even though the blog post claims that you need to wait until the server is running, there is no need to do so: the jboss-cli allows to start an embedded-server, run your jboss-cli commands, stop the embedded-server, then continue with the rest of the entrypoint script that is now able to start a preconfigured wildfly server. It is cleaner to use the embedded-server for configuration purposes.
I used this approach in the past to add database drivers, datasources, truststores and configure other options allong the line.
Generaly: stay away from inline-updates of the core application inside a container, instead create a new image, as you’d need to repeat the update for each container. inline-Updates are considered a bad practice.
I can say from experience, that neither mounting a preconfigured configuration, nor render a configuration within the entypoint script remains maintainable on the long run.
Create a dedicated docker image per application! If you are deploying applications by mounting a ear/war file inside a location or even worse, deploying the ears/wars by using the wildfly console, you might want to reasearch more about the differences of vm’s and containers.
update: rewrote the whole content