When messing around with the ingress I think I found an issue with the way it's setup. At least it's not documented. When defining the ingress it uses the following value:

service:
   port: {number}

This doesn't seem to be in the values.yaml. I do see this service.ports field so maybe that should be used instead?

This commit will disable the streams API via CLI argument. Add a parameter in .Values.streams to enable this flag.

Would be nice if we could support adding additional labels to the container (similar to the podAnnotations), change would be added here and adding an additional input value, maybe podLabels.
For us it would unlock us to use https://docs.datadoghq.com/getting_started/tagging/unified_service_tagging/?tab=kubernetes#partial-configuration.

If this sounds useful I can look to add this.

Instead of manually creating and referencing a config map, users should be able to specify multiple pipelines as part of the chart to use with streams mode. e.g:

streams:
  enabled: true
  pipelines:
  - hello.yaml:
      input:
        generate:
          mapping: root = "woof"
          interval: 5s
          count: 0
      output:
        stdout:
          codec: lines
  - aaaaa.yaml:
      input:
        generate:
          mapping: root = "meow"
          interval: 2s
          count: 0
      output:
        stdout:
          codec: lines

Add PodDisruptionBudget to control the evection of the pods

To help test changes, we should look at implementing the chart-testing library https://github.com/helm/chart-testing/tree/main

Can the logic for initContainers logic to this helm chart. this initContainer will run before the start benthos container. This will help set up a lot of dynamic values based on where the pod comes up

I'm using the latest version of EKS on AWS and wanted to deploy some jobs on benthos.

It seems to try to create a batch/v1beta1, but the latest version of EKS has batch/v1. There is any way to configure this?

Received response status [FAILED] from custom resource. Message returned: Error: b'configmap/benthos-streams configured\nerror: error retrieving RESTMappings to prune: invalid resource batch/v1beta1, Kind=CronJob, Namespaced=true: no matches for kind "CronJob" in version "batch/v1beta1"\n'

let me know if you need more information

We should use chart-releaser to handle the chart releases as it's more standardised.

Under normal operation, benthos' readiness is evaluated by checking the endpoint /ready as defined here.

The behavior is a bit different in streams mode, however:

Given a configMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: benthos-streams
data:
  hello.yaml: |
    input:
      generate:
        mapping: root = "hello"
        interval: 5s
        count: 0
    output:
      stdout:
        codec: lines
  aaaaa.yaml: |
    input:
      generate:
        mapping: root = "AAAAAAAAAA"
        interval: 2s
        count: 0
    output:
      stdout:
        codec: lines

readiness endpoints are created at

/aaaaa/ready
/hello/ready

The readinessProbe object (spec.template.spec.containers[].readinessProbe) only supports one probe, which would prevent sufficient checking to ensure all pipelines are connected.

Currently the readinessProbe is set to the livenessProbe endpoint, potentially returning a false positive. This should be reworked, hopefully with a strategy that includes all streams endpoints.

In addition to the core HTTP server, some inputs can listen on a port to receive data, like http_server and socket_server. Currently there is no support for additional service objects to be created for these inputs when a different port from the HTTP component is specified. Include protocol type in the configurable options.

Consider using this approach.

Hi, I'm trying to use the processor as follows:

    #   processors:
    #     - protobuf:
    #         operator: to_json
    #         message: FillReport
    #         import_paths: [ protobuf ]

So, I have configmap which is mounted as a volume then:

  extraVolumes: 
    - name: proto-vol
      configMap:
        name: protobuf

  extraVolumeMounts:
    - name: proto-vol
      mountPath: /protobuf

And after that I'm getting the following error:
level=error msg="Failed to create stream (fill_report_stream): failed to init processor <no label> path root.pipeline.processors.0: ..2023_11_20_13_23_29.2531302976/FillReport.proto:4:9: symbol \"FillReport\" already defined at FillReport.proto:4:9" @service=benthos

Inside of the container, I'm getting the folder structure with multiple links:

45341956 drwxr-xr-x    2 root     root            30 Nov 20 20:01 ..2023_11_20_20_01_05.1721020983
43088997 lrwxrwxrwx    1 root     root            32 Nov 20 20:01 ..data -> ..2023_11_20_20_01_05.1721020983
43089266 lrwxrwxrwx    1 root     root            23 Nov 20 20:01 FillReport.proto -> ..data/FillReport.proto

Should we actually do this manipulation? What should I do to pass my proto file to the processor?

Add support for commonLabels that is set for all the components of the deployemnt

Hi,

Currently restartPolicy is set to 'always' which causes the pod to constantly restart even if it completed successfully.

Regards.

Resources such as rate limit has to be fed through a separate file and using flag -r. The current arrangement to override args works but would be better if its controlled by a flag in base template chart.

This part of the logic, https://github.com/benthosdev/benthos-helm-chart/blob/main/templates/configmap.yaml#L31 not picking up config contents defined in Values.config if streams.enabled is true, works if changed to {{- if and .Values.config (ne .Values.streams.enabled false) }}

How am I supposed to set my benthos config file to the chart? Since this change/v2.1.0, I am unable to set using --set-file config=./path/config.yaml.

I also tried to set using cat, but no success:

rawConfigFile=$(cat my-config.yaml)

helm upgrade --install my-service benthos/benthos \
    --version 2.1.0 \
    -n my-namespace \
    --set config="$rawConfigFile"

Generated config file

http:
  address: 0.0.0.0:4195
  cors:
    enabled: false
  debug_endpoints: false
  enabled: true
  root_path: /benthos
-
  input:
    http_server:
      path: /poc
  output:
    broker:
      outputs:
        - stdout:
            codec: lines
        - sync_response: {}

We should lint the schema output as part of the tests to ensure that all the manifests are well formed.

Add support for command and args fields that replaces the entrypoint command of the docker. This will be necessary if we have to manipulate some commands, or do some additional operations inside docker before the docker starts

Version

2.0.1

Problem

Defining basic_auth config will fail liveness and readiness probes. Pods will keep getting killed.

Reproduction

Deploy with custom values file:

~ values.yaml ~
...
http:
  basic_auth:
    enabled: true
    username: <username>
    password_hash: <password_hash>

Liveness and readiness probes will fail with status code 401 (Unauthorized)

Notes

The probes probably need to check if http.basic_auth is configured and set <probe>.httpGet.httpHeaders accordingly.

Alternatively, the probes can be exposed to values.yaml so they can be customized.

Problem

Deploy 2.0.0 chart version failed using all default configs

Reproduction

$ helm install mybenthos benthos/benthos --version "2.0.0"
Error: INSTALLATION FAILED: template: benthos/templates/deployment.yaml:24:28: executing "benthos/templates/deployment.yaml" at <include (print $.Template.BasePath "/configmap.yaml") .>: error calling include: template: benthos/templates/_helpers.tpl:14:14: executing "benthos.fullname" at <.Values.fullnameOverride>: can't evaluate field Values in type bool

This chart should be improved to support Benthos streams:

• via config files (probably as configMaps)
• via streams API (enable running the binary in streams mode and verify that the service and ingress passes the data properly)

We will run into the same issue as #1 regarding pulling in external files; consider preloading configMaps as a prerequisite to the installation of the chart.

Problem

Both bugs bellow use --set-file config=./path/config.yaml to set the config file

1. A - is inserted in ConfigMap when replacing the config file by the helm template, making unreadable for Benthos

   • Example

     http:
     address: 0.0.0.0:4195
     cors:
         enabled: false
     debug_endpoints: false
     enabled: true
     root_path: /benthos
     -
     input:
         http_server:
         path: /poc
     
     output:
         broker:
         outputs:
             - stdout:
                 codec: lines
             - sync_response: {}
     

2. Custom config files that have any extra space or blank line are are converted to a raw string instead of being converted to YAML

   • Example

     http:
       address: 0.0.0.0:4195
       cors:
         enabled: false
       debug_endpoints: false
       enabled: true
       root_path: /benthos
     "input:\n  http_server:\n    path: /poc\n   \npipeline:\n  processors:\n    - noop:
       {}\n    \noutput:\n  broker:\n    outputs:\n      - stdout:\n          codec: lines\n
       \     - sync_response: {}\n"

• The bugs were observed in versions in 2.1.0 and 2.1.1.
• The unit tests (configuration_test.yaml) also fail if the bug #2 is reproduced

Cause

This probably happended in this commit, which removed the tpl and now it is not possible to set the config using --set-file config=./path/config.yaml

A POC with more details and outputs can be found at this repository

Related: #82

Test new shiny benthos in chart form.

My original approach to supplying certificate and key to Benthos was via specifying file path in values.yaml. The template then renders a K8s secret of type kubernetes.io/tls and sticks that in a volume upon install.

Issues:

• Helm does not access files outside the chart directory. This is navigable if you pull the chart down to a local filesystem, copy the cert/key into the chart directory, update values.yaml and deploy from there, but this does not work if you are installing the chart by reference.
• There is a PR to add a flag to helm for including external files, but currently it is stale with no ETA for merging.

Possible workarounds:

• Preemptive creation of TLS secret; not great due to extra steps but would probably be the cleanest in the chart templating (e.g. .Values.http.tls.certFile and .Values.http.tls.keyFile become simply .Values.http.tls.secretName). Should also enable other means of cert generation, like K8s CA (in situations where you need full E2E encryption and not just termination at an internal ingress controller)
• Injecting files via initContainer
• Supplying the raw cert/key data in values.yaml. Yuck.

One thought is that perhaps TLS is not as important a feature here due to TLS availability provided by ingress. Opinions welcome!

Using the latest Helm chart version, 0.7.1, results in benthos container failed to start with error: Config lint error" @service=benthos lint="/benthos.yaml(4,1) field read_timeout not recognised https://github.com/benthosdev/benthos-helm-chart/blob/main/templates/configmap.yaml#L14 , the issue is not found on 0.6.0

We should add E2E tests using a kind cluster in the pipeline, this should help catch any potential deployment errors.

Problem

When tls/auth is enabled, ServiceMonitor is not working due to missing scheme: https and basicAuth config for endpoint.

Reproduction

Deploy with custom values file

~ values.yaml ~
http:
  enabled: true
  cert_file: /etc/tls/benthos/cert.pem
  key_file: /etc/tls/benthos/key.pem
  basic_auth:
    username: <username>
    password_hash: <password_hash>

extraVolumes:
  - name: benthos-tls-vol
    secret:
      secretName: benthos-tls-secret

extraVolumeMounts:
  - name: benthos-tls-vol
    mountPath: /etc/tls/benthos

serviceMonitor:
  enabled: true

Notes

ServiceMonitor resource endpoint scheme and basicAuth should be configurable.

Add the possibiliy to run in streams mode without provinding a config map when we only want to use the api :

{{- if .Values.streams.enabled }} - "streams"
instead of
{{- if and .Values.streams.enabled .Values.streams.streamsConfigMap }} - "streams"
In deployement.yaml line 68

Add some nice-to-haves for the updating workflow:

Github Actions

on pull request:
✅ lint chart
✅ test chart against some basic configurations

on pull request commit:
✅ check version in chart.yaml
✅ if new version, tag main at latest commit

on tag:
✅ sync readme from main to gh-pages
✅ helm package new tag
✅ helm index
✅ Either push commit to repo or create PR for review and manual merging

As mentioned on PR #61, we should update the HPA configuration to accept any YAML for metrics, this will save on the maintenance burden of maintaining individual properties

E.g

{{- with .Values.autoscaling.metrics }}
  metrics:
{{- toYaml . | indent 4 }}
{{- end }}

You cant configure the benthos.yaml file manually when the chart is set to streams mode, this prevents enabling basic auth via:

http.basic_auth

http:
  address: 0.0.0.0:4195
  enabled: true
  root_path: /benthos
  debug_endpoints: false
  cert_file: ""
  key_file: ""
  cors:
    enabled: false
    allowed_origins: []
  basic_auth: # <----- cant set this, now I cant secure my streams
    enabled: false
    username: ""
    password_hash: ""
    algorithm: "sha256"
    salt: "

You really should be able to override this entire file when you are in streams mode as you would when not in streams mode....

I.e

    {{- tpl .Values.config . | nindent 4 }}

TODO:

• CONTRIBUTING.md
• CHANGELOG.md
• documentation improvement pass or two
• FANCY SHINY LOGO
• Enhanced testing of different configuration scenarios

Version

2.1.0

Problem

Probe configs in values.yaml are ignored as templats are wrongly indented (14 spaces instead of 12 spaces).

Reproduction

Deploy with http.enabled

Output

W0123 03:05:01.788036 2527026 warnings.go:70] unknown field "spec.template.spec.containers[0].livenessProbe.httpGet.failureThreshold"
W0123 03:05:01.788068 2527026 warnings.go:70] unknown field "spec.template.spec.containers[0].livenessProbe.httpGet.periodSeconds"
W0123 03:05:01.788074 2527026 warnings.go:70] unknown field "spec.template.spec.containers[0].livenessProbe.httpGet.successThreshold"
W0123 03:05:01.788083 2527026 warnings.go:70] unknown field "spec.template.spec.containers[0].livenessProbe.httpGet.timeoutSeconds"
W0123 03:05:01.788090 2527026 warnings.go:70] unknown field "spec.template.spec.containers[0].readinessProbe.httpGet.failureThreshold"
W0123 03:05:01.788094 2527026 warnings.go:70] unknown field "spec.template.spec.containers[0].readinessProbe.httpGet.periodSeconds"
W0123 03:05:01.788099 2527026 warnings.go:70] unknown field "spec.template.spec.containers[0].readinessProbe.httpGet.successThreshold"
W0123 03:05:01.788103 2527026 warnings.go:70] unknown field "spec.template.spec.containers[0].readinessProbe.httpGet.timeoutSeconds"

Cause

Fix

Indentation should be updated to 12 spaces.

When the config changes, the deployment using that config should be restarted.

https://helm.sh/docs/howto/charts_tips_and_tricks/#automatically-roll-deployments

Adding arbitrary volume mounts for configMaps and secrets should come in handy (e.g. for adding shared credentials files for cloud providers).

Currently an operator must list all streams config files in values.yaml like this:

streams: enabled
  streamsConfigMap: benthos-streams
  streamsConfigFilenames:
    - hello.yaml
    - aaaaa.yaml

Benthos has support for globs in filenames specified after the streams subcommand committed, so the next tagged build should include the changes. Refactor the chart afterwards so that the filenames will be pulled in automatically.

I can see that the last commits on this chart is from 7 months ago, and that it points to an older version of Benthos. I prefer to deploy Helm charts as that is less to manage on my end, so I wanted to ask if this chart will be maintained, or if I will be better off by setting up the service outside of Helm? :-)