Create Helm chart for bookkeeper

[gothub]

Helm is a k8s package manager, which could make the deployment of bookkeeper simpler. See
https://github.com/helm/helm

[mbjones]

Started helm configuration in https://github.com/DataONEorg/bookkeeper/tree/k8s-config/helm

The deployment fails to start because the app can't find the bookkeeper.yml file in the PVC. Logs from failure:

$ kubectl logs -n bookkeeper pod/bookkeeper-75694b758b-9nr6j
java.io.FileNotFoundException: File /opt/local/bookkeeper/bookkeeper.yml not found
        at io.dropwizard.configuration.FileConfigurationSourceProvider.open(FileConfigurationSourceProvider.java:18)
        at io.dropwizard.configuration.BaseConfigurationFactory.build(BaseConfigurationFactory.java:79)
        at io.dropwizard.cli.ConfiguredCommand.parseConfiguration(ConfiguredCommand.java:126)
        at io.dropwizard.cli.ConfiguredCommand.run(ConfiguredCommand.java:74)
        at io.dropwizard.cli.Cli.run(Cli.java:79)
        at io.dropwizard.Application.run(Application.java:94)
        at org.dataone.bookkeeper.Bookkeeper.main(Bookkeeper.java:140)

TODO: Discuss with @gothub what the bootstrap sequence was envisioned for getting config files onto the PVCs. Probably easiest to embed a default in the ConfigMap.

[gothub]

Originally the bookkeeper.yml file was built into the Docker image, so I moved it out so that it could be manually placed on the statically provisioned NFS-based PV. The intent was to be able to update the configuration independent of the Docker image build.

Incorporating the config info into a ConfigMap sounds good, although refactoring to read from a ConfigMap from a Java program would be required. I haven't looked into this yet.

[mbjones]

One convenient way to handle the ConfigMap without java changes is to mount the config file as a volume using the ConfigMap as the source. Then, changes to the ConfigMap can be made externally and updated with helm update, and there are no code changes needed.

[mbjones]

For example, use a ConfigMap like this to load the contents of a config directory into a ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configfiles
  {{- template "index-monitor.labels" . }}
data:
{{ (.Files.Glob "config/*").AsConfig | indent 2 }}

And then you can mount those files as a volume in your pods with a snippet like this:

spec:
  volumes:
      - name: {{ .Release.Name }}-config-volume
        configMap:
          name: {{ .Release.Name }}-configfiles
          defaultMode: 0644

Once that is done, someone can update the config by modifying the files in the config directory and make a new ConfigMap which they post using a helm update. This puts reconfiguring the app into a versioned helm command, and allows rollback. For configfiles that don't change often, this might be preferred to using a mutable PVC. Let's discuss our options on slack.

[mbjones]

I moved the config file into a configmap and mounted it, and got past that error. now just postgres deploy and config are needed. See sha 60a67de.

[mbjones]

Began migrating postgres into helm config. See sha 35145ea.

While I am currently mirroring the pg setup from previously, we should consider whether to use an embedded helm subchart for postgres, or whether to install it independently altogether.

Previously I moved the bookkeeper.yml config file into helm, but note that it is not configured with the correct dbname/pass -- determine if those values can be derived from values.yaml.

[mbjones]

From sha 4e4b3ef we can now use values from values.yaml in bookkeeper.yml.

[mbjones]

From sha 5fc896d, we now have a functional helm deployment with both bookkeeper and postgres running, and the web REST API responding on the ingress on the dev cluster. Needs lots of cleanup and refinement work, and testing.

[mbjones]

Basic helm config now working, fully configurable through the values.yaml file. Releasing this as docker image 0.4.0 in sha ca5a7f4.

[mbjones]

Merged into develop with PR #72