Problem/Motivation

Environment variables to pass in global settings/configurations are a thing:

  • Most hosters have some sort of support for them and expose the DB settings as such, for example https://github.com/pantheon-systems/drops-8/blob/master/sites/default/settings.pantheon.php#L39
  • It really explitely defined to be environment specific.
  • Many systems have .env files to share those.

Usecases

Pro/Cons

Questions

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Comments

dawehner created an issue. See original summary.

dawehner’s picture

moshe weitzman’s picture

Issue summary: View changes

Added a Pro about security. It links to https://12factor.net/config

Wim Leers’s picture

Thanks for proposing this, @dawehner! Curious what people more knowledgeable than me wrt server security have to say :) I like the apparent simplicity!

dawehner’s picture

Issue summary: View changes
dawehner’s picture

I added some blog post with some criticism.

mpdonadio’s picture

How crazy / insecure would be be to totally pull settings.php from environment, which can also handle overrides already?

shrop’s picture

This topic reminded me of this article I read a while back that speaks to security of env vars. It appears that a few people in the article have varying opinions, but worth knowing some considerations around this topic.
http://searchsecurity.techtarget.com/blog/Security-Bytes/Environment-var...

This one has some good tips on securing env vars:
http://blog.honeybadger.io/securing-environment-variables/

For this article already mentioned in the issue description, I would like to see documentation around better ways to mange keys and other "secrets" than placing them in env vars.
http://movingfast.io/articles/environment-variables-considered-harmful/

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

gdamjan’s picture

I would also like to be able to specify a "DRUPAL_STATE" directory which is the only place that Drupal will be able to write things. Currently Drupal defaults to writing to sites, without an option to override that (except by using symlinks).

An environment variable would be the proper way to setup that config.

ps.
Drupal should also expect the directory to be empty when first started.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

fago’s picture

yeah, I think adding some support for dotenv would be really helpful and make the project appearing to play nice with industry-standards.

We've been using dotenv driven configs for a while, via symfony/dotenv which is added during the compose autoloader. Having environment variable defaults, allowing custom sites.php overrides and finally having per-multi-site dotenv that is applied across PHP and shell scripts ends up a bit tricky.
The setup we ended up with is testable from our drupal-project and works fine, but I want to improve how multiple dotenv files are combined in future:
https://github.com/drunomics/drupal-project/blob/4.x/web/sites/example.c...

I think some standard patterns that map environment variables to Drupal db credentials, Settings and Config would be definitely helpful.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

geerlingguy’s picture

Issue tags: +docker, +kubernetes, +containers

Adding some tags after DrupalCon Seattle BoF on containerized Drupal in production. This would be a major help in not requiring everyone to come up with their own solution to 'how do I get Drupal's settings from the environment' and make Drupal a better player in the 12-factor app ecosystem.

Berdir’s picture

Environment variables are also almost always prefixed and specific to hosters, e.g. plaform.sh puts stuff inside PLATFORM_VARIABLES, as base64 encoded json.

It's trivial to add a bunch of lines to extract it from there, we use d8config and d8settings prefixes to put stuff in settings/config overrides for example. But generic support wouldn't benefit us as we don't control the environment variables directly.

geerlingguy’s picture

@Berdir - It would still be nice to have a common set, for anyone not using a hosting provider that is unable to provide the vars specific to Drupal. And it would help greatly for local environments as well, so all the Docker-based tools could just use the same set of env vars and a var like DRUPAL_ENV=local. (I think there's a separate issue to standardize support for Drupal 'environment' awareness though.)

moshe weitzman’s picture

There is a standard of sorts the drupal-project. Could be improved and more widely used, of course. See https://github.com/drupal-composer/drupal-project/blob/8.x/.env.example

johnwebdev’s picture

We should probably not use .env at least until we move Drupal in to a separate document root. But then again, it is more secure to store environment variables on the server configuration rather than on the application level. For development and testing purposes its fine.

+1 On better support.

+1 On prefixes.

fago’s picture

>But generic support wouldn't benefit us as we don't control the environment variables directly.

Imo, if you are using proper hosting, you should be able to control them - it's the industry standard for handling per-environment things, as they name "environment variables" say :D With Drupal propagating workflows with staging environments etc. this kind of seems a no-brainer to support.

Speaking of platform.sh, that allows setting custom environment variables as well.

We've been also using dotenv a lot in our projects and have a dotenv loader setup in https://github.com/drunomics/drupal-project to help dotenv file management and making sure .env is loaded across shell scripts and php the same.

Anyway, I highly agree that env variales should be standardized. We've started doing this across projects with a few essential ones here
https://github.com/drunomics/phapp-cli#available-variables
and more recently a few more here: https://github.com/drunomics/multisite-request-matcher/
We also have some helper to ease switching environment modes: https://github.com/drunomics/drush-phapp-env-mode

But in the end, what you want to cover with environment variables and what can stay fixed in some settings.php, differs per project. So having some optional variable support would be the way, e.g. something like

DRUPAL_ENV = {{ NAME }} (local,dev,prod, ..)
DRUPAL_ENV_MODE = production|development

which ideally are enforced to be set by code, and then optional ones for loading config like

DRUPAL_SETTINGS_{{ NAME }} = value
DRUPAL_CONFIG_{{ NAME }}___{{ KEY1 }}__{{ KEY2 }} = value
(only separators in env variables allowed is "_").

moshe weitzman’s picture

That pattern makes good sense to me.

fago’s picture

oh, I almost forgot I also created https://www.drupal.org/project/services_env_parameter
Symfony has better, built-in support for environment variables in services.yml files, but would require some work in various places to make it work in Drupal, since Drupal's container builder is different to symfony's.

Fabianx’s picture

+1 to this issue in properly supporting .env.

We can even make this cleaner for true run-time changing of .env:

While currently the parameters in the parameter bag are included in the ContainerBuild definition [due to a Symfony build step], we could have Parameters that are of a NonIncludableVariable type.

Those variables would then be part of $build_definition['variables'] and can be changed at run-time, which means that they are loaded fresh together with the container to whatever value is in the environment.

It was one of the design goals of the Drupal's implementation of the Container [per alexpott' request at DrupalCon LA] to be able to specify parameters at run-time, but it has sadly not been used, yet.

Code - within likely a middleware - could then map from .env to container parameters.

Thanks, services_env_parameter looks interesting.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

rominronin’s picture

I came across this issue while looking for a twig function that could read environment variables for use in conditional statements eg. something like:

{% if getenv('VACANCIES_ACTIVE') is TRUE %}
  <h2>Apply Now!</h2>
    <p>
      We're currently looking for people to join our team, if you're interested
    </p>
    <a href="/jobs">apply now</a>
{% endif %}

and just in general, I like the idea of being able to enable maintenance mode via .env (eg. MAINTENANCE_MODE = TRUE).

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.