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

共通セットアップ手順

本ページは、スタンドアロン構成とクラスタ構成に共通するセットアップ手順をまとめたものです。 事前準備 のソフトウェア導入と、構築する環境（リポジトリ・ブランチ）の選択が完了している前提で進めます。

構成ごとに異なる構成図・サービス一覧・URL / ポート番号一覧は、スタンドアロン構成 / クラスタ構成 を参照してください。手順中で構成によって異なる箇所（リポジトリ名・ディレクトリ名・Resin のサービス名など）は、その都度「スタンドアロン構成」「クラスタ構成」として書き分けます。

リポジトリの取得​

  1. ターミナルを開きます（ターミナルの開き方 参照）。
  2. 開発環境を構築するディレクトリに移動します。
cd <環境を構築するディレクトリのパス>
  1. 次のコマンドを実行して、リポジトリをクローンします。<ブランチ名> には ブランチの選択（iAP バージョン × DB） で選択したブランチ名（例: 2026autumn-postgres）を指定します。クローンするリポジトリは構成によって異なります。

スタンドアロン構成:

git clone -b <ブランチ名> https://github.com/accelplatform/docker-stacks.git

クラスタ構成:

git clone -b <ブランチ名> https://github.com/accelplatform/docker-stacks-cluster.git

クローン後のディレクトリ構成は以下のとおりです。ルートディレクトリ名はクローンしたリポジトリに対応します。

スタンドアロン構成:

docker-stacks/                      ← リポジトリのルート（clone で作成）
├── .env                            ← 環境情報定義
├── compose.yaml                    ← Docker Compose 定義
├── README.md
├── httpd/                          ← Apache HTTPd
├── resin/                          ← Resin（アプリケーションサーバ）
├── cassandra/                      ← Cassandra
├── solr/                           ← Solr
├── imm/                            ← imm 展開用
├── juggling-build-war/             ← war / 静的ファイルのビルド
├── accelstudio-testing-agent/      ← Accel Studio テスト機能 テスト実行エージェント
└── data/                           ← 永続化データ・ビルド成果物

クラスタ構成:

docker-stacks-cluster/              ← リポジトリのルート（clone で作成）
├── .env                            ← 環境情報定義
├── compose.yaml                    ← Docker Compose 定義
├── README.md
├── httpd/                          ← Apache HTTPd
├── resin/                          ← Resin（アプリケーションサーバ）
├── cassandra/                      ← Cassandra
├── solr/                           ← Solr
├── imm/                            ← imm 展開用
├── juggling-build-war/             ← war / 静的ファイルのビルド
├── accelstudio-testing-agent/      ← Accel Studio テスト機能 テスト実行エージェント
└── data/                           ← 永続化データ・ビルド成果物

クローン後、Git LFS の対象ファイル（imm/lib および juggling-build-war/lib 配下のファイル）が正しく取得されているかを確認します。

Windows 環境でのクローン先ディレクトリ

Windows 環境では、リポジトリは WSL2 上の Linux ファイルシステム配下（例: ~/work/ 等）に clone してください。/mnt/c/...（= Windows 側 C:\ ドライブ配下）に置くと、ファイル I/O が Windows ↔ Linux 間のブリッジを経由するため、ビルドや起動が著しく遅くなります。

Git LFS 未取得時の症状

Git LFS をインストール・初期化していない状態でクローンすると、lib/ 配下のファイルが LFS ポインタファイル（数百バイト程度）のままになります。サイズが極端に小さい場合は、Git LFS の導入・初期化を確認してください。

git lfs install
git lfs pull
プロキシ環境下の設定

プロキシ環境では、resin/overwrite/conf/resin.properties または resin.xml にプロキシ設定が必要になる場合があります（resin.xml を編集した場合はイメージの再ビルドが必要です）。 外部サービスとの接続に失敗する場合は以下を確認してください。

必要資材のダウンロードと配置​

  1. ライセンスポータル から、次の資材をダウンロードし、所定のディレクトリに配置します。配置先はクローンしたリポジトリのルート配下で、構成によってルートディレクトリ名が異なります。
資材配置先（スタンドアロン構成）配置先（クラスタ構成）
Resin Prodocker-stacks/resin/docker-stacks-cluster/resin/
Accel Studio テスト機能 テスト実行エージェントdocker-stacks/accelstudio-testing-agent/docker-stacks-cluster/accelstudio-testing-agent/
Apache Cassandradocker-stacks/cassandra/docker-stacks-cluster/cassandra/
Solr インストーラdocker-stacks/solr/docker-stacks-cluster/solr/
具体的なファイル名は README を参照してください

各資材の具体的なファイル名（バージョン込み）は選択したブランチに依存します。クローンしたリポジトリの README.md を参照し、記載されたファイル名でダウンロード・配置してください。

資材未配置時に発生する典型エラー

必要資材が未配置のままコンテナイメージをビルドすると、COPY の失敗・tar 展開の失敗等でビルドエラーとなります。エラー時はまず配置漏れがないかをご確認ください（→ 共通トラブル「資材配置忘れ」）。

利用するデータベースによっては追加の手動配置が必要です

Oracle を利用する場合は、上記以外に追加の手動配置（Oracle の JDBC ドライバ）が必要です。詳細は選択したブランチの README.md を参照してください。

Cassandra / Solr を環境に含めない場合

Cassandra / Solr の資材を入手できない、あるいは構成から外したい場合は、compose.yaml の該当サービス定義および Resin の depends_on（スタンドアロン構成では resin、クラスタ構成では resin1 / resin2）の該当エントリをコメントアウトすることで、構成から除外できます。詳しい手順は コンテナのカスタマイズ を参照してください。

コンテナイメージのビルド​

  1. 次のコマンドを実行して、リポジトリの取得 でクローンしたリポジトリのルートディレクトリに移動します。ディレクトリ名は構成によって異なります。

スタンドアロン構成:

cd docker-stacks

クラスタ構成:

cd docker-stacks-cluster
  1. 次のコマンドを実行して、メインのコンテナイメージをビルドします。
docker compose build --no-cache
  1. 次のコマンドを実行して、war・静的ファイルをビルドするためのコンテナイメージをビルドします。
docker compose build --no-cache juggling-build-war
ビルドされるもの / されないもの

docker compose build は、各サービスに build: が定義されているものを対象にビルドします。データベース（<db>）や mailpit のようにビルド対象でないサービスは、起動時に Docker Hub から既存イメージが pull されます（対象サービスは選択したブランチの compose.yaml に依存します）。 なお、juggling-build-war / accelstudio-testing-agent は docker compose up -d で自動起動されません（必要なときに run や個別の up -d で実行します）。

ビルド失敗時の確認ポイント

war・静的ファイルのビルド​

  1. 次のコマンドを実行して、iAP 開発環境に展開する war・静的ファイルをビルドします。
docker compose run --rm juggling-build-war

ビルドが完了すると、data/juggling/ 配下に以下の成果物が生成されます。

パス内容
data/juggling/public静的ファイル。Apache HTTPd から直接利用されます。
data/juggling/repositoryIM-Juggling のローカルリポジトリ。次回以降のビルドを高速化するために保持されます。
data/juggling/warwar ファイル。Resin から直接参照されます。クラスタ構成では Resin1 / Resin2 から直接参照されます。
data/juggling/imart.war生成された war ファイル本体（本 Docker stack の実行時には利用されません）。
data/juggling/imart.zip生成された静的ファイルの zip（本 Docker stack の実行時には利用されません）。
初期状態でビルドされる war・静的ファイル

data/juggling/project 配下にビルド対象の IM-Juggling プロジェクトが初期状態で配置されており、そのまま実行すると、選択したブランチの README.md に記載のバージョン構成で war が単体テスト環境で生成されます。 IM-Juggling プロジェクトを差し替える場合は、data/ ディレクトリの説明と活用「差し替え（IM-Juggling プロジェクトの差し替え）」を参照してください。

ユーザモジュールを組み込む場合

data/juggling/additional-modules 配下にユーザモジュール（.imm / .zip）を配置してからビルドすると、IM-Juggling プロジェクトに自動で組み込まれ、war に含まれます。詳しくは ユーザモジュールの追加 を参照してください。

備考
repository ディレクトリ再利用による高速化

data/juggling/repository を残しておくと、次回以降のビルドで再ダウンロード・再解決を省略でき、ビルド時間が大幅に短縮されます。

Accel Studio テスト機能を使わない場合

Accel Studio テスト機能を利用しない場合は、juggling-build-war/overwrite/conf/accel-studio-testing-config.xml の testing-enabled を false に設定したうえでビルドしてください。

コンテナの起動​

  1. 次のコマンドを実行して、各サービスを起動します。
docker compose up -d
コンテナの起動状態の確認

コンテナの起動状態は次のコマンドで確認できます。

docker compose ps

STATUS 列が Up であれば、コンテナは起動しています。

  1. 次のコマンドを実行して、iAP の起動状況を確認します。確認対象の Resin サービスは構成によって異なります。

スタンドアロン構成:

docker compose logs -f resin

クラスタ構成:

docker compose logs -f resin1
docker compose logs -f resin2

以下のようなアスキーアートが表示されれば、iAP の起動は完了です。 Ctrl+C でログの表示を終了します。

[INFO] j.c.i.s.s.WelcomeServlet - []
 _       _                                        _
(_)_ __ | |_ _ __ __ _       _ __ ___   __ _ _ __| |_
| | '_ \| __| '__/ _` |_____| '_ ` _ \ / _` | '__| __|
| | | | | |_| | | (_| |_____| | | | | | (_| | |  | |_
|_|_| |_|\__|_|  \__,_|     |_| |_| |_|\__,_|_|   \__|

      _                _   ____  _       _    __
     / \   ___ ___ ___| | |  _ \| | __ _| |_ / _| ___  _ __ _ __ ___
    / _ \ / __/ __/ _ \ | | |_) | |/ _` | __| |_ / _ \| '__| '_ ` _ \
   / ___ \ (_| (_|  __/ | |  __/| | (_| | |_|  _| (_) | |  | | | | | |
  /_/   \_\___\___\___|_| |_|   |_|\__,_|\__|_|  \___/|_|  |_| |_| |_|

-----
  Platform:
    intra-mart Accel Platform ...
  Applications:
    ...
  Patched Modules:
    ...
サービスの起動完了確認

コンテナの起動直後は、Resin などコンテナ内部のアプリケーションの初期化処理が続いている可能性があります。各サービスの起動完了を確認してから、後続の手順に進んでください。 httpd / <db> / cassandra / solr / mailpit / accelstudio-testing-agent の各サービスのログ確認手順は ログの確認 を参照してください。

フォアグラウンドモードで起動状況を確認する

-d オプションを外して docker compose up を実行すると、フォアグラウンドモードとなりターミナルに直接コンテナが接続された状態で実行され、起動状況が確認できます。起動後でも d でデタッチ・モードに移行できます。

データベースの起動でエラーが発生した場合

利用するデータベースによっては、起動時に追加の対応が必要となる場合があります。データベース関連のエラーが発生した場合は、選択したブランチの README.md もご確認ください。

テナント環境セットアップ​

  1. ブラウザから http://127.0.0.1/imart/system/login にアクセスします。

  2. テナント設定画面に遷移するので、テナント環境セットアップを実行します。詳しい手順は intra-mart Accel Platform セットアップガイド - テナント環境セットアップ を参照してください。

初期状態のプロジェクトでビルドした場合

初期状態のプロジェクトでビルドした場合は、次のように設定してください。

  • テナント情報 - テナント ID: default
  • Cassandra接続情報: 初期値のまま
  1. テナント環境セットアップ完了後、アクティベーションを実行します。詳しい手順は intra-mart Accel Platform ライセンスポータル操作ガイド - 環境を利用するための手続き を参照してください。

テナント環境セットアップとアクティベーションが完了したら、続いて 動作確認 を行います。

コンテナの停止と再起動​

動作確認まで完了したら、ここまで構築した環境を一度停止し、再起動できることを確認します。本書の Docker 環境では data/ 配下にデータを永続化しているため、停止・再起動を行ってもテナント環境セットアップやアクティベーションをやり直す必要はありません。

全体の停止​

  1. 次のコマンドを実行して、すべてのコンテナを停止します。
docker compose down

docker compose down ではコンテナは破棄されますが、data/ 配下のデータはホスト PC 上に残ります。次回起動時は停止前の状態から再開できます。

全体の再起動​

  1. 次のコマンド（コンテナの起動 と同じコマンド）を実行して、各サービスを起動します。
docker compose up -d

起動完了後、ブラウザから http://127.0.0.1/imart/login にアクセスし、停止前と同じテナント管理者でログインできることを確認します。テナント環境セットアップやアクティベーションを再度行う必要はありません。

永続化データの保存場所

永続化データはホスト PC 上の data/ 配下に保存されます。保存対象や活用方法は data/ ディレクトリの説明と活用 を参照してください。

特定のサービスのみを再起動する手順は、Resin のサービス名が構成によって異なるため、スタンドアロン構成 / クラスタ構成 を参照してください。