本人最近在使用docker部署mysql时，在持久化mysql数据时遇到了一个有趣的问题，将排查过程及思考记录在这里，以备后查。

先简单描述下我遇到的问题：在mysql容器中创建了两个数据库，然后使用docker commit想要保存容器的修改为新的镜像，发现只保存下来了新建的一个数据库，而另一个并没有被保存下来。最终通过查看docker文档和自己的实验，发现是mysql镜像中指定了volume为mysql数据路径所致。

具体讲一下我遇到的问题及排查过程：首先我从dockerHub里拉取了最新的mysql镜像来部署

docker pull mysql

然后基于这个镜像创建一个容器

docker run --name mysqldock -e MYSQL_ROOT_PASSWORD=admin -e MYSQL_DATABASE=inst1 -d -p 3066:3066 mysql

这里的MYSQL_ROOT_PASSWORD指定了root账号的密码，MYSQL_DATABASE指定了在容器创建时同时创建的数据库命。MYSQL_DATABASE可以不提供，这样不会预创建数据库。创建好名为mysqldock的容器后，使用

docker exec -it mysqldock bash

进入容器，执行mysql客户端命令，查看mysql的库，发现inst1已经建好：

inst1在容器初始化的时候已经创建

然后手动创建数据库inst2，并且在两个库中创建一些表：

手动创建inst2及两个库中的表

这时，我想把目前为止对mysqldock容器做的变更保存下来，所以就想到了使用docker commit指令

docker commit mysqldock

docker commit 命令会将docker容器的变更保存下来，并且生成新的镜像。生成新的镜像后，我想看看之前创建的库和表还在不在，就使用新的镜像创建了新的容器mysqlnew，并且进入容器查看mysql情况，神奇的现象出现了，mysql中竟然只有inst1库，而没有inst2，同时inst1里面是空的，我们创建的表也消失了：

消失了的inst2和表

这就让我疑惑了，查看了下docker commit命令的说明：

docker commit 说明

没毛病啊，基于容器的变化创建一个新的镜像。为了验证docker commit 命令的可用性，我在mysqldock中创建一个新的文件，再commit成新镜像，再创建容器，查看发现新的容器的确是包含了新创建的文件，也就是说docker commit的确能够基于容器的变化创建新的镜像：

新建文件出现在了新的镜像中

那我就丈二和尚摸不着头脑了，为啥新建的文件可以保存下来，新建的库就不行呢，新建的库不也是在mysql数据文件路径下新建的文件么？是时候求助官方文档了，查阅了docker commit的官方文档说明后，发现了在扩展说明中有这么一句话：

The commit operation will not include any data contained in volumes mounted inside the container.

意思是commit操作并不会包含容器内挂载数据卷中的数据变化。难道是因为mysql容器的挂载数据卷引起的？（这里我就要吐槽一下了，docker --help好歹详细点啊，这么重要的信息竟然都没有显示。）通过

docker inspect mysqlsock

查看mysqldock的属性，发现Mounts里有这样的信息：

Mounts

这说明了这个容器将容器内的/var/lib/mysql路径作为volume挂载。查看容器内的该路径发现的确是mysql数据库的数据文件，这点在mysql的dockerHub主页也能发现：

/var/lib/mysql下的数据

我马上试了一下在该文件下新建一个文件，并且docker commit，然后用新的镜像创建新容器，文件果然不见了！

那么问题来了，学习挖掘机到底哪家强?为何commit之后inst2没有了，但inst1还在？深究起来，连mysql root密码也没有变，还是之前设置的admin。发现没有？数据库inst1及root密码都是我在创建mysqldock容器时通过-e参数指定的，莫非是在容器创建时通过-e创建的，就算是在volume里的也可以保存么？继续研究docker commit命令的官方文档，在扩展说明里发现了这么一句：

It can be useful to commit a container’s file changes or settings into a new image.

看到了么，file changes or settings。文件变更和设置，-e的不就是设置么，这点也可以通过docker inspect发现，在Config下的Env参数中：

mysqldock和mysqlnew有一样的env参数

这么说就说得通了，虽然文件的确是发生了变化，但是由于文件是在容器挂载的数据卷中，所以这些变化没有被commit，然而由于在创建mysqldock容器的时候设置了-e参数，这些设置被容器保留了下来，commit命令使用这些设置构建了新的镜像。排查到这里，我们的问题是找到原因了，可怎么解决呢？我们该如何将mysql docker中修改的数据保存下来呢？通过查看mysql dockerHub主页Where to Store Data一节中的说明，我们可以通过docker提供的数据挂载来实现。

docker的数据挂载分为三种，volume, bind mount和tmpfs，关于三种的具体说明，强烈推荐大家看一下官网的文档。这边简单说明一下：
volume是由docker默认及推荐的挂载方式，volume由docker直接管理，同一个volume可以共享给多个容器使用，volume和容器的生命周期完全独立，容器删除时volume仍然存在，除非使用docker volume相应命令删除volume；缺点是volume在宿主机上比较难定位，在宿主机上直接操作volume比较困难。
bind mount是直接将宿主机文件系统上的文件路径映射到容器中，两边双向同步，显而易见，有缺点也有优点，优点是可以直接访问，也可以被别的程序使用，比如我们打包一个本地应用到本地/target路径，我们就可以把这个路径使用bind mount的方式挂在到依赖他的应用的docker容器中，这样本地应用打包后，docker里的数据卷也会同时更新；缺点也是显而易见的，因为你可以把任何文件路径使用bind mount的方式绑定到容器中，这样有可能一些安全问题，比如把宿主机的系统文件绑定到容器中。
tmpfs这种方式是使用宿主机的内存作为存储，不会写到宿主机的文件系统中，和前两种区别较大。

mysql dockerHub主页中的推荐方式是在宿主机中新建一个专门用来存放mysql docker数据的文件路径，同时在新建容器的时候将该路径映射到容器中，也就是使用bind mount的方式，之所以不使用volume的方式是因为volume是由docker管理，在宿主机上比较难定位。

那对于我的情况，既已经有一个容器使用了volume，想把volume里的数据在新的容器中使用bind mount方式挂载该怎么办呢？我们可以先把mysqldock容器中所需要的文件拷贝出来到本地的/var/own/mysqldata，通过

docker cp mysqldock:/var/lib/mysql /var/own/mysqldata

然后在创建新的mysql容器时，挂载该文件即可

docker run -v /var/own/mysqldata:/var/lib/mysql --name mysqlnew -d mysql

这样新的容器就可以保留mysqldock中的数据了，问题解决！当然，我们也可以使用docker推荐的volume方式挂载，首先找到mysqldock的volume，然后在运行新容器时指定该volume进行挂载就行了：

使用volume进行挂载

这种方式繁琐？别急，还有更简单的，在创建容器的时候，可以指定使用其他容器的volume，也就是共享其他容器的volume，使用--volumes-from参数

docker run --name mysqlvolumn2 --volumes-from mysqldock -d mysql

其实volume还可以在创建的时候进行命名，从而是查找起来不那么繁琐，具体的参数就请大家参考官网或者--help了，其实官方更加推荐的是使用--mount代替-v参数，官网上有详尽的例子，大家也可以自行进行尝试。

当然啦，纯粹把docker作成数据容器其实并没有太大意义，这里只是借这个问题窥探一下docker数据卷的一些用法。