Who We Are Consensus Enterprises is not your average technology company. We are a collective of workers who are driven by optimism, equity, and a shared passion for open-source technologies. Our mission is to build a company that doesn’t just benefit a select few, but instead shares the rewards of our collective hard work.
Having contributed to the Drupal community and others for over 20 years, open-source technology is deeply ingrained in our DNA.
In previous posts, we’ve covered our Kubernetes framework for an alternative back-end to Aegir5, as well as the front-end Tasks and Operations and Clusters, Projects, Releases, and Environments. We also discussed the Queue architecture that ties the front- and back-ends together. This time, let’s consider the planned feature parity between Aegir 3 and Aegir 5.
Clusters, Projects, Releases, and Environments In Aegir3, Servers only have a “verify” task. This ensures that the front end can connect to the server over SSH.
See our recent Aegir5 Roadmapping series for more background! Recently, Dries announced an exciting event at the upcoming DrupalCon Pittsburgh: Shark Tank meets Drupal: pitch your best innovation ideas/):
Announcing “Pitch-burgh”, an innovation contest at DrupalCon Pittsburgh, where members of the Drupal community can pitch their ideas to receive funding. […] The entrepreneurs give short 2-3 minute presentations in the hopes of securing funding for their idea.
Since we’re actively pursuing partners and funding for Aegir5 development, this seemed like it could be a good opportunity.
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.
Previously in this series, we looked at the Aegir5 front-end interface architecture, as well as the lower level entities, Tasks and Operations that provide building blocks.
As mentioned in the first part of the series, our most recent work on Aegir5 itself has been reworking the queue system. In this post, we explore this topic in more detail.
The Aegir5 queue is implemented using Celery, which is a full-featured Python-based task queue, built atop RabbitMQ.
In our previous post, we looked at the Tasks and Operations which form the building blocks for the user interface in Aegir5. Here we’ll look at the additional entities required to support the Kubernetes-based backend framework.
It is worth noting that Aegir has always had a tension between Developer and SysAdmin use-cases. We’ll cover this in more depth in a later post. For the moment, we’re focused on the Developer use-case.
In our previous post, we talked about our recent client work building a Kubernetes-based system for hosting web applications. We’ve defined a general framework to support our development and production hosting workflows, and recognized this as a solid basis for an alternate backend to plug in to the existing Aegir5 front-end. Today we’ll take a look at the Drupal architecture underlying that front-end.
In Aegir5, the building blocks consist of Task and Operation entities.
Aegir5 and Kubernetes Lately we’ve been working with clients ranging from large Canadian government departments to small commercial SaaS companies, who have asked us to deploy CMS apps to Kubernetes (K8S) clusters running on Openstack. In spite of our continued feeling that most of the time Kubernetes Won’t Save You, we’ve found it to be surprisingly useful in certain contexts. In fact, we’ve started to think that K8S will prove an extremely valuable backend to plug in to our existing Aegir5 front-end and queue system.
Aegir5 development is happening! We (Consensus) have been making steady progress on it over the last few years and are looking to kick off a new burst of focused development. Here’s a summary of progress that has been made so far and how you can contribute.
First off, as you’re probably aware, Aegir5 is a complete re-write of Aegir. We are intending to build on all the great aspects of Aegir, while freeing ourselves from a codebase that is rooted in PHP 4.
Aegir is the one-and-only FLOSS hosting system for Drupal sites that’s been around for over 10 years, a rock in the community. While Drupal hosting companies have come and gone, Aegir’s always been there for folks who want to host Drupal sites themselves. According to recent data at the time of this writing, there are 567 instances (that we know about).
It’s used by organizations worldwide such as the US National Democratic Institute, NASA, and the European Commission.
