In January we focused on two main points: CI and storage. In short we have setup a basic CI pipeline that automatically deploys OpenAppStack to a new server and we have made a local storage driver with automatic provisioning. Note, both are still in early alpha development. Lastly, we have closed our investigation into single sign-on (SSO) solutions.
Continuous Integration (CI)
At the moment “OpenAppStack” is a single-node Kubernetes cluster with an ingress controller and an SSO application installed on it. All this gets automatically installed with a “bootstrap script” that requires you to fill in some specific variables in a configuration file up front.
Our new teammate started working on a CI pipeline that sets up an Ubuntu VPS at Greenhost, bootstraps OpenAppStack and checks if the deployment goes without errors. We will keep improving this process, so in the future it also checks if all applications are installed on the VPS correctly. This way, we can test if the installation process succeeds with changes that are made to the cluster configuration, as well as the applications that run on OAS. In the future, we want to include the upgrade process of an existing OAS cluster in the CI as well.
In the process of making the CI script, some improvements have been done to the bootstrapping process and the “control container”, the container is used for managing the kubernetes cluster from kubernetes.
Local storage provisioner
As we explained last month, storage is often a problem for small Kubernetes clusters. Especially if you want to use the storage of the machine you are running on for application storage as well, little good solutions exist. You can tell Kubernetes to use local volumes, but setting up those volumes normally requires some manual labour.
For that reason, we started developing a dynamic provisioner to automate the management of local storage in a Kubernetes cluster. It requires no additional storage layer or external service, only available disk space on the host machine. However, because we use the machine’s local storage, we could run into complications when the cluster scales up to more than 1 machine.
Greenhost storage provisioner (“Ghost”)
Greenhost has done some work to provide an API that can be used by people that want to host a bigger cluster. Using this API, it is possible to create disks and attach them to the VPS that is running a certain application (or “Pod”, more precisely). To consume this API and be able to run bigger clusters, Greenhost is creating a storage driver for Kubernetes.
However not part of this project specifically, this is worth mentioning because that storage driver could be used to make an OpenAppStack cluster more scalable.
Single Sign-on
It is time for us to make some more tough decisions. We have been investigating self hosted single sign-on solutions for a while now, and are in love with none of them. However, KeyCloak came closest to our needs and we decided to integrate and evaluate KeyCloak in practice for now.
To read more about why we made this decision, take a look at our comparison of single sign-on solutions.
Next month
February will see more CI work. Specifically, we will add DNS configuration to the CI script, so we can test if applications can actually be reached the way that the user would reach them. Furthermore, we are planning on improving our existing script to set up KeyCloak and automatic integrations with the other applications.