Integration Server Configuration is one of the Kubernetes custom resources that are defined by the IBM App Connect Operator in IBM Cloud Pak for Integration (V2020.1 and later). If you need to set up configurations for an integration server, you'll need to create Integration Server Configuration objects (will be referred to as configuration objects in this article) that store the contents of configuration files, and then assign them to the corresponding integration servers.
What is the purpose of a configuration object?
An integration flow contains the business logic of an integration solution, which should be reusable between environments and therefore not contain information such as connection details or account credentials. To fulfil this requirement, configuration objects can be used to store this information for integration flows, which include message flows and App Connect Designer flows.
For example, when using the IBM App Connect Enterprise Toolkit to deploy a message flow that produces messages onto a Kafka topic of a Kafka service (for example, IBM Event Streams), the connection information of the Kafka service (for example, bootstrapServers or authentication details) are provided by a policy project and mqsisetdbparms command. To deploy the same integration solution into an App Connect Dashboard instance in Cloud Pak for Integration, you can export and upload the message flow as a BAR file, and then define the connection information of the Kafka service as configuration objects.
Key design principles for configuration objects:
- Intuitive: Straightforward migration experience for developers who have set up the same configurations in the toolkit or App Connect Designer. The format of configuration objects is identical to the existing configuration files.
- Declarative: No stateful information that could cause configuration objects with identical contents to behave differently in different App Connect instances. The objects always produce the same outcome in a CI/CD pipeline.
- Secure: Configuration objects that contain secrets are stored in Kubernetes secrets.
How are configurations stored in configuration objects?
A configuration object is designed as a simple carrier object that stores the Base64-encoded raw contents of existing configurations:
- For configurations that are in file format (for example, server.conf.yaml or JKS keystore), the contents of those configurations are stored in configuration objects.
The name field of this configuration type is used as the file name in an integration server unless a fixed file name is required. For example, for a configuration of type server.conf.yaml, the contents are saved in a file named server.conf.yaml under the overrides directory of the work path instead of using the name of the configuration object.
- For configurations that are stored in a folder, a ZIP file containing the folder is stored in the configuration object. For example, for a policy project, the folder with the policy project name should be compressed and its Base64-encoded content should be used as the configuration object.
- For configurations that are currently not stored as files, alternatives have been provided. For example, mqsisetdbparms commands can be stored in a configuration of type
setdbparms as a text file that contains the parameters of the command.
You can find out more information about each type of configuration from here.
How are configuration objects secured?
To keep your sensitive data safe, some configuration types (for example, setdbparms or keystore) use Kubernetes secrets to store the Based64-encoded raw contents of the configuration data. If you are a command line interface (CLI) user, you've probably noticed that the data field (or contents field in earlier versions) is replaced by the secretName field after you create a configuration object. The following example illustrates this behavior.
Create a configuration object by running the oc create -f configuration_setdbparms.yaml command with the following contents:
apiVersion: appconnect.ibm.com/v1beta1
kind: Configuration
metadata:
name: setdbparms.txt
spec:
description: example setdbparms
data: c2V0ZGJwYXJtczo6dHJ1c3RzdG9yZSBkdW1teSBwYXNzcm9kcw==
type: setdbparms
Inspect the created configuration object by running the oc get configuration.appconnect.ibm.com setdbparms.txt -oyaml command. Notice that the data field is replaced with secretName field:
apiVersion: appconnect.ibm.com/v1beta1
kind: Configuration
metadata:
creationTimestamp: "2020-09-18T15:27:43Z"
name: setdbparms.txt
spec:
description: example setdbparms
secretName: setdbparms.txt-wmq7g
type: setdbparms
Only with privileged access can you retrieve the secret object by running oc get secret setdbparms.txt-wmq7g -oyaml.
This mutation is performed by the Mutating Admission Webhook of configuration objects. The webhook detects configuration objects with a secret type, and automatically stores the contents of those configuration objects into Kubernetes secrets. The generated Kubernetes secrets are managed by the IBM App Connect Operator. The names of those Kubernetes secrets are stored in a secretName field so that a cluster administrator can use it for advanced debugging.
Unless you have a good reason to manage your own set of Kubernetes secrets, you should always use the data field (or contents field in earlier versions) to specify the contents of the configuration object that you are creating.
How does an integration server access the configurations stored in configuration objects?
The IntegrationServer custom resource contains a list of configuration objects that it requires. The contents of those configuration objects are extracted and used by the integration server during its start up.
A configuration object cannot be deleted if it's being used by at least one integration server. This validation is enforced by the Validating Admission Webhook of configuration objects.
A configuration object can be updated at any time, but will not be picked up by an integration server until the integration server restarts.
Summary
A configuration object is a Kubernetes custom resource that is provided by the IBM App Connect Operator, and is designed to be a storage object of integration configurations with intuitive, declarative, and secure characteristics. This helps you to manage all your configurations in one place as first-class operator objects.
#AppConnect#IBMCloudPakforIntegration(ICP4I)