Perforce Helix Core を AWS 上に構築する (Part2)

イントロダクション

前回の記事では AWS 上で Perforce Helix Core を構築することの利点を説明し、実際の構成パターンと構築における注意点を解説しました。

本記事では、実際に Perforce Helix Core をAWS に構築する手順をご紹介します。手順といっても AWS CloudFormation テンプレートを用意しておりますので、大部分は自動化されています。AWS CloudFormation では、設定をjsonやyamlでファイルに記述するだけでAWS のリソースのプロビジョニングを自動化することができます。

今回作成するサーバー構成の全体像は下図のようになります。AWS Cloudと書かれた中にあるサーバ群を設定します。デフォルトは Perforce の Master Server だけを構築する設定になっていますが、手順の中で Read only の Replica server を設定することも可能です。今回はインターネットから直接アクセスできるPublic Subnetにサーバーを配置していますが、Private Subnetにサーバーを配置して、VPNや AWS Direct Connect を介してオフィスやデータセンタのみからアクセスできる閉域にすることも可能です。

本記事では、まずは Perforce の Master server を構築する手順を見ていきます。次の Part3 の記事で、Replica server の構築手順を紹介します。Replica server の設定では、いくつか手動でコマンドを実行していただく必要があります。

なお、今回構築する Perforce Server への接続には SSL を使用しない構成になっています。通信は暗号化されていませんので、オフィスなどの外部から Perforce Server への接続においては、テスト用のファイルだけをコミットするにとどめて、くれぐれも機密情報などをコミットするようなことはしないようにお願いします。(別途VPNやAWS Direct ConnectなどでAWSクラウドと通信すると安全性は保たれます。)

事前準備

事前に EC2 インスタンスに ssh するための Key Pair をこちらを参考にして作成しておいてください。

Perforce Serverを構築する

先ほど述べた通り、必要なリソースを作成するための AWS CloudFormation テンプレートを用意しましたので、それを実行し、必要に応じて残りの設定をコマンドラインで実行します。

1. AWSコンソールにサインインして、下記の [Launch Stack] をクリックします。これによって、お使いの AWS アカウントで CloudFormation スタックが起動されます。このスタックはデフォルトで ap-northeast-1 (東京) リージョンで起動されます。他のリージョンで実行したい場合は、コンソール画面右上のプルダウンメニューから適宜リージョンを変更してください。

2. 次へをクリックすると、パラメータ指定の画面に遷移します。このスタックに名前をつけるために、スタックの名前を入力します。スタックの名前はデフォルトで「AWSPerforceTest」としていますが、識別できればスタック名はなんでも構いません。

3. 次に各種パラメータの設定をします。「VPC Network Configuration」の「Permitted IP range」では、Perforce Serverへのアクセス元を限定する設定を行います。例えば、オフィスからのIPアドレスのみサーバーへのアクセスを許可する場合は、オフィスのパブリックIPをCIDR形式(x.x.x.x/x)で記載します。デフォルトは、全てのIPアドレスを許可する0.0.0.0/0の設定になっていますが、セキュリティ上IPアドレスが限定できる場合は、なるべく設定することが推奨されます。

4. 「Perforce Server Configuration」は、Perforce ServerのEC2インスタンスタイプを指定できます。本番稼働での利用は c5.4xlarge をデフォルトで推奨しています。ただし、今回はテスト用途で利用する場合にはコストがかかるため、時間単価が安価な[t3.nano]や[t3.micro]を選択します。t3ファミリーはテスト環境での利用を意図しているインスタンスですので、本番環境では利用しないでください。

5. Key Pair NameでインスタンスにログインするためのSSH Keyを選択します。SSH keyを事前に作成していない場合は、こちらを参考にして作成してください。

6. さらにパラメータ画面を下にスクロールしていくと、サーバーに設定するEBS volumeの設定が出てきますが、そちらは何もせずにデフォルトのままにしておきます。ただし、一部大きめのVolume Sizeを指定しているところがあるので、コストとの兼ね合いから小さい数字を設定することも可能です。(例えば、Depot では st1 の最低のボリュームサイズである 500GiB、それ以外は 8 GiBもストレージ容量を確保すればテスト用途としては十分でしょう。)

7. 「Enable Replica」と書かれた設定値は、Perforce の Replica Server を作成するかどうかを尋ねています。デフォルトは“No”になっており、Perforce Master Server のみを構築する設定になっています。もし、Replica の構築も必要な場合は、この設定をプルダウンから“Yes”に変更します。(Replica の構築手順は、ブログのPart3で説明します。)

8. 「AWS CloudFormation Template Source Configuration」の設定は、デフォルトのままで変更する必要はありません。(CloudFormation テンプレートを自分で作成した独自のS3バケットから実行する場合には、ここを設定します)

9. 次へをクリックすると「スタックオプションの設定」の画面に遷移。ここでは特に設定の必要はありません。(必要に応じてタグ等つけてください。)

10. さらに次へをクリックするとレビュー画面に遷移して、問題なければ次へをクリック。

11. 一番下までスクロールすると、「機能」の部分にチェックボックスがありますので、全てのチェックボックスにチェックを入れます。忘れずに全てのチェックボックスにチェックを入れてください。「スタックの作成」を実行すると構築が開始して、5分くらい待つと完了予定です。CREATE_COMPLETEが表示されたら構築完了です。

12. CREATE_COMPLETEが表示されたら、CloudFormationルートスタックの詳細画面の「出力」タブを開きます。ルートスタックとは、今回の手順では「AWSPerforceTest」と書かれているスタックのことです(「ネストされた」と書かれていない物)。出力タブのPerforceMasterEIPに、Global IPが記載されているので、これを用いてサーバーインスタンスにsshやその他のTCPアクセスが可能です。この場合の Master Server の Global IP は、18.180.250.162 となります (下の図参照)。Replica Serverも構築した場合は、PerforceReplicaEIP に ReplicaのGlobal IP が記載されています。

13. 構築したサーバーにsshでログインしてみましょう。ログインユーザーは、p4adminというユーザーが作成されていますのでそちらを使います。(ec2-userでもログイン可能です。) ターミナルを開いて、下記のコマンドを実行します。

下記では適宜、[your-ssh-key.pem]の部分を自分のssh keyに、[18.180.250.162]の部分を上記「PerforceMasterEIP」で表示された自分のEIPアドレスに置き換えてください。

$ ssh -i ~/.ssh/[your-ssh-key.pem] p4admin@18.180.250.162

14. サーバーへのログインに成功したらPerforceクライアントのp4コマンドを実行してみましょう。p4 -p localhost:1666 infoを実行して下記の情報が表示されればサーバーの構築は成功です。

$ p4 -p localhost:1666 info
User name: p4admin
Client name: ip-10-0-0-63
Client host: ip-10-0-0-63.ap-northeast-1.compute.internal
Client unknown.
Current directory: /home/p4admin
Peer address: 127.0.0.1:38606
Client address: 127.0.0.1
Server date: 2020/04/23 10:19:02 +0000 UTC
Server version: P4D/LINUX26X86_64/2019.2/1942501 (2020/04/02)
ServerID: master.1
Server services: standard
Server license: none
Case Handling: insensitive

15. Unreal Engine 4 (UE4) のコードを管理する場合は下記の設定を行います(ここからはオプションです)。typemapの設定を下記のコマンドで実行します。

詳細はこちらのPerforce Documentに記載

$  p4 -p localhost:1666 -u perforce typemap

16. コマンドを実行するとviが起動するので、そのままテキストを修正します。コマンド「i」でテキスト挿入モードに移行してテキスト編集をします。下記の設定値を「TypeMap:」と書かれた位置から下の行にコピー & ペーストします。コピーしたら、[esc]を押してコマンドモードに戻り、「:wq」で上書き保存します。

# viで開いたファイルの内容に下記の設定項目を追加
TypeMap:
  binary+w //depot/....exe
  binary+w //depot/....dll
  binary+w //depot/....lib
  binary+w //depot/....app
  binary+w //depot/....dylib
  binary+w //depot/....stub
  binary+w //depot/....ipa
  binary //depot/....bmp
  text //depot/....ini
  text //depot/....config
  text //depot/....cpp
  text //depot/....h
  text //depot/....c
  text //depot/....cs
  text //depot/....m
  text //depot/....mm
  text //depot/....py
  binary+l //depot/....uasset
  binary+l //depot/....umap
  binary+l //depot/....upk
  binary+l //depot/....udk
  binary+l //depot/....ubulk

ファイルのコミットテストをする

ここからは、そのままMaster Serverにssh接続したまま、コンソール画面上からPerforceへファイルのコミットテストをしてみましょう。

1. 毎回接続先とポート番号を指定するのは大変ですので、接続先を環境変数として設定します。

$ echo 'export P4PORT=localhost:1666' >> ~/.bash_profile
$ source ~/.bash_profile

2. p4adminユーザーをサーバー側に作成します。viが起動しますので内容を確認して、「:wq」をタイプして保存します。

$ p4 user p4admin
User p4admin saved.

3. サーバー側にディポを作成します。ディポの名前は任意で決められますが、ここではrepositoryとしています。viが起動しますので内容を確認して、「:wq」をタイプして保存します。

$ p4 depot repository
Depot repository saved.

4. クライアントのワークスペースを作成します。/home/p4adminに移動して、下記コマンドを実行するとviが起動してconfigの記載内容が表示されます。この時RootとViewの設定を確認します。下記のようにRoot: /home/p4adminになっていれば問題ありません。もし違っていれば、下記の情報を参考にして修正してください。また、Viewの項目は、最低限「//repository/… //p4admin/repository/…」という項目があるようにしてください。それ以外が表示されている分には問題ありません。([esc]を押してコマンドモードに戻ります。) 他に問題なければ「:wq」してviを終了します。これによりクライアントのワークスペースがDepotに作成されます。

$ cd /home/p4admin
$ p4 client p4admin
Client p4admin saved.

# viで開いたファイルの内容で下記の設定項目を確認
# ここが正しく設定されてないと今後のp4コマンドやコミットがうまく動作しない
Root: /home/p4admin
View:
  //spec/... //p4admin/spec/...
  //repository/... //p4admin/repository/...
  //depot/... //p4admin/depot/...

5. これ以降、/home/p4admin/repositoryで作業することになります。テスト用に~/repository/test.configというファイルを作成してサーバーインスタンス内でコミットのテストを実行します。

$ mkdir -p ~/repository
$ cd repository/
$ echo test > test.config

6. 下記のコマンドで、チェンジリストにファイルを追加します。

$ p4 -c p4admin add -t text test.config
//repository/test.config#1 - opened for add

7. 下記のコマンドでディポに変更をsubmitします。コマンドを実行するとviが開くので「Description:」の部分に任意の変更理由を記述します。これで一連のコードのコミット処理をテストできました。

$ p4 -c p4admin submit
Change 1 created with 1 open file(s).
Submitting change 1.
Locking 1 files ...
add //repository/test.config#1
Change 1 submitted.

# viが開いたら、変更内容を記載。記載したら「:wq」で変更を保存してviを閉じる。
# 変更内容を記載
Description:
add new file
Files:
//repository/test.config # add

[オプション]ローカルのMacやWindows PCにp4クライアントのインストール

1. p4クライアントのインストール方法は、こちらのURLを参照してください。

2. ローカルにあるPCからp4コマンドを実行してサーバーに接続できるか確認してみます。適宜、IPアドレスは各自の環境に読み替えてください。

オフィスから Perforce Server へアクセスする場合は、Port: 1666 が空いている必要があります。オフィスネットワーク側が Port: 1666 の通信を許可しているかもう一度ご確認ください。
AWS クラウドへの接続に VPN や AWS Direct Connect 等を利用していない場合、オフィスから AWS への接続はインターネットを介して接続されます。今回の手順では Perforce への接続は SSL を有効にしていないため、通信は暗号化されていません。コミットするデータには機密情報等を含まないようにお願いします。

$ p4 -p 18.180.250.162:1666 info
User name: john
Client name: xxxxxxxxxx
Client host: xxxxxxxxxx.sample.com
Client unknown.
Current directory: /Users/john/work
Peer address: xxx.xxx.xx.xx:63559
Client address: xxx.xxx.xx.xx
Server date: 2020/03/03 08:47:02 +0000 UTC
Server version: P4D/LINUX26X86_64/2019.2/1918134 (2020/02/12)
ServerID: master.1
Server services: standard
Server license: none
Case Handling: insensitive

まとめ

本記事では、PerforceのMaster Serverの構築方法を説明しました。

Perforceのテスト構築においてはMaster Serverの構築だけでも十分ですが、本番環境で利用する際にはMasterとReplicaを別々のAvailability Zoneに配置して可用性を高めることがAWSのベストプラクティスとなります。

次回は、CloudFormation テンプレートの設定でReplicaの構築を有効にした場合に、Replica構築のための残りの手順を紹介します。Replica構築においては、Master側の現時点のチェックポイントをReplica側に反映させて構築するためいくつか手動の作業が発生します。

本日ご紹介したAWS CloudFormation テンプレートのソースコードはこちらからご覧いただけます。

著者について

保里善太 (Zenta Hori)
AWS 技術統括本部ソリューションアーキテクト

半導体関連精密機器の組み込み制御エンジニアとして研究開発のキャリアをスタートさせ、モバイルゲーム業界での開発経験、FinTech 業界でのエンジニア経験、スタートアップでの CTO 経験を生かして日々技術支援を必要としている AWS ユーザー様をサポートしています。現在はもっぱら機械学習を利用したセキュリティリスクの自動検知や機械学習をゲーム開発にどう活用するかに興味関心があり、日々研究や学習に励んでいます。

Amazon Web Services ブログ