5

我将 docker 置于 swarm 模式并执行了以下操作

echo "'admin'" | docker secret create password -
docker service create \
--network="host" \
--secret source=password,target=password \
-e PASSWORD='/run/secrets/password' \
<image>

我无法通过 docker 服务传递通过环境变量创建的密码。

请帮我解决我哪里出错了。

4

2 回答 2

8

您误解了 docker secrets 的概念。创建秘密的重点是避免将敏感信息放入环境变量中。

在您的示例中，PASSWORD环境变量将只携带/run/secrets/password文件名而不是密码的值admin。

一个有效的 docker secrets 案例是，您的 docker-image 从该文件中读取密码。在此处查看文档，尤其是有关 MySQL 的示例：

环境变量 MYSQL_PASSWORD_FILE 和 MYSQL_ROOT_PASSWORD_FILE 指向文件 /run/secrets/mysql_password 和 /run/secrets/mysql_root_password。首次初始化系统数据库时，mysql 映像会从这些文件中读取密码字符串。

简而言之：您的 docker 映像应该读取文件的内容/run/secrets/password

于 2018-09-25T07:20:18.277 回答
0

这里没有标准。

Docker 文档不鼓励使用环境变量，但是无论是在“环境”部分中直接将密码设置为字符串还是在容器中使用环境变量的其他用法，都存在混淆。当可能在多个服务中使用相同的值时，也使用字符串而不是秘密需要在多个位置而不是一个秘密值中检查和更改它。

一些图像，如 mariadb，使用带有 _FILE 后缀的环境变量来使用秘密文件内容填充无后缀版本的变量。这似乎没问题。

使用 Docker 不应该只为了支持文件中的机密而重新设计应用程序架构。大多数其他编排工具，如 Kubernetes，都支持将秘密直接放入 env 变量中。如今，这并不被认为是不好的做法。Docker Swarm 只是缺乏将秘密传递给 env 变量的良好实践和适当示例。

恕我直言，最好的方法是使用入口点作为“装饰器”来从秘密中准备环境。

正确的入口点脚本可以编写为处理秘密的几乎通用方式，因为我们可以将原始图像入口点作为参数传递给我们的新入口点脚本，因此在我们使用脚本准备容器后，原始图像“装饰器”正在做自己的工作。

就我个人而言，我正在使用以下带有图像的入口点/bin/sh： https ://github.com/DevilaN/docker-entrypoint-example

于 2021-11-17T14:21:34.063 回答