如何利用Linux容器實現可移植的應用部署

Docker是一種在Linux容器裡運行應用的開源工具，一種輕量級的虛擬機器。除了運行應用，Docker還提供了 一些工具，藉助Docker Index或自己託管的Docker註冊表對進行了集裝箱化處理的應用進行分發，從而簡化複 雜應用的部署過程。

我將在本文介紹如今在部署複雜系統時公司所面臨的挑戰，Docker怎樣有效地解決這個問題，以及Docker 的其他用例。

部署的挑戰

伺服器應用的部署已經越來越複雜了。把幾個Perl指令碼拷貝到正確目錄就完成伺服器應用的安裝，這種時 代已經一去不複返了。如今的軟體有很多類型的需求：

對已安裝軟體和庫的依賴（“Python版本高於2.6.3，使用Django 1.2”）

依賴於正在啟動並執行服務（“需要一個MySQL 5.5資料庫和一個RabbitMQ隊列”）

依賴於特定的作業系統（“在64位的Ubuntu Linux 12.04上構建、測試”）

資源需求：

最小的可用記憶體（“需要1GB的可用記憶體”）

能綁定特定的連接埠（“綁定80和443連接埠”）

我們來看一個相對簡單的應用的部署：Wordpress。Wordpress的安裝通常要求：

Apache 2

PHP 5

MySQL

Wordpress源碼

一個Wordpress MySQL資料庫，配置Wordpress使用該資料庫

Apache的配置：

載入PHP模組

支援URL重寫和.htaccess檔案

指向WordPress源碼的DocumentRoot

在伺服器上部署、運行這樣一個系統，我們可能會遇到下面的問題和挑戰：

隔離性：如果我們已經在這個伺服器上部署了不同的網站，已有的網站只能在nginx上運行，而Wordpress 依賴於Apache，這時我們就會有麻煩：它們都監聽80連接埠。同時運行兩個網站是可以的，但需要調整配置（修 改監聽連接埠），設定反向 Proxy等。庫層級也會出現類似的衝突，如果還要運行一個仍然依賴PHP4的老應用就會 出問題，因為Wordpress不再支援PHP4，同時運行PHP4和PHP5則非常困難。運行在同一個伺服器上的應用沒有 互相隔離（在檔案系統層級和網路層級），所以它們可能會互相衝突。

安全性：Wordpress的安全記錄並不是非常好。所以還是給它建立個沙箱，至少駭客入侵時不會影響其他運 行的應用。

升級、降級：升級應用一般會覆蓋現有檔案。升級過程中會發生什嗎？系統要關閉嗎？如果升級失敗，或 者不對該怎麼辦？我們怎樣快速回退到先前的版本？

快照、備份：一旦所有的內容都設定好，就給系統建立一個“快照”，以便能備份快照，甚至 能移到另一個伺服器上再次啟動，或者拷貝到多個伺服器上以備不時之需。

重複性：系統出新版本之後，比較好的做法是先在測試基礎設施上自動部署並測試，然後再發布到生產系 統。通常會利用諸如Chef、Puppet等工具在伺服器上自動安裝一堆包，等一切內容都就緒後，再在生產系統上 運行相同的部署指令碼。這在百分之九十九的情況下都沒有問題。但有百分之一的例外，在部署到測試環境和生 產環境之間的時間跨度裡，你依賴的包在包倉庫裡有了更新，而新版本並不相容。結果生產環境的設定和測試 環境不同，還有可能破壞生產系統。假如沒有控制部署的每一個方面（例如託管自己的APT或YUM倉庫），持續 在多個階段（比如測試、預演、生產環境）重複搭建出完全相同的系統就很困難。

資源限制：如果我們的Wordpress耗費CPU資源，並佔用了所有的CPU周期，導致其他應用無法做任何事情怎 麼辦？如果它用盡了全部可用的記憶體呢？或者瘋狂寫日誌阻塞磁碟呢？要是能限制應用的可用資源，比如CPU 、記憶體和磁碟空間，就會非常方便。

易於安裝：也許有Debian或CentOS包，抑或是能自動執行所有複雜步驟並安裝Wordpress的Chef菜譜。但這 些菜譜很難穩定下來，因為它們需要考慮目標系統上可能的系統配置。很多情況下，這些菜譜只能在乾淨的系 統上運行。因此，你不太可能更換成自己的包或Chef菜譜。這樣的話，安裝就是個複雜的系統工程，而不是午 休期間就能搞定的事情。

易於移除：軟體應該能輕鬆、乾淨地移除，不留痕迹。但部署應用通常要調整已有的設定檔、設定狀態 （MySQL資料庫的資料，日誌），完全移除應用也變得不那麼容易。

那我們應該如何解決這些問題呢？

虛擬機器！