本人最近在使用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数据卷的一些用法。
作者:SawyerZhou
链接:https://www.jianshu.com/p/530d00f97cbf
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
网友评论