Skip to content

Commit

Permalink
[US-562026] Deprecation of Pega Search on Dockerhub (#611)
Browse files Browse the repository at this point in the history 
* [US-562026] Deprecation of Pega Search on Dockerhub

Updated the README section for Search with the new location of the platform/search image. Clarified that the Elasticsearch plug-in is a deprecated solution.

* Updated platform/search image tag information
  • Loading branch information
@kingakowalska1
kingakowalska1 authored Sep 21, 2023
1 parent 1ea7977 commit ae608f1
Showing 1 changed file with 15 additions and 11 deletions.
26 changes: 15 additions & 11 deletions charts/pega/README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -785,13 +785,15 @@ cassandra:

## Search deployment

Use the `pegasearch` section to configure the source ElasticSearch service that the Pega Platform deployment uses for searching Rules and Work within Pega. The ElasticSearch service defined here is not related to the ElasticSearch deployment if you also define an EFK stack for logging and monitoring in your Pega Platform deployment.
Use the `pegasearch` section to configure the source Elasticsearch service that the Pega Platform deployment uses for searching Rules and Work within Pega. The Elasticsearch service defined here is not related to the Elasticsearch deployment if you also define an EFK stack for logging and monitoring in your Pega Platform deployment.

### For Pega Platform 8.6 and later:

Pega recommends using the chart ['backingservices'](../backingservices) to enable Pega Infinity backing service and to deploy the latest generation of search and reporting capabilities to your Pega applications that run independently on nodes provisioned exclusively to run these services.
This is an independently manageable search solution that replaces the previous implementation of Elasticsearch. The SRS supports, but does not require you to enable, Elasticsearch for your Pega Infinity deployment searching capability.
Use the chart ['backingservices'](../backingservices) to deploy the Search and Reporting Service (SRS), a Pega Platform backing service enabling the latest generation of search and reporting capabilities for your Pega applications. SRS is independent from Pega Platform and replaces the previous implementation of Elasticsearch, the legacy client-server Elasticsearch plug-in.

To use SRS, follow the deployment instructions provided at ['backingservices'](../backingservices) before you configure and deploy the Pega Helm chart. For more information, see [External Elasticsearch in your deployment](https://docs.pega.com/bundle/platform-88/page/platform/deployment/externalization-of-services/externalize-search-in-your-deployment.html).

To use this search and reporting service, follow the deployment instructions provided at ['backingservices'](../backingservices) before you configure and deploy `pega` helm chart. You must configure the SRS URL for your Pega Infinity deployment using the parameter in values.yaml as shown the the following table and exmple:
You must configure the SRS URL for your Pega Platform deployment using the parameter in values.yaml as shown the following table and example:

Parameter | Description | Default value
--- | --- | ---
Expand Down Expand Up @@ -832,26 +834,28 @@ pegasearch:
privateKeyAlgorithm: "RS256"
```

Use the below configuration to provision an internally deployed instance of elasticsearch for search functionality within the platform:
### For Pega Platform 8.5 and earlier:

Use the following configuration to provision the legacy client-server Elasticsearch plug-in with a Pega-provided Docker image. This is a deprecated solution; as a best practice, update your deployment to Pega Platform version 8.6 or later and use SRS instead.

Parameter | Description | Default value
--- | --- | ---
`image` | Set the `pegasearch.image` location to a registry that can access the Pega search Docker image. The image is [available on DockerHub](https://hub.docker.com/r/pegasystems/search), and you may choose to mirror it in a private Docker repository. | `pegasystems/search:latest`
`image` | Set the `pegasearch.image` parameter to a registry that can access the Pega-provided `platform/search` Docker image. Download the image from the Pega repository, tag it, and push it to your local registry. As a best practice, use the latest available image for your Pega Platform version, based on the build date specified in the tag. For example, the image tagged "8.5.6-20230829" was built on August 29, 2023. For more information, see [Pega-provided Docker images](https://docs.pega.com/bundle/platform-88/page/platform/deployment/client-managed-cloud/pega-docker-images-manage.html).| `platform/search:8.5.x-XXXXXXXX`
`imagePullPolicy` | Optionally specify an imagePullPolicy for the search container. | `""`
`replicas` | Specify the desired replica count. | `1`
`minimumMasterNodes` | To prevent data loss, you must configure the minimumMasterNodes setting so that each master-eligible node is set to the minimum number of master-eligible nodes that must be visible in order to form a cluster. Configure this value using the formula (n/2) + 1 where n is replica count or desired capacity. For more information, see the ElasticSearch [important setting documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/important-settings.html) for more information. | `1`
`podSecurityContext.runAsUser` | ElasticSearch defaults to UID 1000. In some environments where user IDs are restricted, you may configure your own using this parameter. | `1000`
`set_vm_max_map_count` | Elasticsearch uses a **mmapfs** directory by default to store its indices. The default operating system limits on mmap counts is likely to be too low, which may result in out of memory exceptions. An init container is provided to set the value correctly, but this action requires privileged access. If privileged access is not allowed in your environment, you may increase this setting manually by updating the `vm.max_map_count` setting in **/etc/sysctl.conf** according to the ElasticSearch documentation and can set this parameter to `false` to disable the init container. For more information, see the [ElasticSearch documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/vm-max-map-count.html). | `true`
`minimumMasterNodes` | To prevent data loss, you must configure the minimumMasterNodes setting so that each master-eligible node is set to the minimum number of master-eligible nodes that must be visible in order to form a cluster. Configure this value using the formula (n/2) + 1 where n is replica count or desired capacity. For more information, see the Elasticsearch [important setting documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/important-settings.html) for more information. | `1`
`podSecurityContext.runAsUser` | Elasticsearch defaults to UID 1000. In some environments where user IDs are restricted, you may configure your own using this parameter. | `1000`
`set_vm_max_map_count` | Elasticsearch uses a **mmapfs** directory by default to store its indices. The default operating system limits on mmap counts is likely to be too low, which may result in out of memory exceptions. An init container is provided to set the value correctly, but this action requires privileged access. If privileged access is not allowed in your environment, you may increase this setting manually by updating the `vm.max_map_count` setting in **/etc/sysctl.conf** according to the Elasticsearch documentation and can set this parameter to `false` to disable the init container. For more information, see the [Elasticsearch documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/vm-max-map-count.html). | `true`
`set_data_owner_on_startup` | Set to true to enable an init container that runs a chown command on the mapped volume at startup to reset the owner of the ES data to the current user. This is needed if a random user is used to run the pod, but also requires privileges to change the ownership of files. | `false`
`podAnnotations` | Configurable annotations applied to all Elasticsearch pods. | {}

Additional env settings supported by ElasticSearch may be specified in a `custom.env` block as shown in the example below.
Additional env settings supported by Elasticsearch may be specified in a `custom.env` block as shown in the example below.

Example:

```yaml
pegasearch:
image: "pegasystems/search:8.3"
image: "platform/search:8.5.6-20230829"
memLimit: "3Gi"
replicas: 1
minimumMasterNodes: 2
Expand Down

0 comments on commit ae608f1

Please sign in to comment.