持續集成之“自動化部署”(2)

　　對環境管理進行版本控制，杜絕對生產環境的手工直接修改

　　“聽上去，對于配置文件、腳本等進行版本管理的確是解決了運維部署的很多問題。但如何對環境管理進行版本控制呢?”Tom問道。

　　Joe想了想，說道：“環境管理比較復雜。一般來說，環境包括幾個層次，包括硬件及網絡配置、操作系統、我們的應用程序所依賴的軟件堆棧及其配置、以及我們的應用程序運行時所需的數據及其配置。目前對我們來說，對于硬件及網絡配置、操作系統這兩層來說，有兩種方式進行管理。一種是利用一些專用軟件進行自動化的遠程配置，即只要給機器加電，就可以通過一些技術對一臺機器進行系統的安裝與配置。另一種是使用虛擬化技術來進行系統配置管理。對我們現在的游戲平臺來說， 使用后者即可。只要將基本的環境做成虛擬機鏡像文件，并將其作為環境基線進行版本管理。當然，由于鏡像通常較大，所以最好不要使用常見的版本控制工具(如subversion，Git等)進行，而使用某種簡單的機制即可。”

　　Joe停了一下，看看大家沒有提問的意思，于是接著說道：“至于基于其上的軟件堆棧及堆棧中各軟件的配置管理完全可以利用類似于CfEngine，Puppet或Chef的工具進行。這些軟件環境管理工具都提供某種領域專屬語言來描述軟件堆棧配置，并保存在文本文件中。這些工具一般通過服務器/客戶端的工作方式運行，客戶端向服務器發送請求，驗證本機器節點的軟件配置是否與服務器中的設置相符，如果不符，就會自動更新。尤其重要的是，這些更新操作都是冪等的，即無論這些配置在該客戶機上執行多少遍，每次的結果狀態都是相同的。另外，它們通常能與版本控制工具集成。所以，只要將我們的軟件堆棧配置管理信息放到版本控制庫中，就可以同時管理數臺機器。”

　　“oh, 對不起，Joe，我想打斷一下，”Tom問道：“你能畫一個圖來解釋一下你剛才所說的這種軟件環境配置管理工具嗎?”

　　“當然沒問題。”Joe拿起筆在白板上畫了一個Puppet的工作示意圖，如下圖所示。

　　“看上去清楚多啦。”Tom笑道，“通過這種方式，我們就只需要將版本控制庫中保存的配置信息簽出到本地，進行相應的修改，再提交到版本控制庫中，這種工具就會自動幫我們完成必要的配置更新了。是這樣的嗎?”

　　“對，”Joe點了點頭，說道，“如果我們的部署腳本也是通過這種方式來做的，那么我們就根本沒有必要登錄到生產環境的機器上，進行手工操作了。而且，Puppet還提供一種Try Run功能，可以進行配置變更的模擬，讓你能夠對比一下變更前后的不同之處。”

　　Tom說道：“你說的這些聽上去都不錯。但并不是所有人都能夠修改生產環境的配置信息的。所以我們還是需要一個軟件平臺來管理上線的申請審批流程。”

　　“在任何企業中，這種申請審批流程和生產環境變更的授權都是必要的，但這僅僅是審核流程的操作。而真正與軟件部署相同的具體操作都不應該在這種審批流程當中。”Joe回答道。

　　Tom接過話來，說道：“嗯，這樣的話，我們仍舊能夠做到：有權限的人才能真正修改生產環境的配置文件，同時達到了無人真正直接操作生產環境的目的，避免了手工誤操作帶來的問題。”

　　參加本次會議的測試人員和運維人員對這種做法產生了濃厚的興趣，并要求開發人員給予配合，將目前游戲平臺的部署自動化。Tom說道：“這就是我們運維工作的一個方向。讓枯燥易出錯的重復性手工操作變成受控的自動化，從而解放運維人員，讓我們可以關注于更加有價值的運行監控等工作中。”

　　Alice說道：“這看上去還是有一定的工作量啊。”

　　“當然，我們可能需要做一些工作，但我想這些投入是值得的。”Joe回答道。“同時，還需要各種角色之間更緊密的配合，而不是像之前那樣，通過一個代表上個世紀八十年代先進技術的辦公自動化平臺來描述部署上線步驟這類關鍵的業務操作信息。”

　　Tom也點了點頭，說：“嗯，應該使用版本控制方式。但我們還是需要一個上線審批的流程，只不過，這個流程中不再保存上線步驟這類與實際部署相關的業務信息，而只是為了部署人員的資格審核與信息周知的目標。”

　　經過一番討論，開發、測試和運維團隊在這件事情上達成了一致，并按計劃開始實施了。

　　需要注意的是，他們似乎沒有談到數據管理。他們會遇到相關的問題嗎?

原文轉自：http://www.anti-gravitydesign.com