Azure で Jira Software Data Center を管理する

Azure で Jira Data Center の使用を開始する

このページの内容

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

参照デプロイメント テンプレートを使用して Jira Software Data Center を Azure にデプロイしたら、独自のハードウェア上でアプリケーションを管理する場合と似た方法でアプリケーションを管理できます (ジャンプボックス経由でノードと共有ホーム ディレクトリにアクセスする必要がある場合を除く)。ジャンプボックスとノードにアクセスするには、以下が必要です。

SSH を介して Azure ジャンプボックスおよびノードへ接続する

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.

はじめる前に

  • 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

    例: 

    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

    例: 

    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

Azure では、新しいノードがクラスターに参加する際に、これらのファイルが共有ホームからローカル ホームにコピーされます。 

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.

そのため、既存のノードで server.xml または dbconfig.xml を変更する場合、共有ホーム内のファイルも更新することが重要です。これを行わない場合、クラスターに参加する新しいノードが古い構成で設定されてしまいます。

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. 

データベース

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:

共有ホーム

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. 

アプリケーションノード

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.

JIRA のアップグレード

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

Zero downtime upgrade is not available when upgrading from Jira 7.x to Jira 8.x. You'll need to use one of the regular methods. If you're already on Jira 8.x, you can use zero downtime to upgrade to any later version.


概要

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 Enterprise Release 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 Enterprise Release 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 Enterprise Release 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 Enterprise Release 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).

最終更新日 2019 年 5 月 31 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.