对于代码使用卷，这是一个docker最佳实践吗？

Question

  

VOLUME指令应用于公开由docker容器创建的任何数据库存储区域，配置存储或文件/文件夹。强烈建议您将VOLUME用于图像的任何可变和/或用户可维修部分。

您会将代码存储在卷中吗？

比如你的jar文件。在不重建映像的情况下部署应用程序可能会有点方便 如果将代码存储在卷中，是否有任何考虑因素？喜欢表现，安全或其他。

Answer 1

我不建议在Dockerfile中使用VOLUME语句来处理当前版本的docker（当前是引入命名卷以来的任何版本的docker）。包含VOLUME命令有多个缺点，包括：

• 可能无法使用任何后续步骤或子图像更改图像位置的内容（此行为在不同场景和不同版本的泊坞窗中显示不同）
• 创建卷的可能性仅仅是用于混淆docker volume ls输出的名称的哈希，如果您需要内部数据，则很难找到并重新使用
• 对于您更改的代码，如果将其放入卷中并从新版本的映像重新创建容器，则卷仍将具有代码的旧副本，除非您自己更新该卷（卷的关键功能）是您不希望在迭代之间保持的持久性数据）

我建议您将数据放在docker run命令行或docker-compose.yml中定义的卷中。在那里定义的卷可以有一个名称或映射回到docker主机上的路径。您可以创建任何文件夹或文件卷，而无需在Dockerfile中定义它。此步骤中定义的卷不会影响图像，允许您扩展图像，而不会被锁定而无法更改目录。

对于您的代码，如果在应用程序开发期间解释（例如javascript）或已编译（例如jar文件），则将代码注入卷是一种常见的最佳做法。您将在容器（而不是Dockerfile）上定义卷，并使用相同的文件名覆盖也复制到映像中的代码或二进制文件。这使您可以快速迭代开发而无需频繁重建映像。根据应用程序的不同，您可以重新加载代码，否则，重新启动容器应该是查看最新更改所需的全部内容。开发完成后，使用当前代码重建映像并将其发送给可以使用它的人，而无需代码的卷装入。

如果您想了解更多相关详情，我也blogged about my concerns with volumes inside of Dockerfiles。

Answer 2

你说：

  

在不重建映像的情况下部署应用程序可能会有点方便。

与其相比，将应用程序版本封装在图像构建中具有很多优势。您可以轻松部署仅部署映像的应用程序，因此您使用应用程序代码的卷这一事实会导致您编排其他部署方法来更新该卷。

你必须（最终）将 jar 版本与正确的图像版本匹配。

关于安全性或性能，我认为没有特别的考虑因素。

无论如何，这不是使用卷的常用方法。正如@BMitch所说，在Dockerfile中使用VOLUME是有些棘手的。