5

I want to run Drupal from a cloud and I am trying to figure out the design of the file system for multi-site setup.

In cloud there are multiple webservers hidden under the load balancer serving content from a single database(which is a service that handles replication on its own so no issue there) and using central storage for user/drupal data.

So far I have solved the user-added data(mostly images uploaded into a content or attached via fields) but I'm stuck on how to handle files like compiled Twig templates, config directory, services file and settings file and similar.

Once a new web server instance is created it will fetch the code from git repository. The user data is handled via stream wrapper(and cdn) so no action is needed there. But how should I handle the system(yml, php..) files? The settings.php and services.yml are global so they won't change(still - how to handle this in multisite setup?) and the rest is dynamic(ie. once the cache is flushed the twig templates are recompiled and this needs to be synced for all instances).

The more static files like the settings.php and services.yml files could be potentially stored in some "remote" storage and fetched from there(ie. a directory tree matching the installed sites with these files already present - not a git repo though, I think that would not be a good idea) or they could be dynamically generated based on data stored in special database.

But what about the rest(twig, config...). Would something like a fast cache be a good design? Redis db that would hold the current files and each instance would either fetch them manually or serve them directly? Once an instance flushes cache this would be immediately "synced" to all instances in second scenario. For first scenario there would have to be some timestamp with latest change that each instance would have to check on each page load and re-fetch the files.

Drupal has this quite specific file system tree so that's why I'm asking this in here. I'm sure many people run Drupal in the cloud and I'm curious how they solved this "issue".

4

This is why platform as a service solutions like platform.sh, getpantheon and others are so popular. They provide solutions to problems like this.

If you don't want to use them, then you can still learn from them. In this case, the answer is environment variables. You commit a settings.php file that reads the configuration from environment variables, e.g. which database server/solr/redis/... to connect to, configuration overrides and so on.

platform.sh also automatically generates a settings.local.php that some configuration built in, but they move more and more towards just documenting how to do it yourself as that's more flexible. See their example setups and specifically, settings.php of the 8.x-composer approach.

How to actually get those environment in place yourself is a non-drupal related question that you'll have better chances for good answers elsewhere. It also depends a lot on how you actually instrument those cloud servers.

So far, I've haven't had the need for customized services.yml files, all I do sometimes (beside having a services.local.yml, just like settings.local.php), is to dynamically load additional files, e.g. with the redis configuration. If you need that, you can either generate those files or you can implement a site specific service provider that generates the service/parameter definitions dynamically.

For twig, while they are generated PHP files, unless you do something really weird, they are based only on the static .html.twig files that you are deploying. So, you do not need to share them between your servers, you just need a deployment step that deletes the files on all servers when you deploy new code. Or, you could write a script that pre-generates them, then you less of a performance hit when re-deploying. Haven't seen a script yet for Drupal that does that, there might already be a question about that here.

The container is in cache, by default in the database, with a bit of configuration you can also have it in Redis or Memcache, see https://github.com/md-systems/redis/issues/12.

I'm not aware of any other files that need to be maintained like this. (other than public or other stream wrappers, which you apparently have already solved).

  • Any tip regarding the timestamp in cache_default table for compiled twig templates? I have observed the names of compiled files/directories stay the same so the only issue is the timestamp(ie. timestamps in the single DB with multiple web servers connected to it will constantly be mismatched). – user21641 Mar 26 '16 at 19:18
  • Those timestamps are only used for the auto-refresh feature, which you definitely do not want to have enabled on your production environment. So, irrelevant. – Berdir Mar 27 '16 at 1:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy