Administering JIRA Software Data Center on Azure

Getting started with JIRA Data Center on Azure

On this page

Still need help?

The Atlassian Community is here for you.

Ask the community

Once you've deployed JIRA Software Data Center to Azure using the reference deployment template, administering the application is similar to managing an application on your own hardware, with the exception that you'll need to go via the jumpbox to access your nodes and shared home directory. To access your jumpbox and nodes you'll need:

Connecting to your Azure jumpbox and nodes over SSH

Your cluster nodes have been deployed into a private subnet, which means you can’t access them directly. To work around that, we’ve also deployed a small Azure VM (jumpbox, or bastion host) into a public subnet, so you can use it to access your nodes over SSH.

Before you begin

  • Get the SSH credentials you provided during the deployment.
  • Get the private key file that you created for SSH during the deployment.
  • Get the IP address of your jumpbox. In Azure Portal, open your resource group, and then go to Deployments > atlassian.JIRA-data-center-<id> > Outputs.
  • Get the private IP address of the instance you want to access. In your resource group, open the JIRAcluster resource, and go to Instances.

  1. Access the jumpbox through a command line: 

    ssh -i privatekeyfile ssh_username@dns_name_or_ip_address

    For example: 

    ssh -i privatekey JIRAadmin@JIRA-jumpbox-ip-73kaq.eastus.cloudapp.azure.com
  2. Once you've accessed the jumpbox, you can connect to any of your nodes in the cluster: 

    ssh ssh_username@node_ip_address

    For example: 

    ssh JIRAadmin@10.0.2.4

Accessing your dbconfig.xml or server.xml files

Once you've accessed your nodes over SSH, navigate to the following directories to find you server.xml and dbconfig.xml files.

  • server.xml: /media/atl/JIRA/shared/server.xml
  • dbconfig.xml: /media/atl/JIRA/shared/dbconfig.xml

In Azure, these files are copied from the shared home to the local home when a new node joins the cluster. 

When making changes to these files on existing nodes, it's important to also update the files in the shared home, otherwise a new node joining the cluster will be set up with outdated configuration.

So, when making changes in server.xml or dbconfig.xml on existing nodes, it's important to also update the files in the shared home, otherwise a new node joining the cluster will be setup with outdated configuration.

These files are only accessible from the existing nodes. The shared home is mounted (think of it as a network hard disk) on each node under /media/atl/JIRA/shared. 

Backing up and recovering from failures

We recommend you use the Azure native backup facilities where possible to make sure your data is backed up, and you can easily recover in the case of a failure. 

Database

We use Azure managed database instances with high availability. Azure provides several excellent options for backing up your database, so you should take some time to work out which will be the best, and most cost effective option for your needs. See the following Azure documentation for your chosen database:

Shared home

The shared home is where your attachments and export files are stored. We create a general purpose Azure storage account, configured with local redundant storage, which means there are multiple copies of the data at any one time. 

Because of the redundancy strategy, it shouldn't be necessary to take regular backups, however you can take point in time backups using snapshots if necessary. 

Application nodes

The application nodes are VMs in an Azure Virtual Machine Scale Set. Each application node has a JIRA installation directory and a local home directory containing things like logs and search indexes. 

Like the shared home, application nodes are configured with local redundant storage, which means there are multiple copies of the data at any one time. 

If you've manually customised any configuration files in the installation directory (for example velocity templates), you may also want to manually back these up as a reference. 

Bastion host

As this VM acts as a jumpbox, and doesn't store any data it doesn't need to be backed up. If the VM becomes unresponsive it can be restarted from the Azure Portal. 

Application gateway

The application gateway is highly available. We deploy 2 instances by default. As with the bastion host, it doesn't need to be backed up. 

Migrating to an Azure deployment

You can migrate your existing JIRA Data Center instance into Azure. To do this, you will need to set up a new JIRA Data Center instance in Azure, and then import data from your existing instance. This approach ensures that your new site is created with optimum settings for Azure.

For an overview of steps, see Getting started with JIRA Data Center on Microsoft Azure.

Upgrading the node's operating system

The easiest way to upgrade the node's operating system is to reimage the node. It will be terminated, and will come back running the latest OS.

  1. In Azure Portal, access the JIRAcluster Virtual Machine Scale Set (VMSS).
  2. Click Instances.
  3. Select a node, and click Reimage.

Upgrading JIRA

You can upgrade your whole JIRA Data Center cluster to the latest JIRA version. The steps described below are similar to Upgrading JIRA Data Center with zero downtime, so you should use this as a reference for any details.

Overview

The upgrade process will include putting your JIRA Data Center into upgrade mode so your nodes can work on different JIRA versions. Then, you will terminate your nodes and start the new ones using the latest available JIRA version. Your cluster will remain active during the upgrade, which means that your users can still use JIRA while you upgrade. 

  1. Put JIRA into upgrade mode to allow your nodes to work on different JIRA versions. Go to  > Applications > JIRA upgrades, and click Put JIRA into upgrade mode.

  2. Scale your cluster down to 1 instance.

    1. In Azure Portal, access the JIRAcluster Virtual Machine Scale Set (VMSS).

    2. Go to Scaling, and scale down to 1 instance. This will delete all of your remaining nodes.

  3. Get your Azure deployment to use the latest JIRA version.

    1. In Azure Portal, access the shared home directory. You can find it in your resource group, called something like JIRAstorage<id>.

    2. Click Files, and then open JIRA-shared-home.

    3. Delete the JIRA-software.version file. This file controls the JIRA version your cluster is using.

  4. Scale your cluster up by 1 instance.

    1. In Azure Portal, access the JIRAcluster Virtual Machine Scale Set (VMSS).

    2. Go to Scaling, and scale up to 2 instances. This will spin up a new node, but this time it will download the latest available JIRA version. 

    3. (info) At this point, your cluster should be running in the mixed node, which means that your nodes are running different JIRA versions. You can check that in JIRA by going to  > Applications > JIRA upgrades.
  5. Reimage the original node, so it can also download the latest JIRA version.

    1. In Azure Portal, access the JIRAcluster Virtual Machine Scale Set (VMSS).

    2. Go to Instances.

    3. Select the node, and click Reimage.

    4. Make sure the node started successfully and joined the App Gateway's healthy backend pool.
  6. Finalize the upgrade.

    1. In JIRA, go to  > Applications > JIRA upgrades. You should now be able to run upgrade tasks.

    2. Click Run upgrade tasks. Your cluster should now be back to the normal mode.

  7. If you’re using more nodes than just 2, increase their number in the Virtual Machine Scale Set (VMSS).

Last modified on Apr 29, 2019

Was this helpful?

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