資料庫安全：為什麼不建議把資料庫部署在Docker容器内

近2年Docker非常的火熱，各位開發者恨不得把所有的應用、軟體都部署在Docker容器中，但是您确定也要把資料庫也部署的容器中嗎？這個問題不是子虛烏有，因為在網上能夠找到很多各種操作手冊和視訊教程，這裡整理了一些資料庫不适合容器化的原因供大家參考，同時也希望大家在使用時能夠謹慎一點。目前為止将資料庫容器化是非常不合理的，但是容器化的優點相信各位開發者都嘗到了甜頭，希望随着技術的發展能夠更加完美的解決方案出現。

Docker不适合部署資料庫的7大原因

1、資料安全問題

不要将資料儲存在容器中，這也是 Docker 官方容器使用技巧中的一條。容器随時可以停止、或者删除。當容器被rm掉，容器裡的資料将會丢失。為了避免資料丢失，使用者可以使用資料卷挂載來存儲資料。但是容器的 Volumes 設計是圍繞 Union FS 鏡像層提供持久存儲，資料安全缺乏保證。如果容器突然崩潰，資料庫未正常關閉，可能會損壞資料。另外，容器裡共享資料卷組，對實體機硬體損傷也比較大。即使你要把 Docker 資料放在主機來存儲 ，它依然不能保證不丢資料。使用目前的存儲驅動程式，Docker 仍然存在不可靠的風險。如果容器崩潰并資料庫未正确關閉，則可能會損壞資料。

2、性能問題

大家都知道，MySQL 屬于關系型資料庫，對IO要求較高。當一台實體機跑多個時，IO就會累加，導緻IO瓶頸，大大降低 MySQL 的讀寫性能。在一次Docker應用的十大難點專場上，某國有銀行的一位架構師也曾提出過：“資料庫的性能瓶頸一般出現在IO上面，如果按 Docker 的思路，那麼多個docker最終IO請求又會出現在存儲上面。現在網際網路的資料庫多是share nothing的架構，可能這也是不考慮遷移到 Docker 的一個因素吧”。

針對性能問題有些同學可能也有相對應的方案來解決：

(1)資料庫程式與資料分離

如果使用Docker 跑 MySQL，資料庫程式與資料需要進行分離，将資料存放到共享存儲，程式放到容器裡。如果容器有異常或 MySQL 服務異常，自動啟動一個全新的容器。另外，建議不要把資料存放到主控端裡，主控端和容器共享卷組，對主控端損壞的影響比較大。

(2)跑輕量級或分布式資料庫

Docker 裡部署輕量級或分布式資料庫，Docker 本身就推薦服務挂掉，自動啟動新容器，而不是繼續重新開機容器服務。

(3)合理布局應用

對于IO要求比較高的應用或者服務，将資料庫部署在實體機或者KVM中比較合适。目前TX雲的TDSQL和阿裡的Oceanbase都是直接部署在實體機器，而非Docker 。

3、網絡問題

要了解 Docker 網絡，您必須對網絡虛拟化有深入的了解。資料庫需要專用的和持久的吞吐量，以實作更高的負載。未解決的 Docker 網絡問題在1.9版本依然沒有得到解決。把這些問題放在一起，容器化使資料庫容器很難管理。你需要花多少時間解決 Docker 網絡問題？将資料庫放在專用環境不會更好嗎？節省時間來專注于真正重要的業務目标。

4、狀态

在 Docker 中打包無狀态服務是很酷的，可以實作編排容器并解決單點故障問題。但是資料庫呢？将資料庫放在同一個環境中，它将會是有狀态的，并使系統故障的範圍更大。下次您的應用程式執行個體或應用程式崩潰，可能會影響資料庫。知識點:在 Docker 中水準伸縮隻能用于無狀态計算服務，而不是資料庫。Docker 快速擴充的一個重要特征就是無狀态，具有資料狀态的都不适合直接放在 Docker 裡面，如果 Docker 中安裝資料庫，存儲服務需要單獨提供。目前，TX雲的TDSQL(金融分布式資料庫)和阿裡雲的Oceanbase(分布式資料庫系統)都直接運作中在實體機器上，并非使用便于管理的 Docker 上。

5、資源隔離

資源隔離方面，Docker 确實不如虛拟機KVM，Docker是利用Cgroup實作資源限制的，隻能限制資源消耗的最大值，而不能隔絕其他程式占用自己的資源。如果其他應用過渡占用實體機資源，将會影響容器裡 MySQL 的讀寫效率。需要的隔離級别越多，獲得的資源開銷就越多。相比專用環境而言，容易水準伸縮是Docker的一大優勢。然而在 Docker 中水準伸縮隻能用于無狀态計算服務，資料庫并不适用。我們沒有看到任何針對資料庫的隔離功能，那為什麼我們應該把它放在容器中呢？

6、雲平台的不适用性

大部分人通過共有雲開始項目。雲簡化了虛拟機操作和替換的複雜性，是以不需要在夜間或周末沒有人工作時間來測試新的硬體環境。當我們可以迅速啟動一個執行個體的時候，為什麼我們需要擔心這個執行個體運作的環境？這就是為什麼我們向雲提供商支付很多費用的原因。當我們為執行個體放置資料庫容器時，上面說的這些便利性就不存在了。因為資料不一緻，新執行個體不會與老執行個體相容，如果要限制執行個體使用單機服務，應該讓 DB 使用非容器化環境，我們僅僅需要為計算服務層保留彈性擴充的能力。

7、運作資料庫的環境需求

常看到 DBMS 容器和其他服務運作在同一主機上。然而這些服務對硬體要求是非常不同的。資料庫（特别是關系型資料庫）對 IO 的要求較高。一般資料庫引擎為了避免并發資源競争而使用專用環境。如果将你的資料庫放在容器中，那麼将浪費你的項目的資源。因為你需要為該執行個體配置大量額外的資源。在公有雲，當你需要 34G 記憶體時，你啟動的執行個體卻必須開 64G 記憶體。在實踐中，這些資源并未完全使用。怎麼解決？您可以分層設計，并使用固定資源來啟動不同層次的多個執行個體。水準伸縮總是比垂直伸縮更好。

總結

針對上面問題是不是說資料庫一定不要部署在容器裡嗎？答案是：并不是我們可以把資料丢失不敏感的業務（搜尋、埋點）就可以容器化，利用資料庫分片來來增加執行個體數，進而增加吞吐量。docker适合跑輕量級或分布式資料庫，當docker服務挂掉，會自動啟動新容器，而不是繼續重新開機容器服務。資料庫利用中間件和容器化系統能夠自動伸縮、容災、切換、自帶多個節點，也是可以進行容器化的。

連結：http://l.wz2.in/0AC
作者：梅西愛騎車

IT技術分享社群
個人部落格網站：https://programmerblog.xyz

文章推薦程式員效率：畫流程圖常用的工具程式員效率：整理常用的線上筆記軟體遠端辦公：常用的遠端協助軟體，你都知道嗎？51單片機程式下載下傳、ISP及序列槽基礎知識硬體：斷路器、接觸器、繼電器基礎知識