Pega Application migration to Container

General
, , , , , ,
1

We are migrating our Pega Application(V 8.6.1) which is currently running as a Weblogic on Oracle DB setup to Openshift Container(on same Oracle DB). We are planning to use the Pega Helm Chart approach to deploy the same. So we are in process of creating the Pega and backingservices yaml files. For pega yaml, we are pulling the latest 8.6.1 image (pegasystems/pega:8.6.1) and for backingservices we are pulling the latest search image(pegasystems/search:latest) from Docker Hub. Need clarification on below questions. Any help here is appreciated.

  1. I see the instruction given in the link(https://github.com/thomasgpeters/pega-deploy/blob/main/docs/Deploying-Pega-on-openshift.md) installs both backingservices.yaml and pega.yaml with same namespace which means that each environment(DEV/STAGING/PROD) is going to have its own backingservices yaml installation. Please correct me if I’m wrong.

  2. How does pega.yaml install links to SRS? Is it by the pegasearch attribute in pega.yaml? Got below questions on the same.

    1. externalURL here is the SRS URL obtained from backingservices yaml deployment? Do we need to update the url after the backingservices yaml install?
    2. What is the purpose of charts/srs under backingservices?


pegasearch:

For Pega Platform 8.6 and later, Pega recommends using the chart ‘backingservices’ to enable Pega SRS. To deploy this service, you must configure your SRS cluster using the backingservices Helm charts and provide the SRS URL for your Pega Infinity deployment.
- externalSearchService: true
- externalURL: pegasearch.externalURL For example, http://srs-service.mypega-pks-demo.svc.cluster.local
  1. How does the Pega Search Indices of Rules/Data/Work will be written in Container setup? Today for Weblogic, we specify the -Dindex.directory argument on the server to direct a node to host and write the Pega Search Indices. How does it work with Container? How do we specify the -Dindex.directory? Do we need to set bind mount using Environment Variable and set the JVM Args in pega.yaml?
  2. Can we copy the currently built indices from Weblogic directory(PegaSearchIndex) to Container volume/bindmount? Will it start building only new Indices or do we need to clean up and start from scratch?
  3. Also if we need to go without a separate SRS(no backingservices yaml install), what is the option to be given in pega.yaml to consider embedded elastic search functionality? Is it supported in 8.6.1?
2

@Jey2705 We support Helm based deployments only.

Using direct yaml deployments with Kubernetes would be very advanced and error prone.

Our documentation has also been updated to reflect the correct information:

https://docs.pega.com/bundle/platform-88/page/platform/deployment/client-managed-cloud/containerized-deployments-kubernetes.html

https://docs.pega.com/bundle/platform-88/page/platform/deployment/client-managed-cloud/installing-patching-updating.html

https://pegasystems.github.io/pega-helm-charts/

Externalization for Elasticsearch using the Search and Reporting services (SRS)

Understanding the Pega deployment architecture

Installing, patching, or updating Pega software in Kubernetes deployments

Could you have a look at the Q&A of the CLSA Community meetup meet the CTO - Architecture to see if this answers your question?

Pega offers support for AWS, Azure, GCP, VMWare Tanzu (formerly Pivotal), and RedHat OpenShift through our Cloud Choice program.

I will check internally to see if there is an SME who can answer your questions .

3

@Jey2705

Hello

Search and SRS are two different images performing different duties.

Search will index the files using elastic search engine

SRS is for performing reporting on top of this indexed data.

Question # 1

yes your understanding is correct each environment will have it’s own SRS.

Question # 2

Yes both are independent installations in itself . Once SRS installation is done, you have to update the helm chart of Pega.yaml and re-deploy - this will only update the search container settings - it will not restart whole system

Question # 3

You need to use persistence volume setup for the stateful sets and disable the Horizontal Pod Autoscaler to false.

Question # 4

Copying old data into a persistence volume on cloud needs special tools to migrate the content. instead re-indexing is simple and easy to handle - it’s one time job. once full data is re-indexed there on it’s real time

Question # 5

Embedded elastic search support will not be available in higher versions. it is recommended to use SRS.

Refer pega-helm-charts/charts/pega at master · pegasystems/pega-helm-charts · GitHub for deployments

4

Thanks a lot @SriharshaAnika for your response. Sorry for the delayed response. We started the Container migration exercise already and were able to successfully migrate. We tried Embedded elastic search which we then came to know that it’s not supported in Container setup. So now we are in process of evaluating upgrade and deploy option to 8.8. Need guidance on below points. Appreciate your help.

  1. We are planning to use action: “upgrade-deploy” in pega values.yaml and also use Custom rules upgrade without a data upgrade option. Which of the upgradeSteps values do we need to keep considering the our scenario of Container migration?

installer:
image: “YOUR_INSTALLER_IMAGE:TAG”
upgrade:
upgradeType: “custom”
upgradeSteps: “enable_cluster_upgrade, rules_migration, rules_upgrade, disable_cluster_upgrade”
targetRulesSchema: “new_rules_schema_name”
targetDataSchema: “temporary_data_schema_name”

  1. We are updating pega-helm-charts/charts/backingservices/values.yaml and for SRS image referring to pegatomo/search-n-reporting-service:1.20.4-20230102164120. Please let us know if that’s the correct srs image.
5

Thanks @MarijeSchillern for your response.

6

@Jey2705

enable_cluster_upgrade - mean - all the pods in your cluster will have latest war file deployed

rules_upgrade- just upgrade

rules_migration - upgrade and migrate to target database

disable_cluster_upgrade - only one single pod in the cluster will get upgraded

targetRulesSchema - schema on which upgrade is expected to performed

new_rules_schema_name - schema to which new rules needs to be migrated after upgrade

targetDataSchema- schema in which data schema upgrade is being performed.

For SRS

as per your license agreement refer to the pega docker images and leverage the one being shared as part of pega license.

We are not aware of any pegatomo.

7

@Jey2705 ,

Have you migrated your existing Pega deployment in weblogic-oracle to Docker using pega provided helm charts with the current code and data or installed fresh image and migrated the data and code from your current environment.

Using pega provided helm charts we can only create a blank Pega instance which should be updated with the current code and data, is my understanding. You mentioned, you migrated your current setup to Docker how was this migration done. Could you please share some details on it.

8

@ParameshA2835 hi Paramesh , have u got answer to your question ? I am also looking for same answer .