MySQL 进行 Docker 容器化之体验与感悟

原则

Docker 的使用原则是所有容器化的应用程序都应该是无状态的 ，即容器内部只跑业务逻辑，容器应用的所有配置文件、日志文件和持久化数据 都应该挂载到宿主机文件系统，不应该存储在容器内部，以免容器被误删或自身出现问题导致数据丢失。

MySQL 容器化方式

MySQL 属于有状态应用，若将其容器化需将其状态抽离到宿主机，其配置文件、日志文件和持久化数据都应该挂载到宿主机。

容器内各路径

通过docker pull 命令拉取下来的官方 MySQL 镜像内，有几个重要路径：

• 配置文件
• 镜像内 MySQL 的配置文件路径为/etc/mysql ，路径下包含my.cnf 配置和一个conf.d 文件夹，my.cnf 文件内是一些base setting ，我们自定义的配置应该写在conf.d 文件夹下的配置文件里，从而覆盖base setting 。conf.d 文件夹下默认有两个配置文件：docker.cnf 和mysql.cnf ，在后文所讲的挂载配置路径到宿主机之后，应将这两个用户自定义配置文件拷贝到宿主机配置路径下。
• 持久化数据
• 镜像内 MySQL 的持久化数据均存储在/var/lib/mysql 下。

命令

$ docker run 
 --name db 
 -e MYSQL_ROOT_PASSword=secret 
 -v /path/to/confdir:/etc/mysql/conf.d 
 -v /path/to/datadir:/var/lib/mysql 
 -d
 mysql:tag

参数解释

• --name 容器名称
• -e 为新容器设置环境变量，容器内 MySQL 会以此初始化 root 用户密码
• -v 两个-v 参数分别将容器内 MySQL 的自定义配置文件目录和持久化数据目录挂载到宿主机，冒号前为宿主机目录，后为容器内目录
• -d 后台启动容器

小技巧

我们可以在宿主机专门建立一个目录用来存放容器状态数据，层级结构为：

docker-container-data
 |
 - container1
 | |
 | - conf
 | |
 | - logs (其下又可以细分路径)
 | |
 | - data
 |
 - container2
 |
 - container3
 |
 ...

灾难措施

将状态数据挂载宿主机的好处就是如果容器发生问题，可以启动一个新容器并将容器状态路径挂载到宿主机上的原状态路径，从而恢复生产。

可以直接将新启动的 MySQL 容器的配置和持久化数据挂载到之前容器的宿主路径，新容器便可以无缝恢复数据（配置、用户、库、表、记录均恢复）。

注意事项

• 不可以将两个均在运行的容器的状态路径挂载到同一个宿主路径 ，两个容器同时在一个宿主路径下写状态，容器应用读取状态时会无法识别，导致崩溃。
• 若新启动的容器要挂载之前容器的宿主数据路径，则会忽略-e MYSQL_ROOT_PASSWORD=foo 命令参数所设定的 root 用户密码环境变量，因为挂载的数据路径下已经包含了 MySQL 用户信息表，而 root 用户的密码之前已经被设定过了。