Jira Service Desk 4.0.x アップグレード ノート

Jira Service Management の以前のバージョンのリリース ノート

このページの内容

関連コンテンツ

  • 関連コンテンツがありません

お困りですか?

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

コミュニティに質問

ここでは、Jira Service Desk 4.0 へのアップグレードに関する重要な注意事項について説明します。このリリースの新機能と改善点に関する詳細は、「Jira Service Desk 4.0 リリース ノート」を参照してください。 

Jira Service Desk は Jira プラットフォームで動作するため、「Jira プラットフォーム 8.0 アップグレード ノート」もご参照ください。


 変更の概要

次のセクションにジャンプ


インデックスへの変更

Jira 8.0 で導入される変更の 1 つは、Jira のインデックスを担当する Lucene ライブラリのアップグレードです。この変更によってインデックス作成 (検索) が改善されますが、ご利用の現在のインデックスには新しいバージョンとの互換性がありません。ただし、通常のアップグレードの完了後に "Jira の再インデックス" によってインデックス全体の再構築を行うことができるため、一般にこれが問題になることはありません。インデックスの再作成後は、インデックスが以降のバージョンとの互換性を持つようになります。

変更内容

現在のインデックスは <home-directory>/caches/indexes に保持されます (アップグレード後に削除してもかまいません) 。今後、新しいインデックスは以下のディレクトリに格納されます。

<home-directory>/caches/indexesV1

アップグレードへの影響

アップグレード直後 (正確には Jira の起動後)、新しいインデックスによって Jira のインデックスが自動的に再作成されます。そのため、Jira を起動した後と、インデックスの再作成が必要な変更を実施した後で、インデックスを再作成する機会は 2 回あります。たとえば、プラグインのアップグレードなどです。大規模な Jira インスタンスでは、インデックスの再作成に非常に時間がかかる可能性があるため、自動再インデックスを無効化し、後から準備ができたら手動で実行することをおすすめします。

自動再インデックスを無効化する方法

インデックス再作成を無効化するために必要な手順を、アップグレード手順に含めました。簡潔に説明すると、アップグレード後、Jira を起動する前に <home-directory>/jira-config.properties ファイルに以下の行を追加する必要があります。

upgrade.reindex.allowed=false

推奨されるアクション

(tick) インデックスが 2 回作成されるのを防ぐために自動再インデックスを無効化し、準備が整ったら手動で再インデックスを実行します。

(info) Jira インスタンスが小規模で、追加の再インデックスで問題が発生しないようであれば、無効化する必要はありません。これは時間を短縮するための方法であるため、いずれの手順を利用した場合もアップグレードへの影響はありません。


互換性のないアプリ (アドオン) の無効化

Jira 8.0 と互換性のないアプリを無効化したり、利用可能な場合は互換性があるバージョンにアップグレードしたりする必要があります。互換性のないアプリは、Jira インデックス、API、一部の UI など、利用できなくなった要素や新しいバージョンで変更された要素を使用しているため、Jira のアップグレードや起動を妨げる可能性があります。

推奨されるアクション

(tick) 互換性のないすべてのアプリについて、無効化するか、互換性があるバージョンがある場合はそれにアップグレードします。必要な手順の詳細については「アップグレードの準備」を参照してください。

(info) 常にテスト環境でアップグレードすることをお勧めします。ステージング環境を Jira 8.0 にアップグレードして、互換性のないアプリを有効化し、新しいバージョンでの動作を確認できます。Jira インスタンスに大きな影響を与えないようなら、互換性が保証されていない場合も 8.0 で使用できます。


アップグレード後、Jira の起動に通常より時間がかかる場合がある

Jira 8.0 で導入された改善の 1 つは、最も頻繁に使用されるデータベース テーブルの 2 つ (changeitem、changegroup) に新しいインデックスを追加したことです。これにより、課題の読み込みが高速になり、その課題を含むデータを取得するためにデータベースに対して実行されるクエリも高速になります。

これらのテーブルへのインデックスの追加には数分かかる場合があります。これはアップグレード後に Jira を起動すると発生します。詳細情報

Data Center でゼロ ダウンタイム アップグレード (ZDU) がサポートされない

8.0 で Jira プラットフォームに導入された重大な変更のため、Jira Service Desk Data Center 3.x から 4.0 へのアップグレードではゼロ ダウンタイム アップグレードがサポートされません。アップグレードするには、通常のアップグレード方法を使用する必要があります。ゼロ ダウンタイム アップグレードは、4.x 系列内でアップグレードするときに再び利用できます。


いくつかの設定プロパティの変更

Jira 8.0 では、インデックス作成に関する一部のプロパティの既定値を変更し、いくつかのプロパティを非推奨にしました。

非推奨のプロパティ:

  • jira.index.commitpolicy
  • jira.index.batch.maxbuffereddocs
  • jira.index.interactive.maxbuffereddocs
  • jira.index.batch.maxmergedocs
  • jira.index.interactive.maxmergedocs
  • jira.index.batch.mergefactor
  • jira.index.interactive.mergefactor

新しい既定値を持つプロパティ:

  • jira.index.issue.threads (20)
  • jira.index.batch.maxrambuffermb (1024)
  • jira.index.interactive.maxrambuffermb (1024)

サポート対象のすべてのプロパティとそれらの現在の値を jpm.xml でいつでも確認できます。

maxrambuffermb プロパティは、インデックス ファイルに保存されるようにキューに格納される、Lucene ドキュメントのメモリ書き込みバッファの最大サイズを定義します。多数のカスタム フィールドを持つ課題をより適切に扱えるようにするため、この値を増やしました。この変更を受け、以下のように既定の最大ヒープ サイズ (xmx) も増やしました。


メモリ要件

maxrambuffermb の増加を受け、既定の最大ヒープ サイズ (xmx) も増やしました。

プロパティJira 7.xJira 8.0
Xmx7682048
jira.index.batch.maxrambuffermb1001024
jira.index.interactive.maxrambuffermb161024


Jira 8.0 で必要なメモリは減りましたが、xmx の値は引き続き maxrambuffermb よりも大きくする必要があります。すでに xmx を 2 GB に設定している場合、この値を増やす必要はありません。

32 bit システムで Jira を実行している場合、2 GB のヒープ サイズは大きすぎるため、以降のように減らす必要があります。


32-bit システム上の Jira のヒープ サイズを縮小

これは、アーカイブを使用して Jira を手動でインストール / アップグレードする場合にのみ適用されます。インストーラーを使用する場合、この手順は不要です。

32 bit のシステムで Jira をインストール / アップグレードする場合、Jira で使用可能な最大ヒープ サイズを減らす必要があります。64 bit システムでの Jira 8.0 用の既定値は 2 GB ですが、これは 32 bit システムに対しては大きすぎる値であり、利用可能なメモリ量を圧迫する可能性があります。アトラシアンでは、すべての適切な設定を含む新しい setenv32.bat/.sh ファイルを作成しました。ユーザーはこのファイルを正しい場所に配置するだけで使用できます。

アーカイブからファイルを抽出し、Jira を起動する前に次の手順を完了します。

ステップ 1: デフォルトの setenv ファイルの名前を変更する

  1. <Jira-install-directory>/bin に移動し、setenv.bat / .sh ファイルを削除 (または名前を変更) します。

  2. setenv32.bat / .sh の名前を setenv.bat / .sh に変更します。Jiar はこのファイルを起動時に使用します。

ステップ 2: jira-config.properties ファイルにプロパティを追加する

  1. Jira ホーム ディレクトリに移動し、jira-config.properties ファイルを編集します。ファイルがない場合は作成できます。詳細情報

  2. 次のプロパティを追加します: 

    jira.index.batch.maxrambuffermb=256
jira.index.interactive.maxrambuffermb=256

MySQL 5.7 の新しい設定

Jira で 4 バイト文字を使用できるよう、MySQL 5.7 用の新しい設定手順が追加されました。古い設定は引き続き使用できますが、4 バイト文字は使用できなくなります。詳細をご確認ください。


Plugin 1 タイプ アプリのインストール ディレクトリ

P1 アプリが <Jira-install-dir>/atlassian-Jira/WEB-INF/lib にインストールされていることを確認します。これらのアプリを Atlassian Marketplace の標準アプリとともに <jira-home-dir>/plugins/installed-plugins にインストールする場合、それらは Jira 8.0 では機能しません。詳細は、「Marketplace アプリのインストール」を参照してください。


catalina.out ファイルへのログ作成を削減

Jira アプリケーションは、アプリケーション ログ出力 (atlassian-jira.log) を Tomcat ログ ファイル catalina.out にミラーしていました。Jira では Log4j 構成を使用して (アプリケーション ログのように) catalina.out ファイルを切り替えることができないため、ファイルが増大し、Jira の一意なイベントや有用なイベントを含むことができませんでした。Jira 管理者は OS レベルで log-rotation スクリプトを使用することでこの問題を回避できましたが、これはセットアップを複雑化していました。

この問題を修正するため、catalina.out  へのログ出力 (Stdout プロセス) へのミラーリングを削除し、サポート チームに役立つ以下の基本的なイベントのみを残すようにしました。

log4j.logger.com.atlassian.jira.(upgrade|startup|config.database)

これまでのように、引き続きすべてのイベントを atlassian-jira.log ファイルに記録します。また、切り替えられる atlassian-jira.log ファイルの数を 5 から 10 に増やしました。


Apache Tomcat のアップグレード

Apache Tomcat をバージョン 8.5.32 にアップグレードしました。これにより、server.xml ファイルへの変更が必要です。

問題点

Apache Tomcat サーバーは特殊文字が含まれるリクエストをフィルタリングするため、このようなリクエストが失敗します。これは、Tomcat がほとんどのブラウザとは異なるエンコーディングおよび URI 標準を採用しているためです。この問題は、多くの特殊文字 ([]<> など) を使用する JQL 検索でもっともよく見られますが、Jira の他のページにも影響を与える可能性があります。詳細情報

影響を受けるバージョン

この変更は Jira 3.15.2 で実装しました。これ以降のバージョンからアップグレードする場合、これらの手順は完了しているものと見なされます。

手順

この問題を解決するには、server.xml ファイルを編集し、リクエスト内の特殊文字を Tomcat が許可するようにするプロパティを追加します。

  1. <Jira-installation-directory>/conf に移動し、server.xml ファイルを編集します。
  2. アプリケーションで使用中のすべてのコネクタを見つけます。ファイルで Connector を検索するか、以下の例をご覧ください。

  3. server.xml の connector プロパティに relaxedPathChars="[]|" relaxedQueryChars="[]|{}^\`"<>" を追加します。例:

    <Connector port="8080" relaxedPathChars="[]|" relaxedQueryChars="[]|{}^&#x5c;&#x60;&quot;&lt;&gt;" maxThreads="150" minSpareThreads="25" connectionTimeout="20000" enableLookups="false" maxHttpHeaderSize="8192" protocol="HTTP/1.1" useBodyEncodingForURI="true" redirectPort="8443" acceptCount="100" disableUploadTimeout="true" bindOnInit="false"/>
  4. Jira を再起動します。
  5. (Data Center) 各ノードで以上のステップを繰り返します。


fugue のサポート終了

Jira Service Desk 4.0 では、com.atlassian.fugue が削除され、代わりにコア Java データ型および例外を使用するように API が更新されました。この変更は、Jira Service Desk での開発を簡単にするために導入されました。

ユーザー側で必要な操作について

Core Java データ型および例外を使用する前に、com.atlassian.fugue を返すエンドポイントにリクエストを送信しているすべてのスクリプト、連携、アプリを更新します。これによって、アップグレード後の障害を防ぎます。

詳細については、Java API ドキュメントや REST API ドキュメントを参照してください。


アプリ開発者向けの情報

アプリに関するすべての重要な変更については、「Jira 8.0 への準備」を参照してください。


アップグレード手順

アップグレードの手順を完了するには、Jira アプリケーションのアップグレードを参照してください。すべての利用可能なアップグレード方法や、Jira Service Desk 4.0 に必要なアップグレード前の手順が含まれます。お客様に最適なアップグレードの詳細については、アップグレード前の計画ツールも参照してください。そのツールでは、アップグレード先のバージョンをお勧めしてアップグレード前のチェックを実行し、ステップ バイ ステップの手順によってカスタム アップグレード ガイドを提供します。

Last modified on Mar 31, 2020

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

はい
いいえ
この記事についてのフィードバックを送信する

関連コンテンツ

  • 関連コンテンツがありません
Powered by Confluence and Scroll Viewport.