Better strategy for managing Drupal settings.php / basic config

[geerlingguy]

This is a larger issue with Drupal's basic configuration in general... but currently this operator uses the same technique as the PoC, which is a settings.php ConfigMap which is mounted into /var/www/html/sites/default/settings.php as a volume.

For my Drupal for Kubernetes project I opted to go a little bit of a different route, and make it up to the ENTRYPOINT of the container, or the settings.php files associated with the individual site codebase to manage settings appropriately, based on environment variables like DRUPAL_DATABASE_HOST and DRUPAL_HASH_SALT... see: https://github.com/geerlingguy/drupal-for-kubernetes/blob/master/pidramble.settings.php

I think the community still hasn't really chosen 'the ideal solution'.

Ten7's Flight Deck platform is also using Secrets + ConfigMaps, but using them to add environment variables and relying on the site's settings.php to use the vars (see https://github.com/ten7/flight-deck/blob/master/docs/getting-started.md#database-connection).

[stale[bot]]

This issue has been marked 'stale' due to lack of recent activity. If there is no further activity, the issue will be closed in another 30 days. Thank you for your contribution!

Please read this blog post to see the reasons why I mark issues as stale.

[stale[bot]]

This issue is no longer marked for closure.

[dmlb2000]

I'm wondering if you could punt on this and support an optional settings.local.php ConfigMap if the user specifies it. Then simply include the line in settings.php to include the extra file if they pass in a settings.local.php file. In that file they could override anything you have set in settings.php if they choose to.

[geerlingguy]

@dmlb2000 - That does make sense. Drupal's default settings.php doesn't have that commented out, so they would have to make sure their Drupal image/codebase has a modified settings.php but that shouldn't be too bad.