How can I handle files in a cloud when when the site is configured as multi-site?

Question

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 the cloud, there are multiple servers hidden under the load balancer which serve content from a single database (a service that handles replication on its own) and using central storage for user or Drupal data.

I solved the problem for user data, mostly images attached to nodes or uploaded via fields, but I'm stuck on how to handle files like compiled Twig templates, configuration files, services file, and similar files.

Once a new server instance is created, it will fetch the code from a Git repository. The user data is handled via a stream wrapper (and CDN); no action is needed.

How should I handle the system files?

The more static files like the settings.php and services.yml files could be potentially stored in some "remote" storage and fetched from there, or they could be dynamically generated based on data stored in a special database.
What about the other files (template and configuration files, for example)?
Would something like a fast cache be a good design?

A Redis database could hold the current files; each instance could either fetch them manually or serve them directly. Once an instance flushes the cache, this would be immediately "synchronized" to all the instances, in second scenario. For first scenario, there could be timestamp value for latest change that each instance would check on each page load to re-fetch the files when necessary.

Answer 1

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).