Managing multiple sites with a combination of shared and individual code, features, and databases are challenging. Drupal includes a feature called “Multi Site” as a way to share core code, theme, and modules while keeping individual databases and features.

But with a large number of sites, Drupal Multi Site can create more problems than it solves. Using Lagoon to manage multiple Drupal sites solves these problems in a more efficient way. In this blog, we’ll look at Drupal Multi Sites and the challenges it can create, as well as explain the advantages of using Lagoon through Poly Sites and Custom Base Images.

Drupal Multi Site

As the name suggests, Drupal Multi Site is a feature with the same or shared code base, but with different databases, different file storage, and domains.

From the visitor and editor perspective, each site looks different. If they have a login, they must log in to each site separately. There are ways to synchronize content and users, but it is not part of the default feature set.

A Drupal Multi Site installation contains shared Drupal Core code, Modules, and Themes. Each of these is available for every individual site having their own databases and modules while sharing the core code, modules, and themes.

Example of a directory structure with Drupal Multi Site

Problems with Drupal Multi Site

Updates

Updates can be problematic with Drupal Multi Site because they have a shared core, modules, and themes. Each update of shared code, especially core, impacts every site at the same time. Database updates, on the other hand, need to happen for each site separately. With a big installation, it’s almost impossible to run the database upgrades for all sites at the same time, therefore sites which are not upgraded yet are in an unstable condition.

If an upgrade of a single site fails, you can choose to roll back the code and databases of all sites. Or you can try to fix the database update for the failed sites. Trying to fix the sites can be time-consuming and there is no guarantee for a fix.

Drupal Multi Site doesn’t provide individual updates or make rollbacks easily possible.

Development

A Drupal Multi Site installation doesn’t provide many options for development instances. As Drupal moves into more modern development workflows, developers may want a production environment as well as a development and staging environment. To accomplish this in Drupal Multi Site you can treat each environment as a separate site, as shown below:

Example for file structure with production and development sites within same Multi Site Installation.

Creating multiple environments for the same site certainly has advantages, but there is no way to test core updates on the development sites because all updates will affect every site in the installation.

Another option is to create multiple Multi Site installations:

An example structure for two Multi Site Installations, the first one for all production sites, the second one for all development sites

This set up means development environments can be easily updated independently from the production environment. But managing unneeded and unused clones can get very complicated fast.

Drupal Multi Sites simply doesn’t fit well into modern development workflows.

Multiple Git Repositories

Example file structure with individual Git repositories for each site.

Managing multiple sites should be easier with multiple Git repositories, especially in cases where an organization has different departments and entities that all have websites with different modules, themes, and content. The most intuitive way to set this up is to have all the core code and shared modules and themes in one place, and the themes, modules, and databases for each site in their own Git repository. Unfortunately, this setup means that developers will not be easily able to run these sites locally as their Git repositories are lacking the shared code, potentially leading to mismatched versions across the board.

Drupal Multi Site also means you cannot give access to individual sites via Drush. Access to one site could mean access to multiple sites, which is not secure in large or diversified organizations.

Each of these problems only multiplies depending on the number of sites involved. Using Lagoon solves these issues with solutions that enable developers to use modern tools and workflow.

What Can Lagoon do for your Multi Sites?

Lagoon offers two solutions for clients needing to run multiple sites with modern workflows.

Poly Site

Poly Sites are suggested if the exact same Git repository is used for all sites. Poly Sites can be used to deploy the same Git repositories for any number of sites, with different databases and files for each site. This solution is specifically for clients that have the same repository for multiple sites, with only content and configuration settings varying across the group.

Custom Base Images

Custom Base Images allows an individual Git repository for each site along with centralized and shared core, modules, and themes in the Custom Base Image. Each site can add their own modules and themes.

Containerized Workflow Basics

This part explains the basics of container workflows without “Custom Base Images”.

Container Image Workflow for regular sites

The first part is the Lagoon Drupal images which are maintained by the Lagoon/amazee.io team and use the official Docker images in order to contain the latest security features and updates. These Images contain everything needed to run Drupal in containers, Developers just need to add the Drupal code for their site.

This Drupal code itself can live in any Git repository. It brings all of the core, modules, themes, and custom code. Lagoon will combine the Drupal Code plus the Lagoon Images and build the container image which is then run and orchestrated by Kubernetes.

As we understand the regular Container Image Workflow, it’s time to look at the Custom Base Image Workflow:

Custom Base Images Workflow

Container Image Workflow with Custom Base Image

From this basic workflow, it’s easy to add a Custom Base Image into the mix. The Base Image has its own Git Repository and brings core, modules, and themes that you want to share across multiple sites. An automated process will build the Base Image from the Lagoon Drupal Images and the Base Image Git Repository. The resulting Images are then pushed to any Docker Container Registry. From here the process is exactly the same as for the regular workflow: Developers are using the published Image to build their sites in their own Git repository.

Advantages of Lagoon Base Images

Every site running on Lagoon has its own Git Repository, own containers and own environments. Multiple sites share code during the build, but not while they are running, which means if one site fails, the others keep going. Sites can individually be upgraded and tested according to the needs of the team.

By running individual environments, organizations can allow developers Drush access to individual sites without the risk of them accessing another site.
All core code, modules, and themes are fully testable without sacrificing the advantages of a centralized system. Developers can have multiple environments per site with local congruent development.
Base images can be automatically built and tested via CI and combined with dependency management tools like Dependabot or others.
Automated testing can check for modifications by Developers from the base image dependencies by comparing it to the base image version. This prevents Developers from overwriting Drupal Core or installing Modules they shouldn’t.
For customers managing large amounts of sites, an Ansible integration with the Lagoon API can deploy too many sites at once.

We believe Lagoon offers a better alternative to Drupal Multi Sites for businesses managing a large number of sites. We offer consulting and management services for clients switching to Lagoon from Multi Sites.

Want to learn more? Watch our webinar or get in touch with us today!