第7节 Docker数据持久化和数据卷容器

用持久化做一下wordpress

docker run -p 3306:3306 -e MYSQL_ROOT_PASSWORD=123456 -e MYSQL_DATABASE=wordpress -e MYSQL_USER=wordpress -e MYSQL_PASSWORD=123456 --name mysql -d --restart=always -v /data/mysql:/var/lib/mysql mariadb:11.3.2

docker run -d -p 8080:80 --name wordpress -v /data/wordpress:/var/www/html --restart=always wordpress:php8.2-apache

也就是生成wp-config.php文件

👆上图localhost是错误的，前文就说过了，要写宿主机的IP。

总之，wordpress容器化就是

①wordpress服务是一个容器，你这个配置界面是wordpress连接mysql的配置界面，其实是wordpress里面配置的localhost，所以是容器里的，而不是宿主的。要注意的。

②mysql，又是另一个容器了

上面的数据配置提交后，实际上就是生成了wp_config.php文件

这个配置完后，mysq里的相关表信息就来了

然后登入进去后，新建文章，上传图片

就会在wordpress的目录下看到

一张图片会根据手机、平板、电脑，分辨率，来生成多张，将来好匹配不同屏幕。

然后发布文章

然后删除上面的两个容器，由于做了数据持久化，所以文章得以保存

删除容器docker rm -f xxxx，如果你用docker -rm -v -f xxx，就要小心了，会不会-v一下子也就把持久化的数据也给删了，但是我们的这个实验不会，因为，-v只能删除匿名卷。

所以胆子不妨大一点~，追女孩子的时候脸皮不妨厚一点~，啥~ 跑题了~~~

删除后，由于持久化的数据还在，所以docker run起来就还能看得见

然后重新run一下就恢复

检查页面已经恢复下

数据卷容器

就是用容器来实现数据持久化

再跑一个wordpress2

发现会自动将9090跳转到8080去

因为数据库没有发开

分开来一遍

这里又会涉及初始化mysql的配置

默认就是3306，也不知道我强行写成3406行不行

可以！wordpress初始化mysql可以带端口👆

你看这就一个宿主两个wordpress了

这是英文的还是👆

这是👇之前中文的

再来一个例子，两个容器共享数据的效果

用之前的自定义的image来弄

那么问题来了，过了这么久，我应该用哪个images去run呢，或者说我的这个image是怎么build出来的，用的哪个Dockerfile呢，对吧，简单，上次的研究就没有白费，👇

寻找熟悉的镜像的准备

①inspect看看From的谁

②hisotry看看build的过程

开始寻找

可见这几个镜像又276MB的还有48.3MB，看看为啥大小差这么多，

再看看

就这看到了为什么0.1版大在哪里👆然后用--no-truc展开看详细CLI

然后找找哪一个Dockerfile里又这个命令的👆

发现不再这个层级目录下

通过当前的Dockerfile的就会看到FROM alpine_3.19_self:v1.0

这就找到了👇

那么276MB的原因找到了，48.3MB为什么这么小呢

找到了

最后实验的时候，FROM的镜像改用了官方镜像了

也许可以这么验证，验证什么呢，就是

这个FROM，build出来了web001_entrypoint0.3

而web001_entrypoint:0.1是自定义的，

run 进去看apk list 就知道了，比如如果是自定义的，那么apk list里是由iotop这个包的

好了，目前就找到这么个方法来定位自己大量的image不知道从哪个Dockerfile来的，

思路就是：找到Dockerfile里的特点，然后基于这个特点，比如这个Dockerfile里安装了某个与众不同的软件，就将对比的images分别run起来去看有没有，有就是FROM的这个，没有就是别的或者直接是官方的。

所以还是docker-compose好啊，哎，赶紧学到那里去看看有没有更好的解决方案~~

下面继续实验，基于定位出来的这个镜像

然后这个镜像的Dockerfile和entrypoint看看

上图，但其实你会发现，TMD，这个其实web001_entrypoint:0.3当初build那会儿，entrypoint脚本里的

echo "$HOST" > ${DOC_ROOT}index.html  这一行是打开的，没有被注释掉的

实验思路：两个容器共享一个持久化

有一个问题

命名卷和匿名卷，都是可以docker volume ls查到的，此时尽管docker ps -a也没了，目录也删掉了，但是docker volume ls可见，就会导致run的时候-v 指定命名卷就会报错

所以要用docker volume rm清理

结果不消息清掉了匿名卷，哈哈哈

重启一下就好了

下次记得删除volume不要用rm，要用docker volume rm

然后宿主机的路径，就是手动创建的目录，不算逻辑卷,，会自动创建，docker volume ls是看不到的

只要docker volume ls 看不到，就可以自动创建，并run的时候挂载过去

只要docker volume ls 看到且文件确实存在，就可以重复run 的时候挂载过去了

继续做2个容器挂载一个目录吧

第一个容器ok

第二个

也OK，而且是共用的一个命名卷mydata

数据卷容器的产生背景

问题来了

如果10个容器都挂同样的目录，比如👇

docker1 -v mydata1 -v mydata2 -v mydata3
docker2 -v mydata1 -v mydata2 -v mydata3
。。。 。。。 
docker10 -v mydata1 -v mydata2 -v mydata3

就要写10遍 -v mydata1 -v mydata2 -v mydata3，配置太繁琐，于是就有了一下的解决方案数据卷容器

容器0正常使用-v -v -v去挂载，其他容器1 2 3 4 .. 参考容器0直接挂过去--就是说你容器0的持久化方案就是我们其他容器的持久化方案

这里所谓的容器0就是图中的Data container。

1、先创建一个服务器容器，这个服务器容器就正常-v -v -v 挂载好目录，不管是逻辑卷(①匿名卷②命名卷)，还是直接使用宿主的文件夹。

2、其他容器就好比client端，都是服务器容器的挂载方案进行复制挂载就行了。

上面两个图其实有一个理解误区，其实就是画图的不专业，是什么呢，就是箭头不是数据卷挂载的动作流，而是-v复制参考的动作流，你这个图搞的好像我删掉容器A或者前一张图的Data Container就会导致容器B C ；Container 1 2 3都断开连接了一样，其实不存在连接，不存在绕行，这个容器B C 绕行容器A的箭头只是复制了-v xx -v xxx -v xxx的配置而已，一旦复制过了，那么容器B C都是直接挂载访问到宿主机的。下面有截图实验证的。

实际配置很简单

docker run --volumes-from <数据卷容器>   Mount volumes from the specified container(s)

实际配置开始-多个容器共享某部分数据的方案

1、配置数据卷容器，server啦，因为只是提供别的容器，来复制挂载目录的。所以就只需要写好-v就信了；

docker run -d -v mydata:/data/website --name volume-server -e HOST='www.dalao.tk' web001_entrypoint:0.3

这里留了一个-e HOST=xxx来测试是否可以复制，和-v一样被其他容器复制。

而且容器都不要UP的，也不要用比较大的镜像去run，直接将上面的优化成

docker run -d -v mydata:/data/website --name volume-server -e HOST='www.dalao.tk' busybox

2、配置使用"数据卷容器"的容器，clients啦

docker run -d --volumes-from volume-server -p 81:80 --name web01 web001_entrypoint:0.3

docker run -d --volumes-from volume-server -p 82:80 --name web02 -e HOST="web02" web001_entrypoint:0.3

docker run -d --volumes-from volume-server -p 83:80 --name web03 -e HOST="web03" web001_entrypoint:0.3

看效果👇

但是要注意到上图的最后两行curl结果是一样的，别没有想当然的出现web02。理由很简单，就是当你上面敲了最后一行docker run的时候，此时就已经传参-e HOST=web03进去了，而entrypoint就是docker run的时候执行的。加上逻辑卷又是挂载同样的一个，所以最后一行的run就把外面逻辑卷里的Index.html的内容改成了web03。

所以此时下图这个的index.htm其实就是web03