Common Setup Steps
This page summarizes the setup steps common to both the standalone configuration and the cluster configuration. It assumes that you have completed the software installation in Before You Begin and the selection of the environment to build (repository and branch).
For the configuration-specific diagrams, service lists, and URL / port number references, see Standalone Configuration / Cluster Configuration. Where a step differs by configuration (for example, the repository name, directory name, or Resin service name), it is written separately for the standalone configuration and the cluster configuration.
Cloning the Repository
- Open a terminal (see Opening a Terminal).
- Navigate to the directory where you want to build the development environment.
cd <path to the directory where you want to build the environment>
- Run the following command to clone the repository. For
<branch name>, specify the branch name you selected in Selecting a Branch (iAP Version × DB) (for example,2026autumn-postgres). The repository to clone differs depending on the configuration.
Standalone configuration:
git clone -b <branch name> https://github.com/accelplatform/docker-stacks.git
Cluster configuration:
git clone -b <branch name> https://github.com/accelplatform/docker-stacks-cluster.git
The directory structure after cloning is as follows. The root directory name corresponds to the cloned repository.
Standalone configuration:
docker-stacks/ ← Repository root (created by clone)
├── .env ← Environment variable definitions
├── compose.yaml ← Docker Compose definition
├── README.md
├── httpd/ ← Apache HTTPd
├── resin/ ← Resin (application server)
├── cassandra/ ← Cassandra
├── solr/ ← Solr
├── imm/ ← For imm deployment
├── juggling-build-war/ ← war / static file builds
├── accelstudio-testing-agent/ ← Accel Studio Testing Function Test Execution Agent
└── data/ ← Persistent data and build artifacts
Cluster configuration:
docker-stacks-cluster/ ← Repository root (created by clone)
├── .env ← Environment variable definitions
├── compose.yaml ← Docker Compose definition
├── README.md
├── httpd/ ← Apache HTTPd
├── resin/ ← Resin (application server)
├── cassandra/ ← Cassandra
├── solr/ ← Solr
├── imm/ ← For imm deployment
├── juggling-build-war/ ← war / static file builds
├── accelstudio-testing-agent/ ← Accel Studio Testing Function Test Execution Agent
└── data/ ← Persistent data and build artifacts
After cloning, verify that the Git LFS target files (files under imm/lib and juggling-build-war/lib) have been retrieved correctly.
In Windows environments, clone the repository to a location within the WSL2 Linux filesystem (for example, ~/work/). Placing it under /mnt/c/... (= the Windows-side C:\ drive) routes file I/O through the Windows ↔ Linux bridge, causing significantly slower builds and startups.
If you clone without installing or initializing Git LFS, files under lib/ will remain as LFS pointer files (a few hundred bytes). If the file sizes appear extremely small, verify your Git LFS installation and initialization.
git lfs install
git lfs pull
In proxy environments, proxy settings may be required in resin/overwrite/conf/resin.properties or resin.xml (rebuilding the image is required if resin.xml is edited).
If connections to external services fail, check the following:
Downloading and Placing Required Materials
- Download the following materials from the License Portal and place them in the specified directories. The destination is under the root of the cloned repository; the root directory name differs depending on the configuration.
| Material | Destination (Standalone Configuration) | Destination (Cluster Configuration) |
|---|---|---|
| Resin Pro | docker-stacks/resin/ | docker-stacks-cluster/resin/ |
| Accel Studio Testing Function Test Execution Agent | docker-stacks/accelstudio-testing-agent/ | docker-stacks-cluster/accelstudio-testing-agent/ |
| Apache Cassandra | docker-stacks/cassandra/ | docker-stacks-cluster/cassandra/ |
| Solr installer | docker-stacks/solr/ | docker-stacks-cluster/solr/ |
The exact file names for each material (including version numbers) depend on the selected branch. Refer to the README.md in the cloned repository and download and place the files using the names listed there.
Building container images without placing the required materials will result in build errors such as COPY failures or tar extraction failures. If an error occurs, first check for any missing materials (→ Common Issues - "Missing Required Materials").
If you are using Oracle, additional manual placement (the Oracle JDBC driver) is required beyond what is listed above. See the README.md of the selected branch for details.
If you cannot obtain the Cassandra or Solr materials, or want to exclude them from the configuration, you can exclude them by commenting out the corresponding service definitions in compose.yaml and the relevant entries in Resin's depends_on (resin for the standalone configuration; resin1 / resin2 for the cluster configuration). For detailed steps, see Container Customization.
Building Container Images
- Run the following command to navigate to the root directory of the repository cloned in Cloning the Repository. The directory name differs depending on the configuration.
Standalone configuration:
cd docker-stacks
Cluster configuration:
cd docker-stacks-cluster
- Run the following command to build the main container images.
docker compose build --no-cache
- Run the following command to build the container image for building war files and static files.
docker compose build --no-cache juggling-build-war
docker compose build targets services that have a build: directive defined. Services without a build target, such as the database (<db>) and mailpit, will have their images pulled from Docker Hub when started (the target services depend on the selected branch's compose.yaml).
Note that juggling-build-war and accelstudio-testing-agent are not started automatically by docker compose up -d (they are run with run or individual up -d when needed).
- Verify that the materials for Cassandra, Solr, and other components are placed correctly (Downloading and Placing Required Materials).
- In proxy environments, check the "Proxy Environment Configuration" notes in Installing Required Software and Cloning the Repository.
- Use the error messages at the end of the detailed build log to identify the cause (→ Common Issues).
Building the war and Static Files
- Run the following command to build the war files and static files to be deployed in the iAP development environment.
docker compose run --rm juggling-build-war
When the build completes, the following artifacts are generated under data/juggling/:
| Path | Contents |
|---|---|
data/juggling/public | Static files. Used directly by Apache HTTPd. |
data/juggling/repository | IM-Juggling local repository. Retained to speed up subsequent builds. |
data/juggling/war | war files. Referenced directly by Resin. In the cluster configuration, referenced directly by Resin1 and Resin2. |
data/juggling/imart.war | The generated war file itself (not used at runtime in this Docker stack). |
data/juggling/imart.zip | A zip of the generated static files (not used at runtime in this Docker stack). |
The IM-Juggling project to be built is placed in the default state under data/juggling/project. Running it as-is generates a war in the unit test environment with the version configuration described in the selected branch's README.md.
To replace the IM-Juggling project, see The data/ Directory: Description and Usage - "Replacing the IM-Juggling Project".
If you place user modules (.imm / .zip) under data/juggling/additional-modules before building, they are automatically incorporated into the IM-Juggling project and included in the war. For details, see Adding User Modules.
repository DirectoryKeeping data/juggling/repository allows subsequent builds to skip re-downloading and re-resolving dependencies, significantly reducing build time.
If you are not using the Accel Studio Testing Function, set testing-enabled to false in juggling-build-war/overwrite/conf/accel-studio-testing-config.xml before building.
Starting the Containers
- Run the following command to start each service.
docker compose up -d
You can check the startup status of the containers with the following command:
docker compose ps
If the STATUS column shows Up, the container is running.
- Run the following command to check the iAP startup status. The Resin service to check differs depending on the configuration.
Standalone configuration:
docker compose logs -f resin
Cluster configuration:
docker compose logs -f resin1
docker compose logs -f resin2
When the ASCII art shown below appears, iAP has finished starting.
Press Ctrl+C to exit the log display.
[INFO] j.c.i.s.s.WelcomeServlet - []
_ _ _
(_)_ __ | |_ _ __ __ _ _ __ ___ __ _ _ __| |_
| | '_ \| __| '__/ _` |_____| '_ ` _ \ / _` | '__| __|
| | | | | |_| | | (_| |_____| | | | | | (_| | | | |_
|_|_| |_|\__|_| \__,_| |_| |_| |_|\__,_|_| \__|
_ _ ____ _ _ __
/ \ ___ ___ ___| | | _ \| | __ _| |_ / _| ___ _ __ _ __ ___
/ _ \ / __/ __/ _ \ | | |_) | |/ _` | __| |_ / _ \| '__| '_ ` _ \
/ ___ \ (_| (_| __/ | | __/| | (_| | |_| _| (_) | | | | | | | |
/_/ \_\___\___\___|_| |_| |_|\__,_|\__|_| \___/|_| |_| |_| |_|
-----
Platform:
intra-mart Accel Platform ...
Applications:
...
Patched Modules:
...
Immediately after the containers start, applications inside the containers such as Resin may still be initializing. Wait until each service has finished starting before proceeding to the next step.
For instructions on checking the logs for httpd, <db>, cassandra, solr, mailpit, and accelstudio-testing-agent, see Checking Logs.
Running docker compose up without the -d option starts in foreground mode, connecting the terminal directly to the containers so you can observe the startup process. You can detach to background mode with d after startup.
Depending on the database you are using, additional steps may be required at startup. If database-related errors occur, also check the README.md of the selected branch.
Tenant Environment Setup
-
Access http://127.0.0.1/imart/system/login from a browser.
-
The tenant configuration screen will appear. Execute the tenant environment setup. For detailed steps, see intra-mart Accel Platform Setup Guide - Tenant environment setup.
When built with the default project, configure the following:
- Tenant information - Tenant ID:
default - Cassandra connection information: Leave at the default values
- After completing the tenant environment setup, execute activation. For detailed steps, see intra-mart Accel Platform License Portal Operation Guide - Procedures for using the environment.
Once the tenant environment setup and activation are complete, proceed to Verifying Operation.
Stopping and Restarting Containers
Once you have verified operation, stop the environment you have built and confirm it can be restarted. Because this Docker environment persists data under data/, you do not need to redo the tenant environment setup or activation after stopping and restarting.
Stopping All Services
- Run the following command to stop all containers.
docker compose down
docker compose down removes the containers, but the data under data/ remains on the host PC. The next time you start, you can resume from where you left off.
Restarting All Services
- Run the following command (the same command as in Starting the Containers) to start each service.
docker compose up -d
After startup completes, access http://127.0.0.1/imart/login from a browser and verify that you can log in with the same tenant administrator credentials as before the stop. There is no need to redo the tenant environment setup or activation.
Persistent data is stored under data/ on the host PC. For details on what is stored and how to use it, see The data/ Directory: Description and Usage.
For the steps to restart only a specific service, see Standalone Configuration / Cluster Configuration, since the Resin service name differs by configuration.