IBM InfoSphere MDM - How to redeploy Enterprise Business Application when part of it is deleted

The application MDM-operational-server-EBA comprises of assets and bundles.  When one of these components gets deleted, the below steps can be followed to uninstall the components manually and install them back using utilities, to get the EBA working.

1. Go to Applications -> MDM-operational-server-EBA-<INSTANCE_ID> and delete all the Assets there.

2. Go to Applications -> Assets and delete all the Assets listed there.

3. Go to Environment -> OSGI Bundle Repositories -> Internal Bundle Repositories and delete all the bundles listed there.

4. Delete the Business Level Application MDM-operational-server-EBA-<INSTANCE_ID>

5. Synchronise the nodes and Save.

6. Replace the placeholder <INSTANCE_IDENTIFIER> with the value of instance id (similar to E001).  Go to <MDM_INSTALL_DIR>/mds/scripts and invoke the below madconfig targets.  Use madconfig.sh or madconfig.bat based on the OS, in this case, we assume that the OS is Linux.

./madconfig.sh install_mdm_eba install_prop_file_jar map_roles_to_users -DblaName=MDM-operational-server-EBA-<INSTANCE_IDENTIFIER> -DpropFileJarName=com.ibm.mdm.server.resources.properties-<INSTANCE_IDENTIFIER>.jar

For example:
./madconfig.sh install_mdm_eba install_prop_file_jar map_roles_to_users -DblaName=MDM-operational-server-EBA-E001 -DpropFileJarName=com.ibm.mdm.server.resources.properties-E001.jar

Please note that we are passing in two parameter values using the -D option.

7. During target execution, provide appropriate values for passwords.  For BLA User and BLA Password, provide values for MDM Administrator User and Password respectively.

8. After completion of targets' execution, synchronise the nodes and restart the application server.

9. Execute IVT to confirm that the EBA has started successfully.

Kubernetes Ingress Resource for HTTPS Service deployed on WebSphere Application Server

As a beginner to Kubernetes, the link to Ingress clearly explained how to write a fanout rule, but writing one to access HTTPS links on WebSphere took me time.  The concepts of TLS Secrets and certain annotations in Ingress along with certain custom parameters to be added to the Web Container were the primary concepts to be applied for it.

Secrets:
There are certain types of Secrets in Kubernetes, including those to access repositories. 
To access HTTPS links of WebSphere, we need to create a Secret of type TLS.  The steps to create a TLS certificate mention about a key file and certificate file.

kubectl create secret tls ${CERT_NAME} --key ${KEY_FILE} --cert ${CERT_FILE}

 Normally, WebSphere Base Profiles are used with the Docker images that are deployed on Kubernetes.  The TLS certificate is created using the Key file (key.p12) located at <WAS_PROFILE_HOME>/config/cells/<CELL>/nodes/<NODE>  The steps to obtain the key file and the cert file using openssl tool are provided below.

openssl pkcs12 -in key.p12 -nokeys -out cert.pem
openssl pkcs12 -in key.p12 -nodes -nocerts -out cert.key

With this, you can create a certificate cert of type TLS using
kubectl create secret tls cert --key cert.pem --cert cert.key

Such a certificate has to be associated with each tls service that is referred to in an ingress resource yml file.  Please find a sample snippet below:
  tls:
  - hosts:
    - sample
    secretName: cert
Here sample is a Service which is referred in the rules section  of the Ingress resource and the tls type Secret cert is used to obtain access to it.   Note that we have created cert from the key.p12 file that is part of the Pod that the Service sample logically represents.

Annotations:
The annotation nginx.org/ssl-services has to be used to specify services that have to be accessed with Security using the TLS secret.  The below is a sample:
metadata:
  annotations:
    nginx.org/ssl-services: sample

Port Redirection in WebSphere Application Server:
Ingress provides us two ports, one corresponding to SSL and one corresponding to non-SSL.  It is also capable of determining the port based on the protocol used.  However, these ports will not be the same as those exposed by WAS Profiles.  The default behaviour of port redirection with WAS Profiles has to be overcome to use it with Ingress.  In order to do this we need to set two custom properties, trusthostheaderport and com.ibm.ws.webcontainer.extractHostHeaderPort, to value true at the Web Container associated with the WAS server.  Note that this change has to be done to the image used with Kubernetes.