Skip to content

Commit

Permalink
Merge branch 'master' of github.com:pegasystems/pega-helm-charts
Browse files Browse the repository at this point in the history
  • Loading branch information
@pegatim
pegatim committed Oct 19, 2023
2 parents 3522ceb + b31d316 commit 77842d9
Show file tree
Hide file tree
Showing 59 changed files with 1,242 additions and 852 deletions.
13 changes: 7 additions & 6 deletions charts/backingservices/charts/srs/README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -18,19 +18,19 @@ The service deployment provisions runtime service pods along with a dependency o
| Pega Infinity version | SRS version | Elasticsearch version | Description |
|-----------------------|-------------|-----------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| < 8.6 | NA | NA | SRS can be used with Pega Infinity 8.6 and later |
| \>= 8.6 | 1.21.1 | 7.10.2, 7.16.3, and 7.17.9 | While SRS Docker images are certified against Elasticsearch versions 7.10.2, 7.16.3 and 7.17.9, Pega recommends using Elasticsearch version 7.17.9. To stay current with Pega releases, use the latest available SRS image 1.21.1.
| \>= 8.6 | 1.25.3 | 7.10.2, 7.16.3, and 7.17.9 | While SRS Docker images are certified against Elasticsearch versions 7.10.2, 7.16.3 and 7.17.9, Pega recommends using Elasticsearch version 7.17.9. To stay current with Pega releases, use the latest available SRS image 1.25.3.

**Note**:

**If your deployment uses the internally-provisioned Elasticsearch:** To migrate to Elasticsearch version 7.17.9 from the Elasticsearch version 7.10.2 or 7.16.3 use the process that applies to your deployment:

* Update the SRS Docker image version to use v1.21.1, which supports both Elasticsearch versions 7.10.x and 7.16.x.
* Update the SRS Docker image version to use v1.25.3, which supports both Elasticsearch versions 7.10.x and 7.16.x.
* Update the Elasticsearch `dependencies.version` parameter in the [requirement.yaml](../../requirements.yaml) to 7.17.3.
* Update Elasticsearch to 7.17.9.

**If your deployment connects to an externally-managed Elasticsearch service:** To migrate to Elasticsearch version 7.17.9 from the Elasticsearch version 7.10.2 or 7.16.3 use the process that applies to your deployment:

* Update the SRS Docker image version to use v1.21.1, which supports both Elasticsearch versions 7.10.x and 7.16.x.
* Update the SRS Docker image version to use v1.25.3, which supports both Elasticsearch versions 7.10.x and 7.16.x.
* Complete the version upgrade to 7.17.9. Refer to Elasticsearch version 7.17 documentation. For example, see [Upgrade Elasticsearch](https://www.elastic.co/guide/en/elasticsearch/reference/7.17/setup-upgrade.html).

### SRS runtime configuration
Expand All @@ -44,7 +44,7 @@ You may enable the component of [Elasticsearch](https://github.com/helm/charts/t
Note: Pega does **not** actively update the elasticsearch dependency in `requirements.yaml`. To leverage SRS, you must do one of the following:

* To use the internally-provided Elasticsearch service in the SRS cluster, use the default `srs.enabled.true` parameter and set the Elasticsearch version by updating the `elasticsearch.imageTag` parameter in the [values.yaml](./values.yaml) to match the `dependencies.version` parameter in the [requirements.yaml](../../requirements.yaml).
* To use an externally-provided Elasticsearch service from the SRS cluster, update the `srs.srsStorage.provisionInternalESCluster` parameter in the [values.yaml](./values.yaml) to `false` and then provide connection details as documented below.
* To use an externally-provided Elasticsearch service with SRS, use the default `srs.enabled.true` parameter, update the `srs.srsStorage.provisionInternalESCluster` parameter in the [values.yaml](./values.yaml) to `false` and then provide connection details as documented below.

### Deploying SRS with Pega-provided busybox images
To deploy Pega Platform with the SRS backing service, the SRS helm chart requires the use of the busybox image. For clients who want to pull this image from a registry other than Docker Hub, they must tag and push their image to another registry, and then pull it by specifying `busybox.image` and `busybox.imagePullPolicy`.
Expand All @@ -53,7 +53,7 @@ To deploy Pega Platform with the SRS backing service, the SRS helm chart require

| Configuration | Usage |
|-----------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `enabled` | Enable the Search and Reporting Service deployment as a backing service. |
| `enabled` | Enable the Search and Reporting Service deployment as a backing service. Set this parameter to `true` to use SRS. |
| `deploymentName` | Specify the name of your SRS cluster. Your deployment creates resources prefixed with this string. This is also the service name for the SRS. |
| `srsRuntime` | Use this section to define specific resource configuration options like image, replica count, cpu and memory resource settings in the SRS. |
| `busybox` | When provisioning an internally managed Elasticsearch cluster, you can customize the location and pull policy of the Alpine image used during the deployment process by specifying `busybox.image` and `busybox.imagePullPolicy`. |
Expand Down Expand Up @@ -99,7 +99,7 @@ Example:

```yaml
srs:
# always set srs.srsStorage.provisionInternalESCluster=false when srs.enabled=false
# Set srs.enabled=true to enable SRS
enabled: true

# specify unique name for the deployment based on org app and/or srs applicable environment name. eg: acme-demo-dev-srs
Expand Down Expand Up @@ -128,6 +128,7 @@ srs:
srsStorage:
# Setting srsStorage.provisionInternalESCluster to true will provision an internal elasticsearch cluster using the configuration
# specified in the `elasticsearch` section
# IF you do not enable SRS and the srs.enabled parameter is set to false, always set srs.srsStorage.provisionInternalESCluster=false
provisionInternalESCluster: true
# To use your own Elasticsearch cluster, set srsStorage.provisionInternalESCluster to false and then
# set the external Elasticsearch cluster URL and port details below when using an externally managed elasticsearch
Expand Down
3 changes: 2 additions & 1 deletion charts/backingservices/values.yaml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ global:

# Search and Reporting Service (SRS) Configuration
srs:
# always set srs.srsStorage.provisionInternalESCluster=false when srs.enabled=false
# Set srs.enabled=true to enable SRS
enabled: true

# specify unique name for the deployment based on org app and/or srs applicable environment name. eg: acme-demo-dev-srs
Expand Down Expand Up @@ -38,6 +38,7 @@ srs:
srsStorage:
# Setting srsStorage.provisionInternalESCluster to true will provision an internal elasticsearch cluster using the configuration
# specified in the `elasticsearch` section
# If you do not enable SRS and the srs.enabled parameter is set to false, always set srs.srsStorage.provisionInternalESCluster=false
provisionInternalESCluster: true
# To use your own Elasticsearch cluster, set srsStorage.provisionInternalESCluster to false and then
# set the external Elasticsearch cluster URL and port details below when using an externally managed elasticsearch
Expand Down
28 changes: 16 additions & 12 deletions charts/pega/README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -343,7 +343,7 @@ Parameter | Description
`tls.secretName` | Specify the Kubernetes secret you created in which you store your SSL certificate for your deployment. For compatibility, see [provider support for SSL certificate injection](#provider-support-for-ssl-certificate-management).
`tls.useManagedCertificate` | On GKE, set to `true` to use a managed certificate; otherwise use `false`.
`tls.ssl_annotation` | On GKE or EKS, set this value to an appropriate SSL annotation for your provider.
`annotations` | Optionally add custom annotations for advanced configurations. For Kubernetes and EKS deployments, including custom annotations overrides the default configuration; for GKE and AKS deployments, the deployment appends these custom annotations to the default list of annotations.
`annotations` | Optionally add custom annotations for advanced configurations. For Kubernetes, EKS, and OpenShift deployments, including custom annotations overrides the default configuration; for GKE and AKS deployments, the deployment appends these custom annotations to the default list of annotations.

Depending on your provider or type of certificate you are using use the appropriate annotation:
- For `EKS` - use `alb.ingress.kubernetes.io/certificate-arn: \<*certificate-arn*\>` to specify required ARN certificate.
Expand Down 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
Loading

0 comments on commit 77842d9

Please sign in to comment.