Keeping a PaaS product online at all times comes with a high level of responsibility. In early 2024 we set up a proof of concept setup with Cloudflare, which would allow us to make a significant ongoing cost saving whilst also playing with some really cool APIs.
In my previous article I outlined that I really needed to get Drupal 10 sites running in Aegir 3. I had no time to wait around for other solutions, and I was going to try to decouple Aegir from running Drupal sites, so that it wouldn't be tied to Drupal versions. Since writing that article and actually sitting down to do this work, I realised that it's quite an undertaking, and the approach outlined by...
Drupalgeddon2 happened! We got all but two of our projects updated within an hour, with those remaining trickier two fully patched another hour later. The key was planning the right process using the right tools. We actually use these tools for regular deployments every day, but speed was essential for this security update. Here's what we did, since some of you may be interested. 1. Our on-call developers split up the various sites/environments/projects that would...
Ten years ago today Adrian Rossouw committed the first code for the Aegir project. ComputerMinds have been involved in Aegir for many of those years, particularly one of our senior developers: Steven Jones. We asked him some questions about it to mark the occasion. ### When did you get involved in the Aegir project? I went to a session at Drupalcon Washington DC in March 2009 and Adrian was presenting this mad thing: Drupal managing...
Much has been said about last month's highly critical Drupal security issue 'SA-CORE-2014-005', otherwise known as 'Drupalgeddon'. It was covered by mainstream international media, even if the reaction needs addressing. Drupal's security team take a responsible approach to security issues - being open & honest in disclosing them with fixes, in keeping with the community values. Security issues should always be expected in any software, it's how they are dealt with that speaks far more. We patched all the sites that we had access to immediately fix, and informed all our clients of the issue as soon as possible. If you host a Drupal site, and haven't yet, run through the Drupalgeddon workflow right now.
There are a few write-ups about using Aegir to automate your deployment process notably one from Mig5: Zero-touch Drupal deployment with Jenkins, Aegir, Git, Fabric and Drush. I recently wanted to set this up for our own project, but felt like I could make some improvements. I don’t like deploying branches, because it can be really hard to actually find out what was deployed at a later date, and you can’t reliably re-deploy that previous...
We recently needed to migrate all our sites on one physical server to another server, there were more than 200 sites, and they were all hosted with Aegir. The old server was to be decommissioned, so we had to move all of Aegir's data about the site to the new server import into a new Aegir master on the new server. We also needed to do this with as small amount of downtime as possible...
[Aegir][aegir] is a very clever Drupal hosting system built using Drupal and Drush. It is divided into two parts: the frontend and the backend. The frontend is essentially just a standard Drupal site that stores its data in the database and then some drush scripts that manipulate the data. The backend (provision) is just a collection of drush scripts, and it stores its data in [Aegir contexts][aegir_contexts] which are essentially just arrays of data stored...
[Aegir][aegir] is a very clever hosting system for [Drupal][drupal] that sites and provisions them on various servers and does lots of clever things. One of the clever things that it has had for a while is a task queuing system. You can ask Aegir to lots of different things all in one go, and Aegir will queue them up and run them at its own pace. This provides a really good separation from the front-end...
These three tools ([drush make][drush_make], [Aegir][aegir] and [Dropbox][dropbox]) have come together to produce a release system that means I don't have to ssh into a remote server to deploy a new version of site. This means that I can do releases really, really simply, and actually with nothing more than a web browser[^1]. Let me explain: ### Drush make If you aren't using [Drush make][drush_make], then you should look into it. Essentially you specify a...