Chapter 3. Deploying AMQ Broker on OpenShift Container Platform using the AMQ Broker Operator
3.1. Prerequisites Copy linkLink copied to clipboard!
- Before you install the Operator and use it to create a broker deployment, you should consult the Operator deployment notes in Section 2.9, “Operator deployment notes”.
3.2. Installing the Operator using the CLI Copy linkLink copied to clipboard!
Each Operator release requires that you download the latest AMQ Broker 7.12.5 Operator Installation and Example Files as described below.
The procedures in this section show how to use the OpenShift command-line interface (CLI) to install and deploy the latest version of the Operator for AMQ Broker 7.12 in a given OpenShift project. In subsequent procedures, you use this Operator to deploy some broker instances.
- For an alternative method of installing the AMQ Broker Operator that uses the OperatorHub graphical interface, see Section 3.3, “Installing the Operator using OperatorHub”.
- To learn about upgrading existing Operator-based broker deployments, see Chapter 6, Upgrading an Operator-based broker deployment.
3.2.1. Preparing to deploy the Operator Copy linkLink copied to clipboard!
Before you deploy the Operator using the CLI, you must download the Operator installation files and prepare the deployment.
Procedure
- In your web browser, navigate to the Software Downloads page for AMQ Broker 7.12.5 releases.
-
Ensure that the value of the Version drop-down list is set to
7.12.5and the Releases tab is selected. Next to the latest AMQ Broker 7.12.5 Operator Installation and Example Files, click Download.
Download of the
amq-broker-operator-7.12.5-ocp-install-examples-rhel8.zipcompressed archive automatically begins.Move the archive to your chosen directory. The following example moves the archive to a directory called
~/broker/operator.mkdir ~/broker/operator mv amq-broker-operator-7.12.5-ocp-install-examples-rhel8.zip ~/broker/operator
$ mkdir ~/broker/operator $ mv amq-broker-operator-7.12.5-ocp-install-examples-rhel8.zip ~/broker/operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow In your chosen directory, extract the contents of the archive. For example:
cd ~/broker/operator unzip amq-broker-operator-7.12.5-ocp-install-examples-rhel8.zip
$ cd ~/broker/operator $ unzip amq-broker-operator-7.12.5-ocp-install-examples-rhel8.zipCopy to Clipboard Copied! Toggle word wrap Toggle overflow Switch to the directory that was created when you extracted the archive. For example:
cd amq-broker-operator-7.12.5-ocp-install-examples
$ cd amq-broker-operator-7.12.5-ocp-install-examplesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Log in to OpenShift Container Platform as a cluster administrator. For example:
oc login -u system:admin
$ oc login -u system:adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow Specify the project in which you want to install the Operator. You can create a new project or switch to an existing one.
Create a new project:
oc new-project <project_name>
$ oc new-project <project_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Or, switch to an existing project:
oc project <project_name>
$ oc project <project_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Specify a service account to use with the Operator.
-
In the
deploydirectory of the Operator archive that you extracted, open theservice_account.yamlfile. -
Ensure that the
kindelement is set toServiceAccount. -
If you want to change the default service account name, in the
metadatasection, replaceamq-broker-controller-managerwith a custom name. Create the service account in your project.
oc create -f deploy/service_account.yaml
$ oc create -f deploy/service_account.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
In the
Specify a role name for the Operator.
-
Open the
role.yamlfile. This file specifies the resources that the Operator can use and modify. -
Ensure that the
kindelement is set toRole. -
If you want to change the default role name, in the
metadatasection, replaceamq-broker-operator-rolewith a custom name. Create the role in your project.
oc create -f deploy/role.yaml
$ oc create -f deploy/role.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
Open the
Specify a role binding for the Operator. The role binding binds the previously-created service account to the Operator role, based on the names you specified.
-
Open the
role_binding.yamlfile. Ensure that the
namevalues forServiceAccountandRolematch those specified in theservice_account.yamlandrole.yamlfiles. For example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create the role binding in your project.
oc create -f deploy/role_binding.yaml
$ oc create -f deploy/role_binding.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
Open the
Specify a leader election role binding for the Operator. The role binding binds the previously-created service account to the leader election role, based on the names you specified.
Create a leader election role for the Operator.
oc create -f deploy/election_role.yaml
$ oc create -f deploy/election_role.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Create the leader election role binding in your project.
oc create -f deploy/election_role_binding.yaml
$ oc create -f deploy/election_role_binding.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
(Optional) If you want the Operator to watch multiple namespaces, complete the following steps:
NoteIf the OpenShift Container Platform cluster already contains installed Operators for AMQ Broker, you must ensure the new Operator does not watch any of the same namespaces as existing Operators. For information on how to identify the namespaces that are watched by existing Operators, see, Identifying namespaces watched by existing Operators.
-
In the deploy directory of the Operator archive that you downloaded and extracted, open the
operator_yamlfile. If you want the Operator to watch all namespaces in the cluster, in the
WATCH_NAMESPACEsection, add avalueattribute and set the value to an asterisk. Comment out the existing attributes in theWATCH_NAMESPACEsection. For example:- name: WATCH_NAMESPACE value: "*" # valueFrom: # fieldRef: # fieldPath: metadata.namespace
- name: WATCH_NAMESPACE value: "*" # valueFrom: # fieldRef: # fieldPath: metadata.namespaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow NoteTo avoid conflicts, ensure that multiple Operators do not watch the same namespace. For example, if you deploy an Operator to watch all namespaces on the cluster, you cannot deploy another Operator to watch individual namespaces. If Operators are already deployed on the cluster, you can specify a list of namespaces that the new Operator watches, as described in the following step.
If you want the Operator to watch multiple, but not all, namespaces on the cluster, in the
WATCH_NAMESPACEsection, specify a list of namespaces. Ensure that you exclude any namespaces that are watched by existing Operators. For example:- name: WATCH_NAMESPACE value: "namespace1, namespace2"`.
- name: WATCH_NAMESPACE value: "namespace1, namespace2"`.Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
In the deploy directory of the Operator archive that you downloaded and extracted, open the
cluster_role_binding.yamlfile. In the Subjects section, specify a namespace that corresponds to the OpenShift Container Platform project to which you are deploying the Operator. For example:
Subjects: - kind: ServiceAccount name: amq-broker-controller-manager namespace: operator-project
Subjects: - kind: ServiceAccount name: amq-broker-controller-manager namespace: operator-projectCopy to Clipboard Copied! Toggle word wrap Toggle overflow NoteIf you previously deployed brokers using an earlier version of the Operator, and you want to deploy the Operator to watch multiple namespaces, see Before you upgrade.
Create a cluster role in your project.
oc create -f deploy/cluster_role.yaml
$ oc create -f deploy/cluster_role.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Create a cluster role binding in your project.
oc create -f deploy/cluster_role_binding.yaml
$ oc create -f deploy/cluster_role_binding.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
In the deploy directory of the Operator archive that you downloaded and extracted, open the
In the procedure that follows, you deploy the Operator in your project.
3.2.2. Deploying the Operator using the CLI Copy linkLink copied to clipboard!
The procedure in this section shows how to use the OpenShift command-line interface (CLI) to deploy the latest version of the Operator for AMQ Broker 7.12 in your OpenShift project.
Prerequisites
- You must have already prepared your OpenShift project for the Operator deployment. See Section 3.2.1, “Preparing to deploy the Operator”.
- Starting in AMQ Broker 7.3, you use a new version of the Red Hat Ecosystem Catalog to access container images. This new version of the registry requires you to become an authenticated user before you can access images. Before you can follow the procedure in this section, you must first complete the steps described in Red Hat Container Registry Authentication.
If you intend to deploy brokers with persistent storage and do not have container-native storage in your OpenShift cluster, you need to manually provision Persistent Volumes (PVs) and ensure that they are available to be claimed by the Operator. For example, if you want to create a cluster of two brokers with persistent storage (that is, by setting
persistenceEnabled=truein your Custom Resource), you need to have two PVs available. By default, each broker instance requires storage of 2 GiB.If you specify
persistenceEnabled=falsein your Custom Resource, the deployed brokers uses ephemeral storage. Ephemeral storage means that that every time you restart the broker Pods, any existing data is lost.For more information about provisioning persistent storage, see:
Procedure
In the OpenShift command-line interface (CLI), log in to OpenShift as a cluster administrator. For example:
oc login -u system:admin
$ oc login -u system:adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow Switch to the project that you previously prepared for the Operator deployment. For example:
oc project <project_name>
$ oc project <project_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Switch to the directory that was created when you previously extracted the Operator installation archive. For example:
cd ~/broker/operator/amq-broker-operator-7.12.5-ocp-install-examples
$ cd ~/broker/operator/amq-broker-operator-7.12.5-ocp-install-examplesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Deploy the CRDs that are included with the Operator. You must install the CRDs in your OpenShift cluster before deploying and starting the Operator.
Deploy the main broker CRD.
oc create -f deploy/crds/broker_activemqartemis_crd.yaml
$ oc create -f deploy/crds/broker_activemqartemis_crd.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Deploy the address CRD.
oc create -f deploy/crds/broker_activemqartemisaddress_crd.yaml
$ oc create -f deploy/crds/broker_activemqartemisaddress_crd.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Deploy the scaledown controller CRD.
oc create -f deploy/crds/broker_activemqartemisscaledown_crd.yaml
$ oc create -f deploy/crds/broker_activemqartemisscaledown_crd.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Deploy the security CRD:
oc create -f deploy/crds/broker_activemqartemissecurity_crd.yaml
$ oc create -f deploy/crds/broker_activemqartemissecurity_crd.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Link the pull secret associated with the account used for authentication in the Red Hat Ecosystem Catalog with the
default,deployer, andbuilderservice accounts for your OpenShift project.oc secrets link --for=pull default <secret_name> oc secrets link --for=pull deployer <secret_name> oc secrets link --for=pull builder <secret_name>
$ oc secrets link --for=pull default <secret_name> $ oc secrets link --for=pull deployer <secret_name> $ oc secrets link --for=pull builder <secret_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow In the
deploydirectory of the Operator archive that you downloaded and extracted, open theoperator.yamlfile. Ensure that the value of thespec.containers.imageproperty corresponds to version 7.12.5-opr-1 of the Operator, as shown below.Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteIn the
operator.yamlfile, the Operator uses an image that is represented by a Secure Hash Algorithm (SHA) value. The comment line, which begins with a number sign (#) symbol, denotes that the SHA value corresponds to a specific container image tag.Deploy the Operator.
oc create -f deploy/operator.yaml
$ oc create -f deploy/operator.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow In your OpenShift project, the Operator starts in a new Pod.
In the OpenShift Container Platform web console, the information on the Events tab of the Operator Pod confirms that OpenShift has deployed the Operator image that you specified, has assigned a new container to a node in your OpenShift cluster, and has started the new container.
In addition, if you click the Logs tab within the Pod, the output should include lines resembling the following:
... {"level":"info","ts":1553619035.8302743,"logger":"kubebuilder.controller","msg":"Starting Controller","controller":"activemqartemisaddress-controller"} {"level":"info","ts":1553619035.830541,"logger":"kubebuilder.controller","msg":"Starting Controller","controller":"activemqartemis-controller"} {"level":"info","ts":1553619035.9306898,"logger":"kubebuilder.controller","msg":"Starting workers","controller":"activemqartemisaddress-controller","worker count":1} {"level":"info","ts":1553619035.9311671,"logger":"kubebuilder.controller","msg":"Starting workers","controller":"activemqartemis-controller","worker count":1}... {"level":"info","ts":1553619035.8302743,"logger":"kubebuilder.controller","msg":"Starting Controller","controller":"activemqartemisaddress-controller"} {"level":"info","ts":1553619035.830541,"logger":"kubebuilder.controller","msg":"Starting Controller","controller":"activemqartemis-controller"} {"level":"info","ts":1553619035.9306898,"logger":"kubebuilder.controller","msg":"Starting workers","controller":"activemqartemisaddress-controller","worker count":1} {"level":"info","ts":1553619035.9311671,"logger":"kubebuilder.controller","msg":"Starting workers","controller":"activemqartemis-controller","worker count":1}Copy to Clipboard Copied! Toggle word wrap Toggle overflow The preceding output confirms that the newly-deployed Operator is communicating with Kubernetes, that the controllers for the broker and addressing are running, and that these controllers have started some workers.
It is recommended that you deploy only a single instance of the AMQ Broker Operator in a given OpenShift project. Setting the spec.replicas property of your Operator deployment to a value greater than 1, or deploying the Operator more than once in the same project is not recommended.
Additional resources
- For an alternative method of installing the AMQ Broker Operator that uses the OperatorHub graphical interface, see Section 3.3, “Installing the Operator using OperatorHub”.
3.3. Installing the Operator using OperatorHub Copy linkLink copied to clipboard!
3.3.1. Overview of the Operator Lifecycle Manager Copy linkLink copied to clipboard!
In OpenShift Container Platform 4.5 and later, the Operator Lifecycle Manager (OLM) helps users install, update, and generally manage the lifecycle of all Operators and their associated services running across their clusters. It is part of the Operator Framework, an open source toolkit designed to manage Kubernetes-native applications (Operators) in an effective, automated, and scalable way.
The OLM runs by default in OpenShift Container Platform 4.5 and later, which aids cluster administrators in installing, upgrading, and granting access to Operators running on their cluster. The OpenShift Container Platform web console provides management screens for cluster administrators to install Operators, as well as grant specific projects access to use the catalog of Operators available on the cluster.
OperatorHub is the graphical interface that OpenShift cluster administrators use to discover, install, and upgrade Operators using the OLM. With one click, these Operators can be pulled from OperatorHub, installed on the cluster, and managed by the OLM, ready for engineering teams to self-service manage the software in development, test, and production environments.
When you have deployed the Operator, you can use Custom Resource (CR) instances to create broker deployments such as standalone and clustered brokers.
3.3.2. Deploying the Operator from OperatorHub Copy linkLink copied to clipboard!
This procedure shows how to use OperatorHub to deploy the latest version of the Operator for AMQ Broker to a specified OpenShift project.
In OperatorHub, you can install only the latest Operator version that is provided in each channel. If you want to install an earlier version of an Operator, you must install the Operator by using the CLI. For more information, see Section 3.2, “Installing the Operator using the CLI”.
Prerequisites
-
The
Red Hat Integration - AMQ Broker for RHEL 8 (Multiarch)Operator must be available in OperatorHub. - You have cluster administrator privileges.
Procedure
- Log in to the OpenShift Container Platform web console as a cluster administrator.
-
In left navigation menu, click
. - On the Project drop-down menu at the top of the OperatorHub page, select the project in which you want to deploy the Operator.
On the OperatorHub page, use the Filter by keyword… box to find the
Red Hat Integration - AMQ Broker for RHEL 8 (Multiarch)Operator.NoteIn OperatorHub, you might find more than one Operator than includes
AMQ Brokerin its name. Ensure that you click theRed Hat Integration - AMQ Broker for RHEL 8 (Multiarch)Operator. When you click this Operator, review the information pane that opens. For AMQ Broker 7.12, the latest minor version tag of this Operator is7.12.5-opr-1.-
Click the
Red Hat Integration - AMQ Broker for RHEL 8 (Multiarch)Operator. On the dialog box that appears, click Install. On the Install Operator page:
Under Update Channel, select the
7.11.xchannel to receive updates for version 7.11 only. The7.11.xchannel is a Long Term Support (LTS) channel.Depending on when your OpenShift Container Platform cluster was installed, you may also see channels for older versions of AMQ Broker. The only other supported channel is
7.10.x, which is also an LTS channel.Under Installation Mode, choose which namespaces the Operator watches:
- A specific namespace on the cluster - The Operator is installed in that namespace and only monitors that namespace for CR changes.
- All namespaces - The Operator monitors all namespaces for CR changes.
NoteIf you previously deployed brokers using an earlier version of the Operator, and you want deploy the Operator to watch many namespaces, see Before you upgrade.
- From the Installed Namespace drop-down menu, select the project in which you want to install the Operator.
Under Approval Strategy, ensure that the radio button entitled
Automaticis selected. This option specifies that updates to the Operator do not require manual approval for installation to take place.NoteThe approval strategy applies only to updates between micro versions of the Operator. Automatic updates between minor Operator versions are not supported. For example, if the current Operator is version 7.11.7, an automatic update to version 7.12.x is not possible. To update between minor versions of the Operator, you must manually uninstall the current Operator and install the new Operator from the channel where Operators for that minor version are made available. For more information, see Section 6.3, “Manually upgrading the Operator using OperatorHub”.
- Click Install.
When the Operator installation is complete, the Installed Operators page opens. You should see that the Red Hat Integration - AMQ Broker for RHEL 8 (Multiarch) Operator is installed in the project namespace that you specified.
Additional resources
- To learn how to create a broker deployment in a project that has the Operator for AMQ Broker installed, see Section 3.4.1, “Deploying a basic broker instance”.
3.4. Creating Operator-based broker deployments Copy linkLink copied to clipboard!
3.4.1. Deploying a basic broker instance Copy linkLink copied to clipboard!
The following procedure shows how to use a Custom Resource (CR) instance to create a basic broker deployment.
While you can create more than one broker deployment in a given OpenShift project by deploying multiple Custom Resource (CR) instances, typically, you create a single broker deployment in a project, and then deploy multiple CR instances for addresses.
Red Hat recommends you create broker deployments in separate projects.
In AMQ Broker 7.12, if you want to configure the following items, you must add the appropriate configuration to the main broker CR instance before deploying the CR for the first time.
Prerequisites
You must have already installed the AMQ Broker Operator.
- To use the OpenShift command-line interface (CLI) to install the AMQ Broker Operator, see Section 3.2, “Installing the Operator using the CLI”.
- To use the OperatorHub graphical interface to install the AMQ Broker Operator, see Section 3.3, “Installing the Operator using OperatorHub”.
- You should understand how the Operator chooses a broker container image to use for your broker deployment. For more information, see Section 2.7, “How the Operator chooses container images”.
- Starting in AMQ Broker 7.3, you use a new version of the Red Hat Ecosystem Catalog to access container images. This new version of the registry requires you to become an authenticated user before you can access images. Before you can follow the procedure in this section, you must first complete the steps described in Red Hat Container Registry Authentication.
Procedure
When you have successfully installed the Operator, the Operator is running and listening for changes related to your CRs. This example procedure shows how to use a CR instance to deploy a basic broker in your project.
Start configuring a Custom Resource (CR) instance for the broker deployment.
Using the OpenShift command-line interface:
Log in to OpenShift as a user that has privileges to deploy CRs in the project in which you are creating the deployment.
oc login -u <user> -p <password> --server=<host:port>
oc login -u <user> -p <password> --server=<host:port>Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Open the sample CR file called
broker_activemqartemis_cr.yamlthat was included in thedeploy/crsdirectory of the Operator installation archive that you downloaded and extracted.
Using the OpenShift Container Platform web console:
- Log in to the console as a user that has privileges to deploy CRs in the project in which you are creating the deployment.
-
Start a new CR instance based on the main broker CRD. In the left pane, click
. - Click the ActiveMQArtemis CRD.
- Click the Instances tab.
Click Create ActiveMQArtemis.
Within the console, a YAML editor opens, enabling you to configure a CR instance.
For a basic broker deployment, a configuration might resemble that shown below.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Observe that in the
broker_activemqartemis_cr.yamlsample CR file, theimageproperty is set to a default value ofplaceholder. This value indicates that, by default, theimageproperty does not specify a broker container image to use for the deployment. To learn how the Operator determines the appropriate broker container image to use, see Section 2.7, “How the Operator chooses container images”.NoteThe
broker_activemqartemis_cr.yamlsample CR uses a naming convention ofex-aao. This naming convention denotes that the CR is an example resource for the AMQ Broker Operator. AMQ Broker is based on the ActiveMQ Artemis project. When you deploy this sample CR, the resulting StatefulSet uses the nameex-aao-ss. Furthermore, broker Pods in the deployment are directly based on the StatefulSet name, for example,ex-aao-ss-0,ex-aao-ss-1, and so on. The application name in the CR appears in the deployment as a label on the StatefulSet. You might use this label in a Pod selector, for example.-
The
sizeproperty specifies the number of brokers to deploy. A value of2or greater specifies a clustered broker deployment. However, to deploy a single broker instance, ensure that the value is set to1. Deploy the CR instance.
Using the OpenShift command-line interface:
- Save the CR file.
Switch to the project in which you are creating the broker deployment.
oc project <project_name>
$ oc project <project_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create the CR instance.
oc create -f <path/to/custom_resource_instance>.yaml
$ oc create -f <path/to/custom_resource_instance>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Using the OpenShift web console:
- When you have finished configuring the CR, click Create.
In the OpenShift Container Platform web console, click
. You see a new StatefulSet called ex-aao-ss.- Click the ex-aao-ss StatefulSet. You see that there is one Pod, corresponding to the single broker that you defined in the CR.
- Within the StatefulSet, click the Pods tab. Click the ex-aao-ss Pod. On the Events tab of the running Pod, you see that the broker container has started. The Logs tab shows that the broker itself is running.
To test that the broker is running normally, access a shell on the broker Pod to send some test messages.
Using the OpenShift Container Platform web console:
-
Click
. - Click the ex-aao-ss Pod.
- Click the Terminal tab.
-
Click
Using the OpenShift command-line interface:
Get the Pod names and internal IP addresses for your project.
oc get pods -o wide NAME STATUS IP amq-broker-operator-54d996c Running 10.129.2.14 ex-aao-ss-0 Running 10.129.2.15
$ oc get pods -o wide NAME STATUS IP amq-broker-operator-54d996c Running 10.129.2.14 ex-aao-ss-0 Running 10.129.2.15Copy to Clipboard Copied! Toggle word wrap Toggle overflow Access the shell for the broker Pod.
oc rsh ex-aao-ss-0
$ oc rsh ex-aao-ss-0Copy to Clipboard Copied! Toggle word wrap Toggle overflow
From the shell, use the
artemiscommand to send some test messages. Specify the internal IP address of the broker Pod in the URL. For example:./amq-broker/bin/artemis producer --url tcp://10.129.2.15:61616 --destination queue://demoQueue
sh-4.2$ ./amq-broker/bin/artemis producer --url tcp://10.129.2.15:61616 --destination queue://demoQueueCopy to Clipboard Copied! Toggle word wrap Toggle overflow The preceding command automatically creates a queue called
demoQueueon the broker and sends a default quantity of 1000 messages to the queue.You should see output that resembles the following:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Additional resources
- For a complete configuration reference for the main broker Custom Resource (CR), see Section 8.1, “Custom Resource configuration reference”.
- To learn how to connect a running broker to AMQ Management Console, see Chapter 5, Connecting to AMQ Management Console for an Operator-based broker deployment.
3.4.2. Deploying clustered brokers Copy linkLink copied to clipboard!
If there are two or more broker Pods running in your project, the Pods automatically form a broker cluster. A clustered configuration enables brokers to connect to each other and redistribute messages as needed, for load balancing.
The following procedure shows you how to deploy clustered brokers. By default, the brokers in this deployment use on demand load balancing, meaning that brokers will forward messages only to other brokers that have matching consumers.
Prerequisites
- A basic broker instance is already deployed. See Section 3.4.1, “Deploying a basic broker instance”.
Procedure
- Open the CR file that you used for your basic broker deployment.
For a clustered deployment, ensure that the value of
deploymentPlan.sizeis2or greater. For example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteIn the
metadatasection, you need to include thenamespaceproperty and specify a value only if you are using the OpenShift Container Platform web console to create your CR instance. The value that you should specify is the name of the OpenShift project for your broker deployment.- Save the modified CR file.
Log in to OpenShift as a user that has privileges to deploy CRs in the project in which you previously created your basic broker deployment.
oc login -u <user> -p <password> --server=<host:port>
$ oc login -u <user> -p <password> --server=<host:port>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Switch to the project in which you previously created your basic broker deployment.
oc project <project_name>
$ oc project <project_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow At the command line, apply the change:
oc apply -f <path/to/custom_resource_instance>.yaml
$ oc apply -f <path/to/custom_resource_instance>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow In the OpenShift Container Platform web console, additional broker Pods starts in your project, according to the number specified in your CR. By default, the brokers running in the project are clustered.
Open the Logs tab of each Pod. The logs show that OpenShift has established a cluster connection bridge on each broker. Specifically, the log output includes a line like the following:
targetConnector=ServerLocatorImpl (identity=(Cluster-connection-bridge::ClusterConnectionBridge@6f13fb88
targetConnector=ServerLocatorImpl (identity=(Cluster-connection-bridge::ClusterConnectionBridge@6f13fb88Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.4.3. Applying Custom Resource changes to running broker deployments Copy linkLink copied to clipboard!
The following are some important things to note about applying Custom Resource (CR) changes to running broker deployments:
-
You cannot dynamically update the
persistenceEnabledattribute in your CR. To change this attribute, scale your cluster down to zero brokers. Delete the existing CR. Then, recreate and redeploy the CR with your changes, also specifying a deployment size. -
As described in Section 3.2.2, “Deploying the Operator using the CLI”, if you create a broker deployment with persistent storage (that is, by setting
persistenceEnabled=truein your CR), you might need to provision Persistent Volumes (PVs) for the AMQ Broker Operator to claim for your broker Pods. If you scale down the size of your broker deployment, the Operator releases any PVs that it previously claimed for the broker Pods that are now shut down. However, if you remove your broker deployment by deleting your CR, AMQ Broker Operator does not release Persistent Volume Claims (PVCs) for any broker Pods that are still in the deployment when you remove it. In addition, these unreleased PVs are unavailable to any new deployment. In this case, you need to manually release the volumes. For more information, see Release a persistent volume in the OpenShift documentation. In AMQ Broker 7.12, if you want to configure the following items, you must add the appropriate configuration to the main CR instance before deploying the CR for the first time.
- During an active scaling event, any further changes that you apply are queued by the Operator and executed only when scaling is complete. For example, suppose that you scale the size of your deployment down from four brokers to one. Then, while scaledown is taking place, you also change the values of the broker administrator user name and password. In this case, the Operator queues the user name and password changes until the deployment is running with one active broker.
-
All CR changes – apart from changing the size of your deployment, or changing the value of the
exposeattribute for acceptors, connectors, or the console – cause existing brokers to be restarted. If you have multiple brokers in your deployment, only one broker restarts at a time.
3.5. Changing the logging level for the Operator Copy linkLink copied to clipboard!
The default logging level for AMQ Broker Operator is info, which logs information and error messages. You can change the default logging level to increase or decrease the detail that is written to the Operator logs.
If you use the OpenShift Container Platform command-line interface to install the Operator, you can set the new logging level in the Operator configuration file, operator.yaml, either before or after you install the Operator. If you use Operator Hub, you can use the OpenShift Container Platform web console to set the logging level in the Operator subscription after you install the Operator.
The other available logging levels for the Operator are:
error- Writes error messages only to the log.
debug- Write all messages to the log including debugging messages.
Procedure
Using the OpenShift Container Platform command-line interface:
Log in as a cluster administrator. For example:
oc login -u system:admin
$ oc login -u system:adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow If the Operator is not installed, complete the following steps to change the logging level.
-
In the
deploydirectory of the Operator archive that you downloaded and extracted, open theoperator.yamlfile. Change the value of the
zap-log-levelattribute todebugorerror. For example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Save the
operator.yamlfile. - Install the Operator.
-
In the
If the Operator is already installed, use the
sedcommand to change the logging level in thedeploy/operator.yamlfile and redeploy the Operator. For example, the following command changes the logging level frominfotoerrorand redeploys the Operator:sed 's/--zap-log-level=info/--zap-log-level=error/' deploy/operator.yaml | oc apply -f -
$ sed 's/--zap-log-level=info/--zap-log-level=error/' deploy/operator.yaml | oc apply -f -Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Using the OpenShift Container Platform web console:
- Log in to the OpenShift Container Platform as a cluster administrator.
-
In the left pane, click
. - Click the Red Hat Integration - AMQ Broker for RHEL 8 (Multiarch) Operator.
- Click the Subscriptions tab.
- Click Actions.
- Click Edit Subscription.
Click the YAML tab.
Within the console, a YAML editor opens, enabling you to edit the subscription.
In the
configelement, add an environment variable calledARGSand specify a logging level ofinfo,debugorerror. In the following example, anARGSenvironment variable that specifies a logging level ofdebugis passed to the Operator container.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Click Save.
3.6. Configuring leader election settings for the operator Copy linkLink copied to clipboard!
You can customize the settings used by the AMQ Broker operator for leader elections.
If you use the OpenShift Container Platform command-line interface to install the operator, you can configure the leader elections settings in the operator configuration file, operator.yaml, either before or after installation. If you use OperatorHub, you can use the OpenShift Container Platform web console to configure the leader elections settings in the operator subscription after installation.
Procedure
Using the OpenShift Container Platform web console:
- Log in to the OpenShift Container Platform as a cluster administrator.
-
In the left pane, click
. - Click the Red Hat Integration - AMQ Broker for RHEL 8 (Multiarch) Operator.
- Click the Subscriptions tab.
- Click Actions.
- Click Edit Subscription.
Click the YAML tab.
Within the console, a YAML editor opens, enabling you to edit the subscription.
In the
configsection, add an environment variable namedARGSand specify the leader election settings in the variable value. For example:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Click Save.
- lease-duration
- The duration, in seconds, that a non-leader operator waits before it attempts to acquire the lease that was not renewed by the previous leader. The default is 15.
- renew-deadline
- The duration, in seconds, the operator waits between attempts to renew the leader role before it stops leading. The default is 10.
- retry-period
- The duration, in seconds, that the operator waits between attempts to acquire and renew the leader role. The default is 2.
Using the OpenShift Container Platform command-line interface:
Log in as a cluster administrator. For example:
oc login -u system:admin
$ oc login -u system:adminCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
In the
deploydirectory of the operator archive that you downloaded and extracted, open theoperator.yamlfile. Set the values of the leader election settings. For example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Save the
operator.yamlfile. If the operator is already installed, apply the updated settings.
oc apply -f deploy/operator.yaml
$ oc apply -f deploy/operator.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow - If the operator is not installed, install the operator.
3.7. Viewing status information for your broker deployment Copy linkLink copied to clipboard!
You can view the status of a series of standard conditions reported by OpenShift Container Platform for your broker deployment. You can also view additional status information provided in the Custom Resource (CR) for your broker deployment.
Procedure
Open the CR instance for the broker deployment.
Using the OpenShift command-line interface:
- Log in to OpenShift Container Platform as a user that has privileges to view CRs in the project for the broker deployment.
View the CR for your deployment.
oc get ActiveMQArtemis <CR instance name> -n <namespace> -o yaml
oc get ActiveMQArtemis <CR instance name> -n <namespace> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Using the OpenShift Container Platform web console:
- Log in to the console as a user that has privileges to deploy CRs in the project for the broker deployment.
-
In the left pane, click
. - Click the Red Hat Integration - AMQ Broker for RHEL 8 (Multiarch) operator.
- Click the ActiveMQ Artemis tab.
- Click the name of the ActiveMQ Artemis instance.
View the status of the OpenShift Container Platform conditions for your broker deployment.
Using the OpenShift command-line interface:
-
Go to the
statussection of the CR and view theconditionsdetails.
-
Go to the
Using the OpenShift Container Platform web console:
In the Details tab, scroll down to the
Conditionssection.A condition has a status and a type. It might also have a reason, a message and other details. A condition has a status value of
Trueif the condition is met,Falseif the condition is not met, orUnknownif the status of the condition cannot be determined. TheValidcondition can also have a status ofUnknownto flag an anomaly in the configuration that does not affect the broker deployment. For more information, see Section 2.8, “Validation of image and version configuration in a custom resource (CR)”.Status information is provided for the following conditions:
Expand Table 3.1. Status information for a broker deployment Condition name Displays the status of… Valid
The validation of the CR. If the status of the
Validcondition isFalse, the Operator does not complete the reconciliation and update the StatefulSet until you first resolve the issue that caused the false status.Deployed
The availability of the StatefulSet, Pods and other resources.
Ready
A top-level condition which summarizes the other more detailed conditions. The
Readycondition has a status ofTrueonly if none of the other conditions have a status ofFalse.BrokerPropertiesApplied
The properties configured in the CR that use the
brokerPropertiesattribute. For more information about theBrokerPropertiesAppliedcondition, see Section 2.4, “Configuring items not exposed in a custom resource definition (CRD)”.JaasPropertiesApplied
The Java Authentication and Authorization Service (JAAS) login modules configured in the CR. For more information about the
JaasPropertiesAppliedcondition, see Section 4.3.1, “Configuring JAAS login modules in a secret”.
View additional status information for your broker deployment in the
statussection of the CR. The following additional status information is displayed:deploymentPlanSize- The number of broker Pods in the deployment.
podstatus- The status and name of each broker pod in the deployment.
version- The version of the broker and the registry URLs of the broker and init container images that are deployed.
upgradeThe ability of the Operator to apply major, minor, patch and security updates to the deployment, which is determined by the values of the
spec.deploymentPlan.imageandspec.versionattributes in the CR.-
If the
spec.deploymentPlan.imageattribute specifies the registry URL of a broker container image, the status of all upgrade types isFalse, which means that the Operator cannot upgrade the existing container images. If the
spec.deploymentPlan.imageattribute is not in the CR or has a value ofplaceholder, the configuration of thespec.versionattribute affects theupgradestatus as follows:-
The status of
securityUpdatesisTrue, irrespective of whether thespec.versionattribute is configured or its value. -
The status of
patchUpdatesisTrueif the value of thespec.versionattribute has only a major and a minor version, for example, '7.10', so the Operator can upgrade to the latest patch version of the container images. -
The status of
minorUpdatesisTrueif the value of thespec.version attributehas only a major version, for example, '7', so the Operator can upgrade to the latest minor and patch versions of the container images. -
The status of
majorUpdatesisTrueif thespec.versionattribute is not in the CR, so any available upgrades can be deployed, including an upgrade from 7.x.x to 8.x.x, if this version is available.
-
The status of
-
If the