- It turns out we can set it up with helm, it was just an issue with not
starting with a clean slate. I guess it probably would have been
better to just set it up from scratch and deleted the develop server,
like we intend to do in production.
- image is set configurable and set to the app version for version
control
- imagePullPolicy revert earlier changes to flatten hierarchy since helm
create uses .Values.image.pullPolicy
- update imagePullPolicy to IfNotPresent since this is the default with
helm create and fits with our strategy as well.
- Source, https://helm.sh/docs/topics/chart_best_practices/pods/
- Variables should use camel case.
- Favor flat hierarchy over nested.
- "Every defined property in values.yaml should be documented. The
documentation string should begin with the name of the property it
describes, and then give at least a one-sentence description."
- Source, https://helm.sh/docs/topics/chart_best_practices/values/
- remove namespace, since it's best practice to use the cli to add it,
@roschaefer points out
- organize templates into directories
- migrations should be ran after the backend has started...
- should init really be ran every time??
Also found:
```
Some users have raised concerns that the Neo4j image changes file permissions on the host machine.
By default, Neo4j runs as the user neo4j who only exists in the container, not on the host. That means that it's hard to set up mount folders on the host which this new user has write permissions for. We have updated the error messaging with advice about how to fix file permission errors. We also introduced writability checks and reduced the amount of file permission changes the image will perform. This has been found to interfere with some Kubernetes setups, so is currently an opt-in feature.
To enforce stricter file permissions checking you can pass this environment variable to the container:
--env SECURE_FILE_PERMISSIONS=yes
```
from https://hub.docker.com/_/neo4j
Implemented the above ☝️
