Tomcat部署策略

Question

這是一個關於Tomcat部署的稍微不同的問題。前面的問題已經部分討論了這個問題，但我想從實際完成Tomcat部署的那些人那裏談談。

在我的組織中，我看到兩種類型的部署。

1. WAR部署到Tomcat的webapps DIR。 Tomcat停止，現有的WAR文件被重命名，webapps（appBase）下的現有應用程序目錄被刪除，新的WAR被複制並且Tomcat重新啓動。好處：部署WAR似乎被大家所瞭解。 我可以看到兩個缺點。如果WAR包含部署特定信息（如數據庫連接信息），則開發環境需要某種版本和構建控制，以確保正確的特定於部署的信息進入WAR文件。這可能變得複雜。 B.很多步驟，並不困難，但每一步都是潛在的錯誤點。

2. appBase指向應用程序文件系統，特定於部署的信息保存在別處。應用程序可部署文件系統或WAR文件被複制到Tomcat框中的某個位置。 Tomcats Servlet.xml中的應用程序的appBase屬性被修改爲指向新部署的代碼。複製後，Tomcat重新啓動。 所有部署特定的配置信息保存在不受部署影響的[tomcat_root]下的單獨目錄中。如果需要進行更改，可以隨時進行編輯，Tomcat重新啓動以獲取更改。好處：簡單，通常只有一步，最多兩步缺點：可能需要部署機器上的文件編輯。這在許多生產環境中是不允許的，或者必須由系統管理員而不是部署人員來完成。如果 出現問題，可能會導致延誤，政治問題和指責。

正如我上面所說，我希望聽到任何一種方法的真實世界的經驗。我絕對贊成第二種方法。我想知道第一個的吸引力是什麼，因爲 它似乎更容易出錯。

感謝， - = B

Answer 1

這裏是我如何做到這一點：

在源頭控制，我爲每個環境屬性文件。例如，production-environment.properties,qa-environment.properties等。所有屬性文件位於resources源目錄中，幷包含在WAR文件中。

Tomcat啓動時與選擇的環境中，例如一個系統屬性：

-Denvironment=production。

應用程序根據系統屬性選擇在運行時使用哪個屬性文件。

不需要特殊的構建或部署步驟。每個構建的WAR文件在所有環境中都使用。

此方法的另一方面是WAR文件中的屬性可以被系統屬性覆蓋。這允許操作員在部署WAR後更改屬性。它還允許像數據庫密碼這樣的敏感信息完全脫離源代碼控制。

Answer 2

第一種方法可以通過自動化的包裝過程進行管理。我通常使用maven和針對不同部署環境的配置文件。構建工具確保可重複構建並防止您犯錯誤。

在較大的商店中，開發者和操作者之間通常會有一個很大的中國牆，選擇第二種方法。開發人員不允許觸摸生產服務器。

Answer 3

我使用kwateeSDCM自動化參數實例化，例如數據庫連接信息和部署在tomcat上。有一篇有趣的博客文章談到了deploying war on multiple tomcat instances。