For an Operator-managed Red Hat AMQ Broker deployment on OpenShift, start with the ActiveMQArtemis custom resource (CR). The Operator’s built-in init container generates broker configuration from that CR before the broker starts. If the required change needs extra files, libraries, or configuration transformations that the CR does not express, use a compatible custom init image with a /amq/scripts/post-config.sh script. These instructions are specific to the documented AMQ Broker Operator workflow; they are not universal instructions for every Apache Artemis or Kubernetes deployment.
First identify the Artemis deployment you have
Apache ActiveMQ Artemis is the upstream broker project. Red Hat AMQ Broker is a Red Hat product with its own OpenShift Operator, custom-resource schema, and release-specific image instructions. Before changing a deployment, identify the product, platform, Operator, and installed version. The examples below describe Red Hat AMQ Broker documentation for versions 7.12 and 7.14, not a universal Kubernetes API.
For AMQ Broker 7.14, Red Hat documents each broker running in a Pod managed by a StatefulSet. The Operator runs an init container that generates configuration from the deployment CR before the broker application container starts. See the AMQ Broker 7.14 deployment guide.
Choose the configuration method
| Need | Use | Key distinction |
|---|---|---|
| A setting represented by the installed Operator’s CRD | Configure the ActiveMQArtemis CR |
The Operator generates broker configuration from the CR. Some settings have merge or replace behavior, so check the release documentation for the field involved. |
| Additional XML, JARs, files, or transformations not represented by CR fields | A custom init image and post-config.sh |
The script runs after CR-based configuration generation and before the broker container starts. |
| Standalone Apache Artemis Docker instance needing replacement configuration files | The Docker image’s etc-override mechanism |
This is a separate image workflow, not an Operator-managed init-container procedure. |
Prefer a native CR field when it can express the setting. Reserve a custom init image for changes that genuinely need supporting files, libraries, or post-generation processing.
#1 Best Overall
How the Operator init-container flow works
- The Operator creates the broker Pod. In the documented AMQ Broker OpenShift deployment, the Pod belongs to a StatefulSet.
- The built-in init container reads the CR. It generates the broker instance configuration before the application container starts.
- The init container and broker share the generated files. The AMQ Broker 7.14 guide identifies
CONFIG_INSTANCE_DIRas the shared installation directory and documents/amq/init/configas its default. - The broker container starts with that instance configuration. The generated files, rather than an ad hoc edit to a running container, are the configuration baseline.
Use ${CONFIG_INSTANCE_DIR} in custom scripts instead of hard-coding the current path. The directory’s documented default is useful for understanding the layout, but using the variable makes a script less dependent on that literal value. See the 7.14 deployment guide and the 7.12 custom-image guidance.
Extend generated configuration with a custom init image
The AMQ Broker 7.12 guide describes basing a custom init image on the corresponding built-in init image and adding /amq/scripts/post-config.sh. The Operator runs the script after it has generated configuration from the CR and before the broker application container starts. Put the XML, JARs, or other supporting files in the image where the script can access them.
Rank #2
The version-scoped CR setting shown in the 7.12 guide has this shape:
spec:
deploymentPlan:
image: <matching-broker-image>
initImage: <custom-init-image>This is an illustrative fragment, not a release-independent manifest. Confirm the API version, field names, and image requirements against the CRD and documentation for the Operator installed in your cluster. The 7.12 guide recommends specifying the corresponding broker image alongside a custom init image; otherwise the broker image may be upgraded automatically. Keep the init and broker images compatible, and use the AMQ Broker 7.12 configuration guide for that release’s custom-image instructions.
Recommended Free Tools
Make the script repeatable
- Reference paths through
${CONFIG_INSTANCE_DIR}. - Keep custom files and script logic in the image so the change can be recreated when a Pod is replaced.
- Do not treat a manual edit to generated files as a durable configuration change unless you have established when the Operator regenerates them and how the edit will be reapplied.
- Keep credentials out of image layers and ordinary configuration files; use the platform’s documented secret handling.
Understand which configuration file you are changing
In standalone Apache Artemis, bootstrap.xml is used at startup by default and identifies items such as the main broker configuration location. broker.xml holds core broker settings, including acceptors, addresses, queues, diverts, and clustering. The Apache Artemis configuration documentation describes these configuration roles.
The official Apache Artemis Docker workflow uses /var/lib/artemis-instance for the broker instance and its data. It supports placing replacements such as broker.xml or artemis.profile in etc-override, which are copied into the instance’s etc directory after instance creation. That workflow is documented in the Apache Artemis Docker guide. Do not substitute it for the AMQ Broker Operator’s CR and init-image flow without confirming that the specific Operator supports it.
Rank #4
Verify the result in the target deployment
- Check the installed API and release documentation. Confirm that the CR fields and image references match the Operator version running in the cluster.
- Inspect init-container and broker logs. Look for script errors or configuration-generation failures before diagnosing the broker as a runtime problem.
- Inspect the generated configuration. The AMQ Broker 7.14 guide describes the running broker’s
broker.xmlunder/home/jboss/amq-broker/etc; verify the path for the exact image and release you use. - Validate startup and behavior after Pod recreation. A successful change should be reproducible from the CR and custom image, not dependent on an edit made inside one running Pod.
Test changes in a representative environment before applying them to production. The image pair, CRD schema, generated-file layout, and configuration behavior are release-sensitive.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
