Docker Community Forums

Share and learn in the Docker community.

Self learning Docker: How to upgrade container (Jboss)

I am new to Docker and learning my self.

Currently I have installed Docker and I am running JBoss Image. I have two scenarios I got stuck, please help me on this.

  1. I need to update the JBoss configuration, for that first I need to stop JBoss. As soon I am stopping the JBoss the container also stopping and I am unable to do any config changes. How can I keep the container UP to make some changes to the configuration files though the JBoss is stopped.

  2. I have some applications deployed in JBoss container and I need to upgrade the JBoss version in the container, how can I do? If I pull new version image again I need to setup all my applications, without doing this rework how can we achieve it?


There is 2 ways of doing it.

1- use volumes, either a docker volume or a shared path into the container, that way changes to files in that folder, will survive a start/stop and even a recreate of the container

2- build an image where the configuration files are copied to the image, and you then have some version control of your images, if you found out the configuration changes you made didnt work, simply specify the version before the current one and start it up again

which one is the easiest? #1

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

Thanks terpz, l will try to implement it.