You are reading our blog series: Aegir5 Roadmapping
- Aegir 5 is Happening!
- Kubernetes backend for Aegir5
- Front-end low-level architecture
- Front-end UI architecture
- Queue architecture
- Kubernetes back-end integration (You are here)
- Feature parity between Aegir 3 and Aegir5
- Roadmap update
In previous posts we covered how the Frontend and queue mechanisms can talk with the Backend. We also covered the stand-alone work we’ve been doing within Drumkit to support Drupal on Kubernetes. In this post, we’ll discuss how we plan to integrate this new Backend into the existing Aegir 5 architecture.
To integrate the Kubernetes Backend into Aegir 5, we will need to build new top-level entities (see this earlier post about Clusters, Projects, Releases, and Environments) for the Frontend. These entities are composed almost entirely of Operations.
The Tasks on the Frontend will primarily gather the variables needed
to generate the templates in Drumkit on the Backend. These are passed through
the Queue system to the Backend. The Backend in turn instantiates the
configuration files, and runs the appropriate kubectl commands to deploy the
various components into the Kubernetes cluster.
Drumkit currently has make targets that initialize an Environment and deploy a
Project Release to it, among other things. We will need to add a Drumkit
Backend to extend dispatcherd to issue these make targets, passing in the
Frontend variables. Having dispatched the job, the Backend will then gather
output and send it back to the Frontend.
In previous editions of Aegir, we sometimes saw the split-brain problem arise as a result of the Frontend and Backend sharing responsibility for the state of the system.
In Aegir5, the Frontend is intended to be canonical with regards to the data about the state of a running application. Aegir manages the Environment, consisting of the application state (files + database).
The Project incorporates the infrastructure Kubernetes resources required to host the application. Drumkit provides commands to initialize a project with such resource definitions.
We are working on getting more specific about the tasks required to implement this in a new roadmap ticket. Our next post in the series will compare Aegir3 and Aegir5 from a features standpoint, after which we’ll discuss the plan to get from here to there, once we’ve established a clear roadmap.
The article Aegir5: Kubernetes Backend integration first appeared on the Consensus Enterprises blog.
We've disabled blog comments to prevent spam, but if you have questions or comments about this post, get in touch!