Swarmのアップグレード

このセクションでは、Swarmパッケージインストールを新しいリリースにアップグレードする方法について説明します。

Swarmのアップグレードプロセス:

• パッケージを使用してSwarmをインストールした場合は、Swarmパッケージのインストール環境のアップグレードを参照してください。
• OVAを使用してSwarm (Swarm 2014.2以降)をインストールした場合は、Swarmパッケージのインストール環境のアップグレードを参照してください。
• OVAを使用してSwarm (Swarm 2014.1以前)をインストールした場合は、Swarm 2014.1以前のSwarm OVAインストール環境のアップグレードを参照してください。
• ソース配布アーカイブ(tarファイル)を使用してSwarmをインストールした場合は、Swarm tarballのインストール環境のアップグレードを参照してください。

Swarmパッケージのインストール環境のアップグレード

Swarmのアップグレードを開始する前に

Swarmのワークフロー機能はSwarm 2018.2で導入されました。このバージョンでは、ワークフロー機能はデフォルトで無効になっていましたが、バージョン2019.2以降のSwarmでは、デフォルトで有効になっています。

Swarmのワークフロー機能ではなく、strictトリガとenforceトリガを使用してコミットを制御している場合は、以下の点に注意してください。

• Swarmのワークフロー機能を使用する場合: strictトリガとenforceトリガをコメント化して、新しいワークフロートリガを使用する必要があります。
注意

既知の制約事項

ワークフロートリガは、Swarm 2018.1以前のバージョンで使用可能な以下のトリガ機能をサポートしていません。

• EXEMPT_FILE_COUNT
• EXEMPT_EXTENSIONS

引き続きこれらのトリガ機能を使用する場合は、以下の説明のように、ワークフロー機能を無効にした状態で、現在のenforceトリガとstrictトリガをそのまま使用する必要があります。

• strict トリガと enforce トリガを引き続き使用する場合: 現在のenforceトリガとstrictトリガをそのまま使用し、ワークフロー機能を無効にしてください。 これらのトリガ行は、今後のリリースでは使用できなくなります。

  ヒント

  Swarmのconfig.phpファイルでワークフロー機能を無効にした場合、ワークフローがSwarmで処理されなくなりますが、Helixサーバがワークフロートリガスクリプトを実行するたびに、わずかなオーバーヘッドが発生します。 次のワークフロートリガ行をコメント化すると、このオーバーヘッドをなくすことができます: swarm.enforce change-submit、swarm.strict change-content、swarm.shelvesub shelve-submit

ワークフロー機能を使用するかどうかにより、使用する必要があるトリガが異なるため、アップグレードを開始する前に、ワークフロー機能を使用するかどうかを決めてください。 トリガの要件について詳しくは、Swarmのアップグレードの「トリガの更新」セクションを参照してください。

Swarmのアップグレード

以下で説明するプロセスは、Swarmのダウンタイムを最小限に抑えることを目的としていますが、短時間のダウンタイムが発生するのを避けることはできません。 ただし、Helixサーバでダウンタイムが発生することはありません。 アップグレードが正常に完了すると、すべてのSwarmユーザがシステムからログアウトされます。

実稼働環境でSwarmを使用している場合は、最初にテスト環境や開発環境などでこのアップグレードプロセスのテストを行うことをお勧めします。

1. 以下に示す各OSディストリビューションで操作を実行します。
Ubuntu:

                            $ sudo apt-get update
$ sudo apt-get install helix-swarm helix-swarm-triggers helix-swarm-optional

CentOS
以下に示すバージョンのCentOSディストリビューションで操作を実行します。
CentOS 6 (以下のコマンドをrootユーザとして実行):
重要
• PHPのアップグレードプロセスの一環として、Apache 2.2サーバは停止し無効化された状態になります。Apache 2.2サーバを別のアプリケーション用に使用している場合、それらのアプリケーションも動作を停止します。 これらのアプリケーションをアップグレードしてPHP 7とApache 2.4で動作するようにするか、アプリケーションを別のサーバに移動させてください。

• Apache 2.4をSCLパッケージまたはRHSCLパッケージからインストールすると、Apacheの設定ファイルは、通常のインストール場所の/etcではなく/opt/rh/httpd24/root/etcにインストールされます。 つまり、通常のservice、systemctl、apachectlコマンドを実行すると、正しくないサーバをコントロールすることになります。 Swarmが使用するApacheのバージョンを制御するには、以下のいずれかの操作を実行します。

  • CentOS/RHEL 6でSystem Vスクリプトを使用する場合: service httpd24-httpd restart
  • CentOS/RHEL 7でsystemdスクリプトを使用する場合: systemctl restart httpd24-httpd

  apachectlコマンドは引き続き存在しますが、/opt/rh/httpd24環境で実行する必要があります。 そのため、上記のいずれかのコマンドを代わりに使用することをお勧めします。

• Apacheサーバの起動時にApache HTTPサーバのLinuxテストページが表示されないようにするには、/opt/rh/httpd24/root/etc/httpd/conf.d/ディレクトリのwelcome.confファイルの内容をコメント化します。
以下で説明するアップグレードプロセスのすべての手順を実行する必要があるのは、初めてPHP 7.xにアップグレードする場合だけです。2回目以降のSwarmのアップグレードでは、手順bだけを実行するだけで済みます。
アップグレードプロセスでは、centos-release-sclを展開してSwarmがPHP 7.xとApache 2.4にアクセスできるようにし、Swarmをアップグレードし、Apache 2.2サーバを停止して無効にし、Swarmのファイルをコピーおよび編集してApache 2.4と連携させて、最後にApache 2.4サーバを起動して有効にします。
1. centos-release-sclリポジトリを展開し、SwarmがPHP 7.xにアクセスできるようにします。

$ yum -y install centos-release-scl

ヒント

centos-release-sclリポジトリを展開しない場合、次の手順を実行すると、以下に示すようなエラーが表示されます。



2. Swarmのアップグレードを実行します。これで自動的にPHP 7.xとApache 2.4がインストールされます。

$ yum install helix-swarm helix-swarm-triggers helix-swarm-optional

3. Apache 2.2 HTTPサーバが自動起動しないように無効にします。

$ chkconfig httpd off

4. Apache 2.2 HTTPサーバを停止します。

$ service httpd stop

5. 特別なphp.ini設定オプションのセットがある場合、php.iniファイルを/etc/opt/rh/rh-php70/php.d/ディレクトリにコピーします:

$ cp /etc/php.d/php.ini /etc/opt/rh/rh-php70/php.d/php.ini

6. perforce-swarm-site.confファイルを/opt/rh/httpd24/root/etc/httpd/conf.d/ディレクトリにコピーします。

$ cp /etc/httpd/conf.d/perforce-swarm-site.conf /opt/rh/httpd24/root/etc/httpd/conf.d/perforce-swarm-site.conf

7. sedコマンドを使用して、/log/httpd/ファイルパスをperforce-swarm-site.confファイルの/log/httpd24で置き換えます。

$ sed -i "s#/log/httpd/#/log/httpd24/#g" /opt/rh/httpd24/root/etc/httpd/conf.d/perforce-swarm-site.conf

8. Apache 2.4の権限を更新します。このために、sedコマンドを使用して、perforce-swarm-site.confファイルのOrder allow,deny参照をRequire all grantedに置き換えます:

$ sed -i "s/Order allow,deny/Require all granted/g" /opt/rh/httpd24/root/etc/httpd/conf.d/perforce-swarm-site.conf

9. Apache 2.4 HTTPサーバが自動起動するように有効にします。

$ chkconfig httpd24-httpd on

10. Apache 2.4 HTTPサーバを起動します。

$ service httpd24-httpd start
CentOS 7.8 (以下のコマンドをrootユーザとして実行):
重要
• PHPのアップグレードプロセスの一環として、Apache 2.2サーバは停止し無効化された状態になります。Apache 2.2サーバを別のアプリケーション用に使用している場合、それらのアプリケーションも動作を停止します。 これらのアプリケーションをアップグレードしてPHP 7とApache 2.4で動作するようにするか、アプリケーションを別のサーバに移動させてください。

• Apache 2.4をSCLパッケージまたはRHSCLパッケージからインストールすると、Apacheの設定ファイルは、通常のインストール場所の/etcではなく/opt/rh/httpd24/root/etcにインストールされます。 つまり、通常のservice、systemctl、apachectlコマンドを実行すると、正しくないサーバをコントロールすることになります。 Swarmが使用するApacheのバージョンを制御するには、以下のいずれかの操作を実行します。

  • CentOS/RHEL 6でSystem Vスクリプトを使用する場合: service httpd24-httpd restart
  • CentOS/RHEL 7でsystemdスクリプトを使用する場合: systemctl restart httpd24-httpd

  apachectlコマンドは引き続き存在しますが、/opt/rh/httpd24環境で実行する必要があります。 そのため、上記のいずれかのコマンドを代わりに使用することをお勧めします。

• Apacheサーバの起動時にApache HTTPサーバのLinuxテストページが表示されないようにするには、/opt/rh/httpd24/root/etc/httpd/conf.d/ディレクトリのwelcome.confファイルの内容をコメント化します。
以下で説明するアップグレードプロセスのすべての手順を実行する必要があるのは、初めてPHP 7.xにアップグレードする場合だけです。2回目以降のSwarmのアップグレードでは、手順bだけを実行するだけで済みます。
アップグレードプロセスでは、centos-release-sclを展開してSwarmがPHP 7.xとApache 2.4にアクセスできるようにし、Swarmをアップグレードし、Apache 2.2サーバを停止して無効にし、Swarmのファイルをコピーおよび編集してApache 2.4と連携させて、最後にApache 2.4サーバを起動して有効にします。
1. centos-release-sclリポジトリを展開し、SwarmがPHP 7.xにアクセスできるようにします。

$ yum -y install centos-release-scl

ヒント

centos-release-sclリポジトリを展開しない場合、次の手順を実行すると、以下に示すようなエラーが表示されます。



2. Swarmのアップグレードを実行します。これで自動的にPHP 7.xとApache 2.4がインストールされます。

$ yum install helix-swarm helix-swarm-triggers helix-swarm-optional

重要

Swarm 2019.3をSwarm 2020.1にアップグレードする場合は、SwarmのPHP 7.1ファイルを削除します。

$ yum remove $(yum list installed | grep php71 | awk '{print $1}')

3. Apache 2.2 HTTPサーバが自動起動しないように無効にします。

$ systemctl disable httpd

4. Apache 2.2 HTTPサーバを停止します。

$ systemctl stop httpd

5. 特殊なphp.ini構成オプションセットが指定されている場合は、php.iniファイルを/etc/opt/rh/rh-php72/php.d/ディレクトリにコピーします。

$ cp /etc/php.d/php.ini /etc/opt/rh/rh-php72/php.d/php.ini

6. perforce-swarm-site.confファイルを/opt/rh/httpd24/root/etc/httpd/conf.d/ディレクトリにコピーします。

$ cp /etc/httpd/conf.d/perforce-swarm-site.conf /opt/rh/httpd24/root/etc/httpd/conf.d/perforce-swarm-site.conf

7. sedコマンドを使用して、/log/httpd/ファイルパスをperforce-swarm-site.confファイルの/log/httpd24で置き換えます。

$ sed -i "s#/log/httpd/#/log/httpd24/#g" /opt/rh/httpd24/root/etc/httpd/conf.d/perforce-swarm-site.conf

8. Apache 2.4 HTTPサーバが自動起動するように有効にします。

$ systemctl enable httpd24-httpd

9. Apache 2.4 HTTPサーバを起動します。

$ systemctl start httpd24-httpd

10. オプションのImageMagick: ImageMagickを有効にすると、Swarmで画像を各種の形式(BMP、EPS、PSD、TGA、TIFF)で表示することができます。
    ImageMagickをインストールします。

# yum install ImageMagick

11. ImageMagick RPMが正しくインストールされていることを確認します。

# ldd /opt/perforce/swarm/p4-bin/bin.linux26x86_64/php72/imagick.so

実行結果の例:

	linux-vdso.so.1 =>  (0x00007fffacff8000)
	libMagickWand-6.Q16.so.6 => not found 
	libMagickCore-6.Q16.so.6 => not found
	libc.so.6 => /lib64/libc.so.6 (0x00007f9963b46000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f996417d000)

いずれかの結果が「not found」になっている場合は、ImageMagickのコアパッケージで正しい依存関係が指定されていません。この状態でImageMagickを使用することはできません。 これは、CentOS 7.6と7.7で発生する問題です。

必要なライブラリがすべて揃っている場合は、ImageMagickを有効にすると、ImageMagickが正しく機能します。

ヒント

PHP ImageMagickライブラリは、Swarmパッケージに含まれていますが、初期設定として無効になっています。 PHP ImageMagickライブラリと40-imagick.ini_ファイルは、/opt/perforce/swarm/p4-bin/bin.linux26x86_64/php72ディレクトリに保管されています。

12. このライブラリを有効にするには、以下のコマンドを使用して、40-imagick.ini_ファイルを/opt/rh/rh-php72/root/usr/lib64/php/modules/ディレクトリにコピーします。コピー後のファイル名からは、アンダースコア(_)が削除されます。

# cp /opt/perforce/swarm/p4-bin/bin.linux26x86_64/php72/40-imagick.ini_ /etc/opt/rh/rh-php72/php.d/40-imagick.ini

13. Webサーバを再起動します。これにより、ImageMagickが取得されます。

# systemctl restart httpd24-httpd

14. SELinuxがシステムで正常に動作していることを確認します。 CentOS 7上のSELinuxを設定する方法については、「CentOS 7上のSELinuxの構成」を参照してください。
RHEL
以下に示すバージョンのRHELディストリビューションで操作を実行します。
RHEL 6 (以下のコマンドをrootユーザとして実行):
重要
• PHPのアップグレードプロセスの一環として、Apache 2.2サーバは停止し無効化された状態になります。Apache 2.2サーバを別のアプリケーション用に使用している場合、それらのアプリケーションも動作を停止します。 これらのアプリケーションをアップグレードしてPHP 7とApache 2.4で動作するようにするか、アプリケーションを別のサーバに移動させてください。

• Apache 2.4をSCLパッケージまたはRHSCLパッケージからインストールすると、Apacheの設定ファイルは、通常のインストール場所の/etcではなく/opt/rh/httpd24/root/etcにインストールされます。 つまり、通常のservice、systemctl、apachectlコマンドを実行すると、正しくないサーバをコントロールすることになります。 Swarmが使用するApacheのバージョンを制御するには、以下のいずれかの操作を実行します。

  • CentOS/RHEL 6でSystem Vスクリプトを使用する場合: service httpd24-httpd restart
  • CentOS/RHEL 7でsystemdスクリプトを使用する場合: systemctl restart httpd24-httpd

  apachectlコマンドは引き続き存在しますが、/opt/rh/httpd24環境で実行する必要があります。 そのため、上記のいずれかのコマンドを代わりに使用することをお勧めします。

• Apacheサーバの起動時にApache HTTPサーバのLinuxテストページが表示されないようにするには、/opt/rh/httpd24/root/etc/httpd/conf.d/ディレクトリのwelcome.confファイルの内容をコメント化します。
以下で説明するアップグレードプロセスのすべての手順を実行する必要があるのは、初めてPHP 7.xにアップグレードする場合だけです。2回目以降のSwarmのアップグレードでは、手順bだけを実行するだけで済みます。
アップグレードプロセスの手順としては、rhel-server-rhscl-6-eus-rpmsを有効にする、SwarmからPHP 7.xとApache 2.4にアクセスできようにする、Swarmをアップグレードする、Apache 2.2サーバを停止して無効にする、Swarmファイルのコピーと編集を行ってSwarmをApache 2.4で使用できるようにする、Apache 2.4サーバを起動して有効にする、という順序になります。
1. rhel-server-rhscl-6-eus-rpmsリポジトリを有効にして、SwarmからPHP 7.xにアクセスできるようにします。

# subscription-manager repos --enable rhel-server-rhscl-6-eus-rpms

ヒント

rhel-server-rhscl-6-eus-rpmsリポジトリを有効にしなかった場合、次の手順を実行すると、以下に示すようなエラーが表示されます。

Error: Package: helix-swarm-2019.2-1845646.el6.x86_64 (perforce)
        Requires: rh-php70

2. Swarmのアップグレードを実行します。これで自動的にPHP 7.xとApache 2.4がインストールされます。

$ yum install helix-swarm helix-swarm-triggers helix-swarm-optional

3. Apache 2.2 HTTPサーバが自動起動しないように無効にします。

$ chkconfig httpd off

4. Apache 2.2 HTTPサーバを停止します。

$ service httpd stop

5. 特別なphp.ini設定オプションのセットがある場合、php.iniファイルを/etc/opt/rh/rh-php70/php.d/ディレクトリにコピーします:

$ cp /etc/php.d/php.ini /etc/opt/rh/rh-php70/php.d/php.ini

6. perforce-swarm-site.confファイルを/opt/rh/httpd24/root/etc/httpd/conf.d/ディレクトリにコピーします。

$ cp /etc/httpd/conf.d/perforce-swarm-site.conf /opt/rh/httpd24/root/etc/httpd/conf.d/perforce-swarm-site.conf

7. sedコマンドを使用して、/log/httpd/ファイルパスをperforce-swarm-site.confファイルの/log/httpd24で置き換えます。

$ sed -i "s#/log/httpd/#/log/httpd24/#g" /opt/rh/httpd24/root/etc/httpd/conf.d/perforce-swarm-site.conf

8. Apache 2.4の権限を更新します。このために、sedコマンドを使用して、perforce-swarm-site.confファイルのOrder allow,deny参照をRequire all grantedに置き換えます:

$ sed -i "s/Order allow,deny/Require all granted/g" /opt/rh/httpd24/root/etc/httpd/conf.d/perforce-swarm-site.conf

9. Apache 2.4 HTTPサーバが自動起動するように有効にします。

$ chkconfig httpd24-httpd on

10. Apache 2.4 HTTPサーバを起動します。

$ service httpd24-httpd start
RHEL 7.6と7.7 (以下のコマンドをrootユーザとして実行):
重要
• PHPのアップグレードプロセスの一環として、Apache 2.2サーバは停止し無効化された状態になります。Apache 2.2サーバを別のアプリケーション用に使用している場合、それらのアプリケーションも動作を停止します。 これらのアプリケーションをアップグレードしてPHP 7とApache 2.4で動作するようにするか、アプリケーションを別のサーバに移動させてください。

• Apache 2.4をSCLパッケージまたはRHSCLパッケージからインストールすると、Apacheの設定ファイルは、通常のインストール場所の/etcではなく/opt/rh/httpd24/root/etcにインストールされます。 つまり、通常のservice、systemctl、apachectlコマンドを実行すると、正しくないサーバをコントロールすることになります。 Swarmが使用するApacheのバージョンを制御するには、以下のいずれかの操作を実行します。

  • CentOS/RHEL 6でSystem Vスクリプトを使用する場合: service httpd24-httpd restart
  • CentOS/RHEL 7でsystemdスクリプトを使用する場合: systemctl restart httpd24-httpd

  apachectlコマンドは引き続き存在しますが、/opt/rh/httpd24環境で実行する必要があります。 そのため、上記のいずれかのコマンドを代わりに使用することをお勧めします。

• Apacheサーバの起動時にApache HTTPサーバのLinuxテストページが表示されないようにするには、/opt/rh/httpd24/root/etc/httpd/conf.d/ディレクトリのwelcome.confファイルの内容をコメント化します。
以下で説明するアップグレードプロセスのすべての手順を実行する必要があるのは、初めてPHP 7.xにアップグレードする場合だけです。2回目以降のSwarmのアップグレードでは、手順bだけを実行するだけで済みます。
アップグレードプロセスの手順としては、rhel-server-rhscl-7-eus-rpmsを有効にする、SwarmからPHP 7.xとApache 2.4にアクセスできようにする、Swarmをアップグレードする、Apache 2.2サーバを停止して無効にする、いくつかのSwarmファイルのコピーと編集を行ってSwarmをApache 2.4で使用できるようにする、Apache 2.4サーバを起動して有効にする、という順序になります。
1. rhel-server-rhscl-7-eus-rpmsリポジトリを有効にして、SwarmからPHP 7.xにアクセスできるようにします。

# subscription-manager repos --enable rhel-server-rhscl-7-eus-rpms

ヒント

rhel-server-rhscl-7-eus-rpmsリポジトリを有効にしなかった場合、次の手順を実行すると、以下に示すようなエラーが表示されます。

Error: Package: helix-swarm-2019.2-1845646.el6.x86_64 (perforce)
        Requires: rh-php72

2. Swarmのアップグレードを実行します。これで自動的にPHP 7.xとApache 2.4がインストールされます。

$ yum install helix-swarm helix-swarm-triggers helix-swarm-optional

重要

Swarm 2019.3をSwarm 2020.1にアップグレードする場合は、SwarmのPHP 7.1ファイルを削除します。

$ yum remove $(yum list installed | grep php71 | awk '{print $1}')

3. Apache 2.2 HTTPサーバが自動起動しないように無効にします。

$ systemctl disable httpd

4. Apache 2.2 HTTPサーバを停止します。

$ systemctl stop httpd

5. 特殊なphp.ini構成オプションセットが指定されている場合は、php.iniファイルを/etc/opt/rh/rh-php72/php.d/ディレクトリにコピーします。

$ cp /etc/php.d/php.ini /etc/opt/rh/rh-php72/php.d/php.ini

6. perforce-swarm-site.confファイルを/opt/rh/httpd24/root/etc/httpd/conf.d/ディレクトリにコピーします。

$ cp /etc/httpd/conf.d/perforce-swarm-site.conf /opt/rh/httpd24/root/etc/httpd/conf.d/perforce-swarm-site.conf

7. sedコマンドを使用して、/log/httpd/ファイルパスをperforce-swarm-site.confファイルの/log/httpd24で置き換えます。

$ sed -i "s#/log/httpd/#/log/httpd24/#g" /opt/rh/httpd24/root/etc/httpd/conf.d/perforce-swarm-site.conf

8. Apache 2.4 HTTPサーバが自動起動するように有効にします。

$ systemctl enable httpd24-httpd

9. Apache 2.4 HTTPサーバを起動します。

$ systemctl start httpd24-httpd

10. オプションのImageMagick: ImageMagickを有効にすると、Swarmで画像を各種の形式(BMP、EPS、PSD、TGA、TIFF)で表示することができます。
    ImageMagickをインストールします。

# yum install ImageMagick

11. ImageMagick RPMが正しくインストールされていることを確認します。

# ldd /opt/perforce/swarm/p4-bin/bin.linux26x86_64/php72/imagick.so

実行結果の例:

 linux-vdso.so.1 => (0x00007fffacff8000) libMagickWand-6.Q16.so.6 => not found libMagickCore-6.Q16.so.6 => not found libc.so.6 => /lib64/libc.so.6 (0x00007f9963b46000) /lib64/ld-linux-x86-64.so.2 (0x00007f996417d000)

いずれかの結果が「not found」になっている場合は、ImageMagickのコアパッケージで正しい依存関係が指定されていません。この状態でImageMagickを使用することはできません。 これは、RHEL 7.6と7.7で発生する問題です。

必要なライブラリがすべて揃っている場合は、ImageMagickを有効にすると、ImageMagickが正しく機能します。

ヒント

PHP ImageMagickライブラリは、Swarmパッケージに含まれていますが、初期設定として無効になっています。 PHP ImageMagickライブラリと40-imagick.ini_ファイルは、/opt/perforce/swarm/p4-bin/bin.linux26x86_64/php72ディレクトリに保管されています。

12. このライブラリを有効にするには、以下のコマンドを使用して、40-imagick.ini_ファイルを/opt/rh/rh-php72/root/usr/lib64/php/modules/ディレクトリにコピーします。コピー後のファイル名からは、アンダースコア(_)が削除されます。

# cp /opt/perforce/swarm/p4-bin/bin.linux26x86_64/php72/40-imagick.ini_ /etc/opt/rh/rh-php72/php.d/40-imagick.ini

13. Webサーバを再起動します。これにより、ImageMagickが取得されます。

# systemctl restart httpd24-httpd

14. SELinuxがシステムで正常に動作していることを確認します。 RHEL 7でSELinuxを設定する方法については、「CentOS 7上のSELinuxの構成」を参照してください。
RHEL 7.8 (以下のコマンドをrootユーザとして実行):
重要
• PHPのアップグレードプロセスの一環として、Apache 2.2サーバは停止し無効化された状態になります。Apache 2.2サーバを別のアプリケーション用に使用している場合、それらのアプリケーションも動作を停止します。 これらのアプリケーションをアップグレードしてPHP 7とApache 2.4で動作するようにするか、アプリケーションを別のサーバに移動させてください。

• Apache 2.4をSCLパッケージまたはRHSCLパッケージからインストールすると、Apacheの設定ファイルは、通常のインストール場所の/etcではなく/opt/rh/httpd24/root/etcにインストールされます。 つまり、通常のservice、systemctl、apachectlコマンドを実行すると、正しくないサーバをコントロールすることになります。 Swarmが使用するApacheのバージョンを制御するには、以下のいずれかの操作を実行します。

  • CentOS/RHEL 6でSystem Vスクリプトを使用する場合: service httpd24-httpd restart
  • CentOS/RHEL 7でsystemdスクリプトを使用する場合: systemctl restart httpd24-httpd

  apachectlコマンドは引き続き存在しますが、/opt/rh/httpd24環境で実行する必要があります。 そのため、上記のいずれかのコマンドを代わりに使用することをお勧めします。

• Apacheサーバの起動時にApache HTTPサーバのLinuxテストページが表示されないようにするには、/opt/rh/httpd24/root/etc/httpd/conf.d/ディレクトリのwelcome.confファイルの内容をコメント化します。
以下で説明するアップグレードプロセスのすべての手順を実行する必要があるのは、初めてPHP 7.xにアップグレードする場合だけです。2回目以降のSwarmのアップグレードでは、手順bだけを実行するだけで済みます。
アップグレードプロセスの手順としては、rhel-server-rhscl-7-eus-rpmsを有効にする、SwarmからPHP 7.xとApache 2.4にアクセスできようにする、Swarmをアップグレードする、Apache 2.2サーバを停止して無効にする、いくつかのSwarmファイルのコピーと編集を行ってSwarmをApache 2.4で使用できるようにする、Apache 2.4サーバを起動して有効にする、という順序になります。
1. rhel-server-rhscl-7-rpmsリポジトリを有効にして、SwarmがPHP 7.xにアクセスできるようにします。

# subscription-manager repos --enable rhel-server-rhscl-7-rpms

ヒント

rhel-server-rhscl-7-rpmsリポジトリを有効にしなかった場合、次の手順を実行すると、以下に示すようなエラーが表示されます。

Error: Package: helix-swarm-2019.2-1845646.el6.x86_64 (perforce)
        Requires: rh-php72

2. Swarmのアップグレードを実行します。これで自動的にPHP 7.xとApache 2.4がインストールされます。

$ yum install helix-swarm helix-swarm-triggers helix-swarm-optional

重要

Swarm 2019.3をSwarm 2020.1にアップグレードする場合は、SwarmのPHP 7.1ファイルを削除します。

$ yum remove $(yum list installed | grep php71 | awk '{print $1}')

3. Apache 2.2 HTTPサーバが自動起動しないように無効にします。

$ systemctl disable httpd

4. Apache 2.2 HTTPサーバを停止します。

$ systemctl stop httpd

5. 特殊なphp.ini構成オプションセットが指定されている場合は、php.iniファイルを/etc/opt/rh/rh-php72/php.d/ディレクトリにコピーします。

$ cp /etc/php.d/php.ini /etc/opt/rh/rh-php72/php.d/php.ini

6. perforce-swarm-site.confファイルを/opt/rh/httpd24/root/etc/httpd/conf.d/ディレクトリにコピーします。

$ cp /etc/httpd/conf.d/perforce-swarm-site.conf /opt/rh/httpd24/root/etc/httpd/conf.d/perforce-swarm-site.conf

7. sedコマンドを使用して、/log/httpd/ファイルパスをperforce-swarm-site.confファイルの/log/httpd24で置き換えます。

$ sed -i "s#/log/httpd/#/log/httpd24/#g" /opt/rh/httpd24/root/etc/httpd/conf.d/perforce-swarm-site.conf

8. Apache 2.4 HTTPサーバが自動起動するように有効にします。

$ systemctl enable httpd24-httpd

9. Apache 2.4 HTTPサーバを起動します。

$ systemctl start httpd24-httpd

10. オプションのImageMagick: ImageMagickを有効にすると、Swarmで画像を各種の形式(BMP、EPS、PSD、TGA、TIFF)で表示することができます。
    ImageMagickをインストールします。

# yum install ImageMagick

11. ImageMagick RPMが正しくインストールされていることを確認します。

# ldd /opt/perforce/swarm/p4-bin/bin.linux26x86_64/php72/imagick.so

実行結果の例:

 linux-vdso.so.1 => (0x00007fffacff8000) libMagickWand-6.Q16.so.6 => not found libMagickCore-6.Q16.so.6 => not found libc.so.6 => /lib64/libc.so.6 (0x00007f9963b46000) /lib64/ld-linux-x86-64.so.2 (0x00007f996417d000)

いずれかの結果が「not found」になっている場合は、ImageMagickのコアパッケージで正しい依存関係が指定されていません。この状態でImageMagickを使用することはできません。 これは、RHEL 7.6と7.7で発生する問題です。

必要なライブラリがすべて揃っている場合は、ImageMagickを有効にすると、ImageMagickが正しく機能します。

ヒント

PHP ImageMagickライブラリは、Swarmパッケージに含まれていますが、初期設定として無効になっています。 PHP ImageMagickライブラリと40-imagick.ini_ファイルは、/opt/perforce/swarm/p4-bin/bin.linux26x86_64/php72ディレクトリに保管されています。

12. このライブラリを有効にするには、以下のコマンドを使用して、40-imagick.ini_ファイルを/opt/rh/rh-php72/root/usr/lib64/php/modules/ディレクトリにコピーします。コピー後のファイル名からは、アンダースコア(_)が削除されます。

# cp /opt/perforce/swarm/p4-bin/bin.linux26x86_64/php72/40-imagick.ini_ /etc/opt/rh/rh-php72/php.d/40-imagick.ini

13. Webサーバを再起動します。これにより、ImageMagickが取得されます。

# systemctl restart httpd24-httpd

14. SELinuxがシステムで正常に動作していることを確認します。 RHEL 7でSELinuxを設定する方法については、「CentOS 7上のSELinuxの構成」を参照してください。
2. 通常、いくつかのSwarm用メジャーアップデートが毎年リリースされますが、そのほかにも、パッチによるアップデートがリリースされる場合があります。 Swarmのアップデートがリリースされているかどうかを確認するには、以下のOSディストリビューションでコマンドを実行します。
Ubuntu:

$ sudo apt-get update
$ sudo apt-get -s upgrade | grep swarm

CentOS/RHEL (以下のコマンドをrootユーザとして実行):

# yum list updates | grep swarm

トリガの更新

1. 新しいSwarmトリガスクリプトをHelix Coreサーバマシンにコピーします。 このトリガスクリプトは、SWARM_ROOT/p4-bin/scripts/swarm-trigger.plです。このスクリプトを使用するには、Helixサーバマシンにバージョン5.08以降のPerlをインストールする必要があります(最新バージョンをインストールすることをお勧めします)。 SwarmでSSLを使用している場合は、PerlモジュールのIO::Socket::SSLも必要になります。

   警告

   この時点で既存のトリガスクリプトを上書きしないでください。 スクリプトに新しい名前を付けます(swarm-trigger-new.plなど)。

2. Helixサーバマシン上の同じディレクトリ内にswarm-trigger.confというファイルを作成して、Swarmトリガスクリプトを設定します。 このスクリプトには以下を指定する必要があります。

   注意

   swarm-trigger.confファイルがすでに存在する場合は、追加の設定は不要です。

   # SWARM_HOST (required)
   # Hostname of your Swarm instance, with leading "http://" or "https://".
   SWARM_HOST="http://my-swarm-host"
   
   # SWARM_TOKEN (required)
   # The token used when talking to Swarm to offer some security. To obtain the
   # value, log in to Swarm as a super user and select 'About Swarm' to see the
   # token value.
   SWARM_TOKEN="MY-UUID-STYLE-TOKEN"
   
   # ADMIN_USER (optional) ワークフロー機能が有効になっている場合は使用しないでください(ワークフロー機能はデフォルトで有効になっています)
   # For enforcing reviewed changes, optionally specify the normal Perforce user
   # with admin privileges (to read keys); if not set, will use whatever Perforce
   # user is set in environment.
   ADMIN_USER=
   
   # ADMIN_TICKET_FILE (optional) ワークフロー機能が有効になっている場合は使用しないでください(ワークフロー機能はデフォルトで有効になっています)
   # For enforcing reviewed changes, optionally specify the location of the
   # p4tickets file if different from the default ($HOME/.p4tickets).
   # Ensure this user is a member of a group with an 'unlimited' or very long
   # timeout; then, manually login as this user from the Perforce server machine to
   # set the ticket.
   ADMIN_TICKET_FILE=				
   										
   # VERIFY_SSL (optional)
   # If HTTPS is being used on the Swarm web server, then this controls whether
   # the SSL certificate is validated or not. By default this is set to 1, which
   # means any SSL certificates must be valid. If the web server is using a self
   # signed certificate, then this must be set to 0.
   # set the ticket.
   VERIFY_SSL=1

   必須のSWARM_HOST変数とSWARM_TOKEN変数に、以前のSwarmトリガスクリプト(通常はswarm-trigger.pl)の設定を入力します。

   ヒント

   ADMIN_USER変数とADMIN_TICKET変数は、バージョン2019.1以前のSwarmの'enforce triggers'で使用されていました。 明示的にワークフローを無効にして、非推奨の'enforce triggers'を使用しない限り、これらの変数は削除してかまいません。

   注意

   バージョン2015.4以前のSwarmの場合: 以前のSwarmバージョンでは、Swarmのトリガスクリプトファイルをシェルスクリプトとして使用することができました (通常はswarm-trigger.sh)。

   Swarmでは、Perlトリガスクリプトファイル(通常はswarm-trigger.pl)を使用する必要があります。

3. Linuxの場合: 以下のコマンドを実行して、スクリプトが実行可能かどうかを確認します。

   $ sudo chmod +x swarm-trigger-new.pl

4. 新しいトリガスクリプトの名前を次のように変更します。

   Linuxの場合:

   $ mv swarm-trigger-new.pl swarm-trigger.pl

   Windowsの場合:

   C:\> ren swarm-trigger-new.pl swarm-trigger.pl

5. Helixサーバのトリガを更新します。

   警告

   • 「swarm.shelvedel shelve-delete」というトリガ行は、バージョン2018.1以降のSwarmで追加され、バージョン2020.1で更新された行です。

     • バージョン2017.4以前の Swarm をアップグレードする場合:「swarm.shelvedel shelve-delete」というトリガ行をHelixサーバのトリガテーブルに追加します(まだ追加されていない場合)。詳しくは、 Helixサーバのトリガテーブルを更新し、トリガスクリプトを実行します。を参照してください。
     • バージョン2018.xまたはバージョン2019.xの Swarm をアップグレードする場合: Helixサーバのトリガテーブル内の「swarm.shelvedel shelve-delete」というトリガ行を、アップグレード先バージョンのSwarmで指定されているトリガ行に置き換えます。

   • ワークフロー機能:

     バージョン2019.2以降のSwarmでは、ワークフロー機能がデフォルトで有効になっています。 ワークフロー機能を有効にするためのトリガ行は、ワークフロー機能を無効にするためのトリガ行とは異なります。

     • ワークフロー機能を有効にする(これがデフォルト設定です)
       • Helixサーバのトリガテーブルで、次のトリガ行をコメント化します(これらのトリガ行が記述されている場合): swarm.enforce.1、swarm.enforce.2、swarm.strict.1、swarm.strict.2。詳細については、「 Helixサーバのトリガテーブルを更新し、トリガスクリプトを実行します。」を参照してください。
       • 次のトリガ行をHelixサーバのトリガテーブルに追加します(これらのトリガ行がまだ追加されていない場合): swarm.enforce change-submit、swarm.strict change-content、swarm.shelvesub shelve-submit。詳細については、「 Helixサーバのトリガテーブルを更新し、トリガスクリプトを実行します。」を参照してください。
     • ワークフロー機能を無効:

       Helixサーバのトリガテーブルで、次のトリガ行をコメント化します(これらのトリガ行が記述されている場合): swarm.enforce change-submit、swarm.strict change-content、swarm.shelvesub shelve-submit。詳細については、「 Helixサーバのトリガテーブルを更新し、トリガスクリプトを実行します。」を参照してください。

   1. Swarmトリガスクリプトを実行して、Perforceトリガテーブルに含める必要があるトリガ行をキャプチャします(WindowsとLinuxの場合はCtrl+Cキーを、macOSの場合はCommand+Cキーを使用します)。

      Linuxの場合:

      $ ./swarm-trigger.pl -o

      Windowsの場合:

      C:\> path/to/perl swarm-trigger.pl -o

   2. super 権限を持つPerforceユーザとしてp4 triggersコマンドを実行し、前述の手順でキャプチャしたすべてのswarm.*行を置き換えます(WindowsとLinuxの場合はCtrl+Vキーを、macOSの場合はCommand+Vキーを使用します)。これによって、Perforceトリガテーブルは更新されます。
   重要

   各種のトリガオプションを適用するなどの目的でSwarmのトリガ行がカスタマイズされている場合は、更新後のトリガ行でも同じカスタマイズ作業を繰り返してください。

アップグレードの確認

アップグレード後のSwarmインスタンスが正しく稼働するかどうかを確認するには、以下の手順を実行します。

1. 以下のチェンジリストを新しく作成します。
   1. 変更されたファイルが1つ以上含まれているチェンジリスト
   2. チェンジリストの説明に#reviewキーワードが含まれているチェンジリスト
2. 作成したチェンジリストをP4Vで右クリックし、[ファイルを保留...]をクリックします。
重要

[新しいSwarmレビューを要求...]を選択しないでください。これを選択するとAPIが使用されるため、Swarmトリガのテストが完全には実行されません。

3. チェンジリストに対して新しいSwarmレビューが作成されたことを確認します。
• Swarmレビューが作成されている場合は、Swarmトリガが機能します。
• Swarmレビューが作成されていない場合は、以下の説明を参照してください。

Swarmインデックスのアップグレード

バージョン2017.2以前のSwarmをアップグレードする場合は、インデックスをアップグレードする必要があります。これにより、[ダッシュボード]ページと[レビューリスト]ページで、レビューに対するアクティビティの履歴が正しい順序で表示されるようになります。

インデックスのアップグレードプロセスは、Swarmシステムの仕様に合わせて設定することができます。 詳細については、「インデックスのアップグレード」を参照してください。

以下のURLにアクセスし、admin 権限を持つユーザとしてアップグレードを実行してください。

http://SWARM-HOST/upgrade

操作はこれで完了です。

Swarm 2014.1以前のSwarm OVAインストール環境のアップグレード

Swarmのアップグレードを開始する前に

Swarmのワークフロー機能はSwarm 2018.2で導入されました。このバージョンでは、ワークフロー機能はデフォルトで無効になっていましたが、バージョン2019.2以降のSwarmでは、デフォルトで有効になっています。

Swarmのワークフロー機能ではなく、strictトリガとenforceトリガを使用してコミットを制御している場合は、以下の点に注意してください。

• Swarmのワークフロー機能を使用する場合: strictトリガとenforceトリガをコメント化して、新しいワークフロートリガを使用する必要があります。
注意

既知の制約事項

ワークフロートリガは、Swarm 2018.1以前のバージョンで使用可能な以下のトリガ機能をサポートしていません。

• EXEMPT_FILE_COUNT
• EXEMPT_EXTENSIONS

引き続きこれらのトリガ機能を使用する場合は、以下の説明のように、ワークフロー機能を無効にした状態で、現在のenforceトリガとstrictトリガをそのまま使用する必要があります。

• strict トリガと enforce トリガを引き続き使用する場合: 現在のenforceトリガとstrictトリガをそのまま使用し、ワークフロー機能を無効にしてください。 これらのトリガ行は、今後のリリースでは使用できなくなります。

  ヒント

  Swarmのconfig.phpファイルでワークフロー機能を無効にした場合、ワークフローがSwarmで処理されなくなりますが、Helixサーバがワークフロートリガスクリプトを実行するたびに、わずかなオーバーヘッドが発生します。 次のワークフロートリガ行をコメント化すると、このオーバーヘッドをなくすことができます: swarm.enforce change-submit、swarm.strict change-content、swarm.shelvesub shelve-submit

ワークフロー機能を使用するかどうかにより、使用する必要があるトリガが異なるため、アップグレードを開始する前に、ワークフロー機能を使用するかどうかを決めてください。 トリガの要件について詳しくは、Swarmのアップグレードの「トリガの更新」セクションを参照してください。

Swarmのアップグレード

以下で説明するプロセスは、Swarmのダウンタイムを最小限に抑えることを目的としていますが、短時間のダウンタイムが発生するのを避けることはできません。 ただし、Helixサーバでダウンタイムが発生することはありません。 アップグレードが正常に完了すると、すべてのSwarmユーザがシステムからログアウトされます。

実稼働環境でSwarmを使用している場合は、最初にテスト環境や開発環境などでこのアップグレードプロセスのテストを行うことをお勧めします。

1. 新しいOVAをhttps://www.perforce.com/downloads/helix-swarmからダウンロードします。
2. OVAの設定手順を実行します。 これにより、Swarmがアップグレードされ、ディストリビューション、Webサーバ、PHP、セキュリティアップデートなど、Webホスト環境を構成する各種要素がOVA内で更新されます。

トリガの更新

1. 新しいSwarmトリガスクリプトをHelix Coreサーバマシンにコピーします。 このトリガスクリプトは、SWARM_ROOT/p4-bin/scripts/swarm-trigger.plです。このスクリプトを使用するには、Helixサーバマシンにバージョン5.08以降のPerlをインストールする必要があります(最新バージョンをインストールすることをお勧めします)。 SwarmでSSLを使用している場合は、PerlモジュールのIO::Socket::SSLも必要になります。

   警告

   この時点で既存のトリガスクリプトを上書きしないでください。 スクリプトに新しい名前を付けます(swarm-trigger-new.plなど)。

2. Helixサーバマシン上の同じディレクトリ内にswarm-trigger.confというファイルを作成して、Swarmトリガスクリプトを設定します。 このスクリプトには以下を指定する必要があります。

   注意

   swarm-trigger.confファイルがすでに存在する場合は、追加の設定は不要です。

   # SWARM_HOST (required)
   # Hostname of your Swarm instance, with leading "http://" or "https://".
   SWARM_HOST="http://my-swarm-host"
   
   # SWARM_TOKEN (required)
   # The token used when talking to Swarm to offer some security. To obtain the
   # value, log in to Swarm as a super user and select 'About Swarm' to see the
   # token value.
   SWARM_TOKEN="MY-UUID-STYLE-TOKEN"
   
   # ADMIN_USER (optional) ワークフロー機能が有効になっている場合は使用しないでください(ワークフロー機能はデフォルトで有効になっています)
   # For enforcing reviewed changes, optionally specify the normal Perforce user
   # with admin privileges (to read keys); if not set, will use whatever Perforce
   # user is set in environment.
   ADMIN_USER=
   
   # ADMIN_TICKET_FILE (optional) ワークフロー機能が有効になっている場合は使用しないでください(ワークフロー機能はデフォルトで有効になっています)
   # For enforcing reviewed changes, optionally specify the location of the
   # p4tickets file if different from the default ($HOME/.p4tickets).
   # Ensure this user is a member of a group with an 'unlimited' or very long
   # timeout; then, manually login as this user from the Perforce server machine to
   # set the ticket.
   ADMIN_TICKET_FILE=				
   										
   # VERIFY_SSL (optional)
   # If HTTPS is being used on the Swarm web server, then this controls whether
   # the SSL certificate is validated or not. By default this is set to 1, which
   # means any SSL certificates must be valid. If the web server is using a self
   # signed certificate, then this must be set to 0.
   # set the ticket.
   VERIFY_SSL=1

   必須のSWARM_HOST変数とSWARM_TOKEN変数に、以前のSwarmトリガスクリプト(通常はswarm-trigger.pl)の設定を入力します。

   ヒント

   ADMIN_USER変数とADMIN_TICKET変数は、バージョン2019.1以前のSwarmの'enforce triggers'で使用されていました。 明示的にワークフローを無効にして、非推奨の'enforce triggers'を使用しない限り、これらの変数は削除してかまいません。

   注意

   バージョン2015.4以前のSwarmの場合: 以前のSwarmバージョンでは、Swarmのトリガスクリプトファイルをシェルスクリプトとして使用することができました (通常はswarm-trigger.sh)。

   Swarmでは、Perlトリガスクリプトファイル(通常はswarm-trigger.pl)を使用する必要があります。

3. Linuxの場合: 以下のコマンドを実行して、スクリプトが実行可能かどうかを確認します。

   $ sudo chmod +x swarm-trigger-new.pl

4. 新しいトリガスクリプトの名前を次のように変更します。

   Linuxの場合:

   $ mv swarm-trigger-new.pl swarm-trigger.pl

   Windowsの場合:

   C:\> ren swarm-trigger-new.pl swarm-trigger.pl

5. Helixサーバのトリガを更新します。

   警告

   • 「swarm.shelvedel shelve-delete」というトリガ行は、バージョン2018.1以降のSwarmで追加され、バージョン2020.1で更新された行です。

     • バージョン2017.4以前の Swarm をアップグレードする場合:「swarm.shelvedel shelve-delete」というトリガ行をHelixサーバのトリガテーブルに追加します(まだ追加されていない場合)。詳しくは、 Helixサーバのトリガテーブルを更新し、トリガスクリプトを実行します。を参照してください。
     • バージョン2018.xまたはバージョン2019.xの Swarm をアップグレードする場合: Helixサーバのトリガテーブル内の「swarm.shelvedel shelve-delete」というトリガ行を、アップグレード先バージョンのSwarmで指定されているトリガ行に置き換えます。

   • ワークフロー機能:

     バージョン2019.2以降のSwarmでは、ワークフロー機能がデフォルトで有効になっています。 ワークフロー機能を有効にするためのトリガ行は、ワークフロー機能を無効にするためのトリガ行とは異なります。

     • ワークフロー機能を有効にする(これがデフォルト設定です)
       • Helixサーバのトリガテーブルで、次のトリガ行をコメント化します(これらのトリガ行が記述されている場合): swarm.enforce.1、swarm.enforce.2、swarm.strict.1、swarm.strict.2。詳細については、「 Helixサーバのトリガテーブルを更新し、トリガスクリプトを実行します。」を参照してください。
       • 次のトリガ行をHelixサーバのトリガテーブルに追加します(これらのトリガ行がまだ追加されていない場合): swarm.enforce change-submit、swarm.strict change-content、swarm.shelvesub shelve-submit。詳細については、「 Helixサーバのトリガテーブルを更新し、トリガスクリプトを実行します。」を参照してください。
     • ワークフロー機能を無効:

       Helixサーバのトリガテーブルで、次のトリガ行をコメント化します(これらのトリガ行が記述されている場合): swarm.enforce change-submit、swarm.strict change-content、swarm.shelvesub shelve-submit。詳細については、「 Helixサーバのトリガテーブルを更新し、トリガスクリプトを実行します。」を参照してください。

   1. Swarmトリガスクリプトを実行して、Perforceトリガテーブルに含める必要があるトリガ行をキャプチャします(WindowsとLinuxの場合はCtrl+Cキーを、macOSの場合はCommand+Cキーを使用します)。

      Linuxの場合:

      $ ./swarm-trigger.pl -o

      Windowsの場合:

      C:\> path/to/perl swarm-trigger.pl -o

   2. super 権限を持つPerforceユーザとしてp4 triggersコマンドを実行し、前述の手順でキャプチャしたすべてのswarm.*行を置き換えます(WindowsとLinuxの場合はCtrl+Vキーを、macOSの場合はCommand+Vキーを使用します)。これによって、Perforceトリガテーブルは更新されます。
   重要

   各種のトリガオプションを適用するなどの目的でSwarmのトリガ行がカスタマイズされている場合は、更新後のトリガ行でも同じカスタマイズ作業を繰り返してください。

カスタマイズされたOVA構成

元のOVAのSwarm設定がカスタマイズされている場合は、以下の手順を実行します。

1. /opt/perforce/swarm/data/config.phpを、新しいOVA内の同じパスにコピーします。
2. /opt/perforce/swarm/data/queue/tokens/内のすべてのトークンファイルを、新しいOVAの同じパスにコピーします。

アップグレードの確認

新しいOVAが正しく稼働するかどうかを確認するには、以下の手順を実行します。

1. 以下のチェンジリストを新しく作成します。
   1. 変更されたファイルが1つ以上含まれているチェンジリスト
   2. チェンジリストの説明に#reviewキーワードが含まれているチェンジリスト
2. 作成したチェンジリストをP4Vで右クリックし、[ファイルを保留...]をクリックします。
重要

[新しいSwarmレビューを要求...]を選択しないでください。これを選択するとAPIが使用されるため、Swarmトリガのテストが完全には実行されません。

3. チェンジリストに対して新しいSwarmレビューが作成されたことを確認します。
• Swarmレビューが作成されている場合は、Swarmトリガが機能します。
• Swarmレビューが作成されていない場合は、以下の説明を参照してください。

新しいOVAが正しく機能していることを確認したら、古いOVAをシャットダウンしてください。

Swarmインデックスのアップグレード

バージョン2017.2以前のSwarmをアップグレードする場合は、インデックスをアップグレードする必要があります。これにより、[ダッシュボード]ページと[レビューリスト]ページで、レビューに対するアクティビティの履歴が正しい順序で表示されるようになります。

インデックスのアップグレードプロセスは、Swarmシステムの仕様に合わせて設定することができます。 詳細については、「インデックスのアップグレード」を参照してください。

以下のURLにアクセスし、admin 権限を持つユーザとしてアップグレードを実行してください。

http://SWARM-HOST/upgrade

操作はこれで完了です。

Swarm tarballのインストール環境のアップグレード

Swarmのアップグレードを開始する前に

Swarmのワークフロー機能はSwarm 2018.2で導入されました。このバージョンでは、ワークフロー機能はデフォルトで無効になっていましたが、バージョン2019.2以降のSwarmでは、デフォルトで有効になっています。

Swarmのワークフロー機能ではなく、strictトリガとenforceトリガを使用してコミットを制御している場合は、以下の点に注意してください。

• Swarmのワークフロー機能を使用する場合: strictトリガとenforceトリガをコメント化して、新しいワークフロートリガを使用する必要があります。
注意

既知の制約事項

ワークフロートリガは、Swarm 2018.1以前のバージョンで使用可能な以下のトリガ機能をサポートしていません。

• EXEMPT_FILE_COUNT
• EXEMPT_EXTENSIONS

引き続きこれらのトリガ機能を使用する場合は、以下の説明のように、ワークフロー機能を無効にした状態で、現在のenforceトリガとstrictトリガをそのまま使用する必要があります。

• strict トリガと enforce トリガを引き続き使用する場合: 現在のenforceトリガとstrictトリガをそのまま使用し、ワークフロー機能を無効にしてください。 これらのトリガ行は、今後のリリースでは使用できなくなります。

  ヒント

  Swarmのconfig.phpファイルでワークフロー機能を無効にした場合、ワークフローがSwarmで処理されなくなりますが、Helixサーバがワークフロートリガスクリプトを実行するたびに、わずかなオーバーヘッドが発生します。 次のワークフロートリガ行をコメント化すると、このオーバーヘッドをなくすことができます: swarm.enforce change-submit、swarm.strict change-content、swarm.shelvesub shelve-submit

ワークフロー機能を使用するかどうかにより、使用する必要があるトリガが異なるため、アップグレードを開始する前に、ワークフロー機能を使用するかどうかを決めてください。 トリガの要件について詳しくは、Swarmのアップグレードの「トリガの更新」セクションを参照してください。

Swarmのアップグレード

以下で説明するプロセスは、Swarmのダウンタイムを最小限に抑えることを目的としていますが、短時間のダウンタイムが発生するのを避けることはできません。 ただし、Helixサーバでダウンタイムが発生することはありません。 アップグレードが正常に完了すると、すべてのSwarmユーザがシステムからログアウトされます。

実稼働環境でSwarmを使用している場合は、最初にテスト環境や開発環境などでこのアップグレードプロセスのテストを行うことをお勧めします。

CentOS/RHEL: PHP 7.xとApache 2.4のインストール

CentOSとRHELにはデフォルトでPHP 7.xとApache 2.4がインストールされていないため、Swarmをアップグレードする前にシステムをアップグレードする必要があります。 このプロセスを実行する必要があるのは、初めてPHP 7.xにアップグレードする場合だけです。

Swarmマシン上でRedisの設定を行う

Swarmでは、Redisを使用してキャッシュを管理する必要があります。デフォルト設定の場合、Swarmは、Swarmマシン上で専用のRedisサーバを使用します。 Swarmは、Helixサーバのデータをキャッシュすることにより、Swarmで実行される一般的な検索処理のパフォーマンスを改善し、Helixサーバに対する負荷を軽減します。 Redisは、Swarm Tarballに付属しています。

このセクションでは、Swarmマシン上でSwarm Redisサービスを設定する方法について説明します。 Swarm Redisサーバを使用する場合は、以下の構成ファイルのデフォルト値を変更しないでください。

SwarmのSWARM_ROOT/p4-bin/bin.linux26x86_64/ディレクトリには、以下に示す2つのRedisバイナリが保管されています。

• redis-server-swarm
• redis-cli-swarm

1. Redisキャッシュデータベースを設定し、/opt/perforce/etc/ディレクトリ内のredis-server.confファイルを開いて、以下の情報を入力します。

bind 127.0.0.1
port 7379
supervised auto
save ""
dir /opt/perforce/swarm/redis

デフォルト値:

ヒント
• 以下の設定は、redis-server.confファイルで定義されているデフォルト設定です。このファイルには、Swarm用のRedis構成に関する詳細情報が記述されています。
• 多数のユーザ、グループ、プロジェクトが存在するSwarmシステムの場合、メモリキャッシュを永続化すると、起動時間を短縮できる可能性があります。 メモリキャッシュを永続化するには、バックグラウンドでの保存機能を無効にして追加保存機能を有効にします。詳細については、redis-server.confファイルのコメントを参照してください。
• bind 127.0.0.1 - RedisサーバのIPアドレス(ループバックインタフェース)
• port 7379 - Redisサーバのポート番号
• supervised autoを指定すると、upstartまたはsystemdの使用状況が自動的に検出され、プロセスでスーパーバイザを使用する準備が整ったことが通知されます。
• 「save ""」を指定すると、バックグラウンドでの保存処理が無効になります(推奨)。
• dir /opt/perforce/swarm/redis - Redisキャッシュデータベースが保存されるディレクトリ
ヒント

Redisサーバの設定を変更する場合は、Laminas Redisアダプタ内で変更を行ってください。 Laminas Redisアダプタの詳細については、Laminas Redisアダプタのドキュメントを参照してください。

2. Swarmを開始する前にRedisキャッシュデータベースを実行する必要があります。そのため、Redisキャッシュデータベースを、システムの起動時に自動的に開始されるサービスとして設定することをお勧めします。

以下に示すサンプルスクリプトの動作は以下のようになります。

• このサンプルスクリプトにより、RedisサービスがPerforceユーザとして稼働します。
• このサンプルスクリプトでは、/opt/perforce/etc/redis-server.confディレクトリ内の構成ファイルが使用されます。
• このサンプルスクリプトは、/opt/perforce/swarm/p4-bin/bin.linux26x86_64/にデータベースサーバがインストールされていることを前提としています。

Redisをサービスとして設定するには、以下に示すいずれかのサンプルスクリプトを使用します。

UbuntuとCentOS/RHEL 7の場合: 以下の内容が記述されたスクリプトを追加してください。この内容は、 /etc/systemd/systemファイルに記述されています。

redis-server-swarm.service

 [Unit] Description=Redis Server for Swarm After=network.target [Service] ExecStart=/opt/perforce/swarm/p4-bin/bin.linux26x86_64/redis-server-swarm /opt/perforce/etc/redis-server.conf ExecStop=/opt/perforce/swarm/p4-bin/bin.linux26x86_64/redis-cli-swarm shutdown Restart=always RestartSec=10 StandardOutput=syslog StandardError=syslog SyslogIndentifier=redis User=perforce Group=perforce [Install] WantedBy=multi-user.target 

CentOS/RHEL 6の場合: 以下の内容が記述されたスクリプトを追加してください。この内容は、/etc/init.dファイルに記述されています。

redis-server-swarm.initd

 #!/bin/sh # # redis-server-swarm init file for starting up the redis daemon used by Helix Swarm # # chkconfig: - 20 80 # description: Starts and stops the redis daemon. # ### BEGIN INIT INFO # Provides: redis-server-swarm # Required-Start: $local_fs $remote_fs $network # Required-Stop: $local_fs $remote_fs $network # Short-Description: start and stop Redis server # Description: A persistent key-value database used by Helix Swarm. Should not clash with # any Redis server used by other products. ### END INIT INFO # Source function library. . /etc/rc.d/init.d/functions name="redis-server-swarm" exec="/opt/perforce/swarm/p4-bin/bin.linux26x86_64/$name" shut="/opt/perforce/swarm/p4-bin/bin.linux26x86_64/redis-cli-swarm" RUNDIR="/opt/perforce/swarm/redis" pidfile="$RUNDIR/redis.pid" REDIS_CONFIG="/opt/perforce/etc/redis-server.conf" PORT=`grep port $REDIS_CONFIG | cut -d " " -f 2` lockfile="$RUNDIR/redis.lock" if [ ! -d "$RUNDIR" ] then mkdir -p "$RUNDIR" chown perforce:perforce "$RUNDIR" chmod 750 "$RUNDIR" fi start() { [ -f $REDIS_CONFIG ] || exit 6 [ -x $exec ] || exit 5 echo -n $"Starting $name: " daemon --user perforce "$exec $REDIS_CONFIG --daemonize yes --pidfile $pidfile" retval=$? echo [ $retval -eq 0 ] && touch $lockfile return $retval } stop() { echo -n $"Stopping $name: " [ -x $shut ] && $shut -p $PORT shutdown retval=$? if [ -f $pidfile ] then # shutdown haven't work, try old way killproc -p $pidfile $name retval=$? else success "$name shutdown" fi echo [ $retval -eq 0 ] && rm -f $lockfile return $retval } restart() { stop start } rh_status() { status -p $pidfile $name } rh_status_q() { rh_status >/dev/null 2>&1 } case "$1" in start) rh_status_q && exit 0 $1 ;; stop) echo stop rh_status_q || exit 0 $1 ;; restart) $1 ;; status) rh_status ;; condrestart|try-restart) rh_status_q || exit 0 restart ;; reload|force-reload) exit 3 ;; *) echo $"Usage: $0 {start|stop|status|restart|condrestart|try-restart}" exit 2 esac exit $?

3. SWARM_ROOT/data/config.phpファイルが存在しない場合は、新しく作成します。 SWARM_ROOT/data/config.phpファイルのredisブロックには、Swarm Redisサーバのpassword、namespace、host、portに関する情報が記述されています。

<?php
    // this block should be a peer of 'p4'
    'redis' => array(
        'options' => array(
            'password' => null, // Defaults to null
            'namespace' => 'Swarm',
            'server' => array(
                'host' => 'localhost', // Defaults to 'localhost' or enter your Redis server hostname
                'port' => '7379', // Defaults to '7379 or enter your Redis server port
            ),            
        ),
        'items_batch_size' => 100000,
        'check_integrity' => '03:00', // Defaults to '03:00' Use one of the following two formats: 
                                      // 1) The time of day that the integrity check starts each day. Set in 24 hour format with leading zeros and a : separator
                                      // 2) The number of seconds between each integrity check. Set as a positive integer. Specify '0' to disable the integrity check.
        'population_lock_timeout' => 300, // Timeout for initial cache population. Defaults to 300 seconds. 
    ),

構成可能変数:

• password: Redisサーバのパスワード。 デフォルト値はnullです。Swarm Redisサーバを使用する場合は、デフォルト値のままにしておく必要があります。
• namespaceには、Redisキャッシュのキー値で使用されるプレフィックスを指定します。 デフォルト値はSwarmです。Swarm Redisサーバを使用する場合は、デフォルト値のままにしておく必要があります。
注意

1つのRedisサーバに対して複数のSwarmインスタンスが稼働している場合、各Swarmサーバで異なるRedis名前空間を使用する必要があります。 これにより、個別のSwarmインスタンスのキャッシュデータを識別できるようになります。 名前空間の長さは128文字以内に制限されています。

1つ以上のSwarmインスタンスが複数のHelixサーバに接続されている場合、Redisの名前空間にはserver labelが含められるため、名前空間の長さが127文字以内に制限されます。詳細については、「複数のHelixサーバインスタンス」を参照してください。

• host: Redisサーバのホスト名。 デフォルト値はlocalhostです。Swarm Redisサーバを使用する場合は、デフォルト値のままにしておく必要があります。
• port: Redisサーバのポート番号。 デフォルト値は「7379」です。 ネットワーク上の他のRedisサーバとの競合を避けるため、Swarmではポート7379がデフォルトのポートとして使用されます。 Swarm Redisサーバを使用する場合は、デフォルト値のままにしておく必要があります。 Swarm Redisサーバ以外のサーバについては、ポート6379がデフォルトのポートとして使用されます。
• items_batch_sizeには、Redisに対するmset呼び出しで許可されるキーと値のペアの最大数を指定します。 この最大数を超えた場合は、処理効率を考慮して一括処理されます。 デフォルト値は「100000」です。
注意

この「100000」というデフォルト値は、処理効率とプロジェクトデータの複雑度のバランスを考慮して決定された値です。 通常、このデフォルト値を変更する必要はありませんが、変更する必要がある場合は、事前にサポートチームに連絡してください。

• check_integrity: Swarmが停止している状態でHelixサーバで変更を行った場合や、更新中にエラーが発生した場合など、特定の状況において、RedisキャッシュがHelixサーバと同期されていない状態になることがあります。 Swarmでは、通常の整合性チェックを実行して、RedisキャッシュとHelixサーバが同期されているかどうかを確認することができます。 整合性チェックで同期されていないキャッシュファイルが見つかった場合は、Swarmにより、そのキャッシュ内のデータが自動的に更新されます。

check_integrity構成可能変数を使用して、Redisキャッシュの整合性チェックを実行するタイミングを指定することができます。 一日のうちの特定の時間を指定することも(24時間形式で指定、1桁の時間の場合は先頭にゼロを付加)、チェック処理の実行間隔を秒数(正の整数)で指定することもできます。 整合性チェックを無効にする場合は、値として「0」を設定します。 デフォルト値は「03:00」です。

• population_lock_timeout: キャッシュに初めてデータを取り込む際のタイムアウトを秒単位で指定します。 Swarmシステムの規模が大きいために、キャッシュへのデータ取り込みがタイムアウトになった場合は、このタイムアウト時間の値を増やしてください。 デフォルト値は300秒です。

これで、Swarmマシンに対してSwarm Redisサービスが設定されました。次に、Swarmのアップグレードを行います。詳細については、「Swarmのアップグレード」を参照してください。

Swarmのアップグレード

このセクションでは、付属のアーカイブファイルを使用してSwarmをアップグレードする手順について説明します。 SWARM_ROOTは、Swarmの現在のインストール場所を表しています。

1. 新しいTARファイルをhttps://www.perforce.com/downloads/helix-swarmからダウンロードします。

2. 以下のコマンドを実行して、新しいswarm.tgzを展開します。

    $ tar -zxf swarm.tgz
   

   swarm.tgzの内容が、swarm-versionという名前の最上位フォルダに展開されます。versionは、ダウンロードされたバージョンです。 このディレクトリは、下記の例ではSWARM_NEWに置き換えられています。

3. SWARM_NEWを、SWARM_ROOTのピアになるように移動します。

   $ mv SWARM_NEW SWARM_ROOT/../

4. SWARM_ROOT/data/config.phpファイルをSWARM_ROOTからSWARM_NEWへコピーします。

    $ cp -p SWARM_ROOT/data/config.php SWARM_NEW/data/
   

5. キュートークンディレクトリを作成します。

    $  mkdir SWARM_NEW/data/queue

6. 既存のトリガトークンをコピーします。

    $ sudo cp -pR SWARM_ROOT/data/queue/tokens SWARM_NEW/data/queue/

7. 新しいSwarmのデータディレクトリに正しい所有権を割り当てます。

    $ sudo chown -R www-data SWARM_NEW/data  sudo chown -R
   

   注意

   上記のwww-dataユーザはWebサーバユーザ名の一例です。この名前はディストリビューションやカスタマイズに応じて異なります。 例えば、Red Hat/Fedora/CentOSのユーザは一般的にapache、Debian/Ubuntuのユーザはwww-data、SuSEのユーザはwwwrun、macOSのユーザは_wwwです。

トリガの更新

1. 新しいSwarmトリガスクリプトをHelix Coreサーバマシンにコピーします。 このトリガスクリプトは、SWARM_ROOT/p4-bin/scripts/swarm-trigger.plです。このスクリプトを使用するには、Helixサーバマシンにバージョン5.08以降のPerlをインストールする必要があります(最新バージョンをインストールすることをお勧めします)。 SwarmでSSLを使用している場合は、PerlモジュールのIO::Socket::SSLも必要になります。

   警告

   この時点で既存のトリガスクリプトを上書きしないでください。 スクリプトに新しい名前を付けます(swarm-trigger-new.plなど)。

2. Helixサーバマシン上の同じディレクトリ内にswarm-trigger.confというファイルを作成して、Swarmトリガスクリプトを設定します。 このスクリプトには以下を指定する必要があります。

   注意

   swarm-trigger.confファイルがすでに存在する場合は、追加の設定は不要です。

   # SWARM_HOST (required)
   # Hostname of your Swarm instance, with leading "http://" or "https://".
   SWARM_HOST="http://my-swarm-host"
   
   # SWARM_TOKEN (required)
   # The token used when talking to Swarm to offer some security. To obtain the
   # value, log in to Swarm as a super user and select 'About Swarm' to see the
   # token value.
   SWARM_TOKEN="MY-UUID-STYLE-TOKEN"
   
   # ADMIN_USER (optional) ワークフロー機能が有効になっている場合は使用しないでください(ワークフロー機能はデフォルトで有効になっています)
   # For enforcing reviewed changes, optionally specify the normal Perforce user
   # with admin privileges (to read keys); if not set, will use whatever Perforce
   # user is set in environment.
   ADMIN_USER=
   
   # ADMIN_TICKET_FILE (optional) ワークフロー機能が有効になっている場合は使用しないでください(ワークフロー機能はデフォルトで有効になっています)
   # For enforcing reviewed changes, optionally specify the location of the
   # p4tickets file if different from the default ($HOME/.p4tickets).
   # Ensure this user is a member of a group with an 'unlimited' or very long
   # timeout; then, manually login as this user from the Perforce server machine to
   # set the ticket.
   ADMIN_TICKET_FILE=				
   										
   # VERIFY_SSL (optional)
   # If HTTPS is being used on the Swarm web server, then this controls whether
   # the SSL certificate is validated or not. By default this is set to 1, which
   # means any SSL certificates must be valid. If the web server is using a self
   # signed certificate, then this must be set to 0.
   # set the ticket.
   VERIFY_SSL=1

   必須のSWARM_HOST変数とSWARM_TOKEN変数に、以前のSwarmトリガスクリプト(通常はswarm-trigger.pl)の設定を入力します。

   ヒント

   ADMIN_USER変数とADMIN_TICKET変数は、バージョン2019.1以前のSwarmの'enforce triggers'で使用されていました。 明示的にワークフローを無効にして、非推奨の'enforce triggers'を使用しない限り、これらの変数は削除してかまいません。

   注意

   バージョン2015.4以前のSwarmの場合: 以前のSwarmバージョンでは、Swarmのトリガスクリプトファイルをシェルスクリプトとして使用することができました (通常はswarm-trigger.sh)。

   Swarmでは、Perlトリガスクリプトファイル(通常はswarm-trigger.pl)を使用する必要があります。

3. Linuxの場合: 以下のコマンドを実行して、スクリプトが実行可能かどうかを確認します。

   $ sudo chmod +x swarm-trigger-new.pl

4. 新しいトリガスクリプトの名前を次のように変更します。

   Linuxの場合:

   $ mv swarm-trigger-new.pl swarm-trigger.pl

   Windowsの場合:

   C:\> ren swarm-trigger-new.pl swarm-trigger.pl

5. Helixサーバのトリガを更新します。

   警告

   • 「swarm.shelvedel shelve-delete」というトリガ行は、バージョン2018.1以降のSwarmで追加され、バージョン2020.1で更新された行です。

     • バージョン2017.4以前の Swarm をアップグレードする場合:「swarm.shelvedel shelve-delete」というトリガ行をHelixサーバのトリガテーブルに追加します(まだ追加されていない場合)。詳しくは、 Helixサーバのトリガテーブルを更新し、トリガスクリプトを実行します。を参照してください。
     • バージョン2018.xまたはバージョン2019.xの Swarm をアップグレードする場合: Helixサーバのトリガテーブル内の「swarm.shelvedel shelve-delete」というトリガ行を、アップグレード先バージョンのSwarmで指定されているトリガ行に置き換えます。

   • ワークフロー機能:

     バージョン2019.2以降のSwarmでは、ワークフロー機能がデフォルトで有効になっています。 ワークフロー機能を有効にするためのトリガ行は、ワークフロー機能を無効にするためのトリガ行とは異なります。

     • ワークフロー機能を有効にする(これがデフォルト設定です)
       • Helixサーバのトリガテーブルで、次のトリガ行をコメント化します(これらのトリガ行が記述されている場合): swarm.enforce.1、swarm.enforce.2、swarm.strict.1、swarm.strict.2。詳細については、「 Helixサーバのトリガテーブルを更新し、トリガスクリプトを実行します。」を参照してください。
       • 次のトリガ行をHelixサーバのトリガテーブルに追加します(これらのトリガ行がまだ追加されていない場合): swarm.enforce change-submit、swarm.strict change-content、swarm.shelvesub shelve-submit。詳細については、「 Helixサーバのトリガテーブルを更新し、トリガスクリプトを実行します。」を参照してください。
     • ワークフロー機能を無効:

       Helixサーバのトリガテーブルで、次のトリガ行をコメント化します(これらのトリガ行が記述されている場合): swarm.enforce change-submit、swarm.strict change-content、swarm.shelvesub shelve-submit。詳細については、「 Helixサーバのトリガテーブルを更新し、トリガスクリプトを実行します。」を参照してください。

   1. Swarmトリガスクリプトを実行して、Perforceトリガテーブルに含める必要があるトリガ行をキャプチャします(WindowsとLinuxの場合はCtrl+Cキーを、macOSの場合はCommand+Cキーを使用します)。

      Linuxの場合:

      $ ./swarm-trigger.pl -o

      Windowsの場合:

      C:\> path/to/perl swarm-trigger.pl -o

   2. super 権限を持つPerforceユーザとしてp4 triggersコマンドを実行し、前述の手順でキャプチャしたすべてのswarm.*行を置き換えます(WindowsとLinuxの場合はCtrl+Vキーを、macOSの場合はCommand+Vキーを使用します)。これによって、Perforceトリガテーブルは更新されます。
   重要

   各種のトリガオプションを適用するなどの目的でSwarmのトリガ行がカスタマイズされている場合は、更新後のトリガ行でも同じカスタマイズ作業を繰り返してください。

古いSwarmインスタンスを新しいSwarmインスタンスで置き換える

以下のコマンドを実行して、古いSwarmを新しいSwarmに置き換えます。 この手順ではダウンタイムが生じます。

$ sudo apache2ctl stop; mv SWARM_ROOT SWARM.old; mv SWARM_NEW SWARM_ROOT; sudo apache2ctl start

Swarm構成キャッシュの削除

Swarm構成キャッシュを削除すると、アップグレード後のSwarmで、新しいモジュールと更新されたモジュールが強制的に使用されるようになります。 Swarm構成キャッシュを削除するには、admin ユーザとして、以下のcurl要求を実行します。

curl -u "username:password" -X DELETE "https://myswarm.url/api/v10/cache/config/"

構成キャッシュの詳しい削除方法については、「Swarm構成キャッシュファイルの削除(v9以降)」を参照してください。

アップグレードの確認

新しいSwarmインスタンスが正しく稼働するかどうかを確認するには、以下の手順を実行します。

1. 以下のチェンジリストを新しく作成します。
   1. 変更されたファイルが1つ以上含まれているチェンジリスト
   2. チェンジリストの説明に#reviewキーワードが含まれているチェンジリスト
2. 作成したチェンジリストをP4Vで右クリックし、[ファイルを保留...]をクリックします。
重要

[新しいSwarmレビューを要求...]を選択しないでください。これを選択するとAPIが使用されるため、Swarmトリガのテストが完全には実行されません。

3. チェンジリストに対して新しいSwarmレビューが作成されたことを確認します。
• Swarmレビューが作成されている場合は、Swarmトリガが機能します。
• Swarmレビューが作成されていない場合は、以下の説明を参照してください。

Swarmインデックスのアップグレード

バージョン2017.2以前のSwarmをアップグレードする場合は、インデックスをアップグレードする必要があります。これにより、[ダッシュボード]ページと[レビューリスト]ページで、レビューに対するアクティビティの履歴が正しい順序で表示されるようになります。

インデックスのアップグレードプロセスは、Swarmシステムの仕様に合わせて設定することができます。 詳細については、「インデックスのアップグレード」を参照してください。

以下のURLにアクセスし、admin 権限を持つユーザとしてアップグレードを実行してください。

http://SWARM-HOST/upgrade

操作はこれで完了です。