Articles tagged with "Aegir"

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 Omega8cc in various github issues was worth a second look.

It works!

But it's wild. It comprises three main things:

1. A custom/forked version of...

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 need updating amongst themselves, using a simple online shared spreadsheet.

2. Ahead of time, we prepared pull requests for sites that simply use Drush make...

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 other Drupal sites. At ComputerMinds we were looking for something to help manage our Drupal hosting and help update sites and generally make things reliable...

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 code later on. I think it’s much better to deploy tags. It also gives you an easy way to flag when you do want to...

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.

In the end we migrated all the sites with about 30 seconds of downtime each, here's how:

The setup before

For clarity, here's a...

[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 in text files on disk. One of the most mysterious processes in Aegir is sending data from the frontend to the backend to be 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 Aegir website and the back-end Aegir scripts.

We've been using Aegir in production for just under a year, and one thing that has bugged me...

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 manifest of all the code that makes up you project and then you can ask drush make to assemble the code for you. It has...