在Docker v1.9中，你可以使用ARG指令在构建操作时获取通过命令行传递给映像的参数。只需使用——build-arg标志。因此，您可以避免在Dockerfile中保留显式密码(或其他敏感信息)，并随时传递它们。

来源:https://docs.docker.com/engine/reference/commandline/build/ http://docs.docker.com/engine/reference/builder/#arg

例子:

Dockerfile

FROM busybox
ARG user
RUN echo "user is $user"

生成映像命令

docker build --build-arg user=capuccino -t test_arguments -f path/to/dockerfile .

在构建过程中打印

$ docker build --build-arg user=capuccino -t test_arguments -f ./test_args.Dockerfile .

Sending build context to Docker daemon 2.048 kB
Step 1 : FROM busybox
 ---> c51f86c28340
Step 2 : ARG user
 ---> Running in 43a4aa0e421d
 ---> f0359070fc8f
Removing intermediate container 43a4aa0e421d
Step 3 : RUN echo "user is $user"
 ---> Running in 4360fb10d46a
**user is capuccino**
 ---> 1408147c1cb9
Removing intermediate container 4360fb10d46a
Successfully built 1408147c1cb9

希望能有所帮助!再见。

我的方法似乎有效，但可能有些幼稚。告诉我为什么这是错的。

在docker构建过程中设置的arg是由history子命令公开的，所以不要去那里。但是，在运行容器时，run命令中给出的环境变量对容器是可用的，但不是映像的一部分。

因此，在Dockerfile中，执行不涉及秘密数据的设置。设置一个类似于/root/finish.sh的CMD。在run命令中，使用环境变量将秘密数据发送到容器中。sh使用这些变量来完成构建任务。

为了更容易地管理秘密数据，将其放入一个文件中，由docker使用——env-file开关加载。当然，要保密。gitignore之类的。

对我来说，finish.sh运行一个Python程序。它检查以确保之前没有运行过，然后完成设置(例如，将数据库名称复制到Django的settings.py中)。

我们的团队避免将凭证放在存储库中，因此这意味着Dockerfile中不允许使用凭证。我们在应用程序中的最佳实践是使用来自环境变量的信用。

我们使用docker-compose来解决这个问题。

docker-compose之内。Yml，你可以为容器指定一个包含环境变量的文件:

 env_file:
- .env

确保将.env添加到.gitignore，然后在.env文件中设置凭据，如下所示:

SOME_USERNAME=myUser
SOME_PWD_VAR=myPwd

将.env文件存储在本地或其他团队成员可以获取它的安全位置。

见:https://docs.docker.com/compose/environment-variables/ / the-env-file

我想，如果它是bash shell，像这样简单的东西就可以工作。

读取-sp "db_password:" password | docker run -itd——name <container_name>——build-arg mysql_db_password=$db_password alpine /bin/bash

只需默读它，并在Docker映像中作为参数传递。你需要在Dockerfile中接受变量作为ARG。

Docker现在(版本1.13或17.06或更高)支持管理秘密信息。下面是概述和更详细的文档

kubernetes和DCOS也存在类似的特征

这肯定是一个问题。dockerfile通常被签入存储库并与其他人共享。另一种方法是在运行时提供任何凭据(用户名、密码、令牌，任何敏感的东西)作为环境变量。这可以通过-e参数(用于CLI中的单个变量)或——env-file参数(用于文件中的多个变量)来运行docker。阅读这篇文章，了解如何在docker-compose中使用环境。

使用——env-file绝对是一个更安全的选择，因为如果使用set -x，它可以防止秘密显示在ps或日志中。

然而，环境变量也不是特别安全。通过docker inspect可以看到它们，因此任何可以运行docker命令的用户都可以使用它们。(当然，在主机上可以访问docker的任何用户都有root权限。)

我更喜欢的模式是使用包装器脚本作为ENTRYPOINT或CMD。包装器脚本可以首先在运行时将秘密从外部位置导入到容器中，然后执行应用程序，提供秘密。具体的机制取决于您的运行时环境。在AWS中，您可以使用IAM角色、密钥管理服务和S3的组合来将加密的秘密存储在S3桶中。HashiCorp Vault或credstash是另一种选择。

在构建过程中使用敏感数据没有最佳模式。事实上，我有一个关于这个话题的SO问题。您可以使用docker-squash从映像中删除图层。但是Docker中并没有用于此目的的本机功能。

您可能会发现在容器中对配置的shykes注释很有用。