Nginx

建立伺服器(例如 Debian)時,有哪些方法可以使環境變數持久化並對 PHP 可用?

  • December 27, 2016

我現在在作業系統級別做什麼:

初始化後,更改為需要變數的使用者並導出變數,然後還指定在配置文件中設置它們 - 或在 /etc/environment (Debian) 中(如果是 root)以說明持久性

我通過“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)

環境和外殼變數

使環境變數對 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

get-cfg-var()將允許您檢索 PHP 項目開發人員設置的值 - 以及您設置的任意值。以這種方式在全域範圍內小心命名這些變數是值得小心的,並確保閱讀使用者提供的註釋以了解一些自動修改。

例子:

php.ini

environment_type=dev
environment_host=AWS

隨機腳本whatever.php

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

在 php-fpm 池配置文件中,下面將通過 $_SERVER 或 TMR 在評論中幽默我提到的類似約定在某處提供自定義環境變數。

例子:

我的池.conf

env[FOO] = bar

隨機腳本whatever.php

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

概括

  • 什麼: 我正在尋求的最終結果是我可以編寫腳本來建立伺服器。由於 weaksauce,我有一個 ansible 包裝器,並且執行的 bash 腳本比我想承認的要多。無論如何,我想在作業系統使用者級別設置某些變數並讓它們向下傳播以幫助我或多或少地“匿名化”我的 Web 應用程式碼庫。
  • 原因: 好處是許多細節,如用於身份驗證的 RSA 密鑰(是的,它們適合環境變數)、密碼和其他“秘密”不在程式碼庫中——你已經移動了所有這些“秘密”到供應腳本,顯然到使用低級訪問控制的正在執行的伺服器上。開發人員無需更改任何程式碼即可執行 Web 應用程序。可以檢查和處理任何配置或偏差。一次編寫,滿懷信心地部署到任何地方,即使不相同,一切都非常相似。配置腳本會自動將用於連接到數據庫的正確 DSN 使用者、主機和密碼放入環境變數中;那些引用環境變數的 PHP 變數只是從一開始就選擇正確的值。
  • 如何: 這是我的問題。如果您已經這樣做了,您會採用哪些步驟和技術?

編輯:

tl;dr - 刪除了一個有爭議的供應想法,提煉成一個簡潔的問題主題

我已經刪除了關於檢測主機和根據發現配置伺服器的內容。有人強烈建議,這種配置伺服器的方式可能是一個糟糕的策略,並且配置工具旨在聲明設置,而不是目標主機在實例化時發現有關自身的事情並做出適當的反應。——而且,最重要的是,它僅次於手頭的任務。我想了解更多關於儲存環境變數中可能發生變化的細節的資訊,這很棒。

- AnrDaemon 特別提到打破了最小意外原則。

從問題提出的方式來看,唯一可能的答案是“不要那樣做”。

網站不應該“試圖弄清楚”任何事情,它應該工作。

根據它設置環境和配置網站是部署腳本的工作。

正如@TML 指出的那樣,有很多編排工具可以做到這一點。Saltstack,puppet,……說出你的選擇。

為了向您的應用程序提供環境資訊,諸如dotenv 之類的呢?

phpdotenv 從配置文件中讀取以填充 PHP$_ENV$_SERVER變數,因此您可以在版本控制之外為每個伺服器獲取單獨的 API 密鑰或其他配置資訊,而無需處理 Web 伺服器本身的配置。

引用自:https://serverfault.com/questions/817925