日志挂载优化
存储卷优化
什么是存储卷
“卷”是容器上的一个或多个“目录”,此类目录可绕过联合文件系统,与宿主机上的某个目录“绑定(关联)”;
在Docker中,要想实现数据的持久化(所谓Docker的数据持久化即数据不随着Container的结束而结束),需要将数据从宿主机挂载到容器中。
Docker管理宿主机文件系统的一部分,默认位于 /var/lib/docker/volumes 目录中;(最常用的方式)
存储卷优化写入速度
Docker镜像由多个只读层叠加而成,启动容器时,docker会加载只读镜像层并在镜像栈顶部加一个读写层;
如果运行中的容器修改了现有的一个已经存在的文件,那该文件将会从读写层下面的只读层复制到读写层,该文件版本仍然存在,只是已经被读写层中该文件的副本所隐藏,此即“写时复制(COW)”机制。
为了避免这种情况,构建Dockerfile的时候应该加入一个存储卷
Dockerfile增加存储卷
增加存储卷
编写Dockerfile增加存储卷,增加日志存储卷
/logs
,这会是一个匿名存储卷
FROM openjdk:8-jdk-alpine
VOLUME /tmp /logs
ADD learn-docker-storage-1.0-SNAPSHOT.jar app.jar
EXPOSE 8003
ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"]
构建镜像
因为我们原来已经构建了镜像,这次使用版本号是
0.0.2
#构建镜像
docker build -t learn-docker-storage:0.0.2 .
# 查看镜像列表
docker images
运行容器
通过run命令运行容器
# 运行容器
docker run -d -p 8003:8003 learn-docker-storage:0.0.2
# 查看运行中的容器
docker ps
查看存储卷
通过
docker volume ls
可以看到存储卷
docker volume ls
查看容器信息
我们发现都是匿名的存储卷,如何来确定都是那个呢,可以通过
docker inspect 容器ID
来查看存储新鲜
docker inspect 2041965c3e87|grep Mounts -A20
通过这个命令可以看到数据卷的名称以及宿主机的存储路径,我们可以直接到宿主机打印日志
# 进入文件挂载目录
cd /var/lib/docker/volumes/d35de1b7e4631908b05635db4c1f114ab3aafbdf25a9843c068696e66a779c75/_data
# 输出日志
tail -f learn-docker-storage.log
这样就看到了我们的日志文件
验证存储卷
删除容器检查存储卷释放消失
# 查看运行的容器列表
docker ps
#删除容器
docker rm -f 2041965c3e87
#查看所有的容器列表(运行+停止)
docker ps -a
我们看到容器已经被删除了,检查我们的存储卷
发现存储卷还存在,数据还是存在的,并且数据也存在
重新运行镜像启动一个新的容器
# 运行容器
docker run -d -p 8080:8080 e1222496c69f
# 查看运行中的容器
docker ps
启动容器后查看存储卷列表
# 查看存储卷列表
docker volume ls
我们发现有创建了两个存储卷,查看容器详情
docker inspect 2041965c3e87|grep Mounts -A20
我们发现新启动的容器新开了一个匿名存储卷
bind挂载共享存储
什么是bind
Bind mounts模式和Volumes非常相似,不同点在于Bind mounts模式是将宿主机上的任意文件或文件夹挂载到容器,而Volumes本质上是将Docker服务管理的一块区域(默认是/var/lib/docker/volumes下的文件夹)挂载到容器。
共享存储
经过上面的测试,我们发现每一个容器都是单独用一个存储卷,用于临时文件没有问题的,但是如果要让容器都用同一个存储路径怎么办呢,这个时候就用到了 bind挂载了,可以使用
-v
进行挂载挂载刚才的存储卷。
# 级联创建文件夹
mkdir -p /tmp/data/logs
# 运行容器,指定挂载路径
docker run -d -v /tmp/data/logs:/logs \
-p 8003:8003 --name learn-docker-storage \
learn-docker-storage:0.0.2
这里面--name
是指定docker容器的名称,我们操作容器就可以使用名称进行操作了
然后使用docker inspect
命令来检查容器详情
docker inspect learn-docker-storage|grep Mounts -A20
我们发现挂载日志的挂载方式已经变了,由原来的volume变为了bind,并且挂载路径变为了我们自己定义的路径,进入目录查看
# 进入目录并浏览目录文件
cd /tmp/data/logs/&&ll
# 打印日志详情
tail -f learn-docker-storage.log
验证共享存储
我们也按照上面步骤验证下bind方式挂载的存储,先删除容器,检查日志文件是否存在
# 停止并删除容器
docker rm -f learn-docker-storage
# 查看容器已经被删除了
docker ps -a
# 进入日志挂载路径查看日志是否存在
cd /tmp/data/logs/&&ll
我们发现容器被删除但是日志文件还存在本地
启动一个新的容器
# 运行容器,指定挂载路径
docker run -d -v /tmp/data/logs:/logs \
-p 8003:8003 --name learn-docker-storage \
learn-docker-storage:0.0.2
# 查看日志文件
cat learn-docker-storage.log
我们发现新的容器的日志文件追加进来了
我们发现日志已经追加,我们让不同的容器挂载同一个目录了
volume和bind的区别
对于多个容器需要共享访问同一数据目录,或者需要持久化容器内数据(如数据库)时,我们都是采用挂载目录形式(bind mounts),将宿主机的某一目录挂载到容器内的指定目录,这种方式能解决问题,但这种方式也一直有一些缺点
- 容器在不同的服务器部署需要根据实际磁盘挂载目录修改路径
- 不同操作系统的文件和目录权限会搞得你昏头转向,火冒三丈 ?
bind mount和volume其实都是利用宿主机的文件系统,不同之处在于volume是docker自身管理的目录中的子目录,所以不存在权限引发的挂载的问题,并且目录路径是docker自身管理的,所以也不需要在不同的服务器上指定不同的路径,你不需要关心路径。
清理volume挂载
volume挂载方式,会生成很多匿名的目录,我们可以找到对应的没有使用的volume进行删除
通过查看我们发现里面,有很多的volume,我们可以找到没有用的删除
还可以通过命令将没有引用的全部volume清除掉,但是这个命令很危险
docker volume prune
这样就将我们服务器上无效的volume清除掉了