1. Deploying Siebel CRM Containers on Kubernetes using Siebel Cloud Manager
  2. Installing SCM using Helm

Installing SCM using Helm

This topic describes the steps to install SCM on a Kubernetes cluster on premises or in the cloud or in your data center on OC3 using Helm.

This topic includes the following sections:

Before Installing SCM

You must perform the following preinstallation tasks before installing SCM on a Kubernetes cluster:

  1. Ensure you've access to the installation directory and container registry provided in Siebel Installer.
  2. Create an image pull secret: A pod uses a secret to pull an image from the container registry. To use the SCM image and SCM Helm chart from the container registry, create a secret using the kubectl command as follows:
    kubectl -n <namespace> create secret docker-registry <secretName> --docker-server=<registryURL> --docker-username=<userName> --docker-password=<password> --docker-email=<email>

    The variables in the example have the following values:

    • <namespace> is the name of the namespace you want to install SCM in.
    • <secretName> is the name of the secret.
    • <registryURL> is the container registry URL to which the SCM image and SCM Helm chart were pushed by Siebel Installer.
    • <userName> is the container registry user name.
    • <password> is the container registry user password.
    • <email> is the container registry user email.
  3. Update the values.yaml file: The SCM Helm package includes a default values.yaml file which determines how SCM will be configured. Before installing SCM, you must update the values.yaml file to configure SCM as per your requirements. To update the values.yaml file:
    1. Open the values.yaml file. You can use the values.yaml file in either:
      • The installation directory on the Linux host machine that was used to run Siebel installer, or
      • The SCM Helm chart in your container registry. To use the values.yaml in the container registry:
        1. Sign in to the container registry as follows:
          helm registry login <registry>

          In this example, <registry> is the basename of the container registry.

        2. Pull the SCM Helm chart from the container registry:
          helm pull oci://<registry>/<repositoryPath> --version <releaseVersion>

          The variables in the example have the following values:

          • <registry> is the container registry basename.
          • <repositoryPath> is the SCM Helm chart (cloudmanager) repository path.
          • <releaseVersion> is the SCM release version.
    2. Unzip the SCM Helm chart zip file as follows:
      tar -zxf cloudmanager_CM_<releaseVersion>.tgz

      In this example, <releaseVersion> is the SCM release build version that you downloaded.

    3. Update the following sections in the values.yaml file:
      • The image section with the container registry details (provided in the Siebel Installer configuration tasks) from which the SCM image and SCM Helm chart will be used for deployment, as follows:
        image:
      registry: "<registryURL>"               
      repository: "<imageRepository>"     
      tag: "<imageTag>"                   
      imagePullPolicy: IfNotPresent

        The variables in the example have the following values:

        • <registryURL> is the container registry URL that was provided in the installer configuration tasks.
        • <imageRepository> is the container registry prefix that was provided in the installer configuration tasks.
        • <imageTag> is the SCM release version.
        • <imagePullPolicy> determines when the SCM image is pulled from container registry. It can take the following values: IfNotPresent, Always or Never.
      • (Optional) The resources section with resource (CPU, memory, and ephemeral storage) allocation for the SCM pod. The default limits and requests values already specified for the resources in the values.yaml are sufficient for Siebel CRM deployment, but you can update these values as required as per the size of your Siebel CRM deployment.
      • The storage section with the network file system (NFS) path for SCM and Siebel CRM deployment as follows:
        storage:
      nfsServer: <nfsServer> 
      nfsPath: <nfsPath> 
      storageSize: 200Gi

        The variables in the example have the following values:

        • <nfsServer> is the IP address or fully qualified domain name of the NFS server.
        • <nfsPath> is the export path in the NFS server to access the SCM file system.
      • The imagePullSecrets section with the secret name required to pull the SCM image from the container registry as follows:
        imagePullSecrets:
      name: <secretName>

        In this example, <secretName> is the name of the secret you created in the step 1 of this section.

      • The sshKeysection with the public and private key file names required for establishing connection between Git repository and Fluxcd operator as follows:
        1. Create a SSH key pair as follows:
          % ssh-keygen
Generating public/private ed25519 key pair.
Enter file in which to save the key (/Users/<uname>/.ssh/id_ed25519): /Users/<uname>/sample
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/<uname>/sample
Your public key has been saved in /Users/<uname>/sample.pub

          In this example, <uname> is the user name.

        2. Copy the private and public key files to the ssh directory in the SCM Helm chart home directory (cloudmanager).
        3. Update the sshKey section with the private and public key file names:
          sshKey:
      pvtKeyFilename: <privateKeyFilename>
      pubKeyFilename: <publicKeyFilename>

          The variables in the example have the following values:

          • <privateKeyFilename> is the private key file name.
          • <publicKeyFilename> is the public key file name.
      • The ociConfig section with the details of the files required for OCI API authentication to access OCI infrastructure services in an OC3 environment as follows:
        Note: You must configure the caCrtFilename and ociCliRcFilename parameters only when deploying Siebel CRM in OC3.
        ociConfig:
      ociPvtKeyFilename:<ociPrivateKeyFilename>
      caCrtFilename: <caCertificateFileName>
      ociCliRcFilename : <cliRCFileName>

        The variables in the example have the following values:

        • <ociPrivateKeyFilename> is the private key PEM file name. For example, oci_api_key.pem.
        • <caCertificateFileName> is the CA certificate file name. For example, ca.crt.
        • <cliRCFileName> is the OCI CLI RC configuration file name.For example, oci_cli_rc.
      • The instanceMetaData section with the applicable region and compartment OCID values as follows:
        instanceMetaData:
      vaultEnabled: "False"                                   
      region: <region>                                
      compartmentOcid: <compartmentOCID>
      ociDeployment: <deploymentType>

        The variables in the example have the following values:

        • <region> is the canonical region name. For example, us-ashburn-1.
        • <compartmentOCID> is the OCID of the compartment used for Oracle Cloud Infrastructure (OCI) calls.
        • <deploymentType> determines the environment on which you are deploying Siebel CRM. If you are deploying Siebel CRM on:
          • A CNCF certified Kubernetes cluster on premises or in the cloud, set the value of this parameter to "false". This parameter is of string type, so ensure you enclose false in quotes.
          • OC3 in your data center, set the value of this parameter to "oc3".
          • OCI, set the value of this parameter to "public".
      • The userEncryptionKey section, enable this section and update it only when the vaultEnabled parameter is set to false.
        userEncryptionKey:
      uek: "<encryptionkey>"

        In this example, <encryptionkey> is a key which matches the following expression: ^[a-zA-Z0-9]{56,60}$

      • The service section with the service type that will be used to expose SCM deployment as follows:
        service:
      serviceType: <servicetype>

        In this example, <servicetype> can be one of the following: ClusterIP, NodePort or LoadBalancer. Since SCM is exposed over https, it requires an SSL certificate.

        You can use your SSL certificate or allow SCM to generate it. If you set the useCustomSSLCertificate parameter to:

        • true: You can use your SSL certificate as follows:
          1. Copy your SSL certificate to the ssl directory in the SCM Helm chart home directory.
          2. Update the certificatePath, keyPath and caCertPath parameters with the relative path of the certificate under the scmCustomCert section.
            Note: You must update the caCertPath parameter under the scmCustomCert section with the appropriate path only when you set the useDualTls parameter to true under the loadBalancer section.
        • false: SCM generates the self-signed SSL certificate based on parameters configured under the scmSelfSignedCert section.

          Configure other parameters applicable for the service type:

          • NodePort and ClusterIP: The customMetadata, customLabels and customAnnotations sections are optional. The following is a sample of the service section for NodePortservice type:
            service:
      serviceType: "NodePort" name: "scm-app-svc"
      useCustomSSLCertificate: false 
      scmCertSecret:
            name: "scm-app-ssl" 
            customMetadata: {} 
            customLabels: {} 
            customAnnotations: {}
      scmSelfSignedCert: 
            country: "US" 
            state: "California"
            locality: "San Francisco" 
            organization: "Oracle Corporations" 
            commonName: "oracle.com"
      scmCustomCert:
            certificatePath: "ssl/scm.crt" 
            keyPath: "ssl/scm.key" 
            caCertPath: "ssl/ca.crt"
      customMetadata: {} 
      customLabels: {}
      customAnnotations: {}
          • LoadBalancer: The customAnnotations section is mandatory and you must configure other parameters under this section as follows:
            • Configure the exposedPort parameter to expose SCM at specific port.
              Note: You must use the same port in the annotations added under the customAnnotations section of the service section. For example, if exposedPort is set to 443, under the customAnnotations section of the service section, add the following annotation: 
              service.beta.kubernetes.io/oci-load-balancer-ssl-ports: "443"
            • Set the useDualTls parameter to true to enable end-to-end TLS for SCM; in this case, the Load Balancer uses two sets of SSL certificates:
              • Listener certificate that is stored as a Kubernetes secret under the loadBalancer section.
              • Backend-set certificate that is stored as a kubernetes secret under the service section.
            • If the useCustomSSLCertificate parameter under the service section is set to:
              • true: Copy your SSL certificate under ssl directory in the SCM Helm chart home directory and update the relative path of the certificate under the customCert section under the loadBalancer section. Additionally, if the useDualTLs parameter is set to true then you must also configure the scmCustomCert section under the service section.
              • false: SCM generates a self-signed SSL certificate based on parameters configured under the selfSignedCert section under loadBalancer section. Additionally, if the useDualTLs parameter is set to true then you must also configure the scmSelfSignedCert section under the service section.
        Note: The customAnnotations section must have annotations with the correct secret name for listener certificates and backend-set certificates.

        The following is a sample of the customAnnotations and loadBalancer sections when deploying Siebel CRM in OC3 using LoadBalancer as the serviceType:

        service:
      serviceType: "LoadBalancer"
      name: "scm-app-svc"
      useCustomSSLCertificate: false
      customAnnotations:
            oci.oraclecloud.com/load-balancer-type: "lb"
            service.beta.kubernetes.io/oci-load-balancer-tls-secret: scm-lb-ssl
            service.beta.kubernetes.io/oci-load-balancer-internal: "false"
            service.beta.kubernetes.io/oci-load-balancer-shape: "flexible"
            service.beta.kubernetes.io/oci-load-balancer-shape-flex-min: "10"
            service.beta.kubernetes.io/oci-load-balancer-shape-flex-max: "100"
            service.beta.kubernetes.io/oci-load-balancer-subnet1: 
                  "ocid1.xxxxx.xxx.xx.xxxxxxxxx................speygundxpjuhu23lorqq"
                  oci.oraclecloud.com/oci-load-balancer-listener-ssl-config:
                  '{"CipherSuiteName":"oci-default-http2-tls-12-13-ssl-cipher-suite-v1",
                  "Protocols":["TLSv1.2","TLSv1.3"]}'
            service.beta.kubernetes.io/oci-load-balancer-ssl-ports: "443"
      loadBalancer:
            exposedPort: 443
            useDualTls: "False"
            certSecret:
                  name: "scm-lb-ssl"
                  customMetadata: {}
                  customLabels: {}
                  customAnnotations: {}
            selfSignedCert:
                  country: "US"
                  state: "California"
                  locality: "San Francisco"
                  organization: "Oracle Corporations"
                  commonName: "oracle.com"
            customCert:
                        certificatePath: "ssl/lb.crt"
                        keyPath: "ssl/lb.key"
        Note: If you updated the values.yaml that you pulled from the container registry, you can push the updated SCM Helm chart in to the container registry after updating the values.yaml file as follows:
        tar -zcf cloudmanager_CM_updated_<releaseVersion>.tgz
helm push cloudmanager_CM_updated_<releaseVersion>.tgz oci://<registry>/<repositoryPath>

        The variables in the example have the following values:

        • <registry> is the container registry basename.
        • <repositoryPath> is the SCM Helm chart (cloudmanager) repository path.
        • <releaseVersion> is the SCM release version.

Installing SCM

This section describes the steps to install SCM on a Kubernetes cluster on premises or in the cloud or in your data center on OC3 using Helm.

To install SCM using Helm:

  1. Go to the SCM Helm chart directory and run the Helm install command as follows:
    cd cloudmanager
helm install <releaseName> . -n <namespace> --timeout 30m

    The variables in the example have the following values:

    • <releaseName> is the SCM Helm chart instance identifier.
    • <namespace> is the name of the namespace to install SCM in.
  2. Verify that the SCM pod is running and fetch the endpoint URL for SCM using the following command:
    kubectl get pods -n <namespace>
  3. Build the SCM application URL (when the service type is NodePort) as follows:
    1. Get a node IP address: 
      kubectl get nodes –wide
      Note: The SCM application port is mapped to all active nodes, hence any node IP can be used to build the SCM application URL. You can copy the external IP (if available) or the internal IP as per your Kubernetes configuration.
    2. Get the assigned node port number from the service (Port Range 30000 – 32767):
      kubectl get svc/scm-app-service -n <namespace>
    3. Build the SCM application URL using the node IP address and node port as follows: 
      https://<nodeIPAddress>:<nodePortNumber>

      The variables in the example have the following values:

      • <nodeIPaddress> is any active node IP address.
      • <nodePortNumber> is the assigned node port number.
    Note: When the serviceType is set to LoadBalancer, build the SCM application URL as follows:
    1. Get the external IP and port:
      kubectl get svc -n <namespace>
    2. Build the SCM application URL using the external IP and port number as follows:
      https://<externalIP>:<PortNumber>
  4. Access the SCM application URL and verify that the swagger page is loading correctly.