Docker 数据卷深入理解：最佳实践、常见问题和故障排除技巧 (docker logs)

简介

Docker 数据卷是一种持久存储机制，允许容器存储和共享数据。它们是管理和保护容器中重要数据的关键组件。

本文将深入探讨 Docker 数据卷，涵盖最佳实践、常见问题以及故障排除技巧，以帮助您充分利用它们。

最佳实践

• 使用有意义的名称： 为数据卷指定有意义的名称，以方便识别和管理。
• 限制容器对数据卷的访问： 仅授予容器对所需数据卷的访问权限，以提高安全性。
• 利用 Docker 卷标签： 使用标签组织和跟踪数据卷，以便于管理和查找。
• 备份数据卷： 定期备份数据卷以确保数据安全。
• 使用持久卷： 在可能的情况下，使用持久卷来确保数据在容器重新启动或销毁后仍然可用。

常见问题

• 检查访问权限： 确保容器拥有访问数据卷所需的权限。
• 验证卷挂载： 检查容器是否正确挂载了数据卷。
• 检查卷是否存在： 验证数据卷是否已创建并存在。

• 使用持久卷： 切换到使用持久卷，它们在容器重新启动后仍会保留数据。
• 使用挂载路径： 将数据卷挂载到持久路径，例如主机上的目录。

• 扩展数据卷大小： 使用 `docker volume expand` 命令扩展数据卷的大小。
• 使用动态卷： 切换到使用动态卷，它们会自动扩展以满足需求。

故障排除技巧

docker logs

查看容器日志以查找有关数据卷问题的线索。

docker volume inspect

获取有关数据卷的详细信息，包括大小、挂载路径和访问权限。

docker inspect | grep Mounts

检查容器是否正确挂载了数据卷。

docker volume rm

docker volume create

如果出现问题，可以尝试重新创建数据卷。

结论

Docker 数据卷是管理和保护容器中数据的强大工具。通过遵循最佳实践、解决常见问题并利用故障排除技巧，您可以充分利用它们，确保数据安全和可用。

通过深入了解 Docker 数据卷，您可以优化容器化应用程序的存储策略，提高性能和可靠性。

docker中使用docker

Docker 容器技术目前是微服务/持续集成/持续交付领域的第一选择。而在 DevOps 中，我们需要将各种后端/前端的测试/构建环境打包成 Docker 镜像，然后在需要的时候，Jenkins 会使用这些镜像启动容器以执行 Jenkins 任务。

为了方便维护，我们的 CI 系统如 Jenkins，也会使用 Docker 方式部署。 Jenkins 任务中有些任务需要将微服务构建成 Docker 镜像，然后推送到 Harbor 私有仓库中。 或者我们所有的 Jenkins Master 镜像和 Jenkins Slave 镜像本身都不包含任何额外的构建环境，执行任务时都需要启动包含对应环境的镜像来执行任务。

我们的 Jenkins Master、Jenkins Slaves 都是跑在容器里面的， 该如何在这些容器里面调用docker run命令启动包含 CI 环境的镜像呢？ 在这些 CI 镜像里面，我们从源码编译完成后，又如何通过docker build将编译结果打包成 Docker 镜像，然后推送到内网仓库呢？

答案下面揭晓。

Docker 采取的是 Client/Server 架构，我们常用的docker xxx命令工具，只是 docker 的 client，我们通过该命令行执行命令时，实际上是在通过 client 与 docker engine 通信。

我们通过 apt/yum 安装 docker-ce 时，会自动生成一个 systemd 的 service，所以安装完成后，需要通过sudo systemctl enable 来启用该服务。 这个 Docker 服务启动的，就是 docker engine，查看/usr/lib/systemd/system/ ，能看到有这样一条语句：

默认情况下，Docker守护进程会生成一个 socket（ /var/run/ ）文件来进行本地进程通信，因此只能在本地使用 docker 客户端或者使用 Docker API 进行操作。

sock 文件是 UNIX 域套接字，它可以通过文件系统（而非网络地址）进行寻址和访问。

因此只要以数据卷的形式将 docker 客户端和上述 socket 套接字挂载到容器内部，就能实现 Docker in Docker，在容器内使用 docker 命令了。具体的命令见后面的「示例」部分。

要记住的是，真正执行我们的 docker 命令的是 docker engine，而这个 engine 跑在宿主机上。所以这并不是真正的 Docker in Docker.

运行过Docker Hub的Docker镜像的话，会发现其中一些容器时需要挂载/var/run/文件。这个文件是什么呢？为什么有些容器需要使用它？简单地说，它是Docker守护进程(Docker daemon)默认监听的Unix域套接字(Unix domain socket)，容器中的进程可以通过它与Docker守护进程进行通信。

在容器内部使用宿主机的 docker，方法有二：

容器的启动方式也有两种，如下：

示例命令如下：

必须以 root 用户启动！（或者其他有权限读写/var/run/的用户） 然后，在容器内就能正常使用 docker 命令，或者访问宿主机的 docker api 了。

文件内容如下：

然后通过docker-compose up -d即可后台启动容器。

通过上面的操作，我们在容器内执行docker ps时，还是很可能会遇到一个问题： 权限问题 。

如果你容器的默认用户是 root，那么你不会遇到这个问题，因为/var/run/的 onwer 就是 root.

但是一般来说，为了限制用户的权限，容器的默认用户一般都是 uid 和 gid 都是 1000 的普通用户。这样我们就没有权限访问/var/run/了。

解决办法：

方法一（不一定有效）：在构建镜像时，最后一层添加如下内容：

方法二：经测试一定有效，在Dockerfile中使用USER参数

这样我们构建的镜像就是root用户了，经测试在文件中user参数并不好用,类似如下

这样我们的默认用户，就能使用 docker 命令了。

参考

Docker：容器管理（启动参数，查看容器和日志，进入和修改容器）

摘要： Docker

容器是一个精简版的操作系统，一般一个容器只运行一个应用，容器通过镜像创建，使用docker run 命令创建，容器起到了 隔离 作用，容器和容器之间独享空间和网络等

容器的基本操作包括创建（启动），停止，重启，查看，检查等，容器通过镜像创建，使用 docker run 命令创建，需要指定run参数，镜像名，容器执行命令，语句格式如下

在实际使用中启动一个镜像，例如

-e 设置环境变量，格式是 -e k1=v1 -e k2=v2 ，使得在docker镜像中的程序能够直接访问到环境变量，同时可以作为配置参数放在docker run启动镜像的时候设置，而不是写死在dockerfile在build的过程中，-e和dockerfile中的 ENV 变量作用相同，当变量重名时-e替换ENV，下面测试一些-e参数，在Dockerfile指定环境变量

直接构建成容器

开启一个终端启动容器内部，打印指定的环境变量a

此时在run指令中增加-e设置环境变量，可见-e替换了Dockerfile中指定的环境变量

因为一个镜像可以启动多个容器，所以可以通过设置不同-e达到设置不同配置参数的目的，比如下一个例子在Dockerfile中设置和将环境变量写入yaml文件再供Python调用，执行的内容为打印yaml配置文件的参数内容，比如下面这个例子先看下目录结构

其中是一个空配置文件，在中先使用echo写入追加配置参数到在执行Python脚本

Dockerfile中启动脚本作为容器执行命令

在启动容器时，使用-e指定环境变量，在中echo将环境变量拿到和写入配置文件，测试多次以不同的配置参数启动容器如下

-v 设置挂载运行，将宿主机当前目录下的文件挂载到容器中/home目录下，例如

如果挂载的目录和Dockerfile中的COPY的目录不一致， -v会替代COPY或者ADD ，例如现在Docker中COPY一个文件到容器/home目录下

同目录下内容是打印1

构建镜像结束后，指定-v启动，起始挂载另外一个目录，目录下内容是打印2

docker run参数中最后的COMMAND会覆盖Dockerfile中指定的 CMD ，例如执行echo 2替换原始Dockerfile中的CMD echo 1，输出结果是2且执行完毕后退出

对于Dockerfile中的 ENTRYPOINT 指定的启动命令docker run的COMMAND不会覆盖，如果要覆盖Docker中的ENTRYPOINT需要指定docker run中的 --entrypoint 参数，格式是

测试一个Dockerfile输出1

在docker run中使用--entrypoint覆盖Dockerfile中的ENTRYPOINT

容器启动后通过 docker ps 或者 docker container ls 查看容器，可以增加额外参数比如 -a 显示所有容器，默认只显示运行的容器，可以增加 --no-trunc 参数使得显示结果不截断，例如

显示结果分别显示了容器的ID，镜像，执行命令，创建时间，状态，端口映射（宿主机->容器）和容器名称。对于已经运行的容器可以使用 docker stop 停止，如果在docker run时增加--rm参数则停止的容器保留不会自动删除，例如

除了docker stop命令还有一种停止容器的命令 docker kill ，相比于docker stop，docker kill是 强制立即停止 ，而docker stop是先给了容器10秒（默认）的时间，使得容器有一定的时间处理、保存程序执行现场， 优雅的退出程序 ，例如

在容器停止之后可以使用 docker start 再启动一个停止的容器，例如

除此之外可以使用 docker restart ，此时容器可以使停止的也可以是在运行中的，例如

查看容器详情使用 docker inspect ，比如

在以上截取的内容中展示了容器详情，包括容器id，创建时间，执行命令和参数，执行状态，容器pid，落脚点，环境变量，网络设置，端口映射等，也可以使用Go语言风格输出指定的详情，比如分别只看容器的pid和容器的执行命令

容器是一个操作系统，可以进入这个操作系统查看容器的运行情况，有多种方式进入容器，其中主要是使用 docker exec 进入容器，在一个运行中的容器中执行一个命令，使用 -it 并带有 /bin/bash 命令就可以进入容器，比如

除了/bin/bash也可以是其他命令挂载exec后面则可以直接对一个运行中的容器执行命令，比如查看容器的进入落脚点路径，容器中的内存情况

当容器以后台 -d 运行时，日志运行在容器内部，可以进入容器内部查看日志，也可以使用 docker logs 查看日志，以一个flask api接口的容器为例，日志写入文件，同时也会输出在flask的控制台

创建Dockerfile以及构建镜像，启动容器

启动一个脚本不断请求api接口

进入容器内部查看日志

另一种方式是直接使用 docker logs 命令，比如使用 -f 追踪输出，并且从最后的第1行开始输出

此时宿主机的logs目录下为空，容器中的logs目录下存在文件，如果使用 -v 将宿主机目录挂载到容器作为容器写入的目录，则容器中数据的变动会同步到本地，这样可以直接在本地查看日志，修改容器启动为 -v 挂载的形式

此时本地logs目录下开始产生日志，且这个日志和容器内的logs目录下一致

如果容器内的内容改变了，此时删除容器从镜像重新启动容器则改动的内容将不会存在，如果相对修改过的容器保留下来则可以从容器生成新的镜像，先测试以下容器内修改在删除的容器后将不再生效，在已有容器中使用pip安装Python包

此时退出容器，并且删除容器，最后从镜像重新生成容器

此时进入容器检查，并不存在pymongo包

如果要容器变化保存下来需要以这个新容器生成一个镜像，使用 docker commit ，语法如下

以新安装pymongo的容器为例，对新容器使用docker commmit

新生成的镜像叫做xiaogp/my_image_test:v2

从新镜像启动容器并进入容器查看存在新安装的pymongo

Docker如何对一个已经创建了的容器添加数据卷？

目前不支持对容器做数据卷的修改。

若对本页面资源感兴趣，请点击下方或右方图片，注册登录后

搜索本页相关的【资源名】【软件名】【功能词】或有关的关键词，即可找到您想要的资源

如有其他疑问，请咨询右下角【在线客服】，谢谢支持！