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. 

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:

• SQL Database: Automated backups
• SQL Database: Backup retention 
• PostgreSQL: Backup concepts

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

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 Data Center on Azure

You can upgrade your whole Jira Data Center cluster to the latest 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.

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 select 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 chosen 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. Select Files and open JIRA-shared-home.

   3. Edit the JIRA-software.version file which controls the Jira version your cluster is using. To upgrade to a specific version, add the version to which you want to upgrade (for example 8.20.11) to the file and save it.

   4. Follow this link and download your chosen version of Jira (in this case 8.20.11) in the .bin format (Linux 64-bit installer). Upload it to the same folder where the JIRA-software.version file is located.

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 chosen 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 chosen Jira version.

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

   2. Go to Instances.

   3. Choose the node, and select 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. Select 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).