A helm chart to help deploy a lemmy instance. Contribute to dudeami/lemmy-chart development by creating an account on GitHub.

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!

  • Ananace@lemmy.ananace.devEnglish
    0·
    1 year ago

    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.winOPEnglish
      0·
      1 year ago

      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 Secret instead of a ConfigMap is obvious, thanks for pointing that out.

      The reason I opted to require creating a Secret was the concern of storing secrets in values.yaml in plaintext. In my opinion secrets in values.yaml is a potential attack vector and an unneeded liability (not that I did much better storing secrets in a ConfigMap). 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 your secrets.yaml to a repo haha. Is this generally considered an acceptable risk?

      • Ananace@lemmy.ananace.devEnglish
        2·
        1 year ago

        Generally, allowing secrets to be inserted through the values.yaml is 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 in values.yaml means 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 input
        • existingSecret with existingSecretKey/existingSecretUsernameKey/etc for users that want to handle the secrets themselves