2011-11-04 88 views
2

有一個團隊用web界面開發企業應用程序:java,tomcat,struts,mysql,REST和LDAP對外部服務的調用等等。環境配置管理?

所有配置存儲在context.xml - 包含通過servlet上下文和通過JNDI資源可用的對象可用變量的tomcat特定文件。

開發人員無法訪問生產和質量保證平臺(因爲它應該是),因此context.xml由support/sysadmin團隊管理。

每個版本都有配置,notes.txt有類似的說明:

please add "userLimit" variable to context.xml with value "123", rename "DB" resource to "fooDB" and add new database connection to our new server (you should know url and  credentials) named "barDb" 

這是不好的。

這是我的想法如何解決它。

每個版本都有特殊配置文件,必需的變量名稱,描述和默認值(如果有的話):即使的web.xml都可以使用。

這裏是僞例如:

foo=bar 
userLimit=123 
barDb=SET_MANUAL(connection to our new server) 

而且還有一個特殊的工具,它支持團隊有違部署神器。 看它(「>」被支持的人輸入文字後):

Config for version 123 of artifact "mySever". 

Enter your config file location> /opt/tomcat/context/myServer.xml 

+"foo" value "bar" -- already exists and would not be changed 
+"userLimit" value "123" -- adding new 
+"barDb"(connection to our new server) please type> jdbc:mysql:host/db 

Saving your file as /opt/tomcat/context/myServer.xml 
Your environment is not configured to run myServer-123. 

這將會給我們,如果需要部署在任何環境和更新配置應用能力。

你喜歡我的想法嗎?你用什麼來進行環境配置管理?是否有爲此準備好使用的工具?

回答

1

我非常不同意你的說法,即開發人員不應該有權訪問產品或登臺環境。正是這種態度導致團隊互相攻擊,而不是互相攻擊。

但要回答您的問題:您正在考慮通常稱爲持續集成(http://en.wikipedia.org/wiki/Continuous_integration)並朝向devops的方向發展。理想情況下,您應該瞄準魔術「一鍵自動部署」。 Flickr的人寫了很多關於他們如何實現這個目標的博客(和書籍)。無論如何..圍繞該領域有很多工具。你可能想看看像哈德森/詹金斯或木偶/廚師的東西。

+0

謝謝。由於安全原因,開發人員無法訪問生產系統。我們確實使用CI(teamcity),它爲我們構建了工件。但它對平臺配置沒有任何作用。我會更接近puppet和flickr書籍。 – user996142

2

有很多不同的策略。他們都很好,取決於最適合你的東西。

  1. 構建一個工件並將配置部署到一個單獨的位置。工件可以有佔位符變量,在部署時,可以讀取配置。查看Springs屬性佔位符。它非常適合使用Spring的webapps,並且不涉及獲取操作參與。
  2. 擁有一個外部屬性配置,它位於webapp之外。保持位置不變並始終從屬性配置中讀取。在任何階段更新配置,重新啓動將升起新的值。
  3. 如果您正在修改環境(即正在使用的應用程序服務器或用戶/組權限),請查看使用puppet或chef的上述方法。也看看用這些工具管理你的配置文件。

至於整個開發者應該能夠獲得prod,這實際上取決於每個公司的基礎。對於每次出現問題時都會調用開發人員的小型公司,無論該問題是否與服務器或應用程序相關,那麼顯然開發人員都需要訪問該開箱。

DevOps不是讓開發人員能夠訪問該框,其關於賦予開發人員將基礎架構作爲服務使用的能力,能夠使用配置Y產生帶有應用程序X的新實例,並將其應用程序推送到環境中而無需操作。在像我們這樣的大公司中,它允許開發人員管理他們放在服務器上的應用程序。操作不應該關心他們的版本是什麼,這是我們的工作,他們的工作就是保持服務器正常運行。