helm: improve deployment and service manifest

[acolombier]

Add support for custom resource definition and extend customisation of service specific settings.

This change is necessary if you want to apply least privilege policy via security context. Here is a custom values.yaml that can be used to achieve just that:

  securityContext: 
    privileged: true

  podSecurityContext: 
    fsGroup: 65534
    runAsUser: 65534
    runAsGroup: 65534
    seccompProfile: 
      type: RuntimeDefault
    sysctls:
      - name: net.ipv4.ip_unprivileged_port_start
        value: "500"

  securityContext: 
    capabilities:
      drop:
      - ALL
    readOnlyRootFilesystem: true
    allowPrivilegeEscalation: false
    runAsNonRoot: true
    runAsUser: 65534
    runAsGroup: 65534

  extraArgs:
    - --no-caps
   
  resources: 
    limits:
      cpu: 100m
      memory: 128Mi
    requests:
      cpu: 100m
      memory: 128Mi


  extraVolumeMounts:
    - mountPath: /var/log/syslog
      name: logs
    - mountPath: /var/lib/syslog-ng
      name: libs
  extraVolumes:
    - name: logs
      emptyDir: 
        sizeLimit: 10Gi
    - name: libs
      emptyDir: 
        sizeLimit: 100Mi

[kira-syslogng]

This user does not have permission to start the build. Can one of the admins verify this patch and start the build?
(admin: you have the next options (make sure you checked the code):
"ok to test" to accept this pull request (and further changes) for testing
"test this please" for a one time test run
"add to whitelist" add author of a Pull Request to whitelist (globally, be careful, it means this user can trigger kira for any PR)
do nothing -> CI won't start)

[kira-syslogng]

This user does not have permission to start the build. Can one of the admins verify this patch and start the build?
(admin: you have the next options (make sure you checked the code):
"ok to test" to accept this pull request (and further changes) for testing
"test this please" for a one time test run
"add to whitelist" add author of a Pull Request to whitelist (globally, be careful, it means this user can trigger kira for any PR)
do nothing -> CI won't start)

[bazsi]

Ok to test;

[bazsi]

Just wrote this for another helm related PR #3937 but applies here similarly.

This PR has been overlooked over a year, sorry for that.

The reason this had such a rough path into the git repo is that this repose has been traditionally been the source code which was used to generate Linux packages.

Those contributing here (including myself) didn't know enough about helm charts to make decisions about it, thus even the original one has been in contrib.

There's however a project called AxoSyslog that aims to be the "cloud native distribution" for syslog-ng. Here's the announcement:

https://axoflow.com/cloud-ready-syslog-ng-images/

And here's the repository for the container
https://github.com/axoflow/axosyslog-docker

And the helm chart:
https://github.com/axoflow/axosyslog-charts

I do see some momentum building around that project, transforming the documentation to be cloud first and also adding typical cloud related features such as Prometheus like metrics.

I think it would make sense to move helm charts to a better home and AxoSyslog could be that home.

What do you think?

PS: I am both the original founder of syslog-ng and Axoflow.

[bazsi]

NOTE: I originally copy-pasted the comment above from a different PR as I didn't have too much time to respond properly. I came back now to give you a proper answer :)

Those contributing to syslog-ng (including myself) don't/didn't know enough about helm charts to maintain one. Also, container focused behaviour do not always match the expectations for syslog-ng's primarily distro based audience.

For this reason, I think it makes sense to separate the original "syslog-ng" we all love and the "cloud-native" distribution of it. The core is the same, but the first is published as source and some distro packages, the second as a container and helm charts.

The defaults may also differ: in a container we don't need to handle local logs (e.g. /dev/log or the journal), whereas this is a critical element in a distribution.

A few months ago, we decided to create a cloud native distribution of syslog-ng, also adding features that make it more suitable for this context. "We" here means Axoflow, which happens to overlap a lot with the original authors of syslog-ng.

Couple of things we added in the last few releases:

• prometheus like metrics
• connectors for Loki and S3

While the code level features are distributed as part of syslog-ng (as you can see in the last couple of release announcements) I think AxoSyslog is a better home for helm charts and the container.

Here are a few links to get you started:

• Original announcement: https://axoflow.com/cloud-ready-syslog-ng-images/
• And here's the repository for the container https://github.com/axoflow/axosyslog-docker
• And the helm chart: https://github.com/axoflow/axosyslog-charts

[bazsi]

I have now merged the axosyslog-docker and axosyslog-charts repo, so now both sits in the same github repo, here:

https://github.com/axoflow/axosyslog/

do you think you could re-open your PR there?

[acolombier]

Hi @bazsi, no problem, I will look into this as soon as I get back to my computer!