為什么不建議把數(shù)據(jù)庫部署在Docker容器內(nèi)？

雖然將數(shù)據(jù)庫部署在 Docker 容器內(nèi)有一定的優(yōu)勢，如便于部署、遷移和擴展等，但在生產(chǎn)環(huán)境中通常不建議這么做，主要原因如下：

1、數(shù)據(jù)安全問題

不要將數(shù)據(jù)儲存在容器中，這也是 Docker 官方容器使用技巧中的一條。容器隨時可以停止、或者刪除。當容器被rm掉，容器里的數(shù)據(jù)將會丟失。為了避免數(shù)據(jù)丟失，用戶可以使用數(shù)據(jù)卷掛載來存儲數(shù)據(jù)。但是容器的 Volumes 設計是圍繞 Union FS 鏡像層提供持久存儲，數(shù)據(jù)安全缺乏保證。如果容器突然崩潰，數(shù)據(jù)庫未正常關(guān)閉，可能會損壞數(shù)據(jù)。另外，容器里共享數(shù)據(jù)卷組，對物理機硬件損傷也比較大。即使你要把 Docker 數(shù)據(jù)放在主機來存儲 ，它依然不能保證不丟數(shù)據(jù)。使用當前的存儲驅(qū)動程序，Docker 仍然存在不可靠的風險。如果容器崩潰并數(shù)據(jù)庫未正確關(guān)閉，則可能會損壞數(shù)據(jù)。

2、性能問題

大家都知道，MySQL 屬于關(guān)系型數(shù)據(jù)庫，對IO要求較高。當一臺物理機跑多個時，IO就會累加，導致IO瓶頸，大大降低 MySQL 的讀寫性能。在一次Docker應用的十大難點專場上，某國有銀行的一位架構(gòu)師也曾提出過：“數(shù)據(jù)庫的性能瓶頸一般出現(xiàn)在IO上面，如果按 Docker 的思路，那么多個docker最終IO請求又會出現(xiàn)在存儲上面?，F(xiàn)在互聯(lián)網(wǎng)的數(shù)據(jù)庫多是share nothing的架構(gòu)，可能這也是不考慮遷移到 Docker 的一個因素吧”。 針對性能問題有些同學可能也有相對應的方案來解決：

• 數(shù)據(jù)庫程序與數(shù)據(jù)分離 如果使用Docker 跑 MySQL，數(shù)據(jù)庫程序與數(shù)據(jù)需要進行分離，將數(shù)據(jù)存放到共享存儲，程序放到容器里。如果容器有異?；?MySQL 服務異常，自動啟動一個全新的容器。另外，建議不要把數(shù)據(jù)存放到宿主機里，宿主機和容器共享卷組，對宿主機損壞的影響比較大。
• 跑輕量級或分布式數(shù)據(jù)庫 Docker 里部署輕量級或分布式數(shù)據(jù)庫，Docker 本身就推薦服務掛掉，自動啟動新容器，而不是繼續(xù)重啟容器服務。
• 合理布局應用 對于IO要求比較高的應用或者服務，將數(shù)據(jù)庫部署在物理機或者KVM中比較合適。

3、網(wǎng)絡問題

• 網(wǎng)絡延遲：容器網(wǎng)絡模型雖然提供了容器之間的網(wǎng)絡通信功能，但與直接在物理機上部署數(shù)據(jù)庫相比，會引入一定的網(wǎng)絡延遲。對于對網(wǎng)絡延遲敏感的數(shù)據(jù)庫應用，如分布式數(shù)據(jù)庫或需要與其他服務進行高頻數(shù)據(jù)交互的數(shù)據(jù)庫，這種延遲可能會影響系統(tǒng)的整體性能和穩(wěn)定性。
• 網(wǎng)絡配置復雜性：配置容器內(nèi)數(shù)據(jù)庫的網(wǎng)絡訪問需要考慮多種因素，如容器網(wǎng)絡模式的選擇、端口映射、安全組設置等。錯誤的網(wǎng)絡配置可能導致數(shù)據(jù)庫無法被正確訪問，或者存在安全風險。而且，當數(shù)據(jù)庫需要與外部系統(tǒng)進行復雜的網(wǎng)絡交互時，容器網(wǎng)絡的配置和管理會變得更加困難。

4、狀態(tài)

在 Docker 中打包無狀態(tài)服務是很酷的，可以實現(xiàn)編排容器并解決單點故障問題。但是數(shù)據(jù)庫呢？將數(shù)據(jù)庫放在同一個環(huán)境中，它將會是有狀態(tài)的，并使系統(tǒng)故障的范圍更大。下次您的應用程序?qū)嵗驊贸绦虮罎ⅲ赡軙绊憯?shù)據(jù)庫。 知識點:在 Docker 中水平伸縮只能用于無狀態(tài)計算服務，而不是數(shù)據(jù)庫。Docker 快速擴展的一個重要特征就是無狀態(tài)，具有數(shù)據(jù)狀態(tài)的都不適合直接放在 Docker 里面，如果 Docker 中安裝數(shù)據(jù)庫，存儲服務需要單獨提供。

5、資源隔離

資源隔離方面，Docker 確實不如虛擬機KVM，Docker是利用Cgroup實現(xiàn)資源限制的，只能限制資源消耗的最大值，而不能隔絕其他程序占用自己的資源。如果其他應用過渡占用物理機資源，將會影響容器里 MySQL 的讀寫效率。需要的隔離級別越多，獲得的資源開銷就越多。相比專用環(huán)境而言，容易水平伸縮是Docker的一大優(yōu)勢。然而在 Docker 中水平伸縮只能用于無狀態(tài)計算服務，數(shù)據(jù)庫并不適用。我們沒有看到任何針對數(shù)據(jù)庫的隔離功能，那為什么我們應該把它放在容器中呢？

6、 運維與管理

• 監(jiān)控與管理復雜性：將數(shù)據(jù)庫部署在容器中，需要同時熟悉 Docker 和數(shù)據(jù)庫的管理工具與技術(shù)。監(jiān)控容器內(nèi)數(shù)據(jù)庫的性能指標、資源使用情況等需要額外的配置和工具，如需要結(jié)合 Docker 自帶的監(jiān)控命令和數(shù)據(jù)庫的監(jiān)控工具來全面了解數(shù)據(jù)庫的運行狀態(tài)，增加了運維的難度和成本。
• 升級與兼容性：Docker 容器的升級和更新可能會對容器內(nèi)的數(shù)據(jù)庫產(chǎn)生影響。 例如，Docker 版本的升級可能導致容器的運行環(huán)境發(fā)生變化，從而影響數(shù)據(jù)庫的兼容性。此外，數(shù)據(jù)庫自身的升級也需要謹慎處理，需要考慮容器環(huán)境對升級過程的影響，以及升級后與容器其他組件的兼容性。

7、運行數(shù)據(jù)庫的環(huán)境需求

常看到 DBMS 容器和其他服務運行在同一主機上。然而這些服務對硬件要求是非常不同的。數(shù)據(jù)庫（特別是關(guān)系型數(shù)據(jù)庫）對 IO 的要求較高。一般數(shù)據(jù)庫引擎為了避免并發(fā)資源競爭而使用專用環(huán)境。如果將你的數(shù)據(jù)庫放在容器中，那么將浪費你的項目的資源。因為你需要為該實例配置大量額外的資源。在公有云，當你需要 34G 內(nèi)存時，你啟動的實例卻必須開 64G 內(nèi)存。在實踐中，這些資源并未完全使用。怎么解決？您可以分層設計，并使用固定資源來啟動不同層次的多個實例。水平伸縮總是比垂直伸縮更好。

8、總結(jié)

針對上面問題是不是說數(shù)據(jù)庫一定不要部署在容器里嗎？答案是：并不是我們可以把數(shù)據(jù)丟失不敏感的業(yè)務（搜索、埋點）就可以容器化，利用數(shù)據(jù)庫分片來來增加實例數(shù)，從而增加吞吐量。docker適合跑輕量級或分布式數(shù)據(jù)庫，當docker服務掛掉，會自動啟動新容器，而不是繼續(xù)重啟容器服務。數(shù)據(jù)庫利用中間件和容器化系統(tǒng)能夠自動伸縮、容災、切換、自帶多個節(jié)點，也是可以進行容器化的。

閱讀原文：原文鏈接