docker 使用 mysql 时选择新建 mysql 容器还是单一容器内新开 mysql 进程？
tafee · 2017-04-25 14:18:20 +08:00 · 6347 次点击这是一个创建于 2768 天前的主题，其中的信息可能已经有所发展或是发生改变。
看了网络上的两种在 docker 中使用 mysql 的方法： 1 、新建 mysql 容器，利用 docker-compose 或者其他编排工具与运行程序的容器 link ； 2 、在单一 docker 容器中，利用 supervisord 创建 mysql 进程和程序进程；
V 友们如何选择的？这两种方案的优缺点在哪儿？ 个人感觉第二种方案已经失去了 docker 容器化的意义。。。
 |
1
xi4oh4o 2017-04-25 14:25:41 +08:00
|
 |
2
windfarer 2017-04-25 14:48:45 +08:00  1
别在 docker 上跑数据库，会被坑死的
|
 |
3
araraloren 2017-04-25 15:19:38 +08:00
~~ 感觉 数据库跑在 container 里各种不顺利
还是搁在外面好 |
 |
4
latyas 2017-04-25 15:31:25 +08:00 via Android
别在 docker 里跑数据库，会被坑死的
|
 |
6
debye 2017-04-25 15:52:31 +08:00
别在 docker 里跑数据库，会被坑死的
|
 |
7
jarlyyn 2017-04-25 15:59:26 +08:00
docker 跑数据库有什么问题。
博客不论，我公司的 gitlab owncloud 数据库都在 Docker 里啊 |
 |
8
tafee OP 大家都说会被坑死，具体是有哪些坑呢
|
|
9
jarlyyn 2017-04-25 16:03:39 +08:00
我目前在 docker 中跑过的数据库包括
mysql (for blog/owncloud) postgresql(for gitlab) redis 可能运气好，暂时还没被坑到 |
 |
10
Bardon 2017-04-25 16:11:36 +08:00
data 不会放容器里，放在其他专有目录
容器里运行数据库程序进程，通过 -v 去读写 data 目录 |
 |
11
sunjourney 2017-04-25 16:12:19 +08:00 via iPhone
想问哪些坑，我的网站、论坛都跑在 docker 里，几个月了都没问题，有什么隐患？
|
 |
12
Miy4mori 2017-04-25 16:16:40 +08:00 via iPhone
完全不懂说被坑的是怎么回事，莫非没用官方镜像自己 build 出了问题？
|
|
13
Bardon 2017-04-25 16:22:02 +08:00 2
想起了昨天有个人说，重启容器数据没了，于是说 docker 的不好的梗 ^_^
|
 |
14
xyjtou 2017-04-25 16:40:10 +08:00 via Android 1
数据库不舍得单独买服务器也就算了，还放 docker 里，这是图个啥呢，又不是需要 docker 容器横向扩容。
|
|
15
jarlyyn 2017-04-25 16:45:49 +08:00
|
|
16
jarlyyn 2017-04-25 16:48:04 +08:00
|
 |
17
junnplus 2017-04-25 16:51:20 +08:00
搞不懂楼上在喊“别在 docker 里跑数据库，会被坑死的”的原因在哪，现在有些云厂商提供的 rds 都是跑在 docker 上的，压根没啥坑，当然你把数据放在容器里面能怪 docker 。。。
|
 |
19
ohhe 2017-04-25 16:52:31 +08:00
当然第一种方案了。
程序和数据库分开比较好。因为数据库一般单独运行。程序可能需要负载均衡之类。 |
|
20
ohhe 2017-04-25 16:54:06 +08:00
不过不是对外提供数据库服务的话。确实数据库没必要放 docker 里面。不方便管理数据库啊。
|
|
22
xyjtou 2017-04-25 16:58:21 +08:00 via Android
@jarlyyn 数据库要什么环境一致？生产机的数据库优化方案在开发机上根本没必要搞，搞了没哪个数据量级也没用。
|
|
23
jarlyyn 2017-04-25 16:58:30 +08:00
@windfarer
顺便， 1 楼的链接，假设他是最原始的链接，上一片文章是 https://myopsblog.wordpress.com/2017/01/02/20-things-ive-done-in-2016/#more-1987 2016 年完成的 20 件事，嗯嗯， |
|
24
jarlyyn 2017-04-25 16:59:43 +08:00
|
 |
28
cxbig 2017-04-25 17:12:04 +08:00 1
Docker 的理念就是一个服务独占一个容器。所以 MySQL 要独立开一个。
目前的测试感受，用 Docker 跑 MySQL ，无论是内置 volume 还是 mount 到 host 文件夹，性能都远不如直接装 MySQL 来得快。 我司一个 dump ， gzip -9 压缩大概 1G 上下，导入速度参考： AWS RDS m4.large 25mins AWS EC2 m4.large Ubuntu 16.04 Apt 安装 30mins MBP 13 寸 13 年款 Brew 安装 40~50mins MBP 13 寸 13 年款 Docker App 4core 8g 内置 volume 3hrs 20mins MBP 13 寸 13 年款 Docker App 4core 8g host 挂载 volume 4~5hrs |
|
30
cxbig 2017-04-25 17:17:08 +08:00
|
|
32
jarlyyn 2017-04-25 17:20:57 +08:00
|
|
34
jarlyyn 2017-04-25 17:26:56 +08:00
|
 |
35
lightening 2017-04-25 17:29:44 +08:00
只好会配置，数据库跑在 Docker 里也是没什么问题。但是配置比较麻烦。
如果用 swarm ，怎么配置多个 replica ？怎么配 cross-machine volume ？ 如果 docker 占了全部硬盘空间，要清理，不小心一条命令删了 volume 也是很有可能的事情。 这些问题只要会配都没问题，但是就怕不熟练不小心搞错不是么。 @cxbig Mac 上的 Docker 是运行在虚拟机里的啊，你这么看到的是虚拟机的性能开销。找个 Linux 机器试试。 |
|
36
cxbig 2017-04-25 17:35:06 +08:00
@lightening 在 EC2 上试过， I/O 性能上不如 RDS 。
|
|
37
cxbig 2017-04-25 17:41:27 +08:00 1
另外 Docker Image 有 Layer 的因素，碎片文件特别多，对 inode 敏感的机器也是不小的压力。
AWS EC2 开过 32G 的 General Purpose SSD (GP2)，只分配了 2M 的 inode ，仅仅只是 pull 了几个常用的 image 就吃掉了 80%的 inode 。用了 5G 空间就报 No space left on device 。 |
 |
38
HypoChen 2017-04-25 18:10:24 +08:00 1
其实并没有什么争论的，至于是不是坑，我只能说，任何软件，工具，轮子都可能被用成坑
首先容器会降低性能，毋庸置疑，无论 网络 还是 磁盘 io ， docker 慢众所周知，但是他部署扩容快啊，看你取舍喽。当然包括上面说 Image 对磁盘的压力，是另一方面，毕竟数据库镜像不经常更新 Layer 。 然后就是把数据库放容器里，因为数据库的特殊性（存储数据以及版本不经常变动），我一般是不建议把这东西放容器里的。 首先是数据问题， docker 并不建议把数据放在容器里，并有了 volume ，数据库这种数据优先的程序更是，无论是把数据放在 volume 还是其他 driver ，都徒增对这些数据的管理（以及风险），而这些管理却一定程度上依赖了 docker 。 然后就是 docker 引入的问题，无论什么数据库，现在的解决方案是非常完善的，但是引入 docker 之后，在一定程度会受到 docker 的影响，比如 daemon 挂了而你恰好要要对数据库这个容器操作，你是打算先修 docker 呢 还是先修 docker 呢。 总之呢， mysql 放在容器里说白了也不过就是一个文件夹的数据和一个进程而已，如果处理的好（对 docker 很熟，没有人为失误）而且运气足够好（遇不到 docker 的 bug ），而且对性能要求不大，那么放哪都一样，怎么喜欢怎么来。 啥？你只是把容器里的 data 目录映射到了宿主机提供数据库服务？我认为你用的是假 Docker 。 |
|
39
HypoChen 2017-04-25 18:15:30 +08:00
不过扯回楼主的主题， docker 建议是单一进程的，也就是这一个容器里只跑一个进程。也就是第一个选择更好一些。
原因很简单，比如这个唯一进程挂掉了，容器也就挂掉了， docker 可以很方便的发现这点并进行后续操作，比如 restart 。 |
|
40
jarlyyn 2017-04-25 18:17:50 +08:00
@HypoChen
“然后就是 docker 引入的问题，无论什么数据库，现在的解决方案是非常完善的，但是引入 docker 之后，在一定程度会受到 docker 的影响，比如 daemon 挂了而你恰好要要对数据库这个容器操作，你是打算先修 docker 呢 还是先修 docker 呢。 ” 不是应该把 data 文件夹 cp 出来 /通过别的方式挂载使用么…… “然后就是 docker 引入的问题，无论什么数据库，现在的解决方案是非常完善的，但是引入 docker 之后，在一定程度会受到 docker 的影响，比如 daemon 挂了而你恰好要要对数据库这个容器操作，你是打算先修 docker 呢 还是先修 docker 呢。 ” 这句话没看懂。 数据库进 docker 不是应该 -v 配置文件夹和数据文件夹的吗？ |
 |
41
Zzzzzzzzz 2017-04-25 18:23:50 +08:00
|
 |
42
hugo775128583 2017-04-25 18:27:02 +08:00 via Android
docker 跑数据库， data 映射到宿主机没问题。但是多个容器读写竞争怎么处理？
|
|
43
jarlyyn 2017-04-25 18:29:52 +08:00
对了，回到楼主的问题。
我跑 Docker 一般是建一个 subnet 每个服务分配一个内网 ip 直接用内网 Ip+端口访问 以 mysql 为例，大概是这样 docker run --network=vps --ip=10.1.1.2 --name mysql -v /dockers/mysql/data:/var/lib/mysql -v /dockers/mysql/conf:/etc/mysql -e MYSQL_ROOT_PASSWORD=123456 -d --restart always mysql |
|
44
HypoChen 2017-04-25 18:30:45 +08:00 2
@jarlyyn
你说的没错，但是这些是建立在单机应用上的，可以简单的把里面的数据文件夹随便映射到宿主机上一个地方，然后保管好宿主机上这个文件夹就可以了 但是，如果只是这样使用的话是不是和不用 docker 一样，和直接在宿主机上装一个 sql 并保护好本地的文件夹没什么区别。 如果要把文件挂主机上，那么有几个问题怎么做，如果这个机器挂了，我的容器需要快速迁移到别的机器上，如果文件在这个机器上，当机器挂了之后数据是不是就不能用了，当然，你可以提前备份，但是这样是不是和不用 docker 的姿势是一样的。或者说我需要扩容，而且是扩容到多台机器上做高可用，是不是这样并不能算方便快捷。 docker 本来就是是的复杂场景变得方便而有了价值，在面对复杂场景的时候，并不是一个简答的 -v 加一个宿主机文件夹就能解决的。但是换句话说，如果需求很简单，怎么方便怎么了喽 |
|
45
jarlyyn 2017-04-25 18:35:39 +08:00
@HypoChen
docker 最开始不就是提供了一个 namespace 和一个网络配置么…… 我也一直把 docker 当成一个单进程的运行环境来用的…… 主要看中 docker 的迁移 /独立的版本控制 /相对独立的环境。 看来是我用的太浅了…… 机器挂了的问题不是该由数据库的主从同步来处理么。 这里对比的是 使用 docker 和使用原声环境安装进程吧？ 你提的问题原生环境直接安装也没办法解决啊。 |
 |
46
mobyride 2017-04-25 18:35:50 +08:00
只能说看需求，追求性能肯定不放 docker ，追求部署简便放 docker （单独放一个）
|
|
47
jarlyyn 2017-04-25 18:37:52 +08:00
@HypoChen
再比如机器挂了的问题。 如果是真机挂了，不是应该直接拆硬盘挂到别的跑了同样 Docker 的机器上处理。 而如果是各种云服务，就是开新的计算单元，装好 docker 把云磁盘架过去…… 我对 docker 的理解只有这么浅。 |
|
48
lightening 2017-04-25 19:39:42 +08:00
@cxbig 也试一下 EC2 上 apt-get 裸装吧。感觉不一定是 Docker 的问题。
|
|
49
Bardon 2017-04-25 19:45:47 +08:00
你们讨论那么多，我算是明白了
数据究竟该不该存镜像内？假 docker ？ 总有种为了 docker 而 docker 的即视感。 |
 |
50
gdtv 2017-04-25 19:59:27 +08:00
|
|
52
cxbig 2017-04-25 20:38:26 +08:00
@gdtv 取决于你在什么环境部署你的项目，如果你有自己的物理服务器，性能不算差。
就目前我用过的 AWS EC2 、 Linode 、 DigitalOcean 这几家的都不理想。 当然测试仅限于小型 VPS ， 4 核 16G Ram 左右。大型独占的没有试过。 |
|
53
Bardon 2017-04-25 20:51:10 +08:00
|
|
55
Bardon 2017-04-25 21:11:35 +08:00 1
linux 下本来就是基于进程级的，负载差别基本就看 IO 以及内存差别了
当然，容器与宿主机文件系统不同， Volume 挂载后磁盘 IO 会造成很大的差别... |
|
56
Bardon 2017-04-26 09:32:01 +08:00
说错了， docker 利用的一种类似图层形式的文件系统，使得读写在不同的层次上
所以上面说错了，不存在 docker 与宿主机的文件系统不同。 IO 差别，反而在 aufs,overlay,btrfs 与 devicemapper 之间，以及不同层上读写的差距了。 |
|
57
Bardon 2017-04-26 09:42:49 +08:00
目前， overlay 人气较高， gentoo 下可以直接选择 overlay 这个 use flag 来使得 docker 采用 overlayfs
centos 下还是 devicemapper ，需要一些技巧才能采用 overlayfs deb 系的没用过，不知道 具体 docker info | grep Driver 查看。 |
|
58
jarlyyn 2017-04-26 09:56:51 +08:00
|
 |
59
oop99 2017-04-26 12:49:06 +08:00
单一容器只运行单一的服务, 减小耦合度
自己 MySQL docker 没遇到过问题 |
 |
60
wangxiaodong 2017-04-26 13:46:03 +08:00
docker 初衷是隔离应用程序的不同版本及灵活编排程序运行环境，避免互相干扰，同时让操作系统版本依赖更少、更稳定；至于数据目录放哪里及性能损耗，可以按 2/8 原则来分析，并不是每个项目都需要全负荷的运作，满足 80%以上场景即可。
如果非要钻牛角尖，你何止不需要用 docker ，完全可以不用数据库啊，直接 io 写数据到硬盘即可，这样性能肯定比经过数据库运算解析后再存储要高很多。 |
Select Language