Overview
This guide summarizes the steps to build a development environment for intra-mart Accel Platform (iAP) using Docker. Even if you have no experience with Docker or building iAP environments, you can follow the steps in order to build a working environment.
Building an environment with Docker is not a requirement for practicing AI native development.
It is entirely possible to build iAP without using containers and still practice AI native development. That said, making use of Docker greatly reduces the effort of environment setup, and it also makes it easier to share environments within a project team and to extend them to DevOps.
The AI-native Development Support Feature is also built into the Docker-based environment by default, so making use of Docker lets you practice AI native development more smoothly.
Benefits of Building with Docker
Traditionally, iAP development environments were built by directly installing components such as Resin, databases (PostgreSQL/Oracle/SQL Server), Solr, and Cassandra on the OS. This guide builds all of these as Docker containers instead.
Using Docker offers the following benefits:
- Fast to build and tear down: Rebuilding an environment is as simple as running
docker compose up/down. No manual installation of individual middleware components is required. - Consistent environments: Sharing the same
compose.yamlminimizes environment differences among team members. - Keeps the host OS clean: Middleware and runtimes are confined inside containers, minimizing their impact on the host OS.
- Multiple versions can coexist: Because environments are isolated, you can manage multiple iAP environments with different versions or databases on the same host and switch between them as needed.
- Shorter development cycles: Because you can assume that environments are disposable and rebuildable, you can proceed with verification work without hesitation.
- Compatible with AI agents: The high reproducibility of environments makes this approach well-suited for integration with workflows such as automated builds and automated testing by AI agents.
What This Guide Achieves
This guide aims to achieve the following:
- Build an iAP development environment on Docker, complete the tenant setup (tenant environment setup), and reach a state where you can log in.
- Become able to customize the built environment to suit your needs (for example, additionally applying your own IM-Juggling project or user modules (imm files)).
Intended Use and Limitations
The Docker environment built in this guide is a "reference resource" intended for development, testing, E2E testing, and other staging purposes. Keep the following in mind:
- Not intended for production use. For production environments, design a configuration that meets your operational and security requirements.
- Redundancy and backup for persistent data (under
data/) are not built in. - The configuration can be modified, but users are responsible for operating any modified configurations.
Target Audience
This guide is intended for the following readers who want to build an iAP development environment using Docker:
- Users who have not used Docker before, or who have no experience building iAP environments with Docker.
- Users who want to set up an iAP development or testing environment on their local PC (Windows / macOS / Linux).
Prerequisites
The prerequisite knowledge for working through this guide (command-line operation, basic web browser operation, and basic Git operations) is summarized in Prerequisites.
Knowledge of Docker itself is not assumed. Terms that appear frequently in this guide are summarized in Basic Docker Terminology. For a deeper understanding, refer to Docker Docs as well.
Basic Docker Terminology
This section explains Docker-related terms that appear frequently in this guide. Feel free to skip this section if you are already familiar with these concepts.
Basic Concepts
| Term | Description |
|---|---|
| Docker | A platform for packaging and running applications in lightweight virtual environments called "containers." It eliminates the need for direct OS installation and enables environments to be quickly created and discarded. |
| Docker Desktop | The official application for easily setting up a Docker environment on Windows, macOS, or Linux. This guide uses Docker Desktop to build the Docker environment. |
Containers and Images
| Term | Description |
|---|---|
| Image | A template (blueprint) for starting containers. It is a package containing all OS files, installed software, and initial configuration, allowing the same container state to be started repeatedly from the same image. In this guide, a separate image is prepared for each service, including Resin, Apache HTTPd, and databases. |
| Container | An isolated execution environment started from an image. Each container runs as a single service (for example, Apache HTTPd or Resin). Even after being stopped or removed, it can be started again from the same image in the same state. |
| Build | The process of generating an image according to a Dockerfile (a text file describing the steps to create an image). In this guide, the docker compose build command is used. |
Managing Multiple Containers (Docker Compose)
| Term | Description |
|---|---|
| Docker Compose | A Docker feature that enables multiple containers to be defined, started, and stopped together. In this guide, it is used to manage multiple containers at once, including Apache HTTPd, Resin, and databases. Operations are performed using the docker compose ... command. |
| compose.yaml | The Docker Compose configuration file. It describes in YAML format which services to start, from which images, on which ports, and so on. It is already prepared in the repositories used in this guide. |
| Service | A single container unit defined in compose.yaml. In this guide, the services include httpd, resin, postgresql, solr, cassandra, and mailpit, among others. |
Image Sources
| Term | Description |
|---|---|
| Docker Hub | The official container image registry (distribution source) for Docker. When running docker compose up, if a required image is not available locally, it is automatically downloaded (pulled, as described below) from Docker Hub. |
| pull | The operation of downloading an image from a remote registry (such as Docker Hub) to your local machine. In this guide, docker pull is not run explicitly; the pull is performed automatically as needed during docker compose up. |
Data Persistence
| Term | Description |
|---|---|
| Mount | A mechanism for linking a directory inside a container with a directory on the host PC. It allows data written inside the container to be accessed as files on the host PC, and vice versa. In this guide, directories under data/ are mounted into each container. |
| Persistence | Ensuring that data is not lost when a container is stopped or removed. In this guide, mounts are used to retain database data, iAP logs, and other data under the data/ directory on the host PC. This means that even after containers are removed, data remains available and the environment can resume from the same state on restart. |
This guide covers the above terminology only to the extent needed to get started. For a deeper understanding of each concept, refer to Docker Docs as well.
Choosing a Configuration
This guide lets you choose between the following two configurations depending on your needs:
- Standalone Configuration: A standard configuration with a single Resin service. Suited for standalone verification, feature development, and testing. For details, see Standalone Configuration.
- Cluster Configuration: A load-balancing configuration with two Resin services and Apache HTTPd. Suited for verifying multi-node behavior and for checking session synchronization and distributed behavior. For details, see Cluster Configuration.
A comparison of the configurations, along with how to choose a repository and branch (iAP version × DB), is summarized in Before You Begin. If you do not specifically need to verify behavior in a cluster environment, the standalone configuration is sufficient.
Setup Flow
With the software installation in Before You Begin complete, perform the following steps for your chosen configuration:
The steps that are common across configurations, regardless of which one you choose, are summarized in Common Setup Steps. For the configuration-specific diagrams, service lists, and URL / port number references, see Standalone Configuration / Cluster Configuration. The steps for verifying operation are summarized in Verifying Operation.
If you want to use the Accel Studio Testing Function, additional setup is required after completing the iAP setup. Follow the steps in Accel Studio Testing Function Setup.