Maintaining attachments can be real resource hog as they tend to grow indefinetly and making the maintenance more and more complex.
Is there a way to outsource the attachments upload, storage and delivery to an external service la Amazon S3?
All Jira needs for attachments is something that is presented to it like a file system it can read and write.
NFS, SAMBA shares, SAN storage, Dropbox, NAS, etc, all present areas that are directory like (whatever the underlying storage is) and work fine as attachment storage. Amazon S3 will work fine as long as it can be mounted and look like a file system to Jira.
Probably you are missing an essential point: the whole point for using S3, Dropbox or similar solutions is to allow people to download the files directly form the provider, without requiring jira server to download and redirect the file.
Because they are using hashes for URLs, security is not so important as anyone with the URL should be able to download the file. And it is virtually impossible to guess links.
Er, no, you asked about storing attachments on external services. I answered that - Jira just needs file system storage for attachments.
Managing attachments is a different question. What exactly are you looking for there? Why are you bypassing Jira when the whole point of attachments is that they belong to issues? If you want external document management, why not just disable attachments in Jira and do it with something designed for it?
There are good performance reasons why anyone would want to just bypass jira for download attachments. Some people have to work with huge attachments, and in this case if you do not provide the link to the clould to the requester, jira will have to download the huge file from the cloud in order to pass it over to the client requesting it. This adds a considerably load and delays in the process.
Attachment management should be done by jira but jira should allow bypassing download links to 3rd party storage solution.
I'm well aware that Jira isn't designed as a highly performant attachment server, but that's pretty much an irrelevance, there are other issues to worry about before you get to performance. As I already said, it's not designed as a document management system, so I'm trying to get at your actual requirements. Why are you trying to use Jira to do this instead of a document manger? It's aimed at small uploads like the odd picture and so-on.
Thanks, Nic, I really apreciate your interest. In this case it is not about improperly using Jira for document management. In fact it is about the normal usage: to attach information related to issues, and sometimes this requires big logs, crashdumps and even memory dumps which can be huge. Most of the time these files are not changed or even accessed. Doing Jira backups can be really tricky if you store attachments locally so storing them in the clould should be much easier.
Is there a manual or guideline somewhere about mounting of Amazon S3 as a storage for attachments? Also, would it be possle to mount S3 to a JIRA instance running on remote host outside Amazon Elasic Cloud? Would you recommend that or would it be better to keep everything hosted at Amazon? Thanks!
The problem hasn't really changed - typical Jira usage is small related attachments, screenshots and logs. If you manage them outside Jira, they lose their relevance. If they're large and numerous, well, that's not what Jira is for and it's not built for it, you should be using a different system.
There are ways to mount S3 buckets and make them appear as part of a filesystem -- on both Windows and modern Unix (using FUSE). So, in theory, one can mount a bucket and tell JIRA (and/or Confluence) to use it to store attachments. To access them one would use the web-server fronting the application (such as Apache) to either flat-out rewrite the app-generated HTML – modifying all attachment-links to point directly at S3 (with something like mod_substitute or mod_sed) – or to simply issue 301 (permanent) redirects in response to any requests for attachments (using RedirectMatch-directives provided by mod_alias).
Another alternative is to simply have a cron-job push new attachments over to S3 – outside of the application – and deleting the local file. Your redirect-rules would then have to be smarter – they'll need to check, whether the requested attachment is available locally and only issue a redirect, if it is no longer found on the host (in the assumption, that it was moved to the cloud already.) Apache's mod_rewrite can handle such logic with aplomb.
No, I have not done it – but it is possible in theory. It would've been much nicer, of course, if Altassian implemented this natively (S3 is not a truly POSIX filesystem, unfortunately – one may be unable to open, what was just written-out, for example).
But until our vendor cooperates, this is the best we can do...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot