Perforce P4 / P4 DAMをAWS上にDockerで構築してみた
こんにちは、ゲームソリューション部のsoraです。
今回は、Perforceのデジタルアセット管理サービスであるP4 DAMを、無料枠の範囲でAWS上にDockerで構築して触ってみました。
SaaS版のトライアル環境で触ってみた記事は以下にあります。
セルフホストの構築方法
セルフホストでP4 / P4 DAMを構築する方法はいくつかパターンがあります。
- Server Deployment Package (SDP)を使う
- Perforce社が公式に提供する本番運用向けのデプロイパッケージで、推奨される構築方法
- ディレクトリレイアウト・運用スクリプト・バックアップ・レプリケーションなど、本番運用のベストプラクティスがまとまっている
- https://swarm.workshop.perforce.com/view/guest/perforce_software/sdp/dev/doc/SDP_Guide.Unix.html
- 公式のDocker Composeリポジトリを使う
- P4 DAM公式リポジトリに、P4 DAMとその依存サービス一式を起動するDocker Compose構成が用意されている
- ただしP4本体(p4d)はDocker Composeには含まれておらず、すでに稼働している前提で組まれている
- https://github.com/perforce/p4dam
- https://help.perforce.com/helix-core/helix-dam/current/Content/HTH-Admin/DAM/install-p4dam-docker.html
今回は後者のDocker Compose構成をベースに、AWS側はTerraformで全自動構築する形にしました。
P4側もDockerで動かすために、p4d用のコンテナイメージを自前で組んで立てています。
構成
今回構築した構成は以下です。
P4 DAMとP4を別EC2に分離しています。
- P4 DAM用EC2はCloudFront(HTTPS 443)経由
- P4用EC2はインターネット向けNLB(TCP 1666)経由
- P4プロトコルはHTTPではないのでNLBを使用
構築はTerraformで行い、EC2のブートストラップまで含めて起動できる状態にしました。
ただし、本記事ではTerraformのコード部分の説明は割愛して、P4 / P4 DAMの構築で使ったDockerイメージとEC2のユーザーデータで実行したコマンドの中身をメインに記載します。
構築 - P4
P4用EC2のユーザーデータで実行している処理を抜粋して説明します。
Dockerでp4dを動かす
今回はP4のサーバプロセスであるp4dをDockerコンテナで動かしました。
ベースイメージはamazonlinux:2023で、Perforce公式のバイナリ配布元ftp.perforce.comからp4d / p4を取得してインストールしています。
FROM amazonlinux:2023
RUN dnf install -y shadow-utils openssl ca-certificates && dnf clean all
RUN curl -fsSL -o /usr/local/bin/p4d https://ftp.perforce.com/perforce/r26.1/bin.linux26x86_64/p4d && \
curl -fsSL -o /usr/local/bin/p4 https://ftp.perforce.com/perforce/r26.1/bin.linux26x86_64/p4 && \
chmod 755 /usr/local/bin/p4d /usr/local/bin/p4
ENV P4ROOT=/data/p4root P4SSLDIR=/data/p4ssl P4PORT=ssl:1666 P4USER=super P4CHARSET=utf8
EXPOSE 1666
ENTRYPOINT ["/entrypoint.sh"]
データディレクトリはホストの/opt/p4d-dataをボリュームマウントして永続化します。
初回起動時のsuperユーザー作成
p4d 2024.1以降はsecurity / dm.user.noautocreate / run.users.authorizeなどのセキュリティ既定値が厳しくなっていて、新規DBの状態だとp4 user -iがユーザー0件でfailed authentication checkに弾かれます。
そのため、標準手順ではないですが、初回ブートストラップ時にこれらの設定を一時的に緩めてsuperを作成 → 厳格に戻す、という流れにしています。
設定値の詳細は以下の公式リファレンスを参照してください。
構築 - P4 DAM
P4 DAM側のユーザーデータは公式リポジトリperforce/p4damをクローンしてDocker Composeで起動する流れです。
Docker Compose一式とESイメージ
docker compose pullで取得するイメージは公式のものをそのまま使います。
おおまかには下記の構成です。
perforce/p4dam-nginx(リバースプロキシ + フロントエンド配信)perforce/p4dam-backend(Rails)perforce/p4dam-workers/scheduler/streamer/moonshine(各種ワーカー)anycable/anycable-go(WebSocket)perforce/p4search(検索)perforce/p4render(Blenderベースのプレビュー生成)mongo/redis(依存DB)elasticsearch
elasticsearchは、公式のDockerfileがpackage.perforce.comからhelix-plugin-filterプラグインを取得してインストールしてイメージをビルドする作りになっています。
今回はこの外部依存を減らすため、すでにperforce/p4searchイメージに同梱されているプラグインのzipを取り出して、それをそのままインストールする形にDockerfileを書き換えました。
# perforce/p4searchイメージから.zipを抜き出してビルドコンテキストに置く
docker run --rm --entrypoint cat perforce/p4search:r26.2 \
/opt/perforce/helix-p4search/lib/p4search-filter-8.19.14-2026.2.2953718.zip \
> elasticsearch/plugins/helix-plugin-filter.zip
# Dockerfileを書き換え
cat > elasticsearch/Dockerfile <<'EOF'
FROM docker.elastic.co/elasticsearch/elasticsearch:8.19.14
COPY --chown=elasticsearch:root plugins/helix-plugin-filter.zip /tmp/helix-plugin-filter.zip
RUN bin/elasticsearch-plugin install --batch file:///tmp/helix-plugin-filter.zip
EOF
なお、nginxはデフォルトでHTTP(80)からHTTPS(443)へのリダイレクト設定が入っています。
本来であればCloudFrontとオリジン間もHTTPSで通すべきところですが、そのためにはオリジン側(EC2のnginx)に有効な証明書を持たせる必要があります。
今回は検証用途のためCloudFrontとオリジン間はHTTPで通すことにし、nginx.confのrewrite行をコメントアウトしてHTTPSへのリダイレクトを無効化しました。
マルチホスト構成でのindexer設定
P4とP4 DAMを別EC2に分離していると、P4にインストールされるhelix-core-search-indexer extensionが参照するp4searchのURL / Token / TenantIDが自動でセットされません。
そのままだとサブミットを検知してもESに何もインデックスされないので、ユーザーデータでp4 propertyに手動でセットしています。
あわせて、P4 DAM側EC2のセキュリティグループでVPC内からの1601/TCPを開放しています。
初期セットアップ
最後に、backendコンテナ上で初期セットアップタスクとマイグレーションを流します。
docker compose exec -T backend bin/rails hth:first_time_dam_setup
docker compose exec -T backend bin/rails hth:migrations:all
hth:first_time_dam_setupが会社ID(dam) / superユーザー / 初期パスワードなどをセットアップしてくれます。
動作確認
CloudFront経由でログイン
ブラウザでCloudFrontのドメイン(独自ドメイン)にアクセスすると、P4 DAMのログイン画面が出ます。
WAFで許可IP以外は403になるようにしています。
会社ID dam、ユーザー super、構築時に発行されたsuperユーザーのパスワードでログインできました。
p4 CLIでP4に直接接続
P4はNLB経由でインターネットから直接p4 CLIで叩けます。
ローカルMacからは、Perforceポータルからp4バイナリをダウンロードして/usr/local/bin/に置けば使えます。
$ export P4PORT=ssl:p4.example.com:1666
$ export P4USER=super
$ export P4CHARSET=utf8
$ p4 trust -y
The fingerprint of the server of your P4PORT setting
'ssl:p4.example.com:1666' is not known.
That fingerprint is 65:3F:93:0B:03:A8:5E:1B:EE:8E:13:35:95:0B:7E:E6:A1:17:FA:93
Added trust for P4PORT 'ssl:p4.example.com:1666'
$ p4 login
Enter password:
User super logged in.
$ p4 info
User name: super
Server version: P4D/LINUX26X86_64/2026.1/2951233 (2026/05/19)
Server encryption: encrypted
ServerID: master
Server services: commit-server
ちなみにインターネット向けNLBは2AZで2つのIPを持ち、p4 trustはIP単位で信頼を登録するので、必要に応じて両方信頼させてください。
p4 depotsやp4 changesでも、デポやチェンジリストの確認ができます。
$ p4 depots
Depot depot 2026/05/22 local depot/... 'Default depot'
Depot spec 2026/05/22 spec spec/... 'Created by super. '
Depot test_stream 2026/05/22 stream test_stream/... 'Created by super. '
Depot unload 2026/05/22 unload unload/... 'Created by super. '
$ p4 changes -m 5
Change 4 on 2026/05/22 by super@hth-01fbd0e6... 'Edited 6 files'
Change 3 on 2026/05/22 by super@____CLIENT_UNSET____ 'Stream //test_stream/test/main'
Change 2 on 2026/05/22 by super@____CLIENT_UNSET____ 'Installing extension: hth-exten'
Change 1 on 2026/05/22 by super@____CLIENT_UNSET____ 'Installing Extension certificat'
アセットアップロードとP4側からの裏取り
P4 DAMのWeb UIで.glb(3Dモデル)を6個アップロードしました。
アップロード後、P4 CLI側から見ると、ちゃんとストリームデポにバージョン管理されて入っています。
$ p4 describe -s 4
Change 4 by super@hth-01fbd0e6... on 2026/05/22 08:46:41
Edited 6 files
Affected files ...
... //test_stream/test/mainline/assets/Avocado.glb#1 add
... //test_stream/test/mainline/assets/BoomBox.glb#1 add
... //test_stream/test/mainline/assets/DamagedHelmet.glb#1 add
... //test_stream/test/mainline/assets/Duck.glb#1 add
... //test_stream/test/mainline/assets/Fox.glb#1 add
... //test_stream/test/mainline/assets/Lantern.glb#1 add
hth-始まりのクライアントはP4 DAMが裏で作ったものです。
「P4 DAMはアセット管理のUI、ストレージとバージョン管理の実体はP4」という関係をP4側から確認できました。
ちなみに、一覧画面のプレビューサムネイルは生成されませんでした。
DAMライセンスが必要な機能のようで、無料枠では出ないようでした。
ファイル詳細画面のプレビュー
一覧サムネイルは出ませんでしたが、ファイルをクリックして詳細画面に行くと、.glb(3Dモデル)のプレビューが表示できました。
ロックの相互認識
P4 CLIからp4 edit → p4 lockでファイルをロックすると、P4 DAM側もロック状態を認識します。
$ p4 client -S //test_stream/test/mainline -o p4lock-test | p4 client -i
Client p4lock-test saved.
$ p4 sync //test_stream/test/mainline/assets/Duck.glb
//test_stream/test/mainline/assets/Duck.glb#1 - added as .../p4lock-test/assets/Duck.glb
$ p4 edit //test_stream/test/mainline/assets/Duck.glb
//test_stream/test/mainline/assets/Duck.glb#1 - opened for edit
$ p4 lock //test_stream/test/mainline/assets/Duck.glb
//test_stream/test/mainline/assets/Duck.glb - locking
$ p4 opened
//test_stream/test/mainline/assets/Duck.glb#1 - edit default change (binary) *locked*
この状態でP4 DAMのWeb UIから同じアセットに新バージョンをアップロードしようとすると、ロック中のため不可というエラーが出ます。
P4とP4 DAMでロック状態が共有されている、ということが確認できました。
コレクション(リポジトリ)の削除
P4 DAMで作成したコレクション(リポジトリ)は、P4 DAMのUI上では削除できず、Perforce TeamHub側の管理画面から削除する仕様です。
P4 DAMからGo To Perforce TeamHubでTeamHubへ進みます。
TeamHubにてプロジェクトやリポジトリが確認できます。
今回はtestリポジトリ(コレクション)の削除を試してみます。
P4 DAM側でも確認してみると、コレクションが無くなっていることが確認できました。
ただし、TeamHubから削除されるのはTeamHubのメタデータだけで、P4側のデポ / ストリーム / ファイルは残ります。
完全に消したい場合はP4 CLIでobliterateする必要があります。
今回はTeamHub UIで削除したあと、P4 CLI側で以下のように後片付けしました。
# 1. ストリームを参照するクライアントを削除
$ p4 client -d hth-xxxxxxx
# 2. ファイル本体を物理削除
$ p4 obliterate -y //test_stream/test/...
Deleted 18 revision record(s).
# 3. ストリームのspec削除
$ p4 stream -d //test_stream/test/mainline
# 4. ストリームのDBレコードも削除
$ p4 stream --obliterate -y //test_stream/test/mainline
逆順でP4側から先に消すと、P4 DAMのmy projects画面に該当プロジェクトが残ったままで、開くとOops! Something went wrong, please try again.のエラーが出ます。
ログアウト / ログインしても解消しません。
公式ドキュメントでは、プロジェクト・コレクションの削除はTeamHubで実施するもので、その操作はP4のデポ・ストリーム・ファイルには影響しないと明記されています。
... does not delete depots, streams, or files from P4 Server.
最後に
今回は、PerforceのP4 DAMをAWS上に構築し、無料枠(DAMライセンスなし)でアセットアップロード・バージョン管理・ロック・削除挙動まで確認してみました。
この記事がどなたかの参考になれば幸いです。
