Using `extraVolume` and `extraVolumeMounts` in IBM Connect:Direct Deployments

When deploying IBM Connect:Direct in Kubernetes environments, administrators may need to augment the container with additional storage locations for configuration files, scripts, logs, key stores, partner‑exchange directories, or other operational assets.

To support this requirement, the Connect:Direct deployment architecture includes two extensible configuration fields:

extraVolume
extraVolumeMounts

These fields allow users to define and mount additional hostPath or persistent volumes into the Connect:Direct container without modifying the base container image, maintaining flexibility and portability.

Purpose of `extraVolume` and `extraVolumeMounts`

The two fields work together as follows:

extraVolume – Defines additional Kubernetes volumes—such as hostPath, NFS, emptyDir, or PVC references—that should be attached to the pod.
extraVolumeMounts – Specifies where inside the Connect:Direct container each extra volume should be mounted.

This modular approach enables administrators to expand storage mappings in a controlled and repeatable way.

Default Volume Mount Example

The deployment may include a default mount (as illustrated in the documentation), but additional volumes can be layered using these fields.

Sample Configuration

Below is a complete example showing how to define and mount two custom volumes: one backed by a local host path and another backed by NFS.

extraVolume Definition

extraVolume:
  - name: svshare-volume
    hostPath:
      path: /svshare
      type: Directory

  - name: backup-volume
    nfs:
      path: <nfs data path>
      server: <server ip>

extraVolumeMounts Definition

extraVolumeMounts:
  - name: svshare-volume
    mountPath: /svshare

  # Replace BACKUP (/opt/backup)
  - name: backup-volume
    mountPath: /opt/backup

Summary

By leveraging `extraVolume` and `extraVolumeMounts`, IBM Connect:Direct Kubernetes deployments can be extended with custom storage mappings tailored to operational needs. This approach ensures:

Consistent configuration across environments
No changes required to the container image
Seamless integration with host‑based or network‑based storage
Flexibility for automation and DevOps pipelines

Ver também

Artigos sobre IBM Sterling