This article covers the basic design of OpenAppStack.
Application build pipeline¶
The following diagram explains the process to go from an application’s source code to a deployment on OpenAppStack.
These are the steps in more detail:
Build container (this process should be maintained by application developer by providing a Dockerfile with the application)
Get application package (source code, installation package, etc.)
If not part of the package: get default configuration for the application
Build container with application package installed
Install application dependencies
Install application package
Setup default configuration
Setup pluggable configuration override, can be:
Reading environment variables
Extra configuration file mounted into the container elsewhere
Deployment configuration to specify:
The container(s) that should be deployed.
The port(s) that they expose.
Volume mounts for configuration files and secrets.
Persistent storage locations and methods
A lot of other things
Service configuration to specify:
Ports exposed to the user of the application
Ingress configuration to specify:
How to proxy to the application (which hostname or URL)
Some authentication plugins (http auth, for example)
Add file templates for mountable application configuration files
Files that specify integrations with other services
values.yamlfile with the variables for the Helm deployment to the Kubernetes cluster
“Manually” add secrets to the Kubernetes cluster.
helm installto install the customised application.
As can be seen in the images, applications are expected to have two different types of configuration. Containers should provide a default configuration, that at least configures things like the port the application runs on, the locations for log files, etc.
What we call the external configuration is provided by the user. This includes overrides of the default application, as well as variables like the hostname that the application will run on and listen to and the title of the web interface.
OpenAppStack will use Helm charts to provide the external configuration for the “Deploy” step. Helm charts can contain configuration file templates with default values that can be overridden during the installation or upgrade of a helm chart.
For inclusion in OpenAppStack, it is required that the application developers provide Docker containers for their applications. There are several reasons for this:
If application developers do not provide a container, chances are they also do not think about how their application would update itself after a new container is deployed. This can lead to problems with things like database migrations.
Maintaining the containerisation for an application can, in most cases, not be fully automated.
When an application update is available, these updates need to be rolled out to OpenAppStack instances. This will be done according the following steps:
Application container is built with new application source and tagged for testing.
Helm chart for application is updated to provide new container.
Helm chart is deployed to an OpenAppStack test cluster following the steps in the diagram above.
Application is tested with automated tests
If tests succeed, new container is tagged for release.
OpenAppStack automated update job fetches new Helm chart and upgrades current instance using Helm.
Most of these steps can be developed by configuring a CI system and configuring Kubernetes and Helm correctly. The automated update job that will run on OpenAppStack clusters will be developed by us.
Containerised applications are normally “stateless” (meaning no data is saved inside the containers). However, it is possible to mount persistent volumes to specific directories in the container, basically adding a persistent layer on top of the containerised application. To provide this in OAS’s simple setup, we use a local storage provisioner that automatically provides persistent data on the VPS running OAS to an application that requests it.
OpenAppStack has an auto-update mechanism that performs unattended upgrades to applications. Flux 2 is the system running in the cluster that is responsible for these updates.
Flux 2 tracks all the files in the
flux2 directory of the OpenAppStack code
repository. Once changes
are pushd the branch that Flux tracks, the changes are applied to the cluster.
We use Flux 2 in “read only” mode, which means that your OpenAppStack cluster does not push changes to our Git repository. You can read more about Flux 2 and its components in the flux 2 documentation.