Create a helm package

[andrewhowdencom]

This distribution seems like a good candidate to create a helm package from.

If you like, I will see if I can create a patch for this, somehow.

[luna-duclos]

I'd certainly have nothing against a helm package, with the caveat that users still need to be able to configure their DNS provider somehow.

[andrewhowdencom]

This is getting towards done (will tidy the history and write a decent commit later, but it's tracked at master...andrewhowdencom:ahowden_add-helm-packge)

There are two outstanding issues:

1. How should we configure the DNS providers? I do not see any way to conditionally create files with helm packages (though this is my first attempt at creating such a package), so I'm inclined to create a secret for all possible combinations, populate them with empty values and mount them all into the container. If the DNS provider is not used, the environment variables will just exist in the session and be ignored. But it means running a lot of mostly pointless mounts -- this feels kind of insane.
2. In testing the HTTP provider, it was binding port 80 rather then port 8080, as doumented in https://github.com/PalmStoneGames/kube-cert-manager/blob/master/docs/providers.md#http

This was verified in a number of ways

• It works
• $ watch -n 1 netstat -tulpn during a HTTP challenge request

[andrewhowdencom]

Stub (mental note) - A large, monolithic secret containing all environment variables is probably fine here.

[paultiplady]

@andrewhowdencom might be possible to do something cunning with named templates: https://github.com/kubernetes/helm/blob/master/docs/chart_template_guide/named_templates.md#the-include-function

Looks like all of these boilerplate env variables are of the form KEY=value, so perhaps you can use something like the {{- range $key, $val := .Values.config }} syntax at the bottom to only specify the env block once, and insert it N times, once for each k/v pair in the config dict.

[andrewhowdencom]

You know, I completely forgot about this. I got it "mostly working", and have thus just been using it.

@paultiplady That is a good idea. However, I'm time limited -- given that this works as it stands, I might offer it up for PR shortly (so, with docs).

The helm charts have also undergone somewhat of a "standardisation" recently based around the prometheus chart, and have abstracted things like storage is a superior way.

For ref, the repo is here: https://github.com/andrewhowdencom/kube-cert-manager/tree/ahowden_add-helm-packge/helm

I don't have an internet connection that's reliable at the minute, but I'll see if I can take a look at this over the next couple weeks!

[luna-duclos]

Thanks! Looking forward to the PR :)

[AlecTroemel]

Just saw this, I actually created a helm chart located here https://github.com/mirusresearch/charts/tree/master/incubator/kube-cert-manager
Feel free to use it, pick it apart, submit PR

[andrewhowdencom]

@AlecTroemel oh my god I forgot about this entirely, I feel so guilty. @luna-duclos the chart I previously constructed does not follow some of the more modern conventions set out by helm. I would probably vote for using @AlecTroemel's version, and as I get time to do work on this (I want to, but am currently under load setting up CI/CD pipelines with Kubernetes as well as some monitoring and logging infra) I will submit patches to @AlecTroemel's chart.

<3 Sorry all.

[AlecTroemel]

@andrewhowdencom no need to feel guilty, I just started using this awesome project! I hope to eventually commit some PR's to kube-cert-manager and merge that chart into the official helm repo.

[rochdev]

Is there still work being done to get this into the official helm charts repo?

[AlecTroemel]

@rochdev I'm not sure. I created a helm chart you can use here https://github.com/mirusresearch/charts/tree/master/stable/kube-cert-manager. If its something the maintainers here want in the repo I could create a PR