iver-wharf / wharf-helm

Deploy Wharf to Kubernetes using Helm

Wharf Helm chart

Repository of Wharf's Helm charts.

Helm charts in this repo

Chart	Description
wharf-helm	Deploy Wharf to Kubernetes using Helm
wharf-cmd	Deploy wharf-cmd, Wharf's execution engine, to Kubernetes
wharf-aino	All-in-One Wharf deployment, including Postgres

To start using, add the Wharf Helm chart repository:

helm repo add iver-wharf https://wharf.iver.com/wharf-helm

Generating charts/*/README.md

The README.md files in each chart is generated using norwoodj/helm-docs.

1. Install helm-docs. Installation instructions can be found at: https://github.com/norwoodj/helm-docs#installation

   If you have Go installed, you may run:

   go install github.com/norwoodj/helm-docs/cmd/[email protected]

2. Run helm-docs, preferrably before you create your pull requests:

   helm-docs

3. Commit the changes on the README.md files.

Publishing

The charts in this repository are published automatically using helm/chart-releaser. No further action is required except getting your change into the master branch.

If you need to group changes into a single release, it's suggested to instead follow git-flow and create a release branch, like so:

git checkout master

git pull

git checkout -b release/wharf-helm/v1.2.0

Then target all your grouped changes and PRs to that release branch. Once you're ready to deploy it you create a pull request from that release branch over to master, where it will be published automatically as soon as it's merged.

Linting

make deps # download linting dependencies

make lint

make lint-helm # only lint Helm charts
make lint-md # only lint Markdown files

Some errors can be fixed automatically. Keep in mind that this updates the files in place.

make lint-fix

#make lint-fix-helm # Helm linter does not support fixes
make lint-fix-md # only lint and fix Markdown files

---

Maintained by Iver. Licensed under the MIT license.

wharf-helm's Issues

wharf-cmd: Restart pod on config change

wharf-cmd doesn't listen for config updates in-place. Instead, on config changes, the whole deployment should be updated to for it to restart.

Suggest adding something like a SHA hash of the config as an annotation on the pod's template inside the deployments.

Use helm-docs syntax on comments

https://github.com/norwoodj/helm-docs uses a particular syntax for its comments. Like this:

controller:
  # -- Configure the healthcheck for the ingress controller
  livenessProbe:
    httpGet:
      # -- This is the liveness check endpoint
      path: /healthz
      port: http

The double dash -- is very important. We need to add this to group the settings appropriately, as since #8 they are a bit jumbled.

values.yaml JSON schema

Based on conversation from #6 (comment)

Helm v3 has support for JSON schemas for its values.yaml. If we add this, we both get extra bit of validation, and for those who use a text editor with the YAML language server from Red Hat then they also get intellisense when editing.

Sometimes, a chart maintainer might want to define a structure on their values. This can be done by defining a schema in the values.schema.json file. /.../

This schema will be applied to the values to validate it. Validation occurs when any of the following commands are invoked:

• helm install
• helm upgrade
• helm lint
• helm template

https://helm.sh/docs/topics/charts/#schema-files

So in our values.yaml we have the following:

$schema: https://raw.githubusercontent.com/iver-wharf/wharf-helm/wharf-helm-v1.0.0/charts/wharf-helm/values.schema.json

nameOverride: ""
fullnameOverride: ""

global:
  url: wharf.example.org
  ## Used in RabbitMQ & Jenkins to multiplex jobs and messages on the same
  ## instances while keeping track of their origin.
  instanceId: dev
  ## This flag is forwarded to the frontend where it can be used to show
  ## slightly different styling depending on if it's for production or not.
  isProduction: false

web:
  ## Defaults to 1
  replicaCount: 1
# ...and the rest of the YAML file

We might want to autogenerate it though, preferrably by using the same info that helm-docs take use of, as this would otherwise require us to maintain two separate files.

WHARF_DB_PORT collides with one provided by Kubernetes

Since wharf-api v4.2.0 it changed the environment variable names. One of those are WHARF_DB_PORT, which was previously DBPORT.

Not sure how kubernetes populates this, but it adds more than just WHARF_DB_PORT, but it also has values that collides with how wharf-api parses these values. Such as:

WHARF_DB_PORT_5432_TCP_ADDR=10.105.20.124
WHARF_DB_PORT_5432_TCP_PORT=5432
WHARF_DB_PORT_5432_TCP_PROTO=tcp
WHARF_DB_PORT_5432_TCP=tcp://10.105.20.124:5432
WHARF_DB_PORT=tcp://10.105.20.124:5432
WHARF_DB_SERVICE_PORT=5432
WHARF_DB_SERVICE_PORT_TCP_POSTGRESQL=5432

And lots lots more.

---

If the deployment already specifies an environment variable for WHARF_DB_PORT, then that will override the value provided by Kubernetes.

For backward compatibility, we should still provide the old DBPORT values as well.

Need way to specify wharf-vars to worker

wharf-cmd-worker needs variables, such as REG_URL.

wharf-cmd-worker supports reading from /etc/iver-wharf/wharf-cmd/wharf-vars.yml, but we've no way of adding that file from the helm chart.

This probably needs support inside wharf-cmd-provisioner to allow specifying additional volumes to mount in, or more specific a name of a secret to load as vars. Probably both: one for easy of config, and the other for those super custom implementations from powerusers.

wharf-helm: use configs like wharf-cmd

The smart environment variables in wharf-helm are nice, but they're weird. Better to just use built in features as-is.

Suggest only relying on plain configs, and then to import values from secrets use environment variables.

This would also remove all .Values.api.db... configs that the chart has. It's just super tedious to duplicate all configs like this. Allowing free configs means less to maintain for us.

Publish chart via GitHub pages

Found a brilliant guide (from 2020) about hosting Helm charts on GitHub pages as well as setting up proper GitHub Actions linting for it: https://jamiemagee.co.uk/blog/how-to-host-your-helm-chart-repository-on-github/

The CR_TOKEN workaround does not seem relevant anymore though: https://github.community/t/github-action-not-triggering-gh-pages-upon-push/16096/6 (source: https://dev.to/mikesir87/comment/1922o)

Depends on #1 to be merged first before work can be started