Azure で Jira Software Data Center を管理する
デプロイ方法としての Azure Resource Manager テンプレートに対するアトラシアンのサポートや保守はすでに終了しました。ただし、ご自身の用途に合わせてカスタマイズを行い、Azure に Data Center 製品をデプロイすることは引き続き可能です。
より効率的で堅牢なインフラストラクチャと運用のセットアップのために、Helm チャートを使用して Data Center 製品を Kubernetes クラスタにデプロイすることをお勧めします。Kubernetes へのデプロイの詳細をご確認ください。
参照デプロイメント テンプレートを使用して Jira Software Data Center を Azure にデプロイしたら、独自のハードウェア上でアプリケーションを管理する場合と似た方法でアプリケーションを管理できます (ジャンプボックス経由でノードと共有ホーム ディレクトリにアクセスする必要がある場合を除く)。
SSH を介して Azure ジャンプボックスおよびノードへ接続する
クラスタ ノードはプライベート サブネットにデプロイされています。つまり、直接アクセスすることはできません。これを回避するため、小規模な Azure VM (ジャンプボックスまたは bastion ホスト) をパブリック サブネットにもデプロイし、それを使用して SSH 経由でノードにアクセスできるようにしました。
はじめる前に
- デプロイ中に提供された SSH 資格情報を取得します。
- デプロイ中に SSH 用に作成された秘密鍵ファイルを取得します。
- ジャンプボックスの IP アドレスを取得します。Azure ポータルでリソース グループを開き、[Deployments] > [atlassian.JIRA-data-center-<id>] > [Outputs] に移動します。
- アクセスしたいインスタンスのプライベート IP アドレスを取得します。リソース グループで、JIRAcluster リソースを開き、[Instances] に移動します。
コマンド ラインからジャンプボックスにアクセスします。
ssh -i privatekeyfile ssh_username@dns_name_or_ip_address例:
ssh -i privatekey JIRAadmin@JIRA-jumpbox-ip-73kaq.eastus.cloudapp.azure.comジャンプボックスにアクセスしたら、クラスタ内の任意のノードに接続できます。
ssh ssh_username@node_ip_address例:
ssh JIRAadmin@10.0.2.4
dbconfig.xml または server.xml ファイルにアクセス
SSH でノードにアクセスしたら、以下のディレクトリに移動し、server.xml および dbconfig.xml ファイルを見つけます。
- server.xml: /media/atl/JIRA/shared/server.xml
- dbconfig.xml: /media/atl/JIRA/shared/dbconfig.xml
Azure では、新しいノードがクラスターに参加する際に、これらのファイルが共有ホームからローカル ホームにコピーされます。
既存のノードでこれらのファイルを変更する場合、共有ホーム内のファイルも更新することが重要です。これを行わない場合、クラスタに参加する新しいノードが古い構成でセットアップされてしまいます。
そのため、既存のノードで server.xml または dbconfig.xml を変更する場合、共有ホーム内のファイルも更新することが重要です。これを行わない場合、クラスターに参加する新しいノードが古い構成で設定されてしまいます。
これらのファイルには既存のノードからのみアクセスできます。共有ホーム は、ネットワーク ハード ディスクのように、/media/atl/jira/shared 配下の各ノードにマウントされています。
バックアップと障害からのリカバリ
可能な場合は Azure のネイティブ バックアップ機能を使用することをおすすめします。これによって、データをバックアップし、障害時に簡単に復元できるようにします。
データベース
当社では高可用性構成の Azure マネージド データベース インスタンスを使用しています。Azure ではデータベースのバックアップに関する複数の素晴らしいオプションが提供されているため、ニーズに最適かつ費用対効果の高いオプションの選択に時間を割くことをおすすめします。選択したデータベースに対応する、以下の Azure ドキュメントを参照してください。
共有ホーム
共有ホームには添付ファイルとエクスポート ファイルが保存されます。アトラシアンでは一般的な Azure ストレージ アカウントを作成します。これはローカル冗長ストレージで構成されており、一度に複数のデータのコピーが存在することを意味しています。
冗長性戦略のため、定期的なバックアップは必須ではありませんが、必要に応じてスナップショットを使用してポイント イン タイム バックアップを取得できます。
Application nodes
アプリケーション ノードは、Azure 仮想マシンスケール セット内の VM です。各アプリケーション ノードには、Jira インストール ディレクトリと、ログや検索インデックスなどが含まれるローカル ホーム ディレクトリがあります。
共有ホームと同様に、アプリケーション ノードはローカル冗長ストレージで構成されているため、一度に複数のデータのコピーが存在します。
インストール ディレクトリで設定ファイルを手動でカスタマイズしている場合 (ベロシティ テンプレートなど)、これらも参照用に手動でバックアップしておくことをおすすめします。
Bastion ホスト
この VM はジャンプボックスとして機能するため、バックアップが必要なデータは持ちません。VM が応答しなくなった場合、Azure Portal から再起動できます。
アプリケーション ゲートウェイ
アプリケーション ゲートウェイは高可用性構成です。デフォルトでは 2 インスタンスがデプロイされています。bastion ホストと同様、バックアップする必要はありません。
Azure デプロイメントへの移行
既存の Jira Data Center インスタンスを Azure に移行できます。これを行うには、Azure で新しい Jira Data Center インスタンスをセットアップして、既存のインスタンスからデータをインポートする必要があります。この方法により、Azure に最適な設定で新しいサイトを作成できます。
手順の概要については、「Microsoft Azure で Jira Data Center の使用を開始する」を参照してください。
アップグレード
デプロイメントのアップグレードについて、次の点をご確認ください。
- Jira Data Center の最新バージョンにアップグレードする前に、アプリにそのバージョンとの互換性があるかを確認します。必要に応じてアプリを更新します。アプリの管理の詳細については、「Universal Plugin Manager の使用」を参照してください。
- アップグレード中もユーザーに Jira Data Center を提供する必要がある場合、ゼロ ダウンタイムで Jira Data Center をアップグレードすることをご検討ください。この方法ではノードを 1 つずつアップグレードしながら異なる Jira バージョンで動作させるため、アップグレード中もユーザーが Jira を利用できます。
- 本番サイトをアップグレードする前に、ステージング環境でアップグレードを実施することを強くおすすめします。「Jira のテスト環境を作成する」には、これを行うための便利なヒントが記載されています。
ノードのオペレーティング システムのアップグレード
ノードのオペレーティング システムをアップグレードする最も簡単な方法は、ノードを再イメージ化することです。ノードが終了され、最新の OS で再度実行されます。
- Azure Portal で、JIRAcluster 仮想マシン スケール セット (VMSS) にアクセスします。
- [Instances] をクリックします。
- ノードを選択し、[Reimage] をクリックします。
Azure で Jira Data Center をアップグレードする
Jira Data Center クラスタ全体を最新の Jira バージョンにアップグレードできます。下記の手順は「Jira Data Center のゼロ ダウンタイム アップグレード」と類似するため、詳細についてはこのドキュメントを参照することをおすすめします。
アップグレード プロセスでは、Jira Data Center をアップグレード モードにし、ノードが異なる Jira バージョンで動作できるようにします。その後、ノードを終了し、利用可能な最新の Jira バージョンを使用して新しいノードを起動します。アップグレード中もクラスタはアクティブなままのため、ユーザーはアップグレード中も Jira を使用し続けることができます。
Jira をアップグレード モードにして、ノードで異なる Jira バージョンを実行できるようにします。
> [アプリケーション] > [Jira アップグレード] に移動し、[Jira をアップグレード モードにする] を選択します。クラスタを 1 インスタンスにスケール ダウンします。
Azure Portal で、JIRAcluster 仮想マシン スケール セット (VMSS) にアクセスします。
[スケーリング] に移動し、1 インスタンスにスケール ダウンします。これによって、残りのノードはすべて削除されます。
Azure デプロイメントで指定の Jira バージョンを使用するようにします。
Azure Portalで、共有ホーム ディレクトリにアクセスします。これはリソース グループにあり、JIRAstorage<id> のように表示されています。
[ファイル] を選択し、
JIRA-shared-homeを開きます。クラスタで使用する Jira バージョンを制御する
JIRA-software.versionファイルを編集します。特定のバージョンにアップグレードするには、アップグレード先のバージョン (8.20.11 など) をファイルに追加して保存します。このリンクにアクセスして、目的の Jira バージョン (このケースでは 8.20.11) を .bin 形式 (Linux 64-bit インストーラー) でダウンロードします。それを
JIRA-software.versionファイルと同じフォルダにアップロードします。
クラスタを 1 インスタンスずつスケール アップします。
Azure Portal で、JIRAcluster 仮想マシン スケール セット (VMSS) にアクセスします。
[スケーリング] に移動し、2 インスタンスにスケールアップします。これによって新しいノードがスピンアップされますが、今回は指定の Jira バージョンがダウンロードされます。
- (情報) この時点では、クラスタは混在モードで実行されているはずです。つまり、ノードでは異なる Jira バージョンが実行されています。これを確認するには、Jira で > [アプリケーション] > [Jira アップグレード] の順に進んでください。
元のノードを再イメージ化し、指定の Jira バージョンをダウンロードできるようにします。
Azure Portal で、JIRAcluster 仮想マシン スケール セット (VMSS) にアクセスします。
[Instances] に移動します。
ノードを選択し、[Reimage (再イメージ化)] を選択します。
- ノードが正常に起動し、アプリ ゲートウェイの健全なバックエンド プールに参加していることを確認します。
アップグレードを完了します。
Jira で、
> [アプリケーション] > [Jira アップグレード] の順に進みます。これでアップグレード タスクを実行できるようになります。[アップグレードタスクを実行] を選択します。これでクラスタが通常モードに戻ります。
2 つより多くのノードを使用している場合、仮想マシン スケール セット (VMSS) の数を増やします。