Administering Jira Data Center on AWS

Getting started with Jira Data Center on AWS

On this page

Still need help?

The Atlassian Community is here for you.

Ask the community

While working with your Jira Data Center on AWS, you can expand your environment by adding additional nodes, upgrade the existing Jira instances, or connect to them over SSH.


Setting custom DNS name

When deploying Jira Data Center on AWS, you get a default domain name that points to the Amazon's load balancer. You'll be using it to access Jira. This domain name depends on the load balancer's name and the AWS region, but in general it looks like this: my-loadbalancer-1234567890.us-west-2.elb.amazonaws.com. You can change it to something more familiar, e.g. jira.atlassian.com, by entering your own domain name in the Existing DNS (optional) parameter in the Quick Start. You'll need a domain name to do this, if you don't have one already, you can register it here.

To set the custom DNS name:

  1. When deploying Jira with the Quick Start, enter your domain name (FQDN) in the Existing DNS (optional) parameter. It'll be saved in the proxyName parameter in Apache Tomcat, which is a web server used by Jira. All nodes will be using this domain name.
  2. After the deployment, when you know the address of the Amazon's load balancer, associate it with your domain name. To do this, you'll need to use your DNS service to create a CNAME record where you enter the source and target URLs, creating an alias. See Associating your custom domain name with your load balancer name.

If you have already deployed Jira, you can still change the parameters that are used by your stack, be it the instance type or the domain name. See Changing resource properties.

Scaling up and down

To change the number of nodes in the cluster:

  1. Sign in to the AWS Management Console, use the region selector in the navigation bar to choose the AWS Region for your deployment, and open the AWS CloudFormation console at https://console.aws.amazon.com/cloudformation/.
  2. Click the Stack name of your deployment. This will display your deployment's Stack info. From there, click Update.
  3. On the Select Template page, leave Use current template selected, and then choose Next.
  4. On the Specify Details page, go to the Cluster nodes section of Parameters. From there, set your desired number of application nodes in the following parameters:
    1. Minimum number of cluster nodes
    2. Maximum number of cluster nodes
  5.  Click through to update the stack.

Disabled Auto Scaling

Since your cluster has the same minimum and maximum number of nodes, Auto Scaling is effectively disabled.

Setting different values for the minimum and maximum number of cluster nodes enables Auto Scaling. This dynamically scale the size of your cluster based on system load.

However, we recommend that you keep Auto Scaling disabled. At present, Auto Scaling can't effectively address sudden spikes in your deployment's system load. This means that you'll have to manually re-scale your cluster depending on the load.

Connecting to your nodes over SSH

You can perform node-level configuration or maintenance tasks on your deployment via SSH. To do this, you'll need your SSH private key file (the PEM file you specified for the Key Name parameter). Remember, this key can access all nodes in your deployment, so keep this key in a safe place.

To help restrict access to the deployment, our Quick Start deploys a Bastion host. To connect to your deployment over SSH, you'll need to access the Bastion host first. This host acts as your "jump box" to any instance in your deployment's internal subnets. That is, you SSH first to the Bastion host, and from there to any instance in your deployment. 

The Bastion host's public IP is the BastionPubIp output of your deployment's ATL-BastionStack stack. This stack is nested in your deployment's Atlassian Standard Infrastructure (ASI). To access the Bastion host, use ec2-user as the user name, for example:

ssh -i keyfile.pem ec2-user@<BastionPubIp>

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

tip/resting Created with Sketch.

Alternatively, you can also access instances in your deployment directly through the Session Manager of the AWS Systems Manager. This will allow you to skip the Bastion host entirely.

Backing up

We recommend you use the AWS native backup facility, which utilizes snapshots to back up your Jira Data Center.

Migrating your existing instance into AWS

To migrate an existing instance into AWS:

  1. Migrate its 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.

Last modified on Jul 28, 2019

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.