Choosing how you want to use IBM MQ in containers

There are multiple options for using IBM® MQ in containers: you can choose to use the IBM MQ Operator, or you can deploy IBM MQ using your own deployment code.

[OpenShift Container Platform][Amazon EKS]

Deploy using the IBM MQ Operator

The IBM MQ Operator automates the creation, configuration, and management of queue managers. It offers several key features:

  1. The IBM MQ Operator offers an abstraction of the lower level Kubernetes resources, so that you don't need such deep Kubernetes skills. The operator adds a new QueueManager custom resource and watches for new queue manager definitions, turning them into the necessary low-level resources. The IBM MQ Operator continues to observe the low-level resources under its control, to prevent configuration drift if they were to be edited manually.
  2. For high availability, the operator can also perform the rolling update of queue manager instances. For example, managing a rolling update across three Native HA instances, in a way which minimizes fail-overs (for example, by upgrading failed Pods first, then replica Pods, then the active Pod).
You can deploy the IBM MQ Operator on the following platforms:
  • Red Hat® OpenShift® Container Platform
  • Amazon Elastic Kubernetes Service (from IBM MQ Operator 3.9.0)

For more information, see Support for the IBM MQ Operator.

Deploy using your own deployment code

There are several key considerations for writing your own code to self-deploy IBM MQ in containers:

  1. Which container image to use:
    1. [MQ 9.4.1] Prebuilt images. From IBM MQ 9.4.1, you can use the prebuilt images that are available from the IBM Container Registry. For more information, see Support for the IBM MQ Advanced container images and Support for IBM MQ licensed container images.
    2. Build your own images. This is required for IBM MQ 9.4.0 and earlier, but you can still choose to do this on later versions. This option offers flexibility to choose your own base image, to install any IBM MQ component, or alter anything else about the image that you require. It requires you to own the resultant container. See Support for building your own IBM MQ container images for details of what is supported when building your own image and deployment code. Samples for building your own images are available. See Preparing for IBM MQ by building your own container image.
  2. You will need to manage and support your own deployment code with this option, for example using helm, kustomize, terraform or ansible. This gives a lot of flexibility over how MQ is deployed, but requires you to have the right skills in configuring containers. IBM provides defect and usage support for the IBM-supplied MQ container image, including IBM MQ itself, but does not help users configure and debug problems with their container environment or deployment pipeline. Examples of how to deploy into Kubernetes are provided in the documentation. There is also an unsupported sample Helm chart. For more information, see Self-deploying and configuring queue managers on Kubernetes, and Self-deploying and configuring queue managers using the sample Helm chart

  3. Rolling updates for highly available queue managers need to be carefully managed. For example, the standard Kubernetes rolling update will update Pods in a fixed order, regardless of which one is the "active" Pod, which can lead to multiple fail-overs. For more details, see Considerations for performing your own rolling update of a Native HA queue manager.