Service and Cluster Architecture Notes

Notes from conversations over the past few weeks in IRC, email and on the skype. These notes are intended to capture the mind-meld consensus on how to architect the guts of Aegir so that we can embrace multiple servers and multiple services for 0.4!

This is an outline for now; I will flesh out and add diagrams in a bit. Feel free to embrace and extend!

• Drush @aliases will allow us to identify servers along with bundles of services. E.g. @webserver might be an IP/domain plus --http-service=apache2 --db-service=null --file-service=local
• Each service class is pluggable with any number of implementations (e.g. apache2, niginex for webserver, mysql or postgres for db)
• For multi-server deployments, a cluster object can be used to group a collection of @aliases
• Hostmaster/provisioning tasks will determine which @aliases to run which specific actions against based on their associated --services
• Initial services to start with are web, db and filesystem
• The initial goal is to use this new architecture with stub implementations that does what aegir does currently on a "one big box" architecture
• Beyond that, individual services and plugins can progress at their own pace

We will need to break down the current structure of the provisioning tasks into class/plugin implementations, as well as decompose any monolithic processes that are part of existing tasks into individual actions.

Note: I'm sliding into some jargon here with "task" vs "action". I think it will be useful to distinguish between the lingo of "tasks" (things like "install", which go in the queue) and the individual actions they're made up of, that might involve different services and aliases.

Here's Vertice's awesome entity map:

Filesystem Requirements

http://drupal.org/node/736706

While the Web and DB services are pretty well-defined by existing functionality, breaking out the Filesystem component requires a little bit of thought. Here are some initial thoughts:

• The service will need to have the entire "platform" in its scope
• It will need to handle putting a codebase in place, though for maximum simplicity, the above can be a NULL operation (which is currently how it works). Aegir doesn't create the codebase, but it does need to be ready to manage its placement on the filesystem.
• It will also need to handle creating the sites directory/settings.php
• The apache virtualhost file or any other config files required by other services
• It should have the ability to specify a location for the Drupal Files directory per-site, and set this via variable_set
• A basic implementation that's cluster-worthy would use rsync or something similar to push out filesystem changes to web heads
• We begin with a hub/spoke model in which the Aegir server is a master; this satisfies virtually all present use cases; mesh awesomeness can come later.