Administering Jira Data Center on AWS
Amazon S3 is now available for Jira Data Center. Currently, you can use Amazon S3 to store user avatars, issue type icons, and project icons. In Jira Service Management, this also includes request type icons. Learn more about configuring Amazon S3
We’re also working on introducing S3 object storage for Jira attachments.
The AWS Quick Start template as a method of deployment is no longer supported by Atlassian. You can still use the template, but we won't maintain or update it.
We recommend deploying your Data Center products on a Kubernetes cluster using our Helm charts for a more efficient and robust infrastructure and operational setup. Learn more about deploying on Kubernetes.
AWS now recommends switching launch configurations, which our AWS Quick Start template uses, to launch templates. We won’t do this switch, however, as we’ve ended our support for the AWS Quick Start template. This means you're no longer able to create launch configurations using this template.
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:
- When deploying Jira with the Quick Start, enter your domain name (FQDN) in the Existing DNS (optional) parameter. It'll be saved in the
proxyNameparameter in Apache Tomcat, which is a web server used by Jira. All nodes will be using this domain name. - 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
The synchronous node start-up is now enforced by the application. See Changes to index management on the Jira startup in version 9.1 for details.
To learn more about the upcoming changes to index management in Jira, check out the Data Center Roadmap.
To change the number of nodes in the cluster:
- 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/.
- Click the Stack name of your deployment. This will display your deployment's Stack info. From there, click Update.
- On the Select Template page, leave Use current template selected, and then choose Next.
- 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:
- Minimum number of cluster nodes
- Maximum number of cluster nodes
- 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 through the AWS Systems Manager Sessions Manager. This browser-based terminal lets you access your nodes without any SSH Keys or a Bastion host. For more information, see Getting started with Session Manager.
Access via Bastion host
You can also access your nodes via a Bastion host (if you deployed one). 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.
The Bastion host acts as your "jump box" to any instance in your deployment's internal subnets. That is, access the Bastion host first, and from there access 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.
Backing up
We recommend you use the AWS native backup facility, which utilizes snapshots to back up your Jira Data Center. For more information, see AWS Backup.
Migrating your existing instance into AWS
- Migrate its database to PostgreSQL (if not already).
- Take a backup of your existing home directory and database.
- Copy the backup file to your file server EC2 instance.
- Unpack the backup file under
/media/atl/jira/sharedof your file server. - Restore the PostgreSQL database dump contained in the backup file to your RDS instance with
pg_restore.