Provide Examples of Worker SH Helm Chart Setup (#2508)

Author: vitaliil-jfrog

examples/worker/README.md

@@ -0,0 +1,27 @@
+# JFrog Worker
+
+JFrog Worker lets you run custom serverless code (Workers) that react to events in the JFrog Platform — for example, before/after a repository upload or download, or on a schedule — without deploying and managing your own service.
+
+Workers are written in JavaScript/TypeScript, run in an isolated sandbox, and are triggered by the JFrog Platform based on the events and permissions you configure for them. This chart deploys the Worker service, which hosts and executes those Workers.
+
+See the [JFrog Workers documentation](https://docs.jfrog.com/administration/docs/workers-overview) for the full list of supported event types, quotas, and configuration options.
+
+## Examples
+
+| Example | Description |
+| --- | --- |
+| [global-values](global-values) | Configure Worker via the shared `global` values block (for example when deployed alongside Artifactory via `jfrog-platform`) |
+| [extra-system-yaml](extra-system-yaml) | Override/extend `system.yaml` entries via `extraSystemYaml` |
+| [container-security-context](container-security-context) | Configure `containerSecurityContext` on the worker/router containers (replaces the deprecated `securityContext` key) |
+| [loggers](loggers) | Expose specific log files as sidecar containers via `loggers` for `kubectl logs`/log-collector visibility |
+
+## Deploy
+
+```shell
+helm upgrade --install worker jfrog/worker \
+  --set jfrogUrl=https://<your-jpd> \
+  --set joinKey=<join-key> \
+  --set masterKey=<master-key>
+```
+
+See the chart's [values.yaml](../../stable/worker/values.yaml) for the full set of configuration options.

examples/worker/container-security-context/README.md

@@ -0,0 +1,28 @@
+# Worker Container Security Context
+
+This example shows how to configure a security context on the `worker` and `router` containers using the `containerSecurityContext` values block.
+
+`containerSecurityContext` is the supported way to control container-level security settings such as `runAsNonRoot`, `allowPrivilegeEscalation`, and dropped Linux capabilities. It is enabled by default with a sensible baseline; the values below show how to further restrict it by dropping the `NET_RAW` capability.
+
+See the [container-security-context-values.yaml](container-security-context-values.yaml) for the configuration example.
+
+## How it works
+
+- `containerSecurityContext` is rendered into the Kubernetes `securityContext` field of both the `worker` and `router` containers in the Worker Deployment.
+- `capabilities.drop` accepts a list of Linux capabilities to remove from the containers, in addition to `runAsNonRoot` and `allowPrivilegeEscalation`.
+
+## Deploy
+
+Install Worker with the following command:
+
+```shell
+helm upgrade --install worker jfrog/worker -f container-security-context-values.yaml
+```
+
+## Notes
+
+- The older top-level `securityContext` key is no longer supported. Setting it causes `helm template`/`helm install` to fail with:
+  ```
+  .Values.securityContext is no longer supported and should be replaced with .Values.containerSecurityContext
+  ```
+  If you have `securityContext` set anywhere in your values, replace it with the equivalent `containerSecurityContext` keys shown in this example.

examples/worker/container-security-context/container-security-context-values.yaml

@@ -0,0 +1,10 @@
+jfrogUrl: "http://artifactory-local.my-arti.svc.cluster.local:8082"
+joinKey: EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
+masterKey: bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
+containerSecurityContext:
+  enabled: true
+  runAsNonRoot: true
+  allowPrivilegeEscalation: false
+  capabilities:
+    drop:
+      - NET_RAW

examples/worker/extra-system-yaml/README.md

@@ -0,0 +1,32 @@
+# Worker Extra System YAML
+
+This example shows how to add custom settings to Worker's `system.yaml` using the `extraSystemYaml` block, without having to override the whole file.
+
+`system.yaml` is the configuration file used internally by Worker (and the Router it runs alongside). The chart renders a base `system.yaml` from its own templates and then merges anything set under `extraSystemYaml` on top of it, so you only need to specify the keys you want to add or change.
+
+See the [extra-system-yaml-values.yaml](extra-system-yaml-values.yaml) for the configuration example.
+
+## How it works
+
+- The chart's base `system.yaml` is rendered from `files/system.yaml` (values like `router.serviceRegistry.insecure` are already wired into it as top-level chart values).
+- `extraSystemYaml` is deep-merged on top of that rendered base (`extraSystemYaml` wins on conflicts), and the merged result is templated again so any `{{ ... }}` values you set are resolved.
+- The final content is stored in the `<release-name>-worker-systemyaml` Secret and mounted into the pod as `/var/opt/jfrog/worker/etc/system.yaml`.
+
+Because of this merge, `extraSystemYaml` can be used to:
+- Add settings that have no dedicated top-level value (for example `shared.node.id` / `shared.node.ip`, or `worker.logging.application.level`), and
+- Override the value the chart would otherwise compute for an existing key (for example `router.serviceRegistry.insecure`, which is normally set from `.Values.router.serviceRegistry.insecure`).
+
+## Deploy
+
+Install Worker with the following command:
+
+```shell
+helm upgrade --install worker jfrog/worker -f extra-system-yaml-values.yaml
+```
+
+## Notes
+
+- `extraSystemYaml` follows the same structure as `system.yaml` itself, so nest keys under `shared`, `router`, `worker`, etc. as they appear in the rendered file.
+- If you only need to override a value the chart already exposes as a top-level setting (like `router.serviceRegistry.insecure`), prefer setting that value directly; use `extraSystemYaml` when there is no dedicated value or when adding entirely new settings.
+- To fully replace `system.yaml` instead of merging into it, use `systemYamlOverride.existingSecret` (or provide your own `systemYaml` block) to point at your own configuration.
+- See the [Worker YAML Configuration documentation](https://docs.jfrog.com/installation/docs/worker-yaml-configuration) for the full list of configuration values supported under `system.yaml`.

examples/worker/extra-system-yaml/extra-system-yaml-values.yaml

@@ -0,0 +1,16 @@
+global:
+  jfrogUrl: "http://artifactory-local.my-arti.svc.cluster.local:8082"
+  joinKey: EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
+  masterKey: bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
+extraSystemYaml:
+  shared:
+    node:
+      id: my-node-id
+      ip: 10.0.0.1
+  router:
+    serviceRegistry:
+      insecure: true
+  worker:
+    logging:
+      application:
+        level: debug

examples/worker/global-values/README.md

@@ -0,0 +1,36 @@
+# Worker Global Values
+
+This example shows how to configure JFrog Worker using the `global` values block instead of (or in addition to) the regular top-level values.
+
+`global` values are meant for settings that are typically shared across multiple JFrog charts deployed together (for example when Worker is deployed as part of the `jfrog-platform` chart, alongside Artifactory). Values under `global` take precedence over their equivalent top-level (service-level) values.
+
+See the [global-values.yaml](global-values.yaml) for the configuration example.
+
+## Precedence
+
+For the values below, if both `global.<key>` and the top-level `<key>` are set, `global.<key>` wins:
+
+| Global value | Equivalent top-level value | Notes |
+| --- | --- | --- |
+| `global.jfrogUrl` | `jfrogUrl` | Artifactory URL |
+| `global.joinKey` / `global.joinKeySecretName` | `joinKey` / `joinKeySecretName` | Join key used to connect Worker to Artifactory |
+| `global.masterKey` / `global.masterKeySecretName` | `masterKey` / `masterKeySecretName` | Unique master key |
+| `global.imageRegistry` | `image.registry` (per-image) | Overrides the registry for all images |
+| `global.imagePullSecrets` | `image.pullSecrets` (per-image) | Merged with existing pull secrets |
+| `global.versions.<component>` | Image `tag` (per-image) | Order of preference: 1) `global.versions` 2) image tag 3) `Chart.AppVersion` |
+| `global.nodeSelector` | `nodeSelector` | Applies to Worker pods |
+| `global.customCertificates.enabled` | `customCertificates.enabled` | Custom certificates copied to the trusted keys directory |
+| `global.customVolumes` / `global.customVolumeMounts` | `common.customVolumes` / `common.customVolumeMounts` | Both global and common entries are applied simultaneously (not mutually exclusive) |
+| `global.customInitContainers` / `global.customSidecarContainers` | `common.customInitContainers` / `common.customSidecarContainers` | Both global and common entries are applied simultaneously (not mutually exclusive) |
+
+## Deploy
+
+Install Worker with the following command:
+
+```shell
+helm upgrade --install worker jfrog/worker -f global-values.yaml
+```
+
+## When to use global values
+
+Use `global` values when deploying Worker together with other JFrog charts (for example via the `jfrog-platform` umbrella chart) and you want a single place to set values like `jfrogUrl`, `joinKey`, `masterKey`, `imageRegistry` or image versions that should apply consistently across all the deployed services.

examples/worker/global-values/global-values.yaml

@@ -0,0 +1,9 @@
+global:
+  jfrogUrl: "http://artifactory-local.my-arti.svc.cluster.local:8082"
+  versions:
+    worker: 1.216.0
+  imagePullSecrets:
+    - mysecret
+  imageRegistry: myregistry.com
+  joinKey: EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
+  masterKey: bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

examples/worker/loggers/README.md

@@ -0,0 +1,29 @@
+# Worker Loggers
+
+This example shows how to expose specific Worker/Router log files as sidecar containers using the `loggers` value, so they can be viewed with `kubectl logs` or picked up by a log collector without exec'ing into the pod.
+
+See the [loggers-values.yaml](loggers-values.yaml) for the configuration example.
+
+## How it works
+
+- For each log file name listed in `loggers`, the chart adds an extra sidecar container to the Worker Deployment (named after the log file, e.g. `worker-service.log` becomes the `worker-service-log` container) that tails that log file.
+- The available logger names are:
+  - `router-request.log`
+  - `router-service.log`
+  - `router-traefik.log`
+  - `worker-service.log`
+  - `worker-request.log`
+- Resource requests/limits for these sidecars can be set with `loggersResources`.
+
+## Deploy
+
+Install Worker with the following command:
+
+```shell
+helm upgrade --install worker jfrog/worker -f loggers-values.yaml
+```
+
+## Notes
+
+- Once deployed, view a given logger's output with `kubectl logs <worker-pod> -c <logger-container>` (for example `kubectl logs <worker-pod> -c worker-service-log`).
+- Any log collector that scrapes container stdout in the cluster will automatically pick up these sidecars' output as well.

examples/worker/loggers/loggers-values.yaml

@@ -0,0 +1,6 @@
+jfrogUrl: "http://artifactory-local.my-arti.svc.cluster.local:8082"
+joinKey: EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
+masterKey: bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
+loggers:
+  - worker-service.log
+  - worker-request.log