☰

当启动服务器（例如 Debian）时，有哪些方法可以使环境变量持久并可供 PHP 使用？

tag-icon • tag-icon nginx php debian bash environment-variables
当启动服务器（例如 Debian）时，有哪些方法可以使环境变量持久并可供 PHP 使用？

我现在在操作系统级别做的事情：

初始化后，更改为需要变量的用户并导出变量，然后指定在配置文件中设置它们 - 或者在 root 的情况下在 /etc/environment (Debian) 中设置它们，以考虑持久性

我通过“echo >>”或“sed”直接对配置文件或对主配置查找设置的目录进行大量此类操作。

为我：

export MYVAR=foobar
echo "export MYVAR=foobar" >> /home/bradchesney79/.profile

上面的命令在执行时使环境变量可用，但当您注销时它将消失。将命令放入 .profile 中将在您登录时为您创建它。

sed -i s/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

我不喜欢重启。但是，我找不到任何方法可以为每个人启用此处设置的环境变量。

那么，想要查看不同用户的环境变量吗？

sudo -u www-data printenv PATH
sudo -u www-data env

env 提供的简洁列表还不够吗？尝试：

set > /tmp/setOutput.tmp

环境变量（Ubuntu）

环境和 Shell 变量

使环境变量可供 PHP 使用：

值得注意的是，环境变量对于守护进程的服务来说并不是自然可用的，因为它们传统上不是作为继承父进程环境变量的子进程启动的。请记住，这是出于很好的理由而设置的一道安全屏障（环境变量被不加区别地共享并不一定是件好事）。我的目标是有选择地提供某些可测试的环境变量值，以便我的系统以不同的方式运行，或者为变量中的应用程序设置正确的凭据并使其可用——所有这些都是在通过配置脚本实例化时进行的，其中一些在重新启动之间会保留下来。

阿帕奇

例子：

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

上述服务器虚拟主机配置块将通过 $_SERVER 或类似约定使自定义环境变量可用，正如 TMR 在评论中提到的那样。

Apache httpd mod_env

您可以在 httpd.conf 文件和类似文件或 .htaccess 的其他地方通过重写规则设置环境变量。

RewriteRule someurl - [E=dbpass:swordfish]

Apache Rewrite 滥用...如果你必须这么做，我想你也必须这么做。不过我一般不喜欢 .htaccess 文件，也不喜欢重写。

NGINX

看来你也许可以利用lua NGINX 模块将环境变量插入服务器。这也需要其他模块。

话虽如此，本文主要关注 PHP - 如果您将 nginx 与 PHP 一起使用 - 也许查看下面的 PHP 部分，这可能是更好的解决方案。

env PATH;
http {
    ...
    server {
        location /path {
            set_by_lua $path 'return os.getenv("PATH")';
            ...
        }
    }
}

NGINX 邮件列表讨论引发可能性

关于完整使用 lua 的博客文章

PHP

获取-cfg-var()将允许您检索 PHP 项目开发人员设置的值 - 以及您设置的任意值。值得注意的是，以这种方式在全局范围内谨慎命名这些变量，并确保阅读用户贡献的说明以了解一些自动混淆。

例子：

php.ini

environment_type=dev
environment_host=AWS

rando-script-whatever.php

get_cfg_var('environment_type') // returns 'dev'
get_cfg_var('environment_host') // returns 'AWS'

在 php-fpm 池配置文件中，以下内容将通过 $_SERVER 或类似的约定使自定义环境变量可用，正如 TMR 在评论中提到的那样。

例子：

我的池配置文件

env[FOO] = bar

rando-script-whatever.php

echo $_SERVER['FOO']; // returns 'bar'

概括

  • 什么： 我最终想要的结果是，我可以编写脚本来建立服务器。由于weaksauce，我有一个ansible包装器，并且运行了比我想承认的更多的bash脚本。无论如何，我想在操作系统用户级别设置某些变量，并让它们向下传播，以帮助我或多或少地“匿名化”我的Web应用程序代码库。

  • 为什么： 好处是，很多细节，如用于身份验证的 RSA 密钥（是的，它们适合环境变量）、密码和其他“秘密”都不受代码库的影响——您已将所有这些“秘密”移至配置脚本，显然移至采用低级访问控制的运行服务器。开发人员无需更改代码即可运行 Web 应用程序。可以检查和处理任何配置或偏差。一次编写，随处部署，一切都非常相似，即使不完全相同。配置脚本会自动将用于连接数据库的正确 DSN 用户、主机和密码放入环境变量中；引用环境变量的那些 PHP 变量从一开始就会选择正确的值。

  • 如何： 我的问题是：如果您已经这样做了，您会采用哪些步骤和技术？

编辑：

tl;dr - 删除了有争议的配置想法，提炼为一个简洁的问题主题

我删除了检测主机信息并根据发现配置服务器的内容。有人强烈暗示，这种配置服务器的方式可能是一种糟糕的策略，并且配置工具旨在声明设置，而不是目标主机在实例化时发现自己的信息并做出适当的反应。——而且，最重要的是，它是手头任务的次要部分。我想了解更多关于在环境变量中存储可能发生变化的细节的信息，这太棒了。

-AnrDaemon 特别提到违反了最小惊讶原则。

答案1

从提问的方式来看，唯一可能的答案是“不要那样做”。

网站不应该“试图弄清楚”任何事情，它应该发挥作用。

设置环境并根据它配置网站是部署脚本的工作。

正如@TML 指出的那样，有很多编排工具可以做到这一点。Saltstack、puppet……随便你选一个。

答案2

为了向您的应用程序提供环境信息，例如杜滕？

phpdotenv 从配置文件中读取以填充 PHP$_ENV和$_SERVER变量，这样您就可以在版本控制之外获得每个服务器的单独 API 密钥或其他配置信息，而无需配置 Web 服务器本身。

答案3

对我来说，最终我会使用 AWS 平台在主机上托管一个站点。

最有可能的是，当我部署新代码或主机配置时，我将创建一个新的服务器映像，将我的网站离线一两分钟，指定我的自动缩放组使用新映像，终止所有旧实例，并在第一个新实例重新启动时将我的网站重新上线。当然，我会事先测试所有内容，并高度确信一切都会按计划进行。如果不是，我将终止新实例并将其替换为旧映像中的实例...

因此，我计划通过环境变量让我的代码使用正确的配置值（例如数据库访问凭据和支持服务的 IP 地址），这并不像我所设想的那样。

我的配置脚本将为可以使用它们的其他内容设置环境变量。对于此单站点服务器上的 PHP，我将附加我自己的任意 key=value 变量对，如下所示。

get-cfg-var() 将允许您检索 PHP 项目开发人员设置的值 - 以及您设置的任意值。值得注意的是，以这种方式在全局范围内谨慎命名这些变量，并确保阅读用户贡献的说明以了解一些自动混淆。

例子：

php.ini

environment_type=dev
environment_host=AWS

rando-script-whatever.php

get_cfg_var('environment_type') // returns 'dev'
get_cfg_var('environment_host') // returns 'AWS'

感谢每个人花时间让我变得更聪明，我剪切/粘贴了我在这里学到的知识，以便为下一个笨蛋节省一些悲伤和时间。

相关内容