看到網路上一片文章說：資料庫不適合Docker及容器化？
文章連結
剛開始用docker，有點疑惑？
phpcn_u15822017-04-27 09:03:42
關於資料庫不適合放在docker裡面，有兩個歪果仁的文章，其一就是樓主所貼，其二是這篇，譯文
還是那個觀點：
量小的時候隨便搞，量大了有些東西就不行了，傳統型數據庫和docker並不對路，建議不要直接容器化，非要把數據庫容器化，那麼需要各種系統的支撐，包括中間件系統、容器化系統。
如果你的資料庫能夠自動伸縮、容災、切換、自帶多節點解決方案等，docker算是比較好的方案。
但是如果不能，還是不要用docker。
原文也說得很清楚：
在 Docker 中水平伸缩只能用于无状态计算服务，而不是数据库。流量小的情況下，什麼東西容器化都行。資料庫，應用，hadoop，各種節點，nginx。
量大的情況下，儲存相關的不適合容器化，應用層、業務層等無狀態的服務適合容器化，快取這類記憶體密集的服務可以容器化。
簡單來說就是三個問題，容災、效能和資料一致性。
就mysql這種傳統資料庫而言，光是我所能列出來的問題就有如下這麼多：
mysql怎麼容器化？
主庫mysqld跪了怎麼辦？
主庫dockerd跪了怎麼辦？
從庫mysqld跪了怎麼辦？
從庫dockerd跪了怎麼辦？
能否在高峰來臨之際透過容器快速擴容mysql？方案？
資料主從切換方案？一致性如何保證？
高峰時期量夠大，有時候一般一台實體機的容量只夠一個mysql進程。
那麼同樣是單一機器，為什麼不能直接啟動mysql？
為什麼還要外面套一層容器？對性能損耗多少？
mysql如何升級？
資料卷是否會遺失資料？ （損壞容器我遇過很多次了…）
但是mysql也不是全然不能容器化。
對資料遺失不敏感的業務（例如京東搜尋搜到的商品）就可以資料化，利用資料庫分片來實現透過增加實例數增加吞吐量。
題主原文中提到的問題，有些東西是有槽點的，但是考慮的很周全。例如以下問題就很有槽點（關於共享資料目錄）：
容易水平伸缩？是否要在多个实例之间共享数据目录？你不害怕直接数据并发问题和可能的数据损坏吗？使用专用数据环境部署多个实例不会更安全吗？最后搞一个主从复制？就我目前接觸到的資料庫來看，只有cassandra這類（個）（還有tidb和cockroachdb，但是目前還沒遇到大公司的用例）資料庫適合容器化。
但是cassandra本身也接近是無狀態了：自己提供容災，擴容，切換方案。
以下提一下京東。
京東是個異類，但是京東也提到類似的問題和需要注意的地方。
计算类应用、无状态应用优先，例如微服务特别容易迁移到弹性云。
应用迁移到弹性云，最好选择统一的规格，避免各个实例的负载不均衡。
应用从物理机迁移到弹性云后，实例数量会增加，相应对后端服务的连接数会增加，特别是数据库连接，所以需要防止连接过载。
在弹性云上共享磁盘IO，要避免应用刷日志，减少本地读写文件，采用JFS或JIMDB来满足文件存储或共享数据需求。
容器的CPU核数原低于原有物理机的核数，应用需要根据CPU核数来合理地配置线程数和网络参数。
修改底层，让应用在运行时能准确地拿到自身容器的核数。甚至，對docker做了很多的客製化。
可以看京東分享。
伊谢尔伦2017-04-27 09:03:42
不適合, 而不是不能.
如果單機沒什麼問題, 在某些情況下還是有利的. 例如之前我公司的oracle資料庫調參數時導致資料庫崩潰徹底起不來了, 還好那時用的是docker, 直接run一個, 把資料目錄指向原來的就好了.
集群的話不管怎麼樣, 用docker手工組, 或swarm這類工具也好, 都不太好搞. 還不如直接在物理機上搭建省事.
國外有家公司就是專屬docker的資料儲存方案的. 例如flocker, 還有rancher的convoy
PHPz2017-04-27 09:03:42
docker放更適合無狀態，不會變更服務。
如大量的集群時：
編寫好docker file。然後當程式碼上傳到程式碼倉庫的後，然後部署讓好docker file以後，再讓發布腳本批次建置docker服務並將服務程式碼放進去。
不只是MySQL，類似redis，mc都不適合放入docker中，或是說放把資料庫放docker中有為了使用docker而這樣做，並沒有太多的好處。