資料庫部署在容器中不行嗎？
通過數據卷的方式把容器中的資料庫持久化到宿主機的存儲上，這樣跟部署在宿主機上基本上沒有區別了。為什麼還有資料庫不適合部署在容器中的說法？
行
可以，特別是集羣部署，可以利用 k8s 方便實現動態擴容收縮監控等。性能問題網路走 host，磁碟直接 local 即可，要的是方便管理而不是死磕 web 集羣的容器部署模式
另一方面 oracle cloud 都在走容器模式，雖然沒用過
不建議！
原因：
1、數據安全問題
不要將數據儲存在容器中，這也是 Docker 官方容器使用技巧中的一條。容器隨時可以停止、或者刪除。當容器被rm掉，容器裏的數據將會丟失。為了避免數據丟失，用戶可以使用數據卷掛載來存儲數據。但是容器的 Volumes 設計是圍繞 Union FS 鏡像層提供持久存儲，數據安全缺乏保證。如果容器突然崩潰，資料庫未正常關閉，可能會損壞數據。另外，容器裏共享數據卷組，對物理機硬體損傷也比較大。
即使你要把 Docker 數據放在主機來存儲 ，它依然不能保證不丟數據。 Docker volumes 的設計圍繞 Union FS 鏡像層提供持久存儲，但它仍然缺乏保證。
使用當前的存儲驅動程序，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 網路，您必須對網路虛擬化有深入的瞭解。也必須準備應付好意外情況。你可能需要在沒有支持或沒有額外工具的情況下，進行 bug 修復。
我們知道：資料庫需要專用的和持久的吞吐量，以實現更高的負載。我們還知道容器是虛擬機管理程序和主機虛擬機背後的一個隔離層。然而網路對於資料庫複製是至關重要的，其中需要主從資料庫間 24/7 的穩定連接。未解決的 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服務掛掉，會自動啟動新容器，而不是繼續重啟容器服務。
資料庫利用中間件和容器化系統能夠自動伸縮、容災、切換、自帶多個節點，也是可以進行容器化的。
作者：IT實戰聯盟
鏈接：https://www.toutiao.com/i6805798581971190276/
侵刪
這些問題一般不用「行/不行「來二元化的回答，而是考慮哪種方式更合適。
就我個人的建議是，業務服務部署到容器中，持久化層（資料庫、文件存儲、隊列等），盡量直接用雲服務廠商提供的服務，雖然會貴點，但是更省心，可用性更有保障。
現在的容器化的服務，多數是希望Stateless的，即容器化的應用本身不存儲狀態，也應該能夠快速啟動、優雅退出。這些恰恰是資料庫服務不擅長的，資料庫服務更希望能夠長期穩定的運行，每次啟動退出還需要各種狀態的檢查處理。
都什麼年代了，你看哪家伺服器多的公司不用k8s？還有不放容器裏的服務嗎？
數據不能部署在容器，主要是古早期間，大家對於容器的不信任傳出來的。
當然，生產上面，真把資料庫放容器運行，也是勇士。
為啥資料庫在生產上面不適合放入容器使用，一來生產環境是相對穩定的環境，容器最大的作用是快速部署，而生產並不需要這種功能，資料庫也很少進行迭代，而且資料庫基本單機單用，既然不需要任何隔離，當然直接在宿主機部署更為方便。
那麼，資料庫一定不能在容器上面嗎？肯定也不是，且不說docker原生就支持volume本地目錄或者自定義卷，你甚至可以通過修改容器的啟動腳本和鏡像，mount一個NFS文件服務進去，也是一種固化數據的方法。
可以的，不過資料庫是有狀態服務，需要存儲數據，可以用類似glusterFS這種存儲系統。或者直接Local PV，之前看到過一篇博客稱阿里的雲原生有用過Local PV方式存mysql數據。但用了這種Local方式還需要考慮動態劃分之類的問題。而且容器的漂移也是要考慮。
可以~
比如一鍵啟動MySQL 5.6
docker run --name mysql56
-v /mnt/mysql56:/var/lib/mysql
-v /mnt/mysql56confd:/etc/mysql/conf.d
-p 3308:3306 -e MYSQL_ROOT_PASSWORD=123456 -d mysql:5.6
肯定行。切記做好備份，印象中有一次把容器刪了，裡面的數據也搞丟了
可以是可以，好處就是你把鏡像和docker裝好之後。dockercompose可以直接幫你快速的部署你想要的東西，替換數據也方便。但是缺點也明顯，庫掛了就掛了，沒招。容器掛了就忍著，也沒招。而且，你包的層越多，需要的資源越多。
推薦閱讀：
