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!