ocf-kubernetes-deploy: create k8s secrets from file templates #146
Conversation
There was a problem hiding this comment.
I left a comment about building yaml, but this whole design looks suspicious to me. You shouldn't need to template Kubernetes resource or even write any part of them in this script-- that's what kubernetes-deploy (or krane render) handles for you.
Instead, the secret resources should be defined in their respective repos as erb files, with templates for where the actual secret data goes. ocf-kubernetes-deploy should read the secrets and add them to the bindings dict so they can get filled in.
EDIT: ok, I kind of get this, since we don't want to make an inner template of the entire synapse config. I guess this is fine, as long as we don't lean on it too much and avoid it when possible. We want repos to be explicit about what Kubernetes resources they're creating, and this change makes the guarantee a bit muddy, but it's probably worth it.
staff/sys/ocf-kubernetes-deploy
Outdated
| SECRET_RESOURCE_TEMPLATE = ''' | ||
| apiVersion: v1 | ||
| kind: Secret | ||
| metadata: | ||
| name: {name} | ||
| type: Opaque | ||
| stringData: | ||
| {string_data} | ||
| ''' | ||
|
|
||
| STRINGDATA_SECRET_TEMPLATE = ''' | ||
| {name}: | | ||
| {value} | ||
| ''' |
There was a problem hiding this comment.
Instead of templating yaml, you should build up a json object with standard Python types (dicts, lists, strings) and then convert it to json at the end. All json is valid yaml anyways so there's no need to touch yaml here.
There was a problem hiding this comment.
The problem is that we aren't creating a yaml file, we are creating an erb file. That is to say, we are NOT doing json or yaml manipulation; fundamentally we are doing string manipulation to create an erb file that will be templated into a yaml file. Working in json creates an additional level of conversion that we have to make sure not to break.
A concrete example of what this means:
Say we decide to use a partial in our secret template. ocf-kubernetes-deploy reads our template and stuff it into a json object. Then we dump the json to a file. Now, the " characters in the partial tag in the template have been escaped by the json parser, and the generated ocf-kubernetes-deploy-secret-xyz.json.erb is not valid erb (even though the secret template is valid erb).
This reasoning is definitely a little unintuitive, but it is principled. That said, the template system I used is a little messy and it would be great if there was a better way to do this.
This will look for files like kubernetes/secrets/<secret_name>/*.erb, and create corresponding Kubernetes secrets containing these files as key-value pairs. This allows us to template files to include injected secrets and then mount the Kubernetes secret resource as a volume into a container.
Fixes #145.
This will look for files like
kubernetes/secrets/<secret_name>/*.erb, and create corresponding Kubernetes secrets containing these files as key-value pairs. This allows us to template files to include injected secrets and then mount the Kubernetes secret resource as a volume into a container.This allows files like homeserver.yaml in matrix to be stored in the git repo for matrix, and just have the secret portions injected (given the correct volume setup in the deployment yaml).