This is a report on the activities done for the OpenAppStack project in August. Because OpenAppStack aims to provide simple provisioning of several applications, this month’s goal was to find the platform best suited to base the application deployment on.
This month’s report contains the following items:
- Setting up a new website
- Researching the differences between Docker Swarm and Kubernetes
- A list of requirements from the base platform
- Choosing the platform
- Next month
Website
Apart from our research, a small website was set up for anyone who wants to track the progress of the project. It contains some general information on the project and our monthly reports as well as other interesting findings we do along the road while developing OpenAppStack. The website can be found at www.openappstack.net. In the future it will also contain links to the software and documentation.
Research
This month we continued the research of last month into Docker Swarm and Kubernetes. We made a list of requirements for OpenAppStack. To determine which platform suits our needs best, we have tried to configure and deploy an application to each of them.
Testing
We have tested each platform by setting up Etherpad with a custom configuration file and storage on MariaDB.
We have first set this up using a docker-compose file on a Docker Swarm. Secondly we have written a kubernetes configuration file to set up the application similarly. Lastly we have setup the same configuration using helm charts.
Both platforms were tested with a local development setup (docker-machine on VirtualBox and minikube on VirtualBox) as well as a remote setup (a single-node Docker Swarm and a single-node Kubernetes setup in Greenhost VPSs).
Requirements
A full report on our Docker Swarm vs. Kubernetes research can be found in this post.
First of all, there are some basic requirements that both Kubernetes and Docker Swarm meet but are important to us any way:
- Open source
- Well known and has a big community of users/developers
- Ability to securely setup passwords
- Fault tolerance
Then there are some differences between the platforms:
-
Simple updating of application containers
Both platform can update application containers, possibly even withouth downtime. It seems to that updating applications with complex configuration files might be a bit simpler if you can use
helm -
Generating custom configuration files
We want to be able to set up an application already customized for the OAS user. Helm is an application that simplifies this process for Kubernetes. We could not find a suitable alternative for Helm that works with Docker Swarm, which would mean that configuring applications requires more “manual” labor.
-
Performance impact
Preliminary tests show that an idle single-node Docker Swarm setup uses about 100 MB of RAM, whereas Kubernetes uses 700 MB for a similar setup. This is a significant difference especially for OAS users that only require small applications with a small amount of users.
However, we expect that the applications that will run on OAS all together will require a machine with at least 8 GB of RAM, for which this overhead can be acceptable.
-
Developer complexity
It seems like Docker Swarm has a bit more gentle learning curve than Kubernetes. Especially if you want to deploy it in a non-standard way, Kubernetes requires you to learn about a lot of concepts. However, it seems like by using Helm, the amount of work a developer has to do for Kubernetes deployments reduces. Debugging Kubernetes also feels very comfortable.
-
Ease of porting existing applications
Many applications are already containerized for the use with Docker. Many developers also maintain a docker-compose file, which simplifies deploying the application in Docker Swarm.
For Kubernetes, while not many applications have a Kubernetes configuration, the ones that have a helm chart are often highly configurable and might already be useable in OpenAppStack.
A difficult choice
It is always difficult to make a decision between two software packages, especially because there is never a one best choice.
We have developed a preference for Kubernetes. The main cause for this is the ease of use that Helm bring onto the table. We expect that Helm can play an important part in configuring applications and tending the OAS user’s needs. Furthermore, we have trust in the community that backs Kubernetes and expect development of both Helm and Kubernetes will continue for the forseeable future.
Next month
In September we will focus on setting up a proof-of-concept system with several applications hosted in a (single node) Kubernetes cluster. We hope to be able to do user management with an existing application that supports Single Sign-on. Applications we will try to deploy in this proof of concept include:
- A file-sharing/storage platform
- A user management/SSO platform
- A chat platform
- A web proxy
By trying to deploy these applications into a Kubernetes cluster and linking them together with the user management, we hope to find out how feasible our current plan is.