爲生產環境準備Docker容器的有關課程

【編者的話】本文爲獨立顧問James Higginbotham於DZone網站中發佈的文章Lessons in Preparing Docker Containers for Production，此文描述了在使用Docker進行生產時須要記住的一些關鍵點，包括自動化，數據庫決策以及編排等方面的重要性。

最近，我花了兩個星期，幫助將來的架構師和技術領導者們瞭解原生雲架構。咱們在Realscale網站上討論了許多涉及到的概念。

其中討論的一部分重點是將容器化做爲舊版應用程序現代化的戰略。部分領導者們決定使用Docker容器去創建他們項目的一部分。在這篇文章中，我將會分享他們在開始這個項目時發現的重要經驗和學到的關鍵教訓。
 

一切自動化

許多的開發者做出的假設是-認爲他們的服務器將是運行很長一段時間。但其實他們並無一個適當的用於恢復的自動化流程，若是他們的Docker主機 -咱們以一個在這種狀況下的EC2實例來舉例，發生故障或終止。這包括存儲在本地文件系統，而不是任何數據遠程塊或基於文件系統的存儲。

咱們的生產環境的Docker容器須要確保Docker主機在故障的狀況下能夠被替換並能用上新的實例。這就要求服務器監控和自動化手段來確保可靠的基礎設施爲咱們的生產中的Docker實例提供足夠的業務支撐。雖然我傾向於經過使用Cloud66來實現，不過一些團隊傾向於選擇使用其餘服務，或使用Docker Swarm或Kubernetes來管理它們。
 

編排您的容器

你是否定爲雲服務器是一種存活時間短而且轉瞬即逝的資源呢？容器存活的時間一般更短。根據它們的須要，容器通常能夠持續存活幾秒鐘或者幾天或更長的時間。這其實應該已被歸入設計和實現代碼的方式。若是你的代碼或應用程序的配置假定了他們的環境是長期的，又或者他們所依賴的其餘服務將會持續存在，那麼，這有可能會帶來意想不到的災難。

容器管理和業務流程的解決方案確保了有足夠的容器可用，可按需擴展或收縮實例，並能夠控制分配給咱們的容器以及主機資源（如CPU和內存）。在研討會期間，咱們討論了像Cloud 66如何處理這種沒有任何多餘的腳本的這樣一種方案，幫助他們瞭解到了選擇適合本身的目標架構供應商的會帶來的好處。

一些開發人員對於容器存活這一問題認識到的有點晚，因此以前一般這麼作他們的內部文件系統。咱們來假設部署一個數據庫 - 咱們用MongoDB來作此次的舉例 - 那麼數據庫必須掛載必要的數據文件和外部存儲。不然當容器被銷燬時，任何插入的數據也是如此。一樣，任何重要文件必須遵循一樣的限制約束。

Docker有一個很好的文檔，它解釋瞭如何運做的這方面的更多細節。
 

明智地選擇你的數據庫

我以前寫過該篇文章，因此就在這裏過多地討論了。那些領導者們會發現他們的數據庫平臺的選擇會正面或負面的影響了他們的基礎設施建設和實施的須要。有些團隊選擇了一個key/value鍵/值存儲例如Redis，他們只是認識到實現一些密鑰聚合功能所需的工做量將能夠經過選擇不一樣的數據庫來實現更好地處理。值得慶幸地是，它有多是一個小項目而且這個問題在早期就被發現。但其實我見過的項目一般不是這種狀況，它最後都花費了至關大的努力來取代最初的選擇，更糟地是，那些出現的各類問題動用了許多方法和業務中斷去解決。
 

無服務狀態是有戲的，但它不能表明一切，然而。。。

一些領導人決定探討一個純粹的無服務器架構。雖然他們可以解決許多使用無服務器方式的現代化需求，可是每每忽略了幾件事情。這些事情包括：每一個賬戶的速率限制，端點和賬戶級別使用狀況報告，以及內置的細粒度訪問控制的完整的API管理解決方案。這些和其餘功能能夠隨着時間的推移和一些代碼來克服，但大多數項目團隊指望專一於功能，而不是基礎設施的建設。

一些領導人選擇了混合使用Docker容器和無服務器的方法來部署他們的API管理層，要求服務器終究仍是要被管理的。經過選擇最佳的容器編排的方式做爲咱們的解決方案（如前所述），團隊能夠經過使用Docker和無服務器功能的組合來合併必要的基礎設施。
 

Docker已經適於生產環境了麼？

是的，Docker確定已經適於生產環境了。許多組織都意識到使用Docker所帶來的好處，像GE，ADP，等等。只要確信你肯花時間來計劃你的Docker生產環境。

 

來源：http://www.youruncloud.com/docker/1_83.html