Installation for everything (Moving from JIRA Studio to local install)

[Michael Rainwater]

We are currently using JIRA Studio, and we are now planning to move from the hosted solution to a local environment. I am purchasing almost all the tools (except for Confluence). I would like to setup an environment that will scale with our company as we adopt JIRA in more areas. For example, I am planning to use Crowd immediately to get the advantage of LDAP login for users.

Do you have a best-practice network topology or suggested deployment strategy for the entire Atlassian suite (perhaps including Confluence for later deployment)? I would like to start with something that can grow easily.

For example, do you normally recommend that Crowd vs JIRA vs Confluence be placed on physically different servers? How would you reccommend we deploy your solution?

I have found installation information for each separate application. But I would like to find something that speaks to the order and method of installing all of the Atlassian tools.

Thank you.

[Martin Cooper · Accepted solution]

There is very little in terms of documentation for this mainly because a lot of it really comes down to you, your infrastructure and planned usage.

The dragon slayer quest does give some guidance on integration, but is a single server installation (last time I checked anyway)

Whether you should split the applications out onto separate servers or not, really comes down to the size and usage of the applications and the specification of your hardware. A well specced server can run all the apps under a light to medium load.

For future proofing it may be wiser to install on separate servers, but if have a slow network between them then the gains in cpu and memory may be lost in network communication.

If you plan to use an enterprise Database, and all ready have the servers and infrastructure in place for this, it makes sense to re-use this rather than setup additional DB servers, or host databases on the same server as the applications. If again a slow network is an issue then a local database may be the way to go, even though potentially more admin overhead.

As to the user management question...all the applications can hook into ldap, or even hook into ldap via Jira (at the latest versions) so the question for whether crowd is appropriate is whether you need its Single Sign On features and user and group management that you can control, without having to refer to a corporate ldap/active directory team.

In terms of order, there isn't really any dependency between the tools in that way, but obviously cannot hook into crowd for authentication until it is up and running. Normally its best to ensure the tools are working independantly before integrating them, as makes troubleshooting any issues easier.

But I tend to install Crowd, Jira, Confluence, crucible/fisheye, bamboo in that order for no real reason apart from the fact that Jira and Confluence have been the main focus of the customer.

Hope that helps

[JamieA]

If you don't know what the load's going to be start with a single server, and create DNS c-name records for "jira", "confluence" etc, that all point the single host. If you decide to split them out later that's an easy task, you just update the dns to point to the new server, and no links are broken.

Or if you want all the tools having different context roots you can use apache as a reverse proxy, and again split them out later if you need to.

I really don't understand the point of Crowd. LDAP seems the ideal choice for managing users and groups. You can set up OpenLDAP and use Cyrus SASL pass-through authentication to authenticate against your corporate LDAP. This way you have full control of groups/users and don't have to bother the LDAP team every time you want to add users to a group.

SSO can be written as an apache module or a jira/confluence/etc authenticator... I have written ones for kerberos and PKI certificates before.

[Colin Goudie]

I think the point of Crowd is for the small cost of the license it does what you described in the last 2 paragraphs with very little effort, especially if your deploying only the Atlassian stack.

[JamieA]

Yeah, fair enough. It had more value pre-jira 4.3 anyway.

[Colin Goudie]

A good blog post was put up a while ago by an old employee of Sun. It is only covering Confluence but does provide some insight into deploying these systems locally in the real world.

http://blog.igorminar.com/2010/07/devops-guide-to-confluence-dgc.html

[brainicorn]

This isn't actually "best practice" documentation, but you might get some useful information out of the dragon slayer:

http://confluence.atlassian.com/display/ATLAS/Here+Be+Dragons