Skip to content

feat(deployment): Add helm charts for deploy

Hannes Heine requested to merge pr1613head into pr1613base

Created by: Tirokk

roschaefer Authored by roschaefer Merged

🍰 Pullrequest

Issues

Todo

Taking from notes in our Daily Standup 2020-01-26, @roschaefer reports, we need to consider these things.

  • helm chart volumes

  • I spent a big part of today trying to get this worked out and it didn't in the end. I was able to create PersistentVolumeClaims, but when they created PersistentVolumes in DigitalOcean, it messed up the neo4j deployment, so that it could not create the needed data/databases directory, etc.

  • The issue is known and explained here https://www.digitalocean.com/docs/kubernetes/how-to/add-volumes/#setting-permissions-on-volumes ... I tried to get this working, and in the end it did get passed the originally error, but then I couldn't restore the neo4j data! it would load successfully, but then when the neo4j pod restarted, the data would dissapear :frowning_face:

  • In the end, it was much easier to set up the PersistenVolumeClaims with kubectl ...

  • If you have read the above, it turns out that the issue was most likely due to existing PV and PVC, I was able to get it to work with Helm, and this is preferable cause not only does it mean it's easier to set up, but Helm manages making sure the pods that have a PVC get assigned correctly. I dealt with issues when setting up the PVC with kubectl and everything else with Helm

  • admin-user

  • please give a use case for this @roschaefer ... in Kubernetes >= 1.16 RBAC(role-based access control) is enabled by default. See, https://helm.sh/docs/topics/rbac/

  • @roschaefer says this is more about database admin, oder?

  • categories

  • I need clarification on what this means.

  • @roschaefer clarifies that we would like a way for other people who want to host the software to be able to adapt it to their needs, so one of those would be the ability to define Categories to suit their needs. We also agreed this could be done in a/several separate PRs. We should open an EPIC for this, with sub-issues moving us closer to this goal.

  • services, ie cert-manager, ingress, maintenance

  • upgrade

  • what do you mean by this @roschaefer ? clarify please, we can use the helm upgrade command to update our version, for example, or scale. It's not something we need to set up, we need to document it, for sure.

  • hooks, ie migration

  • done, but a doubt whether we really want to run migrate init every time we deploy? if not, should we just run it manually the first time, then again anytime there are new indexes/constraints??

after meeting with @roschaefer, we talked about the reasons to favor a Job that handles the database migrations, for example, when/if we scale the backend, we do not want every pod to run the migrations.

Merge request reports