A helm chart to help ease deployment on kubernetes clusters. At the moment it's only designed to run as a single "node" but will work on adding horizontal scaling in time. Thought others might find it a useful.
I am fairly new to creating helm charts, so feel free to comment, critique, or contribute!
3 Comments
ace@lemmy.ananace.dev · 2 pts · 3y
You might want to avoid reimplementing deploying known - and complex - components like postgres, it's better to grab such things as a dependency from someone who's already done so.
It's also quite suboptimal to store secrets - like the postgres password and such - in a ConfigMap, and requiring the user to manually create objects in order to be able to deploy your chart is also a major hurdle towards actually using it.
I wrote my own Helm Chart for lemmy as well, not really finished with it either though as I want to make the deployment safer, and also better support gitops.
dudeami0@lemmy.dudeami.win · 0 pts · 3y
Thank you for taking the time to look through my chart's source. I appreciate the thoughtful critiques and will implement them shortly. I'll also be looking at your chart to learn from, thanks for sharing! In response to each of your points:
Good call on using a dependency for postgres; I did not know of this functionality or think to look for it.
In hindsight storing the config file in a
Secretinstead of aConfigMapis obvious, thanks for pointing that out.The reason I opted to require creating a
Secretwas the concern of storing secrets invalues.yamlin plaintext. In my opinion secrets invalues.yamlis a potential attack vector and an unneeded liability (not that I did much better storing secrets in aConfigMap). This does bring up the concern of secrets being stored in the bash history as well now I think of it. Trying to look up best practices on the matter I can't find anything except don't commit yoursecrets.yamlto a repo haha. Is this generally considered an acceptable risk?ace@lemmy.ananace.dev · 2 pts · 3y
Generally, allowing secrets to be inserted through the
values.yamlis an ease-of-install feature, it's technically no more or less safe than requiring secrets to be created manually. The one place it makes a difference is in GitOps, since having them only invalues.yamlmeans pushing them into git.Normally, the best practice is to have secrets as two sets of inputs in your
values.yaml;username/password/apikey/etc for cleartext inputexistingSecretwithexistingSecretKey/existingSecretUsernameKey/etc for users that want to handle the secrets themselves