Hello everyone:
We released a new version of our Helm chart dgraph-0.0.10 for automating configuration and deployment of Dgraph on the Kubernetes platform.
Documentation on usage:
This brings support for configuring Dgraph enterprise features Access Control Lists and Encryption at Rest with Helm charts.
I’m not a helm expert, but I know the gitlab helm chart has a migration mechanism built into it. I wonder if it would be possible to do something similar with dgraph where on upgrades the helm chart would spin up new dgraph nodes, set the existing nodes to read-only, export data, bulk load data and copy to new nodes, and switch the services over.
It seems like it might be possible. Currently I have a manual script for the process. Until upgrades are solved, I’m not sure how useful the helm chart is for anything other than testing.
I like where you are going with this. Helm chart is mainly a templating system that renders Kubernetes manifests and deploys the manifests, so it by itself doesn’t have rich advanced orchestration outside of Kbuernetes. Kubernetes itself does offer things like batch jobs and cron jobs to allow for operations like export and bulk load. We are beginning to look at this in upcoming feature for scheduling full and incremental binary backups (enterprise feature).
For more advance orchestration scenarios, I think we would need another layer, such as a operator with a dgraph crd to handle such scenarios. In this scenario, you would deploy an operator along with manifests (templated through helm or other) that would then perform dgraph deployments and orchestration.
The way they do it (charts/gitlab/charts/migrations · master · GitLab.org / charts / GitLab Chart · GitLab) is the chart creates a kubernetes job using a helm hook which spins up a POD to perform the migration tasks.
I don’t think a CRD is needed for this.
I think the Spinnaker helm chart does some similar things. It spins up jobs to orchestrate, then runs another tool to build out the rest of the cluster.