Gitolite image - Helm chart

TL;DR

I added a Helm chart to gitolite-dibs.

In last post Gitolite - a dibs repository I introduced gitolite-dibs, a repository where I keep the development stuff for wrapping Gitolite inside a Docker image, aiming at deploying it with Kubernetes.

The sub-directory helm contains the needed parts to build a Helm chart. Run script pack.sh inside to generate a tarball that is suitable for running helm.

The chart is still in a bit of flux. The biggest pain point is managing the PersistentVolume and the deployment might shift to a StatefulSet in the future.

All said, it’s immediately useable with the following configuration options in the values.yaml file:

  • image: the usual stuff here, like a name that points to the image (most probably in a registry) and a pullPolicy that does what you think.
  • service: allows setting the details for the service. Gitolite is accessible through SSH in this image, so the port is 22 by default. It’s possible to bind to a specific node_port if type is set as such.
  • volume: this is the volume where repositories are kept, which is also user git’s home directory. It’s supposed to be a filesystem. Available keys are access_mode (defaulting to ReadWriteMany), size (defaulting to 10 Gi) and the storage_class (defaulting to the empty string). It’s also possible to enable a section about nfs, which currently does nothing special apart generate the specification for a PersistentVolume automatically in the printed text at the end of a deployment via helm.
  • config: this is where Gitolite-specific or less specific stuff ends up. It has several sub-sections:
    • admin_public_key: the key to associate to the admin user, which is the first user created and also enabled to do remote management through the gitolite-admin repository;
    • host_keys: there are three sub-keys pointing to the respective keys, namely rsa, ecdsa, and ed25519;
    • sshd_config: the file sshd_config itself;
    • gitolite_rc: what will be used as file ~/.gitolite.rc.

Configurations end up in ConfigMaps (admin_public_key and gitolite_rc) and a Secret (sshd_config and host_keys) for later tweaking, although it’s best to only use helm with an updated local values.yaml file at this point.

At the end of the deployment, a file is printed including the YAML for a PersistentVolume, which can be used to create the git home volume separately. Also the management of handing over the same volume to a different installation is something that has to be addressed manually at the moment (upgrades in the chart should work fine though).

Enough for today… say safe!


Comments? Octodon, Twitter, GitHub, Reddit, or drop me a line!