Configuring PMF Custom Resource (CR)

PMF CR parameters

Following are the configurable parameters of the PMF CR.

Optional tasks

Following are additional optional tasks you can perform.

Creating custom-defined console login secrets

By default, the console login secrets for all the PMF components are created automatically during the deployment.

One though choose to create Login Secret to access Server, Analytics, and Application Center console explictly. The secret created should be provided for the property consoleSecret in the charts_v1_mfoperator_cr.yaml file.

Example for PMF Server

kubectl create secret generic serverlogin --from-literal=MFPF_ADMIN_USER=admin --from-literal=MFPF_ADMIN_PASSWORD=admin

Example for Analytics

kubectl create secret generic analyticslogin --from-literal=MFPF_ANALYTICS_ADMIN_USER=admin --from-literal=MFPF_ANALYTICS_ADMIN_PASSWORD=admin

Example for Analytics Receiver

kubectl create secret generic analytics_recvrsecret --from-literal=MFPF_ANALYTICS_RECVR_USER=admin --from-literal=MFPF_ANALYTICS_RECVR_PASSWORD=admin

Example for Application Center

kubectl create secret generic appcenterlogin --from-literal=MFPF_APPCNTR_ADMIN_USER=admin --from-literal=MFPF_APPCNTR_ADMIN_PASSWORD=admin

Note: If these secrets are not provided, they are created with default username and password of admin/{random-password} during the installation of PMF.

Creating TLS secret for ingress configuration

PMF components can be configured with hostname-based Ingress for external clients to reach them using hostname. The Ingress can be secured by using a TLS private key and certificate. The TLS private key and certificate must be defined in a secret with key names tls.key and tls.crt.

The mf-tls-secret is created in the same namespace as the Ingress resource by using the following command.

kubectl create secret tls mf-tls-secret --key=/path/to/tls.key --cert=/path/to/tls.crt

The name of the secret is then provided in the field global.ingress.secret in the custom resource configuration yaml.

Creating custom keyStore secret for the deployments

You can provide your own keystore and truststore to Server, Push, Analytics, and Application Center deployment by creating a secret with your own keystore and truststore.

Pre-create a secret with thekeystore.jks and truststore.jks along with keystore and trustore password using the literals KEYSTORE_PASSWORD and TRUSTSTORE_PASSWORD provide the secret name in the field keystoreSecret of respective component.

Following is an example of creating keystore secret for the server deployment using keystore.jks, truststore.jks and set their passwords.

kubectl create secret generic server-secret --from-file=./keystore.jks --from-file=./truststore.jks --from-literal=KEYSTORE_PASSWORD=worklight --from-literal=TRUSTSTORE_PASSWORD=worklight

Note: The names of the files and literals should be the same as mentioned in above command. Provide this secret name in keystoresSecretName input field of respective component to override the default keystores when configuring the helm chart.

Creating secrets for confidential clients

PMF Server is predefined with confidential clients for Admin Service. The credentials for these clients are provided in the mfpserver.adminClientSecret and mfpserver.pushClientSecret fields.

Create these secrets by using the following commands.

kubectl create secret generic mf-admin-client --from-literal=MFPF_ADMIN_AUTH_CLIENTID=admin --from-literal=MFPF_ADMIN_AUTH_SECRET=admin

kubectl create secret generic mf-push-client --from-literal=MFPF_PUSH_AUTH_CLIENTID=admin --from-literal=MFPF_PUSH_AUTH_SECRET=admin

If the values for these fields mfpserver.pushClientSecret, mfpserver.adminClientSecret and mfpserver.liveupdateClientSecret are not provided during helm chart installation, default client secrets are created respectively with the following credentials.

• admin/nimda for mfpserver.adminClientSecret
• push/hsup for mfpserver.pushClientSecret
• liveupdate/etadpuevil for mfpserver.liveupdateClientSecret

Configuring custom server

To customise the configuration (for example, to modify a log trace setting or add a new jndi property and so on), you need to create a configmap with the configuration XML file. This allows you to add a new configuration setting or override the existing configurations of the PMF components.

The custom configuration is accessed by the PMF components through a mfpserver-custom-configconfigMap which can be created as follows -

kubectl create configmap mfpserver-custom-config --from-file=<configuration file in XML format>

The configmap created by using the above command should be provided in the Custom Server Configuration in the Helm chart while deploying PMF.

Following is an example of setting the trace log specification to warning (Default setting is info) using mfpserver-custom-config configmap.

• Sample config XML (logging.xml file)

    <server>
      <logging maxFiles="5" traceSpecification="com.ibm.mfp.*=debug:*=warning" 
      maxFileSize="20" />
    </server>
  

• Create configmap and add the above logging.xml during the helm chart deployment.

    kubectl create configmap mfpserver-custom-config --from-file=logging.xml
  

• Notice the change in the messages.log (of PMF components) - The traceSpecification property is set to com.ibm.mfp.=debug:\*=warning.

Using custom-generated Lightweight Third-Party Authentication (LTPA) keys

By default, the images of PMF bundles a set of ltpa.keys for each PMF component. In production environment, when there is a need to update the out-of-the-box ltpa.keys with custom generated ones, you can use custom configuration to add any custom generated ltpa.keys along with the config xml.

Sample config sample ltpa.xml

<server description="mfpserver">
    <ltpa
        keysFileName="ltpa.keys" />
    <webAppSecurity ssoUseDomainFromURL="true" />
</server>

Example command for adding the custom LTPA keys

kubectl create configmap mfpserver-custom-config --from-file=ltpa.xml --from-file=ltpa.keys

For more details about the LTPA keys generation and other details, see Configuring LTPA in Liberty.

Multiple custom-configmaps is not supported for adding custom configuration, instead it is recommended to create the custom configuration configmap as follows.

kubectl create configmap mfpserver-custom-config --from-file=ltpa.xml --from-file=ltpa.keys --from-file=moreconfig.xml

Using Taint and Tolerations

Taints and tolerations allow the node to control which pods should (or should not) be scheduled on them.

Adding a Taint to an Existing Node

You add a taint to a node using the oc adm taint command. For more information on the parameter usage, see Taint and Tolerations on the Redhat OpenShift Container Platform documentation site.

oc adm taint nodes <node-name> <key>=<value>:<effect>

Example

oc adm taint nodes worker-node1 dedicated=ibm-mf-server:NoExecute

Enabling a Toleration in CR

You can add toleration to a pod by enabling the tolerations property in the Custom Resource.yaml and by setting the required properties key, value, operator, and effect. By default, tolerations are set to false.

Example

To enable Toleration for mfpserver deployment use the following command.

tolerations:      
    enabled: true      
    key: "dedicated"      
    operator: "Equal"      
    value: "ibm-mf-server"      
    effect: "NoSchedule"