Using 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 and configure the resources managed by an assembly.
For information on deploying an assembly, see Integration assembly deployment.
Integration assembly advanced settings
These advanced configuration options that change the behavior of an assembly.
Disable dry webhook check
Before an instance of an 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 assembly. For example:
metadata:
annotations:
"operator.ibm.com/ia-managed-instances-dry-run": "false"
Queue manager advanced settings
The following are advanced configuration options that you can apply to a queue manager managed instance in an assembly. For information about default settings, see the section, "Queue manager managed instance" in Integration assembly deployment.
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.
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
Update the
mqsc
section in the Config map and list the default generated Config map (namedqm-<.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.
The Issuer
created by the assembly 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 theIssuer
created by theIntegrationAssembly
ofqm-<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:
Delete both of the default secrets:
The certificate authority secret named
ia-<IntegrationAssembly name>-ca
in the same namespace as the assembly. 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
.
Delete any secrets created for client certificates, for example, those created in the previous section ("Create a client TLS certificate").
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 assembly. For information about default settings, see the section, "Event Streams managed instance" in Integration assembly deployment.
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
Integration runtime advanced settings
This section describes advanced configuration options for a managed integration runtime in an assembly. For information about default settings, see the section, "Integration runtime managed instance" in Integration assembly deployment.
Configuration examples
Apply BAR URLs and configurations The following is an example of how to add BAR files and configurations to integration runtimes. For more information on configurations see Confiuration Reference and BarAuth type.
managedIntegrations:
list:
- kind: IntegrationRuntime
metadata:
name: ir1
spec:
barURL:
- <barURL>
configurations:
- <Configurations1>
- <Configurations2>