初始化后，切换到需要variables的用户并导出variables，然后指定在configuration文件中设置它们，或者在root用户的/ etc / environment（Debian）中设置它们来考虑持久性
我通过“echo >>”或“sed”直接或通过主configuration查找设置的目录来执行很多操作。
为了我：
export MYVAR=foobar echo "export MYVAR=foobar" >> /home/bradchesney79/.profile 最上面的一个可以在执行时使环境variables可用，但是当你注销时它将不见了。 把这个命令放在你的.profile文件中，你将在login时为你创build它。
sed -is/export MYVAR=.*/export MYVAR=barfoo/g /home/bradchesney79/.profile
为你：
sudo -u brianchesney80 export HISVAR=something sudo -u brianchesney80 echo "HISVAR=something" >> /home/brianchesney80/.profile
为了所有人：
((Not fully certain how to export globally just yet)) sudo echo "OURVAR=fffoooooobbbaaarrr" >> /etc/environment
我不喜欢重新启动。 但是，我没有看到任何方法来启用这里为每个人设置的环境variables。
那么，想要查看不同用户的环境variables？
sudo -u www-data printenv PATH sudo -u www-data env
env提供的简洁列表不够吗？ 尝试：
set > /tmp/setOutput.tmp
环境variables（Ubuntu）
环境和Shellvariables
值得注意的是环境variables对于守护进程的服务来说并不是自然可用的，因为它们不是传统上作为inheritance父环境variables的subprocess启动的。 请记住，这是一个非常好的理由，因为这是一个安全的障碍（环境variables将不分青红皂白地共享不一定是件好事）。 我的目标是有select性地使某些可testing的环境variables值可用，以便我的系统具有不同的行为，或者在variables中设置适当的凭据并将其用于应用程序 – 所有这些都通过供应脚本进行实例化，而其中一些在重新引导之间持续存在。
阿帕奇
例：
export PATH="/var/www:/var/www/html"
整洁的片段，你可以用它来检查你的envvars文件的有效性。
sh -n /etc/apache2/envvars && echo Syntax OK || echo FAIL
在/ etc / apache2（Debian）中有一些设置，我想我可以在虚拟主机块中使用…
例：
SetEnv SPECIAL_PATH /foo/bin
在服务器虚拟主机configuration块中的上述内容将通过$ _SERVER或类似的惯例使得定制的环境variables可用，正如TMR在评论中提到的那样。
Apache httpd mod_env
在httpd.conf文件和类似的.htaccess中的其他地方，你可以通过重写规则来设置环境variables。
RewriteRule someurl - [E=dbpass:swordfish]
Apache重写滥用…如果你需要，你必须猜测。 一般来说，我不喜欢.htaccess文件，但不是重写的粉丝。
NGINX
看来你可能能够利用lua NGINX模块将环境variables插入服务器。 这个其他模块也需要。
这就是说，这是关注于PHP–如果你使用PHP的nginx – 也许看看下面的PHP部分可能是一个更好的解决scheme。
env PATH; http { ... server { location /path { set_by_lua $path 'return os.getenv("PATH")'; ... } } }
NGINX邮件列表线程引发了这种可能性
关于全面使用lua的博客文章
PHP
get-cfg-var（）将允许您检索由PHP项目开发人员设置的值以及您设置的任意值。 谨慎的做法是小心地将这些variables命名为全局范围，并且一定要阅读用户贡献的注释，以便了解一些automagical mangling。
例：
php.ini中
environment_type=dev environment_host=AWS
RANDO脚本，whatever.php
get_cfg_var('environment_type') // returns 'dev' get_cfg_var('environment_host') // returns 'AWS'
在一个php-fpm池configuration文件中，下面将通过$ _SERVER或类似的约定来提供一个自定义的环境variables，正如TMR在评论中提到的那样。
例：
我-pool.conf
env[FOO] = bar
RANDO脚本，whatever.php
echo $_SERVER['FOO']; // returns 'bar'
什么：我正在寻找的最终结果是，我可以脚本站起来一个服务器。 由于弱点，我有一个可怕的包装和运行更多的bash脚本比我想承认。 无论如何，我想在操作系统用户级设置一些variables，并让它们向下传播，以帮助我或多或less地“匿名化”我的Web应用程序代码库。
为什么：好处是许多特殊的身份validation（如，它们适合于环境variables），密码和其他“秘密”密钥不在代码库中 – 您已将所有这些“秘密”到configuration脚本，显然还是运行在使用低级别访问控制的服务器上。 在开发人员接触到的Web应用程序运行的代码中，没有什么需要改变的。 任何configuration或偏差都可以检查和处理。 写一次，放心地部署，如果不一样，一切都非常相似。 configuration脚本自动将正确的DSN用户，主机和密码连接到数据库的环境variables中; 那些引用环境variables的PHPvariables只是从get go中获取正确的值。
如何：这是我的问题。 如果你已经这样做，你会采用哪些步骤和技术？
编辑：
博士 – 删除了一个有争议的供应观念蒸馏到一个简洁的问题主题
我已经删除提及检测有关主机的事情，并根据调查结果调配服务器。 强烈build议这种configuration服务器的方式可能是一个糟糕的策略，configuration工具被devise为声明设置而不是目标主机在实例化时发现关于它自己的事情并且适当地作出反应。 – 最重要的是，它是次要的。 我想了解更多关于存储可能在环境variables中变化的细节的信息。
特别提到的AnrDaemon正在打破最不吃惊的原则。
从提问的方式来看，唯一可能的答案是“不要那样做”。
网站不应该“试图弄清楚”什么，它应该工作。
根据它configuration环境和configuration网站是一个部署脚本的工作。
正如@TML指出的那样，有很多编排工具可以做到这一点。 Saltstack，puppet，…命名您的select。
为了向您的应用程序提供环境信息，那么像dotenv这样的东西呢？
phpdotenv从configuration文件中读取数据以填充PHP的$_ENV和$_SERVERvariables，这样您就可以在版本控制之外获取单独的API密钥或其他configuration信息，而无需处理configurationWeb服务器本身。
对于我来说，在一天结束的时候，我使用AWS平台在主机上托pipe一个站点。
最有可能的是，当我部署新的代码或主机configuration时，我将创build一个新的服务器映像，让我的网站脱机一两分钟，指定我的autoscaling组使用新的映像，杀死所有的旧实例，当第一个新的实例重新启动时，将我的网站重新上线。 当然，我会事先testing一切，并有高度的信心，一切都将按计划进行。 如果不是，我会杀死新的实例，并用旧的图像中的实例replace它们…
所以，通过环境variables让我的代码使用正确的configuration值（支持db访问证书和支持服务的IP地址作为例子）的计划将不会像我预想的那样。
我的供应脚本将设置其他可以使用它们的环境variables。 对于这个单站点服务器上的PHP，我将会追加我自己的任意键=值variables对，如下所示。
get-cfg-var（）将允许您检索由PHP项目开发人员设置的值以及您设置的任意值。 谨慎的做法是小心地将这些variables命名为全局范围，并且一定要阅读用户贡献的注释，以便了解一些automagical mangling。
例：
php.ini中
environment_type=dev environment_host=AWS
RANDO脚本，whatever.php
get_cfg_var('environment_type') // returns 'dev' get_cfg_var('environment_host') // returns 'AWS'
感谢所有花时间让我变得更聪明的人，并且把我在这里学到的东西剪切/粘贴，以节省下一个悲伤和时间。