ETOOBUSY 🚀 minimal blogging for the impatient
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.
All said, it’s immediately useable with the following configuration
options in the
image: the usual stuff here, like a
namethat points to the image (most probably in a registry) and a
pullPolicythat 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
typeis 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
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
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
adminuser, which is the first user created and also enabled to do remote management through the
host_keys: there are three sub-keys pointing to the respective keys, namely
sshd_config: the file
gitolite_rc: what will be used as file
Configurations end up in ConfigMaps (
gitolite_rc) and a Secret (
later tweaking, although it’s best to only use
helm with an updated
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!