TL;DR: Zero to Drupal 10 on Aegir 3 in About Fifteen Minutes For those in a hurry:
Start with a fresh Ubuntu 22 VM. Clone this git repository and follow the instructions in the README file. Use the Aegir 3 site migration process to move your Drupal sites to your new setup. Happy migrating!
For more detailed information, keep reading.
Background: Tectonic Drift At Consensus Enterprises, we’re dedicated to helping organizations transition smoothly from Drupal 7 to Drupal 10 on Aegir 3.
Introduction In a recent project for a federal government client, we needed to upgrade (rebuild, improve, and migrate content) an internal application from Drupal 7 to Drupal 10. One of the challenges we faced was to build reports that display a large set of data fields pulled from a complex data model.
We found that using Views alone was insufficient to meet the performance and maintenance requirements for these reports. This led us to develop Computed Token Field as a way to streamline Views configuration required to produce the necessary reports.
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.
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.
Introduction to the Introduction Over the last few years we’ve built lots of Drupal 8 sites, and some Drupal 9 ones too, both for our clients and for ourselves. As such, we’ve taken a keen interest in (read: faced many challenges with) the Configuration Management subsystem. This was a major new component in Drupal 8, and so, while it’s functional, it isn’t yet mature. Of course, the vibrant Drupal developer community jumped in to smooth the rough edges and fill the gaps, in what has since become known as CMI 2.
Best practices for building Web sites in the Drupal framework (for major versions 8 and above) dictate that codebases should be built with the Composer package manager for PHP. That is, the code repository for any sites relying on it should not contain any upstream code; it should only contain a makefile with instructions for assembing it.
However, there are some prominent Drupal hosting companies that don’t support Composer natively. That is, after receiving updates to Composer-controlled Git repositories, they don’t automatically rebuild the codebase, which should result in changes to the deployed code.
