xuzhen1994
commented
5 years ago Also met this problem when i migrated jira service desk. I commited my running container and pushed the image to the docker hub, then i pulled the image in another server. There is a problem when i run the image. message: Setup: JIRA couldn't create the jira.home directory
First off: You're a hero to the community - thanks for your work on these Atlassian containers.
Second: Sadly, to actually upgrade these, as you know, you've got to do it The Hard Way™. I've found that simply upgrading the containers won't migrate the DB since Atlassian isn't that forward thinking yet. I'm not suggesting you do any work to provide that, but I would like to propose something super simple that would help us out.
This line right here, I want the second volume gone for good:
VOLUME ["/var/atlassian/jira", "/opt/atlassian/jira/logs"]The upgrade binary Atlassian provides requires a complete wipe of the /opt/atlassian directory. It fails when it can't wipe /opt/atlassian, which it can't because it's mounted - rightfully returning a
device or resource busyerror. Because there's no way to remove this volume duringdocker run, I have to rebuild this image for every update and exclude that second opt logs volume to actually upgrade jira, or I have to do a dance and move the install directory around, upgrade it, change the JRE_HOME env var, and move everything back (which is a pain).I'm all about mounting the logs dir, but could we have that be something users need to do during run time? Because your readme told me to, I do it manually anyways in rancher and when running
docker run, so I doubt the need to include it in the image is too important. Note that the /var mount can totally stay, it doesn't cause any issues and should probably be forced to prevent data loss anyways.Additional Context: When upgrading jira "the right way" it requires me to run another container with /bin/bash as the entrypoint and doing the jira upgrade process manually. JIRA has to shut down to upgrade so we can't do it in the already running container as the root pid is jira of course. This proposal would apply to all of your jira containers naturally as the upgrade process is almost identical for all of them.
Thoughts?