I recently wrote a post about Backdrop CMS on Pantheon with fast configuration management. In that article I outlined why your complex Backdrop CMS site will run much, much faster by using a read-only configuration setup on Pantheon. A few months have gone by since then, and while the original post holds true I’ve now gotten around to building a few tools that make this setup even more feasible.
I’d suggest you give that previous post a read if you’re interested in hosting a complex Backdrop CMS site on Pantheon. Here’s the short of it: Backdrop CMS applications hosted on Pantheon with a read-only configuration setup perform four or five times faster than a traditional setup.
For Stanford On & Off-Campus Learning Opportunities and Stanford Seed Funding (you guessed it, Backdrop CMS on Pantheon) the performance difference is night and day — as in placing active configuration in the writable filesystem would be a silly option at best. If your Backdrop application has a few hundred or more JSON configuration files, I bet you’d be in a similar situation.
The performant move is to place active configuration in Pantheon’s blazing fast read-only filesystem, but that comes at a cost:
- You cannot make any configuration changes directly on Pantheon Test or Live environments.
- You can only make configuration changes on Dev or Multidev environments if you place the environment in SFTP mode.
- Configuration changes that imply schema changes or other database updates are not correctly applied simply by pushing changes to your configuration files.
The limitations here are considerable. Since configuration imports cannot complete without writing changes to active configuration, non-trivial configuration changes mean exporting your production database, importing your configuration locally or in a dev environment, then re-importing the updated database to production. And that means downtime and neck pain. Until now.
Pantheon Configuration Deploy: drush utilities
A minor alteration to your Backdrop CMS settings.local.php file and the introduction of a handful of drush utilities simplifies the configuration import process considerably. You won’t need to export / import databases — so configuration deployments can be done in a few moments via drush.
The core concept here is pretty simple: When we push changes to configuration files, we want the target environment to:
- Make a writable copy of the configuration directory and temporarily switch active configuration to point there
- Temporarily define the incoming, version controlled configuration files as staged configuration
- Import those staged configuration changes, copying the changes over to the active directory and completing any necessary database updates
- Switch active configuration back to the read-only filesystem in your repository
We can accomplish all of that using a combination of existing drush commands and those introduced with this module:
Copy the existing active configuration stored in the repository from the read-only filesystem into a temporary directory in the writable filesystem. You’ll want to do this before your config changes in the repository are deployed onto your Pantheon environment.
drush pc-wconfig 1
Turn writable configuration on.This will point active configuration to the writable directory recently cloned from the repository, and will point the staging configuration directory to the repo
Import staging configuration. This will write the incoming configuration changes to the temporary active directory and perform any necessary database changes.
drush pc-wconfig 0
Turn writable configuration off. Your active configuration directory will point back to your repository.
Clean up your temporary writable configuration directory.
You can mix and match these drush commands with your standard git workflow to further automate the process — whether that’s pushing code directly to a Pantheon environment or merging in changes from an upstream. The module includes a few examples of using Pantheon’s Quicksilver webhooks, too, which could make the entire process virtually invisible and seamless.
Your specific use case might imply a different setup or implementation. Download the module to start messing with the possibilities.
For our sites, some of the more complex configuration imports run into Pantheon’s timeout constraints (60 second max execution time) when we fire them off via webhooks — so I opted to chain all of my relevant commands into a shell script, instead.
Have you found a better way to manage read-only configuration in Pantheon? Would you be interested in additional functionality related to these tools? Feel free to comment below.