Atlassian Applications & Apache httpd server versions?

[Andrew Morin]

I have been migrating all of our Atlassian Apps (JIRA, Confluence, F/C, Stash, Bamboo) to an Apache httpd front end . When you visit the supported platform page for any of the applications it only references Apache Tomcat versions. I have done a ton of research on these configurations over the last couple of months and will post it somewhere when I get it compiled. I will leave the critism of this particular documentation to the comments that are already posted on some of these pages. To say the least it is very confusing for some of us administrators who are not experts in this area.

I use a signed CA that is a wildcard cert so I can in theory have two virtual hosts running off a single Apache instance. (Apache server has a dedicated server and application servers are running on their own specific servers.) Using mod_proxy configuration & SSL)

This works on Apache 2.4 but JIRA throws a ton of errors and other issues present themselves.

On 2.2.x it uses the first virtual host and ignores the second after startup is complete.

I really don't have an issue as we have already come up with a solution that works but it would be nice to have at least a recommended version for the httpd server to use.

[HenriqueA · Accepted solution]

Hi Andrew,

I not sure if I fully understand what you meant, but here is what I'm guessing:

You want to create one Virtual Host for every Application that you have installed (JIRA, Confluence, F/C, Stash, Bamboo) in the same apache instance but you had some issues.

Is that correct?

To configure your applications, you will need to define one virtualhost for every application and use the directive "location" inside. I think you might have already done it, but just in case here is the link:

http://httpd.apache.org/docs/current/mod/core.html#location

The errors that you mentioned may have some important information to help you.

If there is no private information on your error message could you provide it? this way we could take a better look at whats going on.

Just a heads up, multiple atlassian application in a single tomcat container is not supported. the reason for that, is that you might encounter known bugs and problems. for more information on the subject here is a link for official documentation:

https://confluence.atlassian.com/display/JIRA/Deploying+Multiple+Atlassian+Applications+in+a+Single+Tomcat+Container

Please let me know if you have any doubts!

Best Regards,

Henrique Lechner

[twong_atlassian]

Hi Andrew,

For the most part, you could use any version of httpd as a reverse proxy to the application running in Tomcat. Tomcat is an application server, httpd is a webserver. The only application server the Confluence application supports is Tomcat.

I wouldn't recommend running multiple containers in the same container either as Henrique mentioned, but for a different reason. If you run all the applications in the same container, then any problem that might arise from any 1 application can have deleterious effects on the rest of the stack. Although you might save on the overhead of multiple application servers if you ran on a single container, you also hitch the stability of every app to every other application.

[Andrew Morin]

Thanks Tim and Henrique. I have got it all working. The documentation is a little this on this setup but I understand there are a lot of different ways and variables to doing this so it would be difficult to have a one size fits all document.

On another note I increased the worker threads for the Confluence apache instance (I did seperate some of the applications for other reasons to have their own web server.) and once or twice a week it seems apache just kind of goes brain dead. Nothing relevant in the logs that I could find you just get a spinning wheel and the Confluence site won't come up. A quick restart of the apache service corrects the issue but any idea on what may cause this. Apache 2.4.4 on Windows 2008 R2. Confluence version 5.2.5.

[twong_atlassian]

Really depends on the state of the httpd pool. Maybe use mod_status to track that down?