Persistent Mobile Foundation Custom Resource (CR) configuration

Parameters

[OPTIONAL] Creating Custom Defined Console Login secrets

By default, the console login secrets for all the PMF components are created automatically during the deployment. Optionally one can 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 charts_v1_mfoperator_cr.yaml. Following is the example.

For Server,

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

For Analytics,

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

For Analytics receiver,

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

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.

[OPTIONAL] 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 secret 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.

[OPTIONAL] 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 keystore.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.

Below 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 command above. Provide this secret name in keystoresSecretName input field of respective component to override the default keystores when configuring the helm chart.

[OPTIONAL] 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.

These secrets can be created as follows:

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 below credentials as follows:

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

[OPTIONAL] Custom Server Configuration

To customise the configuration (example: modifying a log trace setting, adding a new jndi property and so on), you will have 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 configMap (mfpserver-custom-config) which can be created as follows -

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

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

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

• Sample config XML (logging.xml)

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

• Creating configmap and add the same 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) - Property traceSpecification will be set to com.ibm.mfp.=debug:*=warning.

[OPTIONAL] Using custom generated 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.

Following is the config sample ltpa.xml.

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

The following command is an example of 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, refer to the Liberty documentation.

Note: Having 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

[OPTIONAL] Using Taint and Tolerations

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

Note: This feature is only available on PMF component images version 9.1.0 or later.

Adding a Taint to an Existing Node

You add a taint to a node using the oc adm taint command. Refer to Taint and Tolerations to know more about the parameter usage.

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

For example:

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

Enabling a Toleration in Custom Resource

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.

For example:

Enabling Toleration for mfpserver deployment:

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