Over the years the engineering team here at Isos Technology have helped 100s of clients implement and manage Jira Server (and Data Center). An essential part of how we set up Jira is the use of a reverse proxy to handle incoming http/https connections for almost all configuration options. Many customers have questioned why we do this since, as we all know, Jira has a built-in web server. Adding nginx in some cases seems like you are adding complexity to the Jira configuration. If Jira's built in Tomcat can handle connections directly, why add nginx to the mix?
Well wonder no more! Here's a list of why we choose to go the nginx route when setting up Jira (and heck, these all apply to Confluence too):
Yes, Jira's Tomcat DOES support SSL. However, if you read the instructions in the link provided, you'll see a few things that make this configuration less than optimal:
- The configuration is pretty complex. Adding SSL certificates to nginx is super easy.
- It requires Jira downtime to add or update SSL to Tomcat. You can add or change SSL certs with nginx with no perceivable downtime to Jira.
- In our tests, it appears that nginx is more performant in dealing with SSL connnections over Tomcat.
- Letsencrypt support: nginx works with Letsencrypt almost out of the box for free SSL certificates... while Tomcat, not so much.
If you are running SSL, please use nginx.
In many synthetic load tests and real world traffic scenarios, the Isos engineering team has observed that using nginx in front of Jira can increase the load a Jira server can handle while reducing overall load. This is due to the fact nginx can be configured to cache static content. Every time Tomcat serves up any content, static or dynamic, Tomcat must process that request. If nginx senses static data it has served before, it will intercept that call thus saving effort. In some cases, we have seen a 20% lower load / 15% increase in request volume on a single Jira Server node. Our friends at Service Rocket have written a handy blog post on how to configure nginx for caching with Jira.
Mitigation of security vulnerabilities
If you are an Atlassian customer, you will have noticed that there's been an uptick in security vulnerabilities with Jira, Confluence and Bamboo. In the case of each one of these security issues, we've often found that one can implement security fixes at the nginx layer instead of being forces to immediately upgrade apps. This has allowed our customers to schedule or put off applying security updates until it is convenient for their organization.
In many situations we need http style logging for Jira traffic. You can turn that on within Jira but we've seen that logging puts more burden on Tomcat. Also, the logging format options of nginx are much easier to activate than with Tomcat.
A lot of Isos clients run Jira Data Center. In that configuration there are many cases where one might want to take Jira out of a live cluster without having to fiddle with the load balancer that feeds traffic to said cluster. If you run nginx in front of Jira, all you need to do is shutdown Jira and all traffic will immediately drain to other nodes while Jira remains up for further diagnosis. Once you are done with the maintenance, you can turn on Jira which will almost immediately start serving traffic. Because Jira was never shut down, its index cache should be current and ready to go.