IBM® App Connect Enterprise is a market-leading lightweight enterprise integration engine that offers a fast, simple way for systems and applications to communicate with each other. As a result, it can help you achieve business value, reduce IT complexity and save money. IBM App Connect Enterprise supports a range of integration choices, skills and interfaces to optimize the value of existing technology investments.

This chart deploys a single IBM App Connect Enterprise for Developers integration server into a Kubernetes environment.

• Kubernetes 1.11.0 or later, with beta APIs enabled
• A user with operator role is required to install the chart
• If persistence is enabled (see configuration), you must either create a persistent volume; or specify a storage class if classes are defined in your cluster
• If you are using SELinux you must meet the MQ requirements

To separate secrets from the Helm release, a secret can be preinstalled with the following shape and referenced from the Helm chart with the integrationServer.configurationSecret value. Substitute <alias> with a reference to your certificate:

apiVersion: v1
kind: Secret
metadata:
  name: <secretName>
type: Opaque
data:
  adminPassword:
  agentc:
  agentp:
  agentx:
  appPassword:
  ca.crt:
  extensions:
  keystoreCert-<alias>:
  keystoreKey-<alias>:
  keystorePass-<alias>:
  keystorePassword:
  mqsc:
  odbcini:
  policy:
  policyDescriptor:
  serverconf:
  setdbparms:
  switch:
  tls.cert
  tls.key
  truststoreCert-<alias>:
  truststorePassword:

Below is an example of the format of the secret where two certs are being supplied

apiVersion: v1
kind: Secret
metadata:
  name: sample-configuration-secret
type: Opaque
data:
  adminPassword:
  agentc:
  agentp:
  agentx:
  appPassword:
  ca.crt:
  extensions:
  keystoreCert-MyCert1:
  keystoreKey-MyCert1:
  keystorePass-MyCert1:
  keystoreCert-MyCert2:
  keystoreKey-MyCert2:
  keystorePass-MyCert2:
  keystorePassword:
  mqsc:
  odbcini:
  policy:
  policyDescriptor:
  serverconf:
  setdbparms:
  switch:
  truststoreCert-MyCert1:
  truststoreCert-MyCert2:
  truststorePassword:

The following table describes the secret keys:

If using ibm-ace-dashboard-dev for managing integration servers then further instructions and helper script are provided when adding a server. A full set of working example secrets can be found in the pak_extensions/pre-install directory.

This chart requires a SecurityContextConstraints to be bound to the target namespace prior to installation. To meet this requirement there may be cluster-scoped, as well as namespace-scoped, pre- and post-actions that need to occur.

The predefined SecurityContextConstraints ibm-anyuid-scc has been verified for this chart. If your target namespace is not bound to this SecurityContextConstraints resource you can bind it with the following command:

oc adm policy add-scc-to-group ibm-anyuid-scc system:serviceaccounts:<namespace> For example, for release into the default namespace:

oc adm policy add-scc-to-group ibm-anyuid-scc system:serviceaccounts:default

• Custom SecurityContextConstraints definition:

apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
metadata:
  name: ibm-ace-scc
spec:
  allowPrivilegeEscalation: true
  fsGroup:
    rule: RunAsAny
  requiredDropCapabilities:
  - MKNOD
  allowedCapabilities:
  - SETPCAP
  - AUDIT_WRITE
  - CHOWN
  - NET_RAW
  - DAC_OVERRIDE
  - FOWNER
  - FSETID
  - KILL
  - SETUID
  - SETGID
  - NET_BIND_SERVICE
  - SYS_CHROOT
  - SETFCAP
  runAsUser:
    rule: RunAsAny
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  volumes:
  - configMap
  - emptyDir
  - projected
  - secret
  - persistentVolumeClaim
  forbiddenSysctls:
  - '*'

This chart uses the following resources by default:

• 1 CPU core
• 1 GiB memory without MQ
• 2 GiB memory with MQ

If a sidecar container for running flows authored in App Connect Designer is deployed into the pod, the following resources will also be used by default:

• 1 CPU core
• 256 MiB memory

See the configuration section below for how to configure these values.

Deploying an IBM App Connect Enterprise integration server directly with this chart will instantiate an empty integration server. BAR files will have to be manually deployed to this server, and those BAR file deployments will not persist across a restarted pod.

Alternatively, go back to the catalog to install an IBM App Connect Enterprise dashboard (ibm-ace-dashboard-dev). This dashboard provides a UI to upload BAR files and deploy and manage integration servers.

If using a private Docker registry, an image pull secret needs to be created before installing the chart. Supply the name of the secret as the value for image.pullSecret.

To install the chart with the release name ace-server-dev:

helm install --name ace-server-dev ibm-ace-server-dev --set license=accept --tls

This command accepts the IBM App Connect Enterprise license and deploys an IBM App Connect Enterprise integration server on the Kubernetes cluster. Note that this will deploy an empty integration server. If you have an IBM App Connect Enterprise dashboard, you can get a content server URL and set it in the release with the following command:

helm install --name ace-server-dev ibm-ace-server-dev --set license=accept --set contentServerURL="{your content server URL}" --tls

The configuration section lists the parameters that can be configured during installation.

Tip: See all the resources deployed by the chart by using kubectl get all -l release=ace-server-dev.

See the instruction (from NOTES.txt in the chart) after the helm installation completes for chart verification. The instruction can also be viewed by running the command:

helm status ace-server-dev --tls`

To uninstall/delete the ace-server-dev release:

helm delete --purge ace-server-dev --tls

The command removes all the Kubernetes components associated with the chart, except any persistent volume claims (PVCs). This is the default behaviour of Kubernetes, and ensures that valuable data is not deleted.

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

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.

When choosing to deploy the 'App Connect Enterprise with MQ Server' image (imageType=acemqserver) the chart mounts a Persistent Volume for the storage of MQ configuration data and messages. By using a persistent volume (PV) based on network-attached storage, Kubernetes can re-schedule the MQ server onto a different worker node. You should not use "hostPath" or "local" volumes, because this will not allow moving between nodes. The default size of the persistent volume claim is 2Gi.

Performance requirements will vary widely based on workload, but as a guideline, use a storage class which allows for at least 200 IOPS (based on a block size of 16 KB with a 50/50 read/write mix).

For volumes that support ownership management, such as NFS, specify the group ID of the group owning the persistent volumes' file systems using the integrationServer.fsGroupGid parameter. NFS and some other storage classes also require the acemq.initVolumeAsRoot parameter to be enabled so that root permissions can be used to initialize the volume for MQ.

If not using dynamic provisioning: You only need to have an available PV, that is, one that is not already bound). You do not need to create a persistent volume claim (PVC); installation of this chart automatically creates it and binds it to an available PV. The name entered in dataPVC.name will become part of the final name of the PVC created by the chart. Supply a dataPVC.size that is no bigger than the size of the PV created previously so that the volume is claimed by the PVC.

This chart uses the following resources per pod by default:

• Using the 'App Connect Enterprise only' or 'App Connect Enterprise with MQ Client' images (aceonly or acemqclient):
  • 1 CPU core
  • 1024 Mi memory
• Using the 'App Connect Enterprise with MQ Server' image (acemqserver):
  • 1 CPU core
  • 2048 Mi memory

If a sidecar container for running flows authored in App Connect Designer is deployed into the pod, the following resources will additionally be used for that container by default:

• 1 CPU core
• 256Mi memory

See the configuration section for how to configure these values.

The log.format value controls whether the format of the output logs is:

• basic: Human readable format intended for use in development, such as when viewing through kubectl logs
• json: Provides more detailed information for viewing through Kibana

On the command line, you can use utilities like 'jq' to format this output, for example:

kubectl logs foo-ibm-mq-0 | jq -r '.ibm_datetime + " " + .message'

This delivery includes sample code which makes provision for future use of MQ multi-instance queue managers in a high availability scenario. This full feature is not available for production in this release but is intended to be available in the near future.

This chart has replaced the Local default Queue Manager checkbox with a Which type of image to run dropown list. That's because this chart now comes with an additional Docker image, the App Connect Enterprise with MQ client image. Users of Server 2.0.0 and later releases, can reuse existing values when upgrading but must ensure that the new option has the correct value to maintain your image selection.

This chart has changed the way we specify images. Previously we used a common tag across all images. In this release we have moved to including the tag with the name of the image. If you have customised the image name you will need to make sure that when upgrading you include the image tag on the appropriate image value

The pki.trust and pki.keys allow you to supply details of Kubernetes secrets that contain TLS certificates. The TLS certificates are imported into the container at runtime and MQ will be configured to use them. You can supply certificates that contain only a public key and certificates that contain both public and private keys.

If you supply invalid files or invalid YAML objects, the container terminates with an appropriate message. The following two sections detail the requirements for supplying each type of certificate.

When supplying a Kubernetes secret that contains certificate files for both the public and private key, ensure that the secret contains two files with the same name, one with a suffix of .crt and the other with a suffix of .key. For example: tls.crt and tls.key. The extension of the file denotes whether the file is the public key (.crt) or the private key (.key) and must be correct. If your certificate has been issued by a Certificate Authority, then the certificate from the CA must be included as a separate file with the .crt extension. For example: ca.crt.

The format of the YAML objects for pki.keys value is as follows:

- name: mykey
  secret:
    secretName: mykeysecret
    items:
      - tls.key
      - tls.crt
      - ca.crt

or, alternatively, in a single line, you can supply the following:

- name: mykey, secret: {secretName: mykeysecret, items: [tls.key, tls.crt, ca.crt]}

name must be a lowercase alphanumeric value and is used as the label for the certificate in the keystore and queue manager.

secret.secretName must match the name of a Kubernetes secret that contains the TLS certificates you wish to import.

secret.items must list the TLS certificate files contained in secret.secretName you want to import.

To supply the YAML objects when deploying via Helm you should use the following: --set pki.keys[0].name=mykey,pki.keys[0].secret.secretName=mykeysecret,pki.keys[0].secret.items[0]=tls.key,pki.keys[0].secret.items[1]=tls.crt,pki.keys[0].secret.items[2]=ca.crt

If you supply multiple YAML objects then the queue manager will use the first object chosen by the label name alphabetically. For example if you supply the following labels: alabel, blabel and clabel. The queue manager and MQ Console will use the certificate with the label alabel for its identity. In this queue manager this can be changed by running the MQSC command: ALTER QMGR CERTLABL('<new label>').

When supplying a Kubernetes secret that contains a certificate file with only the public key, ensure that the secret contains files that have the extension .crt. For example: tls.crt and ca.crt.

The format of the YAML objects for pki.trust value is as follows:

- secret:
    secretName: mycertificate
    items:
      - tls.crt

or alternatively in a single line you can supply the following: - secret: {secretName: mycertificate, items: [tls.crt]}

secret.secretName must match the name of a Kubernetes secret that contains the TLS certificates you wish to add.

secret.items must list the TLS certificate files contained in secret.secretName you want to add.

To supply the YAML objects when deploying by using Helm you should use the following:

--set pki.trust[0].secret.secretName=mycertificate,pki.trust[0].secret.items[0]=tls.crt

If you supply multiple YAML objects then all of the certificates specified will be added into the queue managers and MQ Console Truststore.

View the IBM App Connect Enterprise Dockerfile repository on Github

View the Official IBM App Connect Enterprise for Developers Docker Image in Docker Hub

Learn more about IBM App Connect Enterprise

Learn more about IBM App Connect Enterprise and Docker

Learn more about IBM App Connect Enterprise and Lightweight Integration