Batch Container
The Batch Server runs scheduled jobs. For more information, see Batch Server Quartz Jobs.
Prerequisites
The batch container image must be built and available. For information on building container images, see Building Container Images.
Suitable Environment Types
The Batch application is a core application and is always deployed.
| Include in Development and QA Environments? | Include in Authoring Environments? | Include in Live Environments? |
|---|---|---|
| Yes | Yes | Yes |
Configuration
The sections below describe typical configurations.
Container user
The application container images are built to be run as user app_runner (user ID 10001), with user group app_runner (group ID 10001). Ensure that you specify the correct user and group when you run the container. Volumes should also be readable and writeable by this user. Consult your container orchestration documentation for more information.
Below is an example security context snippet for a Kubernetes deployment.yaml file.
securityContext:
runAsUser: 10001
runAsGroup: 10001
fsGroup: 10001
Note about production sizing and tuning
The values shared in this document are suggestions that are known to work well in typical scenarios.
Planning and validation is required to finalize resource and scaling settings for production. The settings should be reviewed and re-validated periodically, such as when significant Commerce application changes are deployed or when traffic and load requirements change. For more information, see the Self-Managed Commerce Sizing Guide.
Resource allocation
Resource allocation can vary by usage and load. Below are typical values.
| Resource | Non Production | Production Like (See Note) |
|---|---|---|
| Container Memory (MB) | 3072 | 4096 |
| Container Cores | 0.25 | 1 |
| Java Heap (MB) | 2048 | 2048 |
Scaling and replicas
This service is a singleton and should not be scaled.
| Configuration | Non Production | Production Like (See Note) |
|---|---|---|
| Minimum Replicas | 1 | 1 |
| Maximum Replicas | 1 | 1 |
| Target CPU Utilization (%) | 50 | 50 |
| Max Surge (%) | 25 | 100 |
| Max Unavailable (%) | 25 | 0 |
Ingresses
The table below describes the ingress requirements for this service.
| Port | Non Production | Production | Purpose | Comment |
|---|---|---|---|---|
| 8080 | Yes | Yes | Used for readiness checks. | This port should only be exposed internally, ideally only to the container orchestrator. |
| 8180 | Yes | Yes | Health and liveness checks. | This port should only be exposed internally, ideally only to the container orchestrator. |
| 8888 | Optional | Optional | JMX | The container listens on this port when the ENABLE_JMX environment variable is set to true. This port should only be exposed internally to users and tools that require access to JMX data. |
| 1081 | Optional | No | Java debugger. | The container will listen on this port when the ENABLE_DEBUG environment variable is set to true. This port should only be exposed internally, to developers who debug Java application code. This port is typically not open in production. |
Egresses
The table below describes the egress requirements for this service.
| Endpoint | Purpose | Comment |
|---|---|---|
| Commerce JDBC endpoint | Commerce database | This service must be able to access the Commerce database. |
| Commerce JMS endpoint | Java Messaging Service | This service must be able to access the JMS service for messaging, which is typically ActiveMQ. |
| Git Service | Optional: inject config at start-up | The service can optionally be configured to inject config files from a secured Git project at startup time. If that is configured then the container must be able to connect to the Git project specified in environment variable EP_COMMERCE_CONFIG_REPO. For more information about secure configuration, see Injecting Commerce Configuration at Startup. |
Health, Liveness and Readiness
Container orchestration tools monitor the health and responsiveness of containers. For information about supported endpoints, see Health Monitoring Usage.
Volumes
| Mount Point | Purpose | Comment |
|---|---|---|
| /hdump | Store Java heap dump files, which are created when a Java OutOfMemoryError occurs, on a filesystem that persists after the container dies. These files are large but can be very helpful to diagnose Java memory usage issues. | Each heap dump file can be multiple gigabytes in size so it is important to ensure that the filesystem is large and regularly maintained so that it does not fill up. Consider using a shared filesystem across all containers for this purpose. |
Environment Variables
The application is configured using container environment variables. Some environment variables must be set and some are optional. The environment variables are read and consumed by the container entrypoint scripts. Review Common Environment Variables for a list of required and optional environment variables that are common to all Commerce application services.
The following table shows additional environment variables specific to this service:
| Variable Name | Description | Required |
|---|---|---|
EP_BATCH_X_JVM_ARGS | Can be used to set additional custom Java arguments. | No |
EP_CONTAINER_MEM_BATCH | Used to set the Java heap size. Both the initial heap (Xms) and maximum heap (Xmx) are set to this value. | Yes |
The entrypoint scripts are and will remain the source of truth on the required environment variables. Review the container entrypoint scripts in your selected release to validate the required variables.