due the nature of our business, we need to keep all customer data living in both Confluence and Jira, totally separate from other potential customer areas. I'm trying to figure out the best way to do this.
It looks like we are going to be getting a couple of new customers in the next few months (), and they will all need their data to be kept totally separate from each other.
It seems that I can:
Are my musings above, accurate ? (im new to the Atlassian suite, but hope to do the full training in the next few months )
There is no easy way to run a single confluence & JIRA system, but keep customers 'separate' in different databases ? (I also see that all the attachments for different customers, would be lumped together in Confluence).
Any advice ?
Is clustering going to cost me a small fortune ?
Is there a reason your situation can't be handled with permissions? Each customer is only given permission for certain JIRA stories and spaces in confluence? The content would be stored in the same DB but they wouldn't be able to access each others data since they would not have permission to do so.
To Alex's and Nic's points, we have successfully used space permissions and even page restrictions to segregate customers within one instance. We had one instance that might be considered extreme to some but wasn't to us - where different customers were in the same space. With the diligent use of page restrictions they had access to different content - everyone could see the same landing page but through the use of available macros while they 'knew' other customers were in there, they couldn't access other customer's content.
That being said, having them in different spaces via space permissions would be cleaner and easier especially when the content you wish to provide is more than a page or two's worth.
We have also made the customer spaces more 'elegant' through the use of a theming plugin (there are a number of options in the Marketplace to choose from) that transforms Confluence spaces into more of a typical website look-and-feel. It strips out the updated by line (if desired), adds menu tabs (if desired), and for some home pages especially, the comments area is suppressed (internal departments like this additional customization/clean up). It has been a worthwhile investment for us to add this plugin as it has assisted greatly in acceptance/adoption by other groups in the business who like the 'website look' over raw Confluence in many cases. Since one can apply a theme per space, our internal customers can choose which option they want.
We do similar things because we have employees and customers that access our confluence instance. Employees are allowed to see everything but customers can only see certain spaces. We also use themes on customer facing spaces to give them a different look and hide certain things we don't want customers to be able to use or see like the people directory, space admin section, and various options under the Tools menu. Customer facing spaces also have additional help links and a support button. As of yet we have not run into any issues where customers were able to see anything they were not given permission to. Our JIRA instance is a different story since it is completely internal only so we don't have to worry about customers seeing info there.
I would just echo that space permissions is the way to go, and segregate out your customers to different LDAP groups from your internal staff (note, everyone has to be a member of confluence-users). Then you have good control on rights within a space based on group membership, on a page, and at the space level.
Don't try to complicate your life with multiple Confluence instances.
You're mostly correct in your assumptions, but, I'd say
Tomcat is not a database, it's an application server. For this stuff, you need a supported database service - PostGreSQL is top of the recommendation list, followed by MySQL, then Oracle or MS-SQL
Although you can run several JIRA instances on one machine, they can be quite resource intensive. You'll need to think about resources on the server.
It's actually the same for Confluence - you can run several on one box if you have enough resources to do it. You are right about the licences though - each instance requires its own licence
You can run one JIRA/Confluence and segregate customers by using the application's security systems. The one weakness you will find is that users can see each other (So if Dave has project/Space called "Dave's place", then George, who works for another customer, will not be able to see "Dave's place". But in some cases, he'll be able to work out that Dave is a user in the system). The attachments live within this security scheme, so they're not an issue.
Clustering is not possible unless you go to DataCenter. But that doesn't actually help you because that's one single system for everyone to use, not a set of small individual systems.
Many thanks to all your replies and thoughts on this matter.
I'd love to have everything on one server and use permissions to separate customers (this is an internal tool only - no customer access, plus we are a small company <50 users atm).
However, the customers hard-core audit requires robust data separation. Separate VMs and installs is the only sure way to do this I think.
Hi team, I’m Avinoam, a product manager on Confluence Cloud, and today I’m really excited to let the Community know that all customers can now try out the new editing experience and see some of the ...
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
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs