From 4724384dfcb3ab28c23b0858e10615fb345d6932 Mon Sep 17 00:00:00 2001 From: foobar Date: Thu, 25 Apr 2024 18:33:18 +0100 Subject: [PATCH] helmify rfc --- docs/designs/helmify.md | 44 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 docs/designs/helmify.md diff --git a/docs/designs/helmify.md b/docs/designs/helmify.md new file mode 100644 index 000000000..f2b5b43d7 --- /dev/null +++ b/docs/designs/helmify.md @@ -0,0 +1,44 @@ +# Helm-ify + +## The problem + +Currently the project relies on helm install-ing several helm Charts, +required for the various components. +However, other parts of the project such as the project components themselves +and migrations are a combination of `kustomize.yaml` manifests (components), k8s + yamls applied through `draconctl` (migrations). This is significantly confusing +and tech debt since it is not clear what installs what, how and why. + +It is suggested that the project uses Helm as its sole way of deploying things. + +## Changes suggested + +The following changes are suggested + +* Make a `dracon-dev` chart which installs all the sub-charts referenced by +the `make-dev` target +* Make `draconctl migrations apply` only apply migrations against a database url +and not try to manage a k8s job +* Make a `dracon` chart which installs dracon components and migrations only +assuming there are prerequisite systems present (Elasticsearch, Postgres etc), +values for those systems are provided through `values.yaml` +* Transform all components into Charts, one chart for each. +* Make `pipelines` be their own Charts +* Add the ability for draconctl to interface with an OCI registry and discover + components. +* Add the ability for draconctl to create Charts via CLI arguments and manage + them + +## Benefits + +This approach allows for maximum extensibility and configurability. +e.g. Adding private components is an extra line in the Chart, adding migrations +is just running another chart with another post-job that depends on the original +dracon. + +Moreover this makes components universally findeable and allows anyone to host +components wherever they want. + +This approach is also testable as there are lots of Helm test utils and allows +for flexibility in both deployment and piecing together our many +(often optional) moving parts. \ No newline at end of file