Swarmインスタンスの移動

このセクションでは、Swarmインスタンスを別のサーバに移動する方法について説明します。Swarmを別のサーバに移動してパフォーマンスを改善する場合や、新しいバージョンのオペレーティングシステムでSwarmを実行する場合は、このセクションで説明する方法を使用すると便利です。SwarmデータはSwarmではなくHelix Coreサーバに保存されるため、新しいSwarmインスタンスにデータを移行する必要はありません。

注意

元のSwarmインスタンスよりも新しいバージョンのSwarmをインストールする際に、元のバージョンのSwarmに設定オプションが存在しない場合は、それらのオプションを指定しなければならないことがあります。

例えば、Swarmワークフロー、更新後のトリガスクリプト、Redisキャッシュの導入、カスタムモジュールの変更などに関するオプションです。Swarmに対する重要な変更については、「Swarm 最新情報」ページの「重要な情報」セクションを参照してください。

サマリ

ここでは、Swarmのインストール環境を別のサーバに移動するための手順をまとめます。

  1. 新しいサーバにSwarmをインストールします。

  2. 元のSwarm config.phpファイルと認証トークン新しいSwarmインスタンスにコピーします。

  3. SwarmトリガスクリプトをHelixサーバマシンにコピーし、swarm-trigger.confファイルを新しいSwarmインスタンスにインストールします。

  4. 元のSwarmインスタンスをシャットダウンし、新しいSwarmインスタンスを起動します。

    5. 警告

    この手順では、ダウンタイムが発生します。

  5. 新しいSwarmインスタンスが正しく稼働しているかどうかを確認します。

Swarmインスタンスを移動するための詳しい手順については、「Swarmの移動」を参照してください。

Swarmの移動

Swarmのインストール環境を新しいサーバに移動するとダウンタイムが発生しますが、ここで説明する手順を実行すると、ダウンタイムを最小限に抑えることができます。

新しいサーバにSwarmをインストールする

以下に示すいずれかの方法でSwarmをインストールしてください(可能であれば、パッケージを使用してインストールすることをお勧めします)。

既存のSwarm構成情報をコピーする

  1. 元のSWARM_ROOT/data/config.phpファイルを新しいSwarmインスタンスにコピーします。

  2. 新しいSwarmインスタンス上でキュートークンディレクトリを作成します。

    mkdir SWARM_ROOT/data/queue

  3. 元のトリガトークンをSWARM_ROOT/data/queue/tokensから新しいSwarmインスタンスにコピーします。

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

    sudo chown -R www-data SWARM_ROOT/data
    注意

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

  5. 次のタスクに進みます(「トリガの更新」を参照)。

トリガの更新

操作を開始する前に

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のアップグレードの「トリガの更新」セクションを参照してください。

トリガの更新

  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では、ワークフロー機能がデフォルトで有効になっています。ワークフロー機能を有効にするためのトリガ行は、ワークフロー機能を無効にするためのトリガ行とは異なります。

    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のトリガ行がカスタマイズされている場合は、更新後のトリガ行でも同じカスタマイズ作業を繰り返してください。

  1. 次のタスクに進みます(「元のSwarmインスタンスを新しいインスタンスで置き換える」を参照)。

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

警告

この手順ではダウンタイムが生じます。

元のSwarmインスタンスを新しいインスタンスで置き換えます。

  1. 元のSwarmインスタンスを停止します。

    2. sudo apache2ctl stop

  2. 新しいSwarmインスタンスを起動します。

    3. sudo apache2ctl start

    注意

    Swarm起動時に以下のエラーメッセージが表示される場合は、Swarmが使用しているP4PHPのバージョンが正しくありません。最新バージョンのP4PHPはSwarmに付属しています。

    tarballからSwarmをインストールする場合は、最新バージョンのP4PHPを使用するようにSwarmを設定する必要があります。P4PHPの新しいバージョンを使用するようSwarmを設定する手順については、「PHP構成」を参照してください。

    P4PHPバージョンのエラーメッセージの画像

  3. 次のタスクに進みます(「新しいSwarmインスタンスの検証」を参照)。

新しいSwarmインスタンスの検証

ヒント

Swarmを起動すると、Redisキャッシュの確認処理が実行されます。この確認処理の実行中は、Swarmにログインすることはできません。Redisキャッシュの確認処理にかかる時間は、Swarm上のユーザ数、グループ数、プロジェクト数によって異なります。メモリキャッシュを永続化すると、Swarmが起動するまでの時間を短縮することができます。メモリキャッシュを永続化するには、バックグラウンドでの保存機能を無効にして追加保存機能を有効にします(これらの設定は、redis-server.confファイルで行います)。詳しくは、「Redisサーバ構成ファイル」を参照してください。

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

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

    3. 重要

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

  3. チェンジリストに対して新しいSwarmレビューが作成されたことを確認します。
    • Swarmレビューが作成されている場合は、Swarmトリガが機能します。
    • Swarmレビューが作成されていない場合は、以下の説明を参照してください。
注意
  • アップグレード環境の確認時に新しいSwarmレビューが作成されていない場合は、一部のSwarmトリガがHelixサーバにインストールされていない可能性があります。新しいトリガが定期的にSwarmに追加されるため、アップグレードを行う場合はこれらのトリガをインストールする必要があります。詳しくは、上記の「トリガの更新」セクションを参照してください。HelixサーバでSwarmトリガを設定する方法については、「Swarm用のHelix Coreサーバの構成」を参照してください。

  1. 以下のいずれかを実行します。

    • 新しいSwarmインスタンスが正常に稼働している場合: 元のSwarmインスタンスを無効にします。

    • 新しいSwarmインスタンスが正常に稼働していない場合: 新しいSwarmインスタンスをシャットダウンし、Helixサーバ上のトリガに対する変更内容をすべて削除し、元のSwarmインスタンスに切り替えます。次に、新しいSwarmインスタンスの構成と接続を確認します。問題が見つからない場合は、サポートリクエストを提出してください。