Deploy BDS

From Genesys Documentation
Jump to: navigation, search
This topic is part of the manual Billing Data Service Private Edition Guide for version Current of Billing Data Service.

Learn how to deploy Billing Data Service (BDS).

Related documentation:

Prepare your environment

OpenShift

  1. In the OpenShift UI, on the menu where your user name appears, select Copy Login Command.
    A token and command for login appears.
  2. Log in to cluster with OC CLI:
    oc login --token=$token --server=https://api.vce-c0.eps.genesys.com:6443
  3. Check if the cluster is running:
    oc get clusterversion
  4. If the project doesn't already exist, create new project:
    oc new-project bds
  5. Create Secret for accessing the JFrog registry and map it to the genesys account:
    oc create secret docker-registry mycred --docker-server=pureengage-docker-staging.jfrog.io --docker-username=<camelot-username> --docker-password=<API key from jfrog> --docker-email=<emailid> -n bds
    oc secrets link genesys mycred --for=pull -n bds
  6. Create StorageClass, Persistent Volume, and Persistent Volume Claim by referring to Create StorageClass, Persistent Volume, and Persistent Volume Claim > OpenShift Storage in Provision BDS.

Kubernetes

  1. Log in to the Kubernetes cluster.
  2. Check if the cluster is running:
    kubectl cluster-info
  3. If the namespace for BDS doesn't already exist, create a new namespace:
    kubectl create namespace bds
  4. Create Secret for accessing the Docker private registry if needed. Use the following command:
    kubectl create secret generic docker-cred \ 
        --from-file=.dockerconfigjson="/home/${USER}/.docker/config.json" \ 
        --type=kubernetes.io/dockerconfigjson --namespace=bds
    If the Docker registry requires authentication, name of the Docker secret must be passed to deployment as bdsApp.image.imagePullSecrets parameter.
  5. If you are deploying in a production environment,
    • Create StorageClass, Persistent Volume, and Persistent Volume Claim by referring to Create StorageClass, Persistent Volume, and Persistent Volume Claim > OpenShift Storage in Provision BDS. For the Kubernetes production environment, you can use the yaml manifests similar to OpenShift storage manifests.
      Important
      In production environments, the actual storage class and storage method could be different, for example, network storage or cloud storage. Hence, modify the sample code with appropriate storage values that is suitable for the environment you deploy.
  6. If you are deploying in a lab or testing environment,
    1. Create a folder on every cluster worker node that schedules BDS cronjob. Use the following command:
      sudo mkdir –p /genesys/data
      sudo chmod 777 –R /genesys/data
    2. Create yaml manifests for Persistent Volume and Persistent Volume Claim. Use the sample codes from Create StorageClass, Persistent Volume, and Persistent Volume Claim > Kubernetes Storage in Provision BDS.
  7. Override the bdsApp.volumes.pvc.claim chart parameter with the PVC name created in the previous step, for example, bds-pvc.

Google Kubernetes Engine (GKE)

  1. Log in to the GKE cluster.
  2. If the namespace for BDS doesn't already exist, create a new namespace:
    kubectl create namespace bds
  3. Create Secret for accessing the JFrog registry, if needed. Use the following command:
    kubectl create secret docker-registry <secret-name> --docker-server=<jfrog-url> --docker-username=<username> --docker-password=<API key from jfrog> --docker-email=<email-id> -n <namespace>
  4. Create Persistent Volume Claim by referring to Create StorageClass, Persistent Volume, and Persistent Volume Claim > GKE in Provision BDS.
    • Important
      In production environments, the actual storage class and storage method could be different, for example, network storage or cloud storage. Hence, modify the sample code with appropriate storage values that is suitable for the environment you deploy.
  5. Override the bdsApp.volumes.pvc.claim chart parameter with the PVC name created in the previous step, for example, bds-pvc.

Deploy

Prerequisites

Ensure that you have the following:

  • From JFrog:
    • Helm chart package
    • BDS docker image
  • The CLI is installed (Download the CLI), and oc copied to the folder /usr/bin/.

Deployment steps

OpenShift

  1. Download the bds-cronjob helm charts from the JFrog repository (or receive it from premise packages).
    Helm charts are located here: https://pureengage.jfrog.io/artifactory/helm-stage/
    For example, the bds-cronjob-100.0.003+0029.tgz version is used for explaining the deployment.
    1. Create a folder for current deployment and extract the bds-cronjob-100.0.003+0029.tgz:
      developer@docker:~/ tar xvzf bds-cronjob-100.0.003+0029.tgz
      bds-cronjob/Chart.yaml
      bds-cronjob/values.yaml
      bds-cronjob/templates/_helpers.tpl
      bds-cronjob/templates/alerts.yml
      bds-cronjob/templates/run-bds.yml
      bds-cronjob/.helmignore
    2. Create bds-manual-secrets.yaml with secrets to access data sources like GIM and few other services like GWS. See OpenShift Secrets for a sample secrets file.
    3. Create override.yaml with applicable values in the bds-cronjob folder. The Default value of BDS mode type must be one of the following:
      • For 9.0.00x releases: BDS_OPERATING_MODE = MULTICLOUD
      • For 100.0.00x.xxxx and later releases: BDS_OPERATING_MODE = MULTICLOUD_PE
      For example:
      tenantName: testtenant
      serviceAccount:
         name: genesys
      bdsApp:
        secrets:
          gim:
            volumes:
              tenantID: 001
            mounts:
              name: ""
          gvp:
            mounts:
              name: ""
          consul:
            mounts:
              name: ""
        container:
          env:
            ## Description of the BDS mode type
            modeValue: MULTICLOUD
            ## URL for Prometheus PushGateway service. Set to empty string if PG is not available.
            pgValue: "http://prometheus-pushgateway.monitoring.svc.gke2-useast1.gcpe002.gencpe.com:9091"
        volumes:
          pvc:
            claim: bds-pvc
        image:
          tag: 100.0.003.0029
       
          ## Should be overriden with own values
          registry: pureengage-docker-staging.jfrog.io/
        securityContext:
          # Containers should run as genesys user and cannot use elevated permissions
          runAsGroup: 500
          runAsUser: 500
  2. Run the following command to install CronJob:
    helm upgrade --install --history-max 5  <cronjob-name> ./helm/bds-cronjob -f override.yaml -n bds

Where <cronjob-name> = bds-<env> -<tenant name>

For Example:

developer@docker:~/OpenShift$ helm upgrade --install --history-max 5 bds-dev-testtenant ./bds-cronjob -f override.yaml -n bds
coalesce.go:196: warning: cannot overwrite table with non table for tag (map[])
coalesce.go:196: warning: cannot overwrite table with non table for tenantID (map[])
Release "bds-dev-testtenant" has been upgraded. Happy Helming!
NAME: bds-dev-testtenant
 
LAST DEPLOYED: Wed May 12 13:31:53 2021
NAMESPACE: bds
STATUS: deployed
 
REVISION: 2
TEST SUITE: None

Kubernetes

  1. Download the bds-cronjob helm charts from the JFrog repository (or receive it from premise packages).
    Helm charts are located here: https://pureengage.jfrog.io/artifactory/helm-stage/
    For example, the bds-cronjob-100.0.003+0029.tgz version is used for explaining the deployment.
    1. Create a folder for current deployment and extract the bds-cronjob-100.0.003+0029.tgz:
      developer@docker:~/ tar xvzf bds-cronjob-100.0.003+0029.tgz
      bds-cronjob/Chart.yaml
      bds-cronjob/values.yaml
      bds-cronjob/templates/_helpers.tpl
      bds-cronjob/templates/alerts.yml
      bds-cronjob/templates/run-bds.yml
      bds-cronjob/.helmignore
    2. Create bds-manual-secrets.yaml with secrets to access data sources like GIM and few other services like GWS. See Kubernetes Secrets for a sample secrets file.
    3. Create override.yaml with applicable values in the bds-cronjob folder. The Default value of BDS mode type must be one of the following:
      • For 9.0.x versions: BDS_OPERATING_MODE = MULTICLOUD
      • For 100.0.00x.xxxx versions and later releases: BDS_OPERATING_MODE = MULTICLOUD_PE
      For example:
    tenantName: testtenant
    serviceAccount:
       name: genesys
    bdsApp:
      secrets:
        gim:
          volumes:
            tenantID: 001
          mounts:
            name: ""
        gvp:
          mounts:
            name: ""
        consul:
          mounts:
            name: ""
      container:
        env:
          ## Description of the BDS mode type
          modeValue: MULTICLOUD_PE
          ## URL for Prometheus PushGateway service. Set to empty string if PG is not available.
          pgValue: "http://prometheus-pushgateway.monitoring.svc.gke2-useast1.gcpe002.gencpe.com:9091"
      volumes:
        pvc:
          claim: bds-pvc
      image:
        tag: 100.0.003.0029
      
        ## Should be overriden with own values
        registry: pureengage-docker-staging.jfrog.io/
      securityContext:
        # Containers should run as genesys user and cannot use elevated permissions
        runAsGroup: 500
        runAsUser: 500
    Make sure you modify the service account name that your organization created or default to Kubernetes value (default k8s value).
  2. Run the following command to install CronJob:
    helm upgrade --install --history-max 5  <cronjob-name> ./helm/bds-cronjob -f override.yaml -n bds

Where <cronjob-name> = bds-<env> -<tenant name>

GKE

  1. Download the bds-cronjob helm charts from the JFrog repository (or receive it from premise packages).
    Helm charts are located here: https://pureengage.jfrog.io/artifactory/helm-stage/
    For example, the bds-cronjob-100.0.003+0029.tgz version is used for explaining the deployment.
  2. Create a folder for current deployment and extract the bds-cronjob-100.0.003+0029.tgz:
    developer@docker:~/ tar xvzf bds-cronjob-100.0.003+0029.tgz
    bds-cronjob/Chart.yaml
    bds-cronjob/values.yaml
    bds-cronjob/templates/_helpers.tpl
    bds-cronjob/templates/alerts.yml
    bds-cronjob/templates/run-bds.yml
    bds-cronjob/.helmignore
  3. Deploy the Configuration file manually by running the following command:
    helm install --debug bds-config bds-config  --version=100.0.003+0029-pe -n bds
  4. Create bds-manual-secrets.yaml with secrets to access data sources like GIM and few other services like GWS. See GKE Secrets for a sample secrets file.
  5. Create override.yaml with applicable values in the bds-cronjob folder. The Default value of BDS mode type must be one of the following:
    • For 9.0.x versions: BDS_OPERATING_MODE = MULTICLOUD
    • For 100.0.00x.xxxx versions and later releases: BDS_OPERATING_MODE = MULTICLOUD_PE
    For example:
    tenantName: t100-100
    serviceAccount:
       name: default
    bdsApp:
      secrets:
        gim:
          volumes:
            tenantID: 001
          mounts:
            name: ""
        gvp:
          mounts:
            name: ""
        consul:
          mounts:
            name: ""
      container:
        env:
          ## Description of the BDS mode type
          modeValue: MULTICLOUD_PE
          ## URL for Prometheus PushGateway service. Set to empty string if PG is not available.
          pgValue: "http://prometheus-pushgateway.monitoring.svc.gke2-useast1.gcpe002.gencpe.com:9091"
      volumes:
        pvc:
          claim: bds-pvc
      image:
        tag: "100.0.003.0029"
        ## Should be overriden with own values
        registry: pureengage-docker-staging.jfrog.io/
        pullSecrets:
          name: "pullsecret"
    Make sure you modify the service account name that your organization created or default to Kubernetes value (default k8s value).
  6. Run the following command to install CronJob:
    helm --install -n bds bds-cronjob https://pureengage.jfrog.io/artifactory/helm-stage/bds-cronjob-100.0.003+0029.tgz  -f override_values.yaml —username <username> --password <jfrog-password/Key>

Validate the deployment

To validate the deployment, run the following commands to trigger the CronJob manually, and check pod Events:

kubectl -n bds create job --from=cronjob/bds-mytenant bds-run
kubectl -n bds get pod
NAME READY STATUS RESTARTS AGE
bds-run-98771 0/1 Completed 0 100s
 
kubectl -n bds describe pod bds-run-98771
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  15s   default-scheduler  Successfully assigned bds/bds-run-npqc6 to minikube
  Normal  Pulling    14s   kubelet            Pulling image "genesys-local.jfa.genesyslab.com:443/cloudbilling/scripts:latest"
  Normal  Pulled     11s   kubelet            Successfully pulled image "genesys-local.jfa.genesyslab.com:443/cloudbilling/scripts:latest" in 2.829413381s
  Normal  Created    11s   kubelet            Created container scripts-mytenant
  Normal  Started    10s   kubelet            Started container scripts-mytenant
Retrieved from "https://all.docs.genesys.com/BDS/Current/BDSPEGuide/Deploy (2022-05-20 19:52:50)"