{"id":5919,"date":"2018-03-30T20:08:36","date_gmt":"2018-03-31T01:08:36","guid":{"rendered":"http:\/\/www.carnaghan.com\/?p=5919"},"modified":"2019-01-04T09:48:38","modified_gmt":"2019-01-04T14:48:38","slug":"infrastructure-options-for-hosting-multiple-drupal-sites","status":"publish","type":"post","link":"https:\/\/www.carnaghan.com\/infrastructure-options-for-hosting-multiple-drupal-sites\/","title":{"rendered":"Infrastructure Options for Hosting Multiple Drupal Sites"},"content":{"rendered":"

A project I was recently working on had in place a cloud-based infrastructure that\u00a0was designed to support a single installation of the Drupal CMS running in Amazon Web Services (AWS). This infrastructure included an auto-scaling setup with load balancers hosting a ‘cache’ layer and an ‘application’ layer that hosted the Drupal CMS. On the backend tier, an AWS Relational Database Service (RDS) provided the MySQL database needed for the application. There were other components of the infrastructure such as our shared services for continuous integration, monitoring and development tools.<\/p>\n

At a high level,\u00a0the following tiers provided a basic organization of the infrastructure broken down into its respective layers.<\/p>\n

\"\"
\n<\/a>Driving the continuous integration and continuous delivery pipeline (CI\/CD) was a library of bash scripts, which were created initially to support Drupal 7 AWS projects. The limitation of these scripts was that they were built to only support one instance of Drupal. Their main function was to deploy Drupal in the Application tier serving the cached tier backed by one RDS database instance. In order to scale the scripts, much work would have been involved in re-architecting the CI\/CD processes that would ultimately impact the infrastructure. As such, multi-site options were researched.\u00a0This document outlines four approaches we considered in order to scale to multiple sites, leveraging the existing infrastructure, that would not impact the current website or architecture. Each of the approaches includes a brief description, links to resources where applicable, and a scorecard and set of assumptions. While every Drupal project is different, it is my hope that some may benefit from this overview.<\/p>\n

Method 1: Multi-site Drupal<\/h2>\n

Multi-site Drupal (https:\/\/www.drupal.org\/docs\/7\/multisite-drupal\/multi-site-sharing-the-same-code-base<\/a>) has been around for a while. It allows you to share a single Drupal installation (including core code, contributed modules, and themes) among several sites. Each site will however need its own database or new prefixed tables within the existing Drupal database (Not recommended due to size).<\/p>\n

\"\"
\n<\/a>Figure 2: Sourced from
OS Training<\/a><\/p>\n

Multisite carries a certain level of risk depending on the complexity and traffic to the new sites that would be added to the infrastructure. Since only one codebase is used, one single point of failure exists and is now shared with the main Drupal website and any that are shared. Ideally, in this and any of the scenarios given, a proper risk assessment would be created supported by analytics data and any other information available on the proposed migration sites prior to implementation.<\/p>\n

Another option for multi-site implementation comes from the Aegir multisite system (http:\/\/www.aegirproject.org\/<\/a>) that helps reduce risk for a larger number of sites by providing a way to split Drupal into separate codebases for multi-site implementation.<\/p>\n

\"\"
\n<\/a>Figure 3: Sourced from
OS Training<\/a><\/p>\n

This is a much more complex system to setup, however it may provide the scalability needed to support a high number of sites. Keep in mind every new site still needs its own set of RDS databases or prefixed tables which could add to long-term maintainability issues.<\/p>\n

Regardless of multi-site implementation, both options here allow for shared module use as well as siloed site-specific module and theme code. This can be both a benefit and drawback depending on how complex each site will be adding to Drupal core overhead.<\/p>\n

Scorecard<\/strong><\/p>\n