Cloud Pak for Business Automation

 View Only

User Management Services Deployment Guide for IBM Cloud Pak for Automation Beginners - Part 2

By Larissa Auberger posted Mon December 21, 2020 10:44 AM

Authors: Larissa Auberger, Benjamin Wende Reviewers: Jürgen Neth, Georg Sander, Jens Engelke


You have successfully deployed the IBM Cloud Pak for Automation operator following the User Management Services Deployment Guide for IBM Cloud Pak for Automation Beginners - Part 1

Provide configuration in the Custom Resource file

In Part 1 a Custom Resource Definition (CDR) has been added to the cluster and the operator has been deployed.
Now capabilities such as the User Management Services can be installed.
Capabilities are installed using the command line interface by leveraging a custom resource file.

A custom resource file defines the configuration that is shared across capabilities, as as the LDAP and datasource configuraiton.
A custom resource also has configuration sections dedicated to each of the capabilities.
The UMS section in the Custom Resource file starts with the key ums_configuration. If this key is available in the custom resource file, the operator detects the configuration and deploys UMS.

In addition, IBM Cloud Pak for Automation capabilities can be deployed using patterns. UMS is part of many patterns including content, workflow or decisions. UMS is "pattern-aware" of these patterns. By configuring a pattern in the custom resource file, UMS is automatically deployed without any configuration in the custom resouce file.

As we want to install UMS stand-alone, we will not be using a configuration pattern. Instead, we will adjust a custom resource template.

In IBM Cloud Pak for Automation a set of templates is provided that can be used to manually create a custom resource file. In IBM Cloud Pak for Automation, UMS is part of the foundation pattern. The foundation pattern is defined in ibm_cp4a_cr_enterprise_FC_foundation.yaml. Copy the file from descriptors/patterns directory of the cloned repository to your working directory.

Save ibm_cp4a_cr_enterprise_FC_foundation.yaml as a new file, for instance my-ums-cr.yaml.
Edit my-ums-cr.yaml

Shared Configuration

Provide or adjust the shared configuration in the Custom Resource file.

1. Accept the license

Accept the license:
  ## MUST exist, used to accept ibm license, valid value only can be "accept"
  ibm_license: "accept"
2. Verify the image pull secret
    ## All CP4A components must use/share the image_pull_secrets to pull images
    - admin.registrykey
and the image repository of the keytool_job container
   tag: 20.0.3
3. As we only want to install UMS, but the foundation pattern has other mandatory components, comment the sc_deployment_pattern parameter
 # sc_deployment_patterns: foundation
4. Specify OCP as the sc_deployment_platform
 sc_deployment_platform: OCP
5. Provide a valid host name for the deployment hostname suffix
 ## For OCP, this is used to create route, you should input a valid hostname in the required field.
sc_deployment_hostname_suffix: "{{ meta.namespace }}.<Required>"
Note: In OCP you can run this command to get the hostname:
oc get route console -n openshift-console -o yaml|grep routerCanonicalHostname
6. Create and provide the different storage classes for the slow, medium and fast storage parameters below. If you only have only one storage class defined, then you can use that storage class for all three parameters. To obtain the existing storage class in OCP, run
oc get storageclass
Specify this storage class
sc_slow_file_storage_classname: "<storage-class>"
sc_medium_file_storage_classname: "<storage-class>"
sc_fast_file_storage_classname: "<storage-class>"
7. If your intend is, for instance, to learn more about the UMS Teams capability, then you should configure UMS to connect to an LDAP server. With an LDAP connection you can create teams from LDAP users and groups or assign owners to teams. To configure LDAP, provide configuration in the section ldap_configuration:
  ## The beginning section of LDAP configuration for CP4A
Refer to LDAP configuration in the IBM Cloud Pak for Automation Knowledge Center
8. For evaluation purposes, you can configure derby as a datasource. In this case, the built-in database will be used. But note that you can not use multiple replicas, as each pod has its own database. For derby, you do not need to specify any other datasource parameters, comment them.
      dc_ums_oauth_type: derby
      dc_ums_teamserver_type: derby
Refer to Preparing the UMS database to configure DB2, Oracle, MSSQL or PostgreSQL as the datasource instead
9. Remove configuration for
  • IBM Business Automation Navigator 
  • Resource Registry 
  • BAStudio
  • AppEngine Playback server 
  • IBM Business Automation Insights 
  • IBM Business Automation Application/Service 

10. Save my-ums-cr.yaml.

UMS Configuration

Create UMS secrets

Before you deploy UMS you must manually create a secret to avoid passing sensitive information in configuration files. Create the secret configuration in a file, for instance ums-secrets.yaml, with the following content. Replace the content for the adminUser and adminPassword:

apiVersion: v1
kind: Secret
name: ibm-dba-ums-secret
type: Opaque
adminUser: "<umsadmin>"
adminPassword: "<my-secret-passw0rd>"

If you use configure UMS to use a database other than the built-in derby, additionally specify secrets for the oauth and the teamserver database in the stringData section:

  oauthDBUser: "<dbuser>"
oauthDBPassword: "<dbuser-password>"
tsDBUser: "<dbuser>"
tsDBPassword: "<dbuser-password>"

Create the secret

oc create -f ums-secrets.yaml

Provide or adjust the UMS configuration in the Custom Resource file

Edit my-ums-cr.yaml.

1. Verify the configuration for the image repository

        tag: 20.0.3


2.Verify the name of the secret that you previously created. It must be the value of the parameter admin_secret_name:

admin_secret_name: ibm-dba-ums-secret

3. For any of the UMS pods – sso, scim, teamserver – you can use the default configuration for now. However, if you use the built-in derby database, only replica_count: 1 makes sense, as with the built-in derby database the data is not shared across the pods. And: if you restart a pod, all configuration will be lost, as the data in the built-in database will disappear with the pod. You can also disable autoscaling when using the built-in derby database.

    # Configuration for sso pods
      replica_count: 1
          cpu: 500m
          memory: 512Mi
          cpu: 200m
          memory: 256Mi
       enabled: false
        minReplicas: 2
        maxReplicas: 5
        targetAverageUtilization: 98
        traceSpecification: "*=info"

Save the changes.

Deploy UMS

Deploy UMS by applying the CR

oc create -f my-ums-cr.yaml
During installation / startup, you see pods in different states (Init, PodInitializing, Running but not READY yet (0/1), finally Running and READY: 1/1). Wait for UMS pods to become READY.
oc get pods

UMS is now deployed on your OCP!

Verify the UMS installation

You can now access the User Management Services for investigation.
1.      Navigate to the OCP console and login as kubeadmin
2.      In the navigation click on Projects and select your project:

3. In the Navigation click on Workloads, then on Pods. You see the UMS and operator pods running. Click in the name and investigate the details in Overview, Environment, Logs etc.
4. In the navigation click in on Networking, then click on Rotes. These are the Routes to access the UMS services:

6. You see the UMS Login screen:

7. If you configured UMS to connect to an LDAP, authenticate with an LDAP user. Otherwise, use user id and the password that you specified in the ibm-dba-ums-secret for the ums administrator.
Happy investigations!

What to do next?

If you experienced issues with UMS deployment, refer to the Troubleshooting documentation to analyze and fix issues.

If you successfully deployed UMS, start investigating UMS Teams:
Access Management for Teams in UMS Teams service