[英]Building Production Release - DB Connection Credentials
我們有一個可以為特定環境打包war文件的構建,其中我們的所有屬性文件都嵌入在存檔(war文件)中。
我們現在即將為生產而構建。 我擔心的是代碼庫需要公開生產數據庫密碼,雖然不太可能存在生產構建配置文件可能會產生負面影響的風險。
我想到的消除這種風險的選項是不在 SVN 中存儲生產細節,並且:
讓管理員覆蓋用於連接到數據庫的系統屬性,或
讓容器管理數據庫連接而不是 c3p0,這樣他們就可以自己管理這個配置。
你有什么建議嗎?
您絕對不應該將生產數據庫用戶名和密碼放入您的源代碼控制系統中。 您的應用程序應該使用 JNDI 獲取其數據庫連接(例如DataSource
),該連接由生產環境中的管理員控制/限制。
例如,如果您的應用程序部署到 Tomcat,則您在 tomcat/conf/context.xml 中有以下內容
<Resource name="jdbc/myDB"
auth="Container"
type="javax.sql.DataSource"
maxActive="20"
maxIdle="10"
maxWait="3000"
username="myusername"
password="mypassword"
driverClassName="com.mysql.jdbc.Driver"
url="jdbc:mysql://myhost:3306/myschema"
defaultAutoCommit="false"/>
..並且連接是從java:/comp/env/jdbc/myDB
而您的應用程序不必提供用戶名或密碼。 tomcat 安裝在 prod 服務器上受到管理員的保護,因此在您的 prod 服務器上沒有管理員訪問權限的任何人都無法使用它。
在生產中,我喜歡完全不在屬性文件上存儲憑據的方法。 相反,我更喜歡應用程序服務器使用jndi
提供憑據。
如果您使用的是 Apache Tomcat,請參閱例如他們的jndi 參考。
我已經嘗試在存檔中和存檔外都有屬性,並且將它們放在存檔之外更容易管理此類問題。
一些注意事項:
使用這兩個策略,開發人員可以負責管理非生產屬性文件,因此也可以作為生產管理員的示例。 它還使大多數屬性集中在源代碼控制中,提供了保持事物集中的一些好處,同時仍然充分解耦屬性。
編輯:請注意,JNDI 是一個選項,但在體系結構上它與在外部存儲屬性文件相同 - 您仍然需要注意版本這些不要讓它們在不同的環境中松散。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.