Difference between revisions of "Draft: PEC-REP/Current/RAAPEGuide/Planning"
From Genesys Documentation
Line 12: | Line 12: | ||
JDBC driver can be overridden by copying driver file to '''lib\jdbc_driver_<RDBMS>''' (or by making link) in a work dir. See for [https://docs.genesys.com/Documentation/RAA/9.0.0/Dep/PostInstall#JDBCDriverForRAA JDBC driver for RAA] for details. | JDBC driver can be overridden by copying driver file to '''lib\jdbc_driver_<RDBMS>''' (or by making link) in a work dir. See for [https://docs.genesys.com/Documentation/RAA/9.0.0/Dep/PostInstall#JDBCDriverForRAA JDBC driver for RAA] for details. | ||
|HelmText===Init containers== | |HelmText===Init containers== | ||
+ | For more information, see: {{SuiteLevelLink|helmchart}}. | ||
+ | |||
The RAA Helm chart includes two explicit init containers: | The RAA Helm chart includes two explicit init containers: | ||
− | *'''configDelivery''' -- this container delivers required XML configuration and *.SS files in the RAA working directory. Those files must be available in a GZIP archive, encoded as base64, which must be passed using the Helm install/update option '''--set-file raa.deployment.configTar=config.tar.gz.b64'''. Default '''conf.xml''' and '''user-data-map.ss''' are supplied with the Helm chart. If a GZIP archive is not specified by the '''--set-file''' option, the init container copies them into the working directory (unless they are already present). <br />The configDelivery init container is optional, and is disabled by default; when it is disabled, you can create RAA configuration files in the mounted config volume. The configDelivery init container makes sense when access to the mounted working directory is restricted for any reason -- often for security reasons, or due to use of ephemeral storage for the configuration volume.<br/>You must specify a container name value to enable configDelivery container: | + | *'''configDelivery''' -- this container delivers required XML configuration and *.SS files in the RAA working directory. Those files must be available in a GZIP archive, encoded as base64, which must be passed using the Helm install/update option '''--set-file raa.deployment.configTar=config.tar.gz.b64'''. Default '''conf.xml''' and '''user-data-map.ss''' are supplied with the Helm chart. If a GZIP archive is not specified by the '''--set-file''' option, the init container copies them into the working directory (unless they are already present). <br />The configDelivery init container is optional, and is disabled by default; when it is disabled, you can create RAA configuration files in the mounted config volume. The configDelivery init container makes sense when access to the mounted working directory is restricted for any reason -- often for security reasons, or due to use of ephemeral storage for the configuration volume.<br />You must specify a container name value to enable configDelivery container: |
*:'''myvalues.yaml''' | *:'''myvalues.yaml''' | ||
*:<source lang="bash">raa: | *:<source lang="bash">raa: | ||
Line 25: | Line 27: | ||
name: "{{ $.Chart.Name }}-conf-delivery"</source> | name: "{{ $.Chart.Name }}-conf-delivery"</source> | ||
− | * '''testRun''' -- this container executes all the aggregations on an empty time range. This helps to quickly detect configuration and customization problems -- SQL execution (even on empty data) checks the presence of involved tables and columns. The testRun init container is optional, and is enabled by default. To disable the container, set testRun: with no value in the container section of your myvalues.yaml: | + | *'''testRun''' -- this container executes all the aggregations on an empty time range. This helps to quickly detect configuration and customization problems -- SQL execution (even on empty data) checks the presence of involved tables and columns. The testRun init container is optional, and is enabled by default. To disable the container, set testRun: with no value in the container section of your myvalues.yaml: |
*:'''myvalues.yaml''' | *:'''myvalues.yaml''' | ||
*:<source lang="bash">raa: | *:<source lang="bash">raa: | ||
Line 35: | Line 37: | ||
testRun: | testRun: | ||
name: "{{ $.Chart.Name }}-test-run"</source> | name: "{{ $.Chart.Name }}-test-run"</source> | ||
+ | |||
==Pod containers== | ==Pod containers== | ||
RAA has two execution containers: | RAA has two execution containers: | ||
− | * '''aggregation''' -- this container does the aggregation work. It is a required container, and only the container name is specified in values.yaml.: | + | *'''aggregation''' -- this container does the aggregation work. It is a required container, and only the container name is specified in values.yaml.: |
*:'''myvalues.yaml''' | *:'''myvalues.yaml''' | ||
*: | *: | ||
Line 50: | Line 53: | ||
...</source> | ...</source> | ||
− | * '''monitor''' -- this container allows execution of RAA tool from file, using with parameters placed in the working directory. Use this function when the kubeclt exececutable is not available in yoru environment; for example, for security reasons. The monitor container also exposes two ports to enable scraping of aggregation metrics and health metric by Prometheus, or other monitoring tools. Monitor container is optional and disabled by default. Set values for '''monitor:''' as follows: | + | *'''monitor''' -- this container allows execution of RAA tool from file, using with parameters placed in the working directory. Use this function when the kubeclt exececutable is not available in yoru environment; for example, for security reasons. The monitor container also exposes two ports to enable scraping of aggregation metrics and health metric by Prometheus, or other monitoring tools. Monitor container is optional and disabled by default. Set values for '''monitor:''' as follows: |
*:'''myvalues.yaml''' | *:'''myvalues.yaml''' | ||
*:<source lang="bash">raa: | *:<source lang="bash">raa: | ||
Line 73: | Line 76: | ||
containerPort: "9101" | containerPort: "9101" | ||
...</source> | ...</source> | ||
+ | |||
==Test containers== | ==Test containers== | ||
RAA includes two test containers for the Helm test command. They bust be executed in the following order: | RAA includes two test containers for the Helm test command. They bust be executed in the following order: | ||
− | # '''testRunCheck''' -- this container waits for execution of the testRun init container, and returns a result of test execution. The test is optional, and enabled by default. Enable it only when you plan to run the testRun init container; otherwise, disable it by setting testRunCheck: with no value in the testPod section of your values.yaml, as follows: | + | |
+ | #'''testRunCheck''' -- this container waits for execution of the testRun init container, and returns a result of test execution. The test is optional, and enabled by default. Enable it only when you plan to run the testRun init container; otherwise, disable it by setting testRunCheck: with no value in the testPod section of your values.yaml, as follows: | ||
#:'''myvalues.yaml''' | #:'''myvalues.yaml''' | ||
#:<source lang="bash">raa: | #:<source lang="bash">raa: | ||
Line 95: | Line 100: | ||
"helm.sh/hook-delete-policy": "before-hook-creation" | "helm.sh/hook-delete-policy": "before-hook-creation" | ||
...</source> | ...</source> | ||
− | # healthChek -- this container executes and returns status of healthCheck, and prints the content of current configuration files and health files to standard output. The test is optional and enabled by default. To disable this test, set healthCheck: with no value in the testPod section of your values.yaml , as follows: | + | #healthChek -- this container executes and returns status of healthCheck, and prints the content of current configuration files and health files to standard output. The test is optional and enabled by default. To disable this test, set healthCheck: with no value in the testPod section of your values.yaml , as follows: |
#:'''myvalues.yaml''' | #:'''myvalues.yaml''' | ||
#:<source lang="bash">raa: | #:<source lang="bash">raa: |
Revision as of 19:11, June 22, 2021
This is a draft page; it has not yet been published.
Find out what to do before deploying Reporting and Analytics Aggregates (RAA).
Related documentation: