メインコンテンツまでスキップ

付録

Accel Studio テスト機能のセットアップ​

Accel Studio テスト機能 テスト実行エージェント(accelstudio-testing-agent)は、メインのビルド対象に含まれていません。利用する場合は、別途イメージのビルドと環境変数の設定を行います。

イメージのビルド​

docker compose build --no-cache accelstudio-testing-agent

API キーとベース URL の設定​

.env ファイルの以下の環境変数を設定します。

  • ACCELSTUDIO_TESTING_AGENT_ACCELPLATFORM_ACCESS_TOKEN: iAP の管理画面で発行した API キー。
  • ACCELSTUDIO_TESTING_AGENT_ACCELPLATFORM_BASE_URL: ベース URL。初期状態の http://127.0.0.1/imart を使用しない場合に設定します。ベース URL が不適切な場合、エージェントがテスト対象 URL にアクセスする際の認証に失敗することがあります。

起動と停止​

# エージェントの起動
docker compose up -d accelstudio-testing-agent

# エージェントの停止
docker compose down accelstudio-testing-agent

バージョンによるエラー​

テスト実行時にエージェントのログ(data/accelstudio-testing-agent/logs/accel_studio_testing_agent.log)に以下のようなメッセージが出力される場合は、.env の ACCELSTUDIO_TESTING_AGENT_PLAYWRIGHT_VERSION を指定されたバージョンに更新してください。

??????????????????????????????????????????????????????????
? Looks like Playwright was just updated to 1.60.0. ?
? Please update docker image as well. ?
? - current: mcr.microsoft.com/playwright:v1.59.1-noble ?
? - required: mcr.microsoft.com/playwright:v1.60.0-noble ?
? ?
? <3 Playwright Team ?
??????????????????????????????????????????????????????????

上記の例であれば ACCELSTUDIO_TESTING_AGENT_PLAYWRIGHT_VERSION=1.60.0 に変更します。変更後はイメージの再ビルドと再起動が必要です。

docker compose build --no-cache accelstudio-testing-agent
docker compose up -d accelstudio-testing-agent

ログの確認​

各サービスのログは、コンテナのコンソール出力(標準出力/標準エラー)と、ファイルとして書き出されるログの 2 系統があります。

  • コンソール出力: docker compose logs コマンドで確認できます。-f オプションを付けると追跡表示となり、Ctrl+C で抜けられます。
  • ファイルログ: data/ 配下に永続化されます。コンソール出力よりも詳細な場合や、コンソール出力には現れない情報が含まれる場合があります。
コンソール出力とファイルログの使い分け

サービスの起動状況や明らかな例外を手早く把握するにはコンソール出力が便利です。一方、iAP のアプリケーションログのようにコンソールに出力されない情報や、より詳細な情報が必要な場合はファイルログを確認します。各サービスのコンソール出力に何が含まれるか、ファイルログがどこに保存されるかは、以下の各サービスの説明を参照してください。

以下、サービスごとにログ確認コマンドと、ファイルログの保存先を示します。

Resin(アプリケーションサーバ)​

Resin 本体および iAP の動作ログです。標準設定では、コンソールにはサーバの運用状態を通知するためのログやエラー発生時のログなどが出力されます。

スタンドアロン構成:

docker compose logs -f resin

クラスタ構成:

docker compose logs -f resin1
docker compose logs -f resin2
クラスタ構成における Resin1 / Resin2 のログの違い

resin1 / resin2 は同じイメージ・同じ設定で動作しますが、両者は独立したプロセスです。動作不良時には片系のみエラーが出ている場合があるため、両方のログを横断的に確認してください。

ファイルログ:

クラスタ構成では、それぞれ data/resin1/log/... / data/resin2/log/... 配下に出力されます。

Apache HTTPd(Web サーバ)​

外部からの HTTP リクエストを受ける Web サーバのログです。コンソールにはアクセスログ(common 形式)とエラーログ(warn レベル以上)の両方が出力されます。

docker compose logs -f httpd

ファイルログ:

  • data/httpd/log/access.log: アクセスログ(common 形式。コンソールと同じ内容)

データベース​

iAP のメインデータベースのログです。コンソールには起動メッセージ、接続エラー、初期化等の標準ログが出力されます(クエリログはデフォルトでは出力されません)。

docker compose logs -f <db> # <db> は選択したブランチの DB サービス名(例: postgresql)

ファイルログ:

  • ファイルログの保存先は DB により異なります。詳細は選択したブランチの README.md を参照してください。

Cassandra(NoSQL データベース)​

iAP の IMBox で利用する Cassandra のログです。コンソールには起動~初期化ログ全般(Binding thrift service to ...、Listening for thrift clients ... 等の起動完了メッセージを含む)や、GC・コミットログ関連の INFO ログが出力されます。

docker compose logs -f cassandra

ファイルログ:

  • data/cassandra/log/system.log: Cassandra のシステムログ

Solr(検索エンジン)​

iAP の検索機能で利用する Solr のログです。コンソールには Started SolrJettyServer 等の起動完了メッセージや、コアロード、各種 INFO ログ、起動失敗時のエラーが出力されます。

docker compose logs -f solr

ファイルログ:

  • data/solr/logs/: Solr のログ群(solr.log、GC ログ solr_gc.log、スロークエリログ solr_slow_requests.log、日付付きのリクエストログ YYYY_MM_DD.request.log 等)

mailpit(テスト用 SMTP サーバ)​

iAP からのメール送信を受け取るテスト用 SMTP サーバのログです。コンソールには起動完了メッセージや、SMTP 受信時のログが出力されます。

docker compose logs -f mailpit

ファイルログ:

  • 本構成ではファイルログは出力されません(コンソール出力のみ)。

accelstudio-testing-agent(Accel Studio テスト機能 テスト実行エージェント)​

Accel Studio テスト機能のテスト実行エージェントのログです。コンソールには Spring Boot の起動ログ、Tomcat の起動状況(ポート 8188)、Playwright 関連プラグインのセットアップログ(npm i @playwright/test の実行を含む)、テスト実行リクエスト受信時のログなどが出力されます。

docker compose logs -f accelstudio-testing-agent

ファイルログ:

  • data/accelstudio-testing-agent/logs/accel_studio_testing_agent.log: テスト実行エージェントのログ(コンソールと同じ内容)
トラブル時のログ採取

解決しないトラブルが発生した場合は、-f ではなく --tail=200 のような行数指定でログ末尾を取得すると、共有や調査に便利です(→ 解決しないときの情報収集)。

data/ ディレクトリの説明と活用​

data/ ディレクトリは、各サービスのデータを永続化するための領域です。コンテナを停止・再起動しても、data/ 配下を保持していれば前回の状態を引き継げます。

永続化されるもの(スタンドアロン構成)​

パス内容
data/cassandraCassandra のデータおよびシステムログ
data/httpdApache HTTPd のアクセスログ
data/jugglingIM-Juggling プロジェクト・追加するユーザモジュール・成果物(project、additional-modules、public、war、repository 等)
data/mailpitmailpit のメールデータ
data/<db>データベースのデータ。ディレクトリ名は選択したブランチに依存します(選択したブランチの README.md を参照)。
data/resinResin の各種ログ、iAP の各種ログと Storage 領域
data/solrSolr のインデックスデータ
data/accelstudio-testing-agentAccel Studio テスト機能 テスト実行エージェントのログ

永続化されるもの(クラスタ構成)​

パス内容
data/cassandraCassandra のデータおよびシステムログ
data/httpdApache HTTPd のアクセスログ
data/jugglingIM-Juggling プロジェクト・追加するユーザモジュール・成果物
data/mailpitmailpit のメールデータ
data/<db>データベースのデータ。ディレクトリ名は選択したブランチに依存します(選択したブランチの README.md を参照)。
data/resin/storageiAP の Storage 領域(Resin1 / Resin2 で共有)
data/resin1Resin1 の各種ログ、iAP の各種ログ
data/resin2Resin2 の各種ログ、iAP の各種ログ
data/solrSolr のインデックスデータ
data/accelstudio-testing-agentAccel Studio テスト機能 テスト実行エージェントのログ

退避・移行(セットアップ済み data/ の持ち運び)​

テナント環境セットアップ直後の data/ を退避しておくと、時間のかかるテナント環境セットアップを省略して同等の環境を再構築できます。

# 退避(任意の場所にコピー)
cp -r data data.backup

別マシンに移行する場合は、退避した data/ を新環境の同位置に配置してから docker compose up -d を実行します。

差し替え(IM-Juggling プロジェクトの差し替え)​

ユーザが作成した IM-Juggling プロジェクトで環境を構築する場合は、data/juggling/project 配下を削除したうえで、ユーザの IM-Juggling プロジェクトをコピー配置します。

data/
└── juggling/
└── project/
├── juggling.im
├── resin-web.xml
├── classes/
├── conf/
├── lib/
├── modules/
└── schema/

プロジェクト直下には、次のファイル・ディレクトリが配置されている必要があります。

  • juggling.im
  • resin-web.xml
  • conf/
  • modules/
  • schema/
  • classes/(必要に応じて)
  • lib/(必要に応じて)

差し替え後、war の再ビルドと Resin / HTTPd の再起動を行います。

# war 作成 + 静的ファイル配置
docker compose run --rm juggling-build-war

# スタンドアロン構成の場合
docker compose restart resin
docker compose restart httpd

# クラスタ構成の場合
docker compose restart resin1
docker compose restart resin2
docker compose restart httpd
設定ファイルの上書き

docker compose run --rm juggling-build-war を実行すると、生成される war の WEB-INF 配下の設定ファイルが、本リポジトリ同梱の設定ファイル(juggling-build-war/overwrite 配下)で上書きされます。IM-Juggling プロジェクト内の設定ファイル自体は変更されません。対象は resin-web.xml / javamail-config.xml / accel-studio-testing-config.xml / cassandra-config.xml / network-agent-config.xml / server-context-config.xml / solr-config.xml / storage-config.xml です。

初期化(data/ 配下の削除)​

データを初期化する場合は、コンテナを停止のうえ data/ 配下の各サービスディレクトリを削除します。

以下のコマンド例の data/<db> は、選択したブランチのデータベースのデータディレクトリに読み替えてください(例: PostgreSQL の場合は data/postgresql)。具体的なディレクトリ名は選択したブランチの README.md を参照してください。

スタンドアロン構成:

docker compose down
# 個別起動していたテスト実行エージェントが残っている場合は併せて停止
# docker compose down accelstudio-testing-agent

sudo rm -rf data/cassandra data/httpd data/mailpit data/<db> data/resin data/solr data/accelstudio-testing-agent

docker compose up -d

クラスタ構成:

docker compose down
# 個別起動していたテスト実行エージェントが残っている場合は併せて停止
# docker compose down accelstudio-testing-agent

sudo rm -rf data/cassandra data/httpd data/mailpit data/<db> data/resin data/resin1 data/resin2 data/solr data/accelstudio-testing-agent

docker compose up -d
警告
data/juggling/project を消さないでください

data/juggling/project を削除すると、war・静的ファイルのビルドが実行できなくなります。Juggling 成果物のみを初期化したい場合は、以下のように project を除いて削除してください。

sudo rm -rf data/juggling/public data/juggling/repository data/juggling/war data/juggling/imart.war data/juggling/imart.zip

部分的に資材を追加する場合​

data/juggling/public および data/juggling/war は、Apache HTTPd / Resin にマウントされています。これらのディレクトリに直接ファイルを追加し、サービスを再起動するだけで、war の再ビルドなしに変更を反映できます。

# スタンドアロン構成
docker compose restart resin
docker compose restart httpd

# クラスタ構成
docker compose restart resin1
docker compose restart resin2
docker compose restart httpd

Apache HTTPd は、再起動せずとも変更が反映されるケースが多くあります。

war・静的ファイルを再ビルドすると消えます

docker compose run --rm juggling-build-war を実行すると、data/juggling/public と data/juggling/war は作り直されるため、直接追加したファイルは消えます。継続して利用する資材は、ユーザモジュールの追加 の手順でユーザモジュールとして組み込んでください。

ユーザモジュールの追加​

作成したユーザモジュールを、環境の IM-Juggling プロジェクト(data/juggling/project)に組み込む手順です。

data/juggling/additional-modules 配下に、ユーザモジュールのファイル(.imm または .zip)を配置します。

data/
└── juggling/
├── project/
└── additional-modules/
└── <ユーザモジュール>.imm

war・静的ファイルをビルドし、サービスを再起動します。

docker compose run --rm juggling-build-war

# スタンドアロン構成
docker compose restart resin
docker compose restart httpd

# クラスタ構成
docker compose restart resin1
docker compose restart resin2
docker compose restart httpd

juggling-build-war は、war・静的ファイルを生成する前に、additional-modules 配下のユーザモジュールを IM-Juggling プロジェクトへ組み込んで保存します。

  • 同じモジュール ID のユーザモジュールがプロジェクトにすでにある場合は、配置したファイルで差し替えます(バージョンが異なる場合も含みます)。新しいバージョンを組み込むときは、ファイルを置き換えて再度ビルドします。
  • 配置したファイルは、ビルドのたびにファイル名順に組み込まれます。同じモジュール ID のファイルを複数配置すると後のファイルで差し替えられるため、1 つだけ配置してください。
  • ベースモジュールやアプリケーションなど、リポジトリから取得するモジュールと同じ ID のユーザモジュールは組み込めず、エラーになります。
  • 組み込み後の構成の検証や war の生成が失敗した場合は、プロジェクトを組み込み前の状態に戻します。元に戻せなかった場合は、組み込み前のプロジェクトが data/juggling/.project-backup に残るため、そこから手作業で戻してください。
ファイルを削除してもプロジェクトからは外れません

組み込んだユーザモジュールは、プロジェクトの juggling.im と modules/ に保存されます。additional-modules からファイルを削除しても、プロジェクトからは外れません。

外す場合は、IM-Juggling(または IM-Juggling ライブラリ)でプロジェクトからユーザモジュールを削除し、war・静的ファイルを再ビルドしてください。

コンテナのカスタマイズ​

デバッグポートの追加​

Resin のリモートデバッグを行う場合は、compose.yaml の resin(クラスタ構成では resin1 / resin2)に対し、デバッグポートを ports: に追加します。

# 例: 9009 をデバッグポートとして開ける場合
ports:
- 8080:8080
- 9009:9009 # ポートを追加

あわせて、resin/overwrite/conf/resin.properties にある jvm_args に以下の引数を追加してください。

-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=*:<ポート番号>

設定例(9009 をデバッグポートとして利用する場合):

jvm_args : -Dfile.encoding=UTF-8 ... -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=*:9009
設定変更後の反映

compose.yaml の ports: を変更した場合はコンテナの再作成が必要です。

docker compose down
docker compose up -d

不要なサービスを構成から外す(Cassandra / Solr 等)​

Cassandra / Solr の資材を入手できない場合や、構成から外したい場合は、compose.yaml の該当サービス定義と、Resin の depends_on 内の該当エントリをコメントアウトします。

以下では cassandra を例に示します。Solr を外す場合は cassandra を solr に読み替えてください。両方を外す場合は両サービス分のコメントアウトを行います。

# 例: cassandra を構成から外す場合(compose.yaml)
# クラスタ構成では resin1 / resin2 双方の depends_on を編集してください

# cassandra:
# image: $DOCKER_IMAGE_REPOSITORY/${DOCKER_IMAGE_TAG_PREFIX}cassandra:1.1.12
# ...

resin: # クラスタ構成では resin1 / resin2
...
depends_on:
- postgresql
# - cassandra
- solr
構成変更後の影響

Cassandra / Solr を外す場合、iAP 側でも該当機能を使わない構成にする必要があります。IM-Juggling プロジェクトの設定ファイル(cassandra-config.xml / solr-config.xml 等)の見直しも合わせて行ってください。

タイムゾーンの変更​

.env の TZ 環境変数を変更します。

TZ=Asia/Tokyo

.env 変更後は、コンテナを再起動して反映してください。

docker compose down
docker compose up -d

コマンドリファレンス​

本書中で利用する Docker / Docker Compose の頻出コマンドを、用途別に一覧化したものです。本書を再利用する際の手元のリファレンスとしてご利用ください。各コマンドの詳細な前提や補足は、参照列のリンク先の節で確認できます。

サービス名・コンテナ名の読み替え

一部のコマンドは、利用する構成・データベースに応じて読み替えが必要です。

  • <サービス名> は対象のサービスに応じて読み替えてください。
  • <コンテナ名> は実際に起動しているコンテナの名称です(例: docker-stacks_2026autumn-postgres-resin-1)。docker compose ps コマンドで表示される一覧の NAME 列で確認できます。

イメージのビルド​

リポジトリ取得・資材配置の後、各コンテナイメージを生成するためのコマンドです。--no-cache はキャッシュを使わずクリーンに再ビルドするオプションで、本書では確実な再現性のために常に付けることを推奨しています。

用途コマンド参照
メインのコンテナイメージを一括ビルドするdocker compose build --no-cacheコンテナイメージのビルド
war・静的ファイルのビルド用イメージをビルドするdocker compose build --no-cache juggling-build-warコンテナイメージのビルド
Accel Studio テスト機能 テスト実行エージェントのイメージをビルドするdocker compose build --no-cache accelstudio-testing-agentAccel Studio テスト機能のセットアップ

資材のビルド・展開(run)​

常駐サービスとしてではなく、一度きりの処理として実行するコンテナの起動コマンドです。--rm は実行後にコンテナを自動削除するためのオプションです。

用途コマンド参照
war・静的ファイルをビルドする(additional-modules 配下のユーザモジュールも組み込む)docker compose run --rm juggling-build-warwar・静的ファイルのビルド / ユーザモジュールの追加

起動・停止​

iAP 開発環境を構成する全サービスの起動・停止に使うコマンドです。

用途コマンド参照
全サービスをバックグラウンドで起動するdocker compose up -dコンテナの起動
全サービスをフォアグラウンドで起動する(起動状況を直接確認する場合)docker compose upコンテナの起動
全サービスを停止するdocker compose downコンテナの停止と再起動
Accel Studio テスト機能 テスト実行エージェントのみを起動するdocker compose up -d accelstudio-testing-agentAccel Studio テスト機能のセットアップ
Accel Studio テスト機能 テスト実行エージェントのみを停止するdocker compose down accelstudio-testing-agentAccel Studio テスト機能のセットアップ

再起動(個別サービス)​

設定変更後やトラブルシューティング時に、特定のサービスのみを再起動するためのコマンドです。

用途コマンド参照
サービスを再起動するdocker compose restart <サービス名>コンテナの停止と再起動 / 個別サービスの再起動(スタンドアロン構成) / 個別サービスの再起動(クラスタ構成)

状態確認・ログの確認​

起動状況の把握や、トラブルシューティング時の情報収集に利用するコマンドです。-f はログを追跡表示し続けるオプション(Ctrl+C で抜けます)、--tail=200 は末尾 200 行のみ表示するオプションです。

用途コマンド参照
コンテナの起動状態を一覧表示するdocker compose psコンテナの起動
サービスのログを追跡表示するdocker compose logs -f <サービス名>ログの確認
サービスのログ末尾 200 行を表示する(共有・調査用)docker compose logs --tail=200 <サービス名>解決しないときの情報収集
コンテナの詳細情報を表示するdocker inspect <コンテナ名>解決しないときの情報収集