Advanced configuration for an integration assembly

An integration assembly is a custom resource that allows you to deploy multiple instances of IBM Cloud Pak® for Integration capabilities from the same YAML file. Learn how to customize the default configurations of queue manager and Event Streams managed instances that were created using an integration assembly.

For information on deploying an integration assembly, see Deploying an integration assembly.

Important: Managed instances created with an integration assembly can only be edited in the integration assembly custom resource, as shown in the following examples.

Integration assembly advanced settings

This section describes advanced configuration options that change the behavior of an integration assembly.

Disable dry webhook check

Before an instance of an integration assembly can be created, a dry run validation of the managed instances is done to ensure instance configurations are valid. This check can be disabled, by adding the "operator.ibm.com/ia-managed-instances-dry-run": "false" annotation to the metadata section of an integration assembly. For example:

metadata:
  annotations:
    "operator.ibm.com/ia-managed-instances-dry-run": "false"

Queue manager advanced settings

This section describes advanced configuration options for a queue manager managed instance in an integration assembly. For information about default settings, see the section, "Queue manager managed instance" in Deploying an integration assembly.

Configuration examples

Disable the web interface

The web interface can be disabled if the UI is not needed. To disable the web interface, add the following to the queue manager managed instance:

managedInstances:
  list:
  - kind: QueueManager
    metadata:
      name: qm1
    spec:
      web:
        enabled: false

Change the queue manager name

By default, the queue manager name is based on the .metadata.name value specified for kind: QueueManager. However, the name is automatically modified to remove characters such as -. To override this default, specify a name as follows:

managedInstances:
  list:
  - kind: QueueManager
    metadata:
      name: qm1
    spec:
      queueManager:
        name: queuemanager1

Add a queue and set up permissions

Access to the channel is disabled by default. The following procedure updates the default configuration to:

  • Create a queue named APPQ.

  • Allow access to the queue by the app1 user.

  • Map from a client certificate's CN/OU to the app1 user.

  • Allow access to the channel by the app1 user.

  1. Create a ConfigMap containing the additional MQSC commands needed to perform the actions:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: qm-qm1-queues
    data:
      myqm.mqsc: |
        DEFINE QLOCAL('APPQ') REPLACE
        SET AUTHREC PROFILE('APPQ') PRINCIPAL('app1') OBJTYPE(QUEUE) AUTHADD(BROWSE,GET,INQ,PUT)
        SET CHLAUTH('MTLS.SVRCONN') TYPE(SSLPEERMAP) SSLPEER('CN=app1,OU=my-team') USERSRC(MAP) MCAUSER('app1') ACTION(REPLACE)
        SET AUTHREC PRINCIPAL('app1') OBJTYPE(QMGR) AUTHADD(CONNECT,INQ)
        REFRESH SECURITY
  2. Update the mqsc section in the Config map and list the default generated Config map (named qm-<.metadata.name>-default) and new Config map created in step 1 (in this example, qm-qm1-queues):

    managedInstances:
      list:
      - kind: QueueManager
        metadata:
          name: qm1
        spec:
          queueManager:
            mqsc:
              - configMap:
                  name: qm-qm1-default
                  items:
                    - myqm.mqsc
              - configMap:
                  name: qm-qm1-queues
                  items:
                    - myqm.mqsc

For more information on MQSC commands, see Configuration reference.

Create a client TLS certificate

To connect to a queue manager instance with the default TLS configuration, the client needs to use a certificate signed by the same certificate authority used by that queue manager. If SSLPEER is being used to map from a common name/organizational unit (CN/OU) to a user (as in the data.myqm.mqsc example in step 1), the certificate needs to have the matching CN/OU set.

There is an Issuer created by the integration assembly that can be used to create the certificate, as in the following example:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: qm1-client
spec:
  commonName: app1
  subject:
    organizationalUnits:
    - my-team
  secretName: qm1-client
  issuerRef:
    name: qm-qm1-issuer
    kind: Issuer
    group: cert-manager.io

Note the following values:

  • .spec.commonName - the CN; needs to match that used in the SSLPEER in the MQSC.

  • .spec.subject.organizationalUnits - the OU; needs to match that used in the SSLPEER in the MQSC.

  • .spec.issuerRef.name - needs to match the name of the Issuer created by the IntegrationAssembly of qm-<QueueManager name>-issuer

  • .spec.secretName - where your certificate is created.

Rotate the TLS certificate

TLS certificates are set up with a default renewal period of 60 days, after which the certificate manager regenerates the secrets. To manually initiate generation of a new secret:

  1. Delete both of the default secrets:

    • The certificate authority secret named ia-<IntegrationAssembly name>-ca in the same namespace as the integration assembly. Note that if the queue manager is in a different namespace, when this secret gets regenerated by the certificate manager, it is automatically copied to the same namespace as the queue manager.

    • The server secret named qm-<QueueManager name>-server.

  2. Delete any secrets created for client certificates, for example, those created in the previous section ("Create a client TLS certificate").

  3. When the certificate secrets are regenerated:

    • Restart the QueueManager pods.

    • Restart any clients.

Event Streams advanced settings

This section describes advanced configuration options for an Event Streams managed instance in an integration assembly. For information about default settings, see the section, "Event Streams managed instance" in Deploying an integration assembly.

Configuration examples

Increase the Kafka storage, replicas, and resources

The following is an example of how to increase:

  • Kafka storage from the default of 10Gi to 20Gi.

  • Kafka replicas from the default of 1 to 3.

  • Kafka resources from the default of 8Gi/4 CPUs to 12Gi/6 CPUs.

Note that this configuration leaves the storage class at the default.

managedInstances:
  list:
  - kind: EventStreams
    metadata:
      name: es1
    spec:
      strimziOverrides:
        kafka:
          storage:
            size: 20Gi
          replicas: 3
          resources:
            requests:
              memory: 12Gi
              cpu: 6000m
            limits:
              memory: 12Gi
              cpu: 6000m

Override the default storage classes

The following is an example of how to override the default storage classes used for Kafka and ZooKeeper:

managedInstances:
  list:
  - kind: EventStreams
    metadata:
      name: es1
    spec:
      strimziOverrides:
        kafka:
          storage:
            class: a-read-write-once-class-for-kafka
        zookeeper:
          storage:
            class: a-read-write-once-class-for-zookeeper