[[425692]]

 讓我們來討論一下如何配置Python應(yīng)用程序，特別是那些可能存在于多個環(huán)境中的應(yīng)用程序——開發(fā)環(huán)境、模擬環(huán)境、生產(chǎn)環(huán)境等等……

應(yīng)用程序中使用的工具和框架并不是特別重要，因?yàn)槲覍⒃谙旅娓攀龅姆椒ㄊ腔谄胀≒ython的。這種方法的出現(xiàn)是由于使用Django設(shè)置會令人懊惱，此外，這種方法還是我將要處理的任何Python應(yīng)用程序的首選。

概述:Python模塊和包

我最喜歡的Python特性之一是，構(gòu)成你應(yīng)用程序的文件和目錄與你在代碼中導(dǎo)入和使用它們的方式是一一對應(yīng)的。

例如，給定這個import語句:

我們可以推斷出以下目錄結(jié)構(gòu):

許多語言和框架都依賴于這個新概念，包括Clojure和ES6。

在我們的示例中，Python將utils目錄視為一個Package。當(dāng)你在一個目錄中放置一個空的__init__.py時，該目錄就變成了一個包。

作為一名Python黑客，你可能會遇到這樣一個常見的場景，其中有一個utils.py文件最終會變得太大，因此你將它拆分成一個包含許多較小文件的utils//目錄。

當(dāng)遇到這種情況時，我們可以做以下事情:

所以現(xiàn)在我們已經(jīng)看到了一個Python包是由一個目錄中是否存在一個__init__.py文件決定的…但是如果這個文件不是空的呢?

在__init__.py中放入代碼

由于它只是一個普通的舊Python文件，你可以把任何你想要的東西放在其中，該文件會在第一次導(dǎo)入包時被執(zhí)行。

>>>旁注

通常我們不贊成將代碼放在__init__.py中，因?yàn)樗鼤趯?dǎo)入時帶來意想不到的副作用。

你可以自己測試一下。創(chuàng)建一個名為foo的目錄，并給它一個空的__init__.py文件。

從相同目錄中的Python REPL運(yùn)行以下代碼:

這里沒有輸出是很好的，這意味著語句成功運(yùn)行。

現(xiàn)在讓我們編輯我們的__init__.py文件以包含以下代碼:

sys.exit()通常用于使一個進(jìn)程以特定的狀態(tài)退出。

在一個新的REPL中重新運(yùn)行相同的實(shí)驗(yàn)，你將觀察到你的Python shell在導(dǎo)入之后會立即退出。在更大的應(yīng)用程序中，效果會更明顯:整個應(yīng)用程序?qū)⑼顺觥?/p>

這樣，我們了解了基本原理，并了解了如何惡意使用此功能。

也許我們可以用它來做好事?

多個環(huán)境&十二因素應(yīng)用程序

你的應(yīng)用程序可能存在于多個環(huán)境中。你的本地開發(fā)環(huán)境可能是第一個，并且你可能有一個位于Jenkins或另一個CI平臺上的測試環(huán)境。你的代碼被部署到一個生產(chǎn)或活動環(huán)境中。一些系統(tǒng)可能有一個模擬環(huán)境，在實(shí)際運(yùn)行之前使用。

即使你只認(rèn)為自己是一個業(yè)余愛好者，在本地開發(fā)代碼并將其部署到一個vps或類Heroku平臺上也意味著你要處理多個環(huán)境。

我在構(gòu)建應(yīng)用程序時遵循的一個規(guī)則是，我應(yīng)該能夠?qū)⒋a庫部署到任何環(huán)境中(無需修改)，前提是我們有辦法告訴系統(tǒng)它在哪里運(yùn)行。

與此相比，為每個部署目標(biāo)構(gòu)建多個部件，需要額外的時間和復(fù)雜性來構(gòu)建和保持。這些部件通常被設(shè)計為在單一目標(biāo)環(huán)境中運(yùn)行，因此在本地或測試模式中運(yùn)行它們通常是困難的或不可能的。

著名的十二因素方法論也認(rèn)同這一觀點(diǎn)，并且認(rèn)為所有配置都應(yīng)該作為環(huán)境變量存在。我在一定程度上同意這一點(diǎn)，但有時有一種趨勢，就是把所有東西都變成一個環(huán)境變量，很快就會變得難以支持。

如果你的系統(tǒng)的每個旋鈕和刻度盤都是一個環(huán)境變量，那么你將發(fā)現(xiàn)，你最終會將各種變量的組合存儲在某個地方，以便運(yùn)行或調(diào)試。在這里看到問題了嗎?我們將配置從一個區(qū)域(代碼，通常保存在版本控制中)移出，并將它們移到更容易出現(xiàn)錯誤和人為錯誤的區(qū)域。

我用來劃定界限的一般準(zhǔn)則:

•  不經(jīng)常更改的靜態(tài)內(nèi)容，或者顯著影響系統(tǒng)行為的內(nèi)容應(yīng)該存在于代碼中。
•  頻繁更改的動態(tài)內(nèi)容或應(yīng)該保密的內(nèi)容(API鍵/憑據(jù))應(yīng)該存在于代碼之外。

我們?nèi)绾吻袚Q環(huán)境?

為了讓應(yīng)用程序在不同環(huán)境之間改變其行為，我們需要一種方法來告訴它，它正在哪里運(yùn)行。依賴于環(huán)境變量(看到模式了嗎?)，我傾向于使用ENV(或變體)來實(shí)現(xiàn)此目的。

•  Ruby/Rails生態(tài)系統(tǒng)使用RACK_ENV或RAILS_ENV
•  Javascript項(xiàng)目通常會利用NODE_ENV

>>>旁注

在改變底層框架或工具的運(yùn)行時行為的標(biāo)志與特定應(yīng)用程序的操作模式的標(biāo)志之間劃一條線是很重要的。例如，有時一個簡單的DEBUG=True/False并不夠好。

我最近為一個客戶完成一個帶有以下約定的項(xiàng)目:

•  我的本地開發(fā)環(huán)境沒有設(shè)置一個ENV變量，因此系統(tǒng)默認(rèn)情況下會推斷開發(fā)環(huán)境。
•  AWS CodePipeline上的測試環(huán)境使用ENV=test
•  EC2上的生產(chǎn)環(huán)境使用ENV=production

注意:考慮不設(shè)置這個變量的后果是很重要的。這會是災(zāi)難性的嗎?例如，應(yīng)用程序能否在生產(chǎn)集群內(nèi)部以DEV模式啟動，并最終向公眾顯示回溯信息?對于某些應(yīng)用程序，默認(rèn)設(shè)置應(yīng)該是production。這里沒有正確或錯誤的答案，但它需要被考慮。

最終的目標(biāo)

從開發(fā)者的角度來看，我們想要像這樣訪問我們的配置:

上面的導(dǎo)入行不包含任何能提示我們所處環(huán)境的內(nèi)容。我們在任何地方都沒有看到development或production這樣的詞。相反，我們只導(dǎo)入了我們需要的，并允許配置系統(tǒng)來決定它來自何處。

我們利用文件系統(tǒng)和語言本身來提供一個用于讀取配置的API。

在幕后，這是config目錄在磁盤上的樣子:

•  common.py包含我們所有的公共或共享配置。這些東西在不同的環(huán)境中并沒有太大的不同。你可以稱其為base或shared配置，如果你愿意。
•  environments/development.py包含開發(fā)配置。該文件可以排除在版本控制之外，這樣團(tuán)隊中的每個開發(fā)人員都可以實(shí)現(xiàn)自己的配置設(shè)置。
•  environments/(production|staging).py包含每個環(huán)境特有的配置。

讓我們來看看common.py:

這是一個人為的例子，所以請不要太深入地了解細(xì)節(jié)。需要注意的是，這是一個相當(dāng)靜態(tài)的配置，不會經(jīng)常改變。

現(xiàn)在讓我們來看看environment/development.py：

•  我們首先導(dǎo)入common配置，以便在默認(rèn)情況下繼承所有公共配置。現(xiàn)在我們可以添加、替換或增加參數(shù)，而不需要從父配置進(jìn)行復(fù)制粘貼。
•  為了支持本地開發(fā), 我可以自定義在我的環(huán)境中使用的AWS資源。系統(tǒng)的其余部分沒有改變，但是現(xiàn)在我的本地系統(tǒng)使用我自己的Dynamo表和S3 bucket。
•  因?yàn)樵撐募辉诎姹究刂浦?，所以我可以放心地存儲機(jī)密信息，比如我自己的GOOGLE_CLIENT_ credentials。
•  因?yàn)榭梢栽L問公共的DEFAULT_NAMESERVERS，所以我可以擴(kuò)展它們，而不是復(fù)制粘貼任何公共值到我自己的配置中。
•  在生產(chǎn)環(huán)境中，systemd命令用于在響應(yīng)某些管理操作時重新啟動應(yīng)用程序。因?yàn)槲业腗ac沒有systemd，所以我用一個簡單的no-op替換了system reboot命令，從而完全避免了這個問題。

它是如何工作的

回到我們的config/__init__.py文件，我們可以在這里實(shí)現(xiàn)什么來實(shí)現(xiàn)它呢?其實(shí)很簡單:

我們正在利用import-time evaluation來動態(tài)地從相應(yīng)的子環(huán)境中獲取必要的配置。讓我們一步一步來:

     1.  首先，我們導(dǎo)入importlib模塊(文檔)，它為我們提供了一些用代碼導(dǎo)入代碼的方便工具。

     2.  使用我們建立的約定—ENV環(huán)境變量—我們獲取當(dāng)前運(yùn)行的環(huán)境的名稱。

     3.  如果沒有設(shè)置環(huán)境，我們就選擇development作為默認(rèn)設(shè)置，但是如前所述，這個決定將根據(jù)系統(tǒng)的不同而有所不同。

          我們甚至可以考慮阻止應(yīng)用程序啟動，除非定義了這個變量。下面是一個這樣的例子:

    4.  接下來我們使用importlib.import_module函數(shù)將包含特定環(huán)境代碼的模塊加載到局部變量module中。

    5.  最后，我們更新這個模塊的globals，將development.py文件中設(shè)置合并到其中。

    6.  最終，你將看到一些便利的工具(a-la Rails)，使基于環(huán)境切換具體的邏輯變得更加容易。它們作為函數(shù)保存，以便將實(shí)現(xiàn)隔離到此模塊，而不是隔離到使用它的任何地方。

這種方法深受Ruby on Rails配置的啟發(fā)，它實(shí)現(xiàn)了一個非常相似的外觀，只是底層實(shí)現(xiàn)有所不同。

 一個真實(shí)的例子

為了提供另一個實(shí)際的例子，以下是本網(wǎng)站的配置:

首先，這是我的config目錄的確切目錄結(jié)構(gòu):

•  development.py在本地使用
•  production.py用于Heroku
•  test.py用于帶有pytest的本地單元測試

base.py包含靜態(tài)配置:

•  一個在項(xiàng)目的其他地方使用的集中式日志格式。
•  通用目錄和一個使路徑相關(guān)的工作更容易的助手函數(shù)。
•  我的服務(wù)的時區(qū)。
•  當(dāng)頁面不提供自己的標(biāo)題時使用的默認(rèn)標(biāo)題。

在development.py中，站點(diǎn)標(biāo)題會被覆蓋，這樣，當(dāng)我在編輯的時候，我就知道我正在查看的是一個本地副本。我還定義了一些本地的Redis配置，它們與Production有很大的不同。

•  SENTRY_DSN只在production.py中被定義，而沒有在base或其他環(huán)境中定義。這是為了防止Sentry(集中式錯誤日志)在開發(fā)或測試情況下被激活。
•  在Heroku上，Redis連接細(xì)節(jié)來自一個URL，因此我們在這里進(jìn)行了配置。

最后，為了演示如何在應(yīng)用程序的其他地方使用這個設(shè)置，我們來看看Redis連接是如何建立的:

注意最后一行:RedisManager.from_config()用于隔離關(guān)注點(diǎn)。RedisManager的其余部分不知道config中的數(shù)據(jù)是什么樣子的，也不需要知道。這是配置層和系統(tǒng)其余部分之間的一個切換點(diǎn)。

結(jié)論

我在所有的Python項(xiàng)目中都使用了這種方法，但還沒有發(fā)現(xiàn)這種方法(或其變體)不起作用的情況。

1.   我們有創(chuàng)造無限數(shù)量環(huán)境的靈活性。例如，如果我們想為一個拉取請求啟動一個臨時環(huán)境:我們只需要使用“cp environments/staging.py environments/PR_402.py and ENV=PR_402”就可以了。
2.   當(dāng)在本地進(jìn)行開發(fā)時，我們可以在生產(chǎn)模式下運(yùn)行系統(tǒng)，方法是在它前面加上ENV=production，反之亦然，我們也可以在開發(fā)或測試模式下在其他任何地方運(yùn)行軟件。
3.   開發(fā)人員可以通過查看每個環(huán)境被覆蓋的配置來快速收集每個環(huán)境之間的主要差異。這使得將新的團(tuán)隊成員加入到你的代碼庫中變得更加容易。
4.   類似地，團(tuán)隊中的每個開發(fā)人員都可以有自己獨(dú)特的配置。這不會過多地影響中心配置，因?yàn)槟愕南到y(tǒng)有一些不同于其他系統(tǒng)的設(shè)置。
5.   我們可以通過顯式地將environments/test.py 中的某些變量設(shè)置為None來保護(hù)我們的測試環(huán)境，以避免意外地訪問生產(chǎn)環(huán)境資源。
6.   我們消除了在各種CLI工具(如Docker等等)之間傳遞較大鍵/值配置映射的負(fù)擔(dān)(盡管現(xiàn)在的工具越來越能夠從文件中讀取env)
7.   我們將我們的配置公開為一個普通的Python包，因此與其他Python工具幾乎沒有學(xué)習(xí)曲線和互操作性問題。
8.   我們避免了支持外部庫/依賴項(xiàng)所需要的成本。

總而言之，這種方法并不是很吸引人，而這正是我們在構(gòu)建可靠、可維護(hù)和高效的系統(tǒng)時所想要的。使用一些簡單的舊Python和幾行特殊代碼，我們就已經(jīng)在我們的系統(tǒng)配置中釋放了大量的靈活性和強(qiáng)大功能。