Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The log volumes, they burn! #8

Open
James9074 opened this issue Feb 18, 2018 · 2 comments
Open

The log volumes, they burn! #8

James9074 opened this issue Feb 18, 2018 · 2 comments

Comments

@James9074
Copy link

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 busy error. Because there's no way to remove this volume during docker 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?

@xuzhen1994
Copy link

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

image

@xuzhen1994
Copy link

Fixed this problem by upgrading the docker version from 1.13 to 18.09.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants