Release 3.0.0 - Helm Chart Production readiness

[marcemv90]

Hello!

Here's another PR to make the Helm Chart more Production-Ready. I know it is a big one, so please feel free to reach if something needs clarification or explanation.

At the end of this message, there are instructions to run a version of this Helm Chart from my forked repository, so you can test whatever you want before merging this PR.

Motivation

• The current helm chart does not allow all the installation options described in the documentation, following are all the options that should be available:

  • Option 1a - Low Volume Deployment (Streaming)
  • Option 1b - Low Volume Deployment (Non-streaming)
  • Option 2a - Streaming Scalable Deployment
  • Option 2b - Non-Streaming Scalable Deployment

• Properties of the services are restricted to just the contents of the hardcoded keys specified in the configMaps, limiting the amount of properties that can be passed to the services (E.g OAuth, logging, etc.) For example:

  • api-config.yaml
  • dacha-config.yaml
  • edge-config.yaml

• Add some Helm Chart and Kubernetes best practices, such as:

  • Ability to enable and disable the different components from the values.yaml
  • Ability to pass configuration as environment variables (Still compatible with property files)
  • Ability to pass configuration from existing secrets, to prevent the secrets from being readable in the values.yaml
  • Better ingress rules management.
  • Ability to pass extraContainers, if needed.
  • Ability to pass extraVolumes, if needed.
  • Ability to pass extraVolumeMounts, if needed.
  • Ability to specify the Deployment Strategy from the values.yaml
  • Independent configuration for each of the component from the values.yaml, such as the securityContext, podSecurityContext, environment variables, extra configuration, etc.
  • Organize template files in folders, for readability.

More details on the Changes section.

Changes

Non-Helm-related changes

• Helm release GitHub action was broken when merging Various chart improvements #33, preventing new Chart releases from being pushed automatically on merges to the master branch (Sample error here). The problem was with the helm client not having added the required helm repositories from Chart dependencies, now the GitHub code has been upgraded to automatically add all the helm repositories specified in the Charts.yaml dependencies.
• Git ignore .DS_Store file to prevent accidental commits

Helm changes

• Big refactor:

  • Configuration now can be passed with both environment variables and property files.
  • Secret configuration now can be passed from existing secret, in the form of both environment variables and property files (this last one using extraVolumes and extraVolumeMounts.
  • Now all the deployments accept extraContainers, extraVolumes and extraVolumeMounts to make it more flexible.
  • Common configuration files now can be updated from the values.yaml (E.g /etc/common-config/log4j2.xml)
  • Better ingress rules management. Now each service can expose its own ingress, instead of sharing the same ingress among all the services. This is a best practice, which in turns makes using the ingress defaultBackend no longer needed. It was needed before because the ingress rule was not correctly specified.

• Prometheus compatibility:
  All the components were exposing Prometheus metrics, but the services weren't exposing the metrics endpoints and the Prometheus Operator serviceMonitors were not included.

  • Now Prometheus metrics exporting can be toggled on and off from the values.
  • If Prometheus is enabled, services expose metrics endpoints.
  • If Prometheus is enabled, Prometheus Operator serviceMonitor resources are also deployed.
  • Now if you have the Prometheus Operator in your Kubernetes Cluster, you can deploy the corresponding serviceMonitors directly from the Helm Chart.

How to test it before merging

There's a Helm Release with the content of this PR on my forked repository that can be installed prior merging this Pull Request. You can either download the release from the Releases page or pull it using helm CLI:

• Releases: https://github.com/marcemv90/featurehub-install/releases
• Helm CLI instructions follow:

helm repo add marcemv90-featurehub-install https://marcemv90.github.io/featurehub-install
helm repo update
helm pull marcemv90-featurehub-install/featurehub --version 3.0.0

Feel free to commit to this branch if desired. I've updated helm-docs documentation and added comments on the values and templates, but I will be probably improving the documentation a bit more, so expect few sporadic commits.

Many thanks for your time and work!

Kind regards.

[rvowles]

this is a little unusual - do you see a use case where Dacha needs an ingress? It should never be exposed outside the cluster, only MR and Edge would normally be?

[marcemv90]

Hello!

Probably you are right, as I don't have all the insights of the application, I did my best just by reading the documentation, but if dacha having an ingress does not make sense, just let me know and I'll remove its template and the corresponding values :)

[rvowles]

This is a tremendous amount of work! We are very grateful!