集中的屬性文件管理

全部，集中的屬性文件管理

我正在尋找一個集中的屬性管理解決方案，例如：我有一個流量/應用程序在騾子。我有不同環境的多個屬性文件。與其他應用程序一樣，這非常棒。

在這些文件中配置的屬性幾乎是用戶名，密碼，目標端點等，但我不想在這些簡單的文件中公開它們。相反，我正在尋找一個集中式解決方案，我可以將我的屬性配置爲鍵，並在我的應用程序中使用鍵。

像這樣的事情

數據庫用戶= $ {中心 - 屬性 - key.database.user}

代替

數據庫用戶的= dbuser1

我知道，我可以在這裏使用類似Zuul的東西。但就我搜索而言，祖魯沒有託管解決方案。（我不喜歡在內部託管和管理任何東西;））

想法？任何其他最好的方法？

來源

2016-06-28 gnanagurus

我之前使用過Zuul和Mule。它比手動處理屬性文件更容易。優點是： 1）基於UI的鍵值對定義 2）分離環境（如具有DEV的Zuul實例，測試& UAT配置和PROD配置的單獨實例） 3）Mule支持Zuul集成屬性 4）數據在Zuul可以被加密（它在數據庫中維護的數據在內部）上的配置數據 5）用戶的訪問控制可以做到

缺點在Zuul或者在使用屬性/安全屬性佔位符是，我們不能動態訪問值 - 騾強制重新部署應用程序。爲了克服這個問題，我們構建了包裝API，它在運行時從Zuul（基於環境）獲取屬性。這些在Mule/Zuul中並不是開箱即用的，但它主要是爲了避免重啓。

感謝，

Ananth

來源

2016-06-29 05:26:05

非常感謝Ananth，你的重新部署是非常好的一點。當然，我們討厭重新部署。對於這一點，即使您使用cloudhub控制檯更新屬性，mule也會重新部署應用程序。包裝API也很有趣，我會跳過並試一試。看起來Zuul是目前最好的解決方案，無法找到任何其他備用選項。 – gnanagurus

我會在回購中使用多個文件，例如dev.properties，qa.properties和stage.properties。這些將留在項目中。然後prod.properties會留在我的個人機器上。

我會再加入這騾子配置：

<context:property-placeholder location="classpath:${env}.properties"/>

在mule-app.properties我想補充一點：

env=dev

如果有人對開發數據庫或端點篡改， qa，我不擔心如果他們傷害生產，我會擔心。對於生產，我會編寫將prod.properties複製到項目中的操作，設置env = prod，然後在部署準備好放入生產服務器的應用程序目錄之前執行Maven clean包。

您認爲如何？如果你同意，讓我知道並給我一個答案的投票。

來源

2016-06-28 07:03:38

我希望你已經在使用David提到的內容。我還看到ZUUL博文是針對老版本的mule。

正如我從你的解釋中理解的，儘管你要求集中存儲屬性的機制，但是需要安全性和相應的答案。

騾子現在有像下面

安全性更好的特點：當我們使用這個Anypoint雲提到的屬性將如帶星號****。在屬性文件中的屬性不必給予或保持空的，而部署管理員提供的細節，它也將被屏蔽
物業佔位加密：當使用在屬性文件的屬性將被加密

https://docs.mulesoft.com/mule-user-guide/v/3.6/installing-anypoint-enterprise-security

爲此，您需要從bleow網站騾子安全模塊安裝到您的Anypoint工作室（這是Eclipse等）

http://security-update-site.s3.amazonaws.com/

安裝安全模塊形式在那裏。

Mule還提供了其他功能，作爲企業安全解決方案的一部分。

來源

2016-06-28 07:15:21

感謝納文，我已經通過所有這些鏈接不見了。 mule-credentials-vault很有前途，但我的要求稍有不同。我不希望騾子開發者知道任何值，這意味着我不希望騾子開發者知道任何用戶名或密碼。整個用戶名和密碼將由其他團隊管理。騾子們只會知道用戶名和密碼的關鍵。明白了嗎？任何解決方案/思想進入你的想法？這樣Zuul非常接近，唯一的事情是我需要在我自己的某個地方主持Zuul。 – gnanagurus

我並不僅限於使用Zuul的解決方案，我也很樂意看到其他任何最佳實踐。例如：有一種做法，其中的人可以將這些屬性設置爲系統屬性，這樣只有運行mule的用戶才能讀取這些系統屬性。我基本上正在探索什麼是達到我的要求的最佳方式。 :) – gnanagurus

這是前提還是在雲端。誰在部署。如果部署是由Infra傢伙完成的，那麼Masking解決方案就是您可以想到的答案中提到的一個選項。這會工作。只有部署的人員才能看到密碼，並且一旦爲任何看到屬性的人員進行了第一次部署，它將顯示爲***。此外，Mule還有RBAC可以幫助限制訪問。 –

對於環境的特定密碼，我們通常在上下文中添加最後一個文件：屬性佔位符 -

<context:property-placeholder ignore-resource-not-found="true" 
    location="project-common.properties,env/project-${env_name}.properties,file:///var/mule/properties/project.properties"/>

Offcourse，你能說出你想要的任何方式的屬性。然後，所有密碼都將轉到file：///var/mule/properties/project.properties服務器上，並具有隻讀用戶的讀取權限。

來源

2016-06-28 15:43:08

@Downvoter，downvoting是好的，但它應該伴隨着爲什麼downvote的評論？這些問題還詢問了其他最佳方法。這裏的所有三個答案爲相同的情況提供了不同的方法。你認爲最好，對別人可能不是最好的，所以請慎重考慮答案，並與人討論。希望你很快找到你的「最佳」答案！ –

集中的屬性文件管理

回答

相關問題