Installing and Configuring IBM® MQ Advanced for Developers for Pivotal Platform (PKS)

This topic describes how to install and configure IBM MQ Advanced for Developers for Pivotal Platform on Pivotal Container Service (PKS).

Download IBM MQ Advanced for Developers for Pivotal Platform (PKS)

  1. Download the IBM MQ Advanced for Developers for Pivotal Platform Helm chart (ibm-mqadvanced-server-dev-X.X.X.tgz)
  2. (Optional) Download the IBM MQ Advanced Server Image (mqadvanced-server-dev-X.X.X.X-amd64.tar) from Pivotal Network

    Note: The Helm chart will automatically pull the latest version of the image from Docker Hub

Install Image into Private Registry (Optional)

Load the image into Docker, tag it, then push it to your registry (where <IMAGE_NAME> is the image downloaded in the optional download step)

$ docker load -i <IMAGE_NAME>.tar
$ docker tag <IMAGE_NAME>.tar registry.mycompany.com/<IMAGE_NAME>.tar 
$ docker push registry.mycompany.com/<IMAGE_NAME>.tar 

Obtain Cluster Access

A Pivotal Container Service (PKS) cluster is required to install IBM MQ Advanced for Developers for Pivotal Platform. To obtain access to your cluster, do the following:

  1. Log in to PKS: pks login -a <pks-url> -u <username> -p <password> -k
  2. Update your ~/.kube/config: pks get-credentials <cluster-name>
  3. Configure your Kubernetes client: kubectl config use-context <cluster-name>

Install Helm Server

IBM MQ Advanced for Developers for Pivotal Platform is distributed as a Helm chart. To install Helm on your PKS cluster, create a initialize_helm_rbac.yaml file as follows:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: tiller
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: tiller
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - kind: ServiceAccount
    name: tiller
    namespace: kube-system

Create the service account and cluster role binding (this sets the necessary privileges for Helm with a service account named tiller):

$ kubectl create -f initialize_helm_rbac.yaml

serviceaccount "tiller" created
clusterrolebinding.rbac.authorization.k8s.io "tiller" created

Initialize Helm with the command:

$ helm init --service-account tiller

$HELM_HOME has been configured at /<path>/.helm.

Install Helm Chart

Install the chart, specifying the release name (for example foo) and Helm repository name (for example mylocal-repo) with the following command (where ibm-mqadvanced-server-dev-X.X.X.tgz is the Helm chart file downloaded from Pivotal Netwok):

helm install --name foo ibm-mqadvanced-server-dev-X.X.X.tgz \
  --set license=accept \
  --set security.initVolumeAsRoot=true \
  --set queueManager.dev.secret.name=mysecret \
  --set queueManager.dev.secret.adminPasswordKey=adminPassword

This example assumes that you have created a Secret mysecret, containing a key adminPassword with your admin password.

(Optional) - Set image.repository, image.tag and image.pullSecret to specify an image in a private registry, rather than pulling in the latest image from Docker Hub

This command accepts the IBM MQ Advanced for Developers license and deploys an MQ Advanced for Developers server on the PKS cluster. The Configuration section lists the parameters that can be configured during installation.

Uninstalling the Chart

You can uninstall/delete the foo release as follows:

helm delete foo

The command removes all the Kubernetes components associated with the chart, except any Persistent Volume Claims (PVCs). This is the default behavior of Kubernetes, and ensures that valuable data is not deleted.

Configuration

The following table lists the configurable parameters of the ibm-mqadvanced-server-dev chart and their default values.

Parameter Description Default
license Set to accept to accept the terms of the IBM license "not accepted"
image.repository Image full name including repository ibmcom/mq
image.tag Image tag 9.1.2.0-UBI
image.pullPolicy Image pull policy IfNotPresent
image.pullSecret Image pull secret, if you are using a private Docker registry nil
arch.amd64 Preference for installation on worker nodes with the amd64 CPU architecture. One of: “0 - Do not use”, “1 - Least preferred”, “2 - No preference”, “3 - Most preferred” 2 - No preference - worker node is chosen by scheduler
arch.ppc64le Preference for installation on worker nodes with the ppc64le CPU architecture. One of: “0 - Do not use”, “1 - Least preferred”, “2 - No preference”, “3 - Most preferred” 2 - No preference - worker node is chosen by scheduler
arch.s390x Preference for installation on worker nodes with the s390x CPU architecture. One of: “0 - Do not use”, “1 - Least preferred”, “2 - No preference”, “3 - Most preferred” 2 - No preference - worker node is chosen by scheduler
metadata.labels Additional labels to be added to resources {}
persistence.enabled Use persistent volumes for all defined volumes true
persistence.useDynamicProvisioning Use dynamic provisioning (storage classes) for all volumes true
dataPVC.name Suffix for the PVC name for main MQ data (under /var/mqm) "data"
dataPVC.storageClassName Storage class of volume for main MQ data (under /var/mqm) ""
dataPVC.size Size of volume for main MQ data (under /var/mqm) 2Gi
logPVC.enabled Whether or not to use separate storage for transaction logs false
logPVC.name Suffix for the PVC name for transaction logs "log"
logPVC.storageClassName Storage class of volume for transaction logs ""
logPVC.size Size of volume for transaction logs 2Gi
qmPVC.enabled Whether or not to use separate storage for queue manager data false
qmPVC.name Suffix for the PVC name for queue manager data "qm"
qmPVC.storageClassName Storage class of volume for queue manager data ""
qmPVC.size Size of volume for queue manager data 2Gi
service.type Kubernetes service type exposing ports, e.g. NodePort ClusterIP
metrics.enabled Enable Prometheus metrics for the Queue Manager true
resources.limits.cpu Kubernetes CPU limit for the Queue Manager container 500m
resources.limits.memory Kubernetes memory limit for the Queue Manager container 512Mi
resources.requests.cpu Kubernetes CPU request for the Queue Manager container 500m
resources.requests.memory Kubernetes memory request for the Queue Manager container 512Mi
security.serviceAccountName Name of the service account to use default
security.context.fsGroup File system group ID (if required by storage provider) nil
security.context.supplementalGroups List of supplemental groups (if required by storage provider) nil
security.initVolumeAsRoot Whether or not storage provider requires root permissions to initialize false
queueManager.name MQ Queue Manager name Helm release name
queueManager.multiInstance Whether to run in multi-instance mode with an active and standby queue manager false
queueManager.dev.secret.name Secret that contains the ‘admin’ user password and optionally the 'app’ user password to use for messaging Mandatory - a secret name must be set
queueManager.dev.secret.adminPasswordKey Secret key that contains the 'admin’ user password Mandatory - a key must be set
queueManager.dev.secret.appPasswordKey Secret key that contains the 'app’ user password nil (no password required to connect an MQ client)
pki.keys An array of YAML objects that detail Kubernetes secrets containing TLS Certificates with private keys. See section titled “Supplying certificates to be used for TLS” for more details []
pki.trust An array of YAML objects that detail Kubernetes secrets containing TLS Certificates. See section titled “Supplying certificates to be used for TLS” for more details []
nameOverride Set to partially override the resource names used in this chart ibm-mq
livenessProbe.initialDelaySeconds The initial delay before starting the liveness probe. Useful for slower systems that take longer to start the Queue Manager. 60
livenessProbe.periodSeconds How often to run the probe 10
livenessProbe.timeoutSeconds Number of seconds after which the probe times out 5
livenessProbe.failureThreshold Minimum consecutive failures for the probe to be considered failed after having succeeded 1
readinessProbe.initialDelaySeconds The initial delay before starting the readiness probe 10
readinessProbe.periodSeconds How often to run the probe 5
readinessProbe.timeoutSeconds Number of seconds after which the probe times out 3
readinessProbe.failureThreshold Minimum consecutive failures for the probe to be considered failed after having succeeded 1
log.format Error log format on container’s console. Either json or basic basic
log.debug Enables additional log output for debug purposes. false

Specify each parameter using the --set key=value[,key=value] argument to helm install.

Alternatively, a YAML file that specifies the values for the parameters can be provided while installing the chart.