Running JIRA Data Center in AWS

JIRA Data Center instances are an excellent fit for the Amazon Web Services (AWS) environment. Not only does AWS allow you to scale your deployment elastically by resizing and quickly launching additional nodes, it also provides a number of managed services that work "out of the box" with JIRA Data Center instances and handle all their configuration and maintenance automatically.

 

On this page:

AWS components

A typical JIRA Data Center deployment in AWS can be illustrated as follows:

This deployment consists of the following components:

  • One or more Amazon Elastic Compute Cloud (EC2) instance(s) as cluster node(s), running JIRA Software or JIRA Service Desk.
    • Typically these instance(s) are managed by an Amazon Auto Scaling Group, which can scale up and down the number of cluster node(s) either manually or automatically in response to load between prescribed minimum and maximum limits.
  • An Amazon Elastic Load Balancer (ELB), both as load balancer and SSL-terminating reverse proxy.
  • An EC2 instance as a dedicated EFS server.
  • An Amazon Relational Database (RDS) instance as the shared database.
JIRA version JIRA Software Server 7.2.3 and/or JIRA Service Desk 3.2.3.
Cluster nodes One or more EC2 instances running JIRA.
Load balancer & reverse proxy

Amazon Elastic Load Balancer (ELB), with Listeners configured as follows:

Load Balancer Protocol Load Balancer Port Instance Protocol Instance Port
HTTP 80 HTTP 8080
TCP 7999 TCP 7999
EFS server

An EC2 instance configured as a dedicated EFS server for the cluster, with an EBS volume storing the JIRA shared home directory. This contains all of JIRA's attachments and other data. You need to ensure you set up your JIRA AWS deployment in a region that offers EFS support).

Database Amazon RDS for PostgreSQL.

CloudFormation template and Quick Start guide

An AWS CloudFormation template is a single JSON or YAML file which describes a collection of AWS resources, allowing you to create, update, and delete them all together as a single "stack". Using AWS CloudFormation to manage your resources is much quicker and more convenient that deploying and managing the separate resources individually.

Amazon also publishes Quick Starts as standard, automated reference deployments for a number of key applications in AWS. Each Quick Start launches, configures, and runs the AWS compute, network, storage, and other services required to deploy a specific workload on AWS, using AWS best practices for security and availability.

The easiest way to launch JIRA Data Center in the AWS environment is to follow this Quick Start guide and use the associated CloudFormation template. AWS CloudFormation and Quick Starts do not incur any additional AWS charges, though of course you must pay for all AWS resources launched via CloudFormation normally with your usual AWS account billing process.

Scaling up and down

To increase or decrease the number of cluster nodes:

  1. Go to Services > CloudFormation in the AWS console, select the stack, and click Update Stack.
  2. Change the Minimum number of cluster nodes and Maximum number of cluster nodes parameters as desired.

It may take several minutes for the Auto Scaling Group to detect and apply changes to these parameters.

Unless you specify the same number for Minimum and Maximum number of cluster nodes, the Auto Scaling Group is allowed to launch new cluster nodes and terminate existing ones automatically to achieve the optimal desired number of nodes between these two limits. By default, this target number is determined by the following CloudWatch metrics:

  • If the average CPU utilization across the Auto Scaling Group exceeds 60% for 5 minutes, the target number of nodes increases by one (up to the Maximum).
  • If the average CPU utilization across the Auto Scaling Group is lower than 40% for 30 minutes, the target number of nodes decreases by one (down to the Minimum).

A default "cooldown" period of 10 minutes between scaling events is also applied. See Scaling Based on Metrics for more information. 

Note: Adding new cluster nodes, especially automatically in response to load spikes, is a great way to increase capacity of a cluster temporarily. Beyond a certain point, adding very large numbers of cluster nodes will bring diminishing returns. In general, increasing the size of each node (i.e., "vertical" scaling) will be able to handle a greater sustained capacity than increasing the number of nodes (i.e., "horizontal" scaling), especially if the nodes themselves are small. See Recommendations for running JIRA Software Data Center in AWS for more information.

Connecting to your nodes over SSH

Sooner or later you will need to SSH to your JIRA cluster node(s) and file server to perform configuration or maintenance tasks. Note that you must keep your SSH private key file (the PEM file you downloaded from Amazon and specified as the Key Name parameter) in a safe place. This is the key to all the nodes in your instance, and if you lose it you may find yourself "locked out". See Running JIRA Data Center in AWS for more information.

Note: JiraDataCenter.template deploys all EC2 instances in the Subnets specified by the Internal subnets parameter. If you have specified Internal subnets that are completely unreachable from outside, then you may need to launch an EC2 instance with SSH running and accessible in one of the the External subnets, and use this as a "jump box" to SSH to any instances in your Internal subnets. That is, you SSH first to your "jump box", and from there to any instance deployed in the Internal subnets.

When connecting to your instance over SSH, use ec2-user as the user name, for example:

ssh -i keyfile.pem ec2-user@ec2-xx-xxx-xxx-xxx.compute-1.amazonaws.com

The ec2-user has sudo access. SSH access is by root is not allowed.

Upgrading

To upgrade a JIRA Data Center instance launched from JIRADataCenter.template:

  1. Go to Services > CloudFormation in the AWS console, select the stack, and click Update Stack.
  2. Change the Version parameter to the new version (this doesn't actually upgrade any existing cluster node(s), but ensures that any new nodes launched will be on the new version). 
  3. Terminate your existing cluster node(s), and manually launch new node(s) running the new version.

JIRA Data Center in AWS currently doesn't allow upgrading an instance without some downtime in between the last cluster node of the old version shutting down and the first cluster node on the new version starting up.

Backing up

We recommend you use the AWS native backup facility, which utilizes snap-shots to back up your JIRA Data Center.

Migrating your existing instance into AWS

To migrate an existing instance into AWS:

  1. Migrate it's database to PostgreSQL (if not already).
  2. Take a backup of your existing home directory and database.
  3. Copy the backup file to your file server EC2 instance.
  4. Unpack the backup file under /media/atl/jira/shared of your file server.
  5. Restore the PostgreSQL database dump contained in the backup file to your RDS instance with pg_restore.

Was this helpful?

Thanks for your feedback!

Why was this unhelpful?

Have a question about this article?

See questions about this article

Powered by Confluence and Scroll Viewport