容器與應用程序+數據庫

Question

我一直在做一些測試與碼頭，到目前爲止，我想知道爲什麼它被認爲是一個很好的做法，在兩個容器中分開數據庫和應用程序。

擁有兩個容器似乎很麻煩，我也沒有看到它的價值。 雖然我喜歡每個應用程序擁有自我可持續容器的想法。

Answer 1

一個原因是數據存儲和應用程序的分離。如果您將兩者都放在自己的容器中，則可以獨立更新它們。根據我的經驗，這是一個常見的過程，因爲通常應用程序的演變速度要比底層數據庫快。

它還釋放你在不同的地方運行容器，這可能是你的操作的一個限制。或者用不同的應用程序從同一個數據庫映像運行多個容器。

通常，將UI從一個實例擴展到多個實例（全部連接到同一個數據庫（或緩存實例或HTTP後端））也是一件好事。這在docker best practices中簡要提及。

我也理解在一個容器中運行多個進程的衝動。這就是爲什麼像s6這樣的極簡主義初始系統/管理員最近出現的原因。我更喜歡這個用於需要一些東西的應用程序的演示，例如用於前端的nginx，數據庫以及可能的redis實例。但是你也可以編寫一個基本的docker-compose file並用多個容器運行該演示。

Answer 2

這取決於你認爲你的「DB」，它是數據庫應用程序還是內容。

後者很簡單，內容需要在應用程序的生命週期之外持續存在。慣例曾經有一個「數據」容器，簡化了它與應用程序的鏈接（例如使用Docker引擎創建命令--volumes-from參數）。在Docker 1.9中，有一個新的卷API取代了「數據」容器的概念。但是，您絕不應將數據存儲在覆蓋文件系統中（如果不僅用於持久性，還用於性能）。

如果您指的是數據庫應用程序，那麼您真的與微服務人羣進入半宗教辯論。 Docker的構建是爲了運行單個進程。它爲12個因素的應用程序構建。它是爲微服務而構建的。在一個容器中運行多個進程是絕對有可能的，但是有了它你必須考慮管理/監視這些進程的額外複雜性（例如使用像supervisord這樣的初始化進程），處理日誌記錄等。

我交付了兩個。如果您正在管理容器部署（例如您正在託管應用程序），那麼使用多個容器實際上工作量較小。這使您可以將Docker的抽象層用於聯網和持久性存儲。它還可以在擴展應用程序時提供最大的可移植性（也許您可以考慮使用車隊或flocker卷驅動程序或覆蓋網絡來跨多個服務器託管容器）。如果您正在開發用於分發的產品，交付單個Docker存儲庫（使用一個映像）會更方便。這可以在您通過部署指導客戶時最大限度地降低支持成本。