Chapter 6. Reference
6.1. Application Template Parameters for Persistent Configuration
Configuration of the A-MQ for OpenShift image is performed by specifying values of application template parameters. Different A-MQ images require different subsets of these parameters. The following parameters can be configured:
- The password used for authentication to the broker. If no value is specified, a random password is generated.
- The user name used as an admin authentication to the broker. If no value is specified, a random user name is generated.
- The SSL keyStore filename. If no value is specified, a random password is generated but SSL will not be configured.
- The password used to decrypt the SSL keyStore (optional).
- The discovery agent type to use for discovering mesh endpoints. 'dns' will use the OpenShift DNS service to resolve endpoints. 'kube' will use Kubernetes REST API to resolve service endpoints. If using 'kube' the service account for the pod must have the 'view' role.
- Name of service used for mesh creation.
- The namespace in which the service resides. Must be specified if using kube discovery.
Specifies the memory limit set on a destination (limits the amount of memory on each queue listed in the
MQ_QUEUESenvironment variable). The value of
AMQ_QUEUE_MEMORY_LIMITcan be a string, such as
- The A-MQ release version. This determines which A-MQ image will be used as a basis for the application — for example, version 6.2 or 6.3.
- The name of a secret containing SSL related files. If no value is specified, a random password is generated.
- Boolean. Setting to ‘true’ partitions the persistent volume, allowing for multiple A-MQ pods for scalability.
- The A-MQ storage usage limit.
- The SSL trustStore filename. If no value is specified, a random password is generated but SSL will not be configured.
- The password used to decrypt the SSL trustStore (optional).
- The name of the application used internally in OpenShift. It is used in names of services, pods, and other objects within the application.
- The password used for authentication to the broker. In a standard non-containerized JBoss A-MQ, you would specify the password in the <amq-home>/opt/user.properties file. If no value is specified, a random password is generated.
- Comma-separated list of the messaging protocols used by the broker. Available options are amqp, mqtt, openwire, and stomp. If left empty, all available protocols will be available. Please note that for integration of the image with Red Hat JBoss Enterprise Application Platform, the OpenWire protocol must be specified, while other protocols can be optionally specified as well.
- Comma-separated list of queues available by default on the broker on its startup.
- Comma-separated list of topics available by default on the broker on its startup.
- The user name used for authentication to the broker. In a standard non-containerized JBoss A-MQ, you would specify the user name in the <amq-home>/opt/user.properties file. If no value is specified, a random user name is generated.
- The size of the persistent storage for database volumes.
6.2. Configuration using S2I
You can modify the configuration of the A-MQ for OpenShift image using the Source-to-image feature, described in full detail at S2I Requirements.
To specify a custom A-MQ broker configuration, create a new folder called
configuration inside the root directory of your project. Then specify your custom A-MQ configuration by creating an
openshift-activemq.xml file inside the 'configuration' folder. On each commit, this file gets copied to the
conf directory in the A-MQ root and its contents are used to configure the broker.
Please be careful when making a changes to the
openshift-activemq.xml file and do not remove the placeholders, as automated configuration may not work properly.
Only SSL connections can connect from outside of the OpenShift instance, regardless of the protocol specified in the
MQ_PROTOCOL property of the A-MQ application templates. The non-SSL version of the protocols can only be used inside the OpenShift instance.
For security reasons, using the default keyStore and trustStore generated by the system is discouraged. Generate your own keyStore and trustStore and supply them to the image using the OpenShift secrets mechanism or S2I.
In addition to viewing the OpenShift logs, you can troubleshoot a running A-MQ image by viewing the A-MQ logs that are outputted to the container’s console:
$ oc logs -f <pod-name> <container-name>
By default, the A-MQ for OpenShift image does not have a file log handler configured. Logs are only sent to the console.