我看到的许多项目都使用了您提到的s3方法。你的观点仍然有效，我们应该/将在社区讨论这个问题。

您还可以在hdfs或ftp/ftps服务器中托管.dockercfg。如果https不可接受，那么mesos获取程序可以支持这些协议中的任何一个。

由于mesos文档在这方面相当差，我将回答这个wiki风格，并在我去的时候更新这个答案。

应该有效的策略

将其托管在s3上（具有基于网络的访问限制）

在s3上托管.dockercfg文件。为了更好的安全性，您应该考虑将它放在自己的存储桶中，或者放在专门存储秘密的存储桶中。这在创建一个安全策略方面提出了一些有趣的挑战，该策略实际上可以锁定s3存储桶，这样只有meso才能看到它，但它是可以做到的。
mesos任务配置：

{
  ...
  "uris": ["https://s3-eu-west-1.amazonaws.com/my-s3-bucket-name/.dockercfg"]
  ...
}

s3 bucket策略（使用vpc端点）：
注意：这个策略允许允许主体做任何事情，这对于生产来说太草率了，但是在测试集群中调试时应该会有所帮助。

{
  "Id": "Policy123456",
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "Stmt123456",
    "Action": "s3:*",
    "Effect": "Allow",
    "Resource": [
      "arn:aws:s3:::my-s3-bucket",
      "arn:aws:s3:::my-s3-bucket/*"
    ],
    "Condition": {
      "StringEquals": {
        "aws:sourceVpce": "vpce-my-mesos-cluster-vpce-id"
      }
    },
    "Principal": "*"
  }]
}

您还需要一个vpce配置，为您提供一个vpce id以插入上述s3 bucket条件(我想如果你不使用vpc端点，你可以只匹配一个vpc id吗？）
您可以通过转到mesos用户界面（如果您使用的是dcos，则这不是漂亮的dcos用户界面）并观察具有应用程序名称的任务是否显示在活动任务或已完成任务列表中，来检查这是否起作用。

 诱人的策略（还没有）奏效

在s3上托管（带有签名的URL）

在这个s3变体中，我们没有使用基于网络的访问限制，而是使用指向.dockercfg文件的签名url。
mesos任务配置应如下所示：

{
  ...
  "uris": ["https://my-s3-bucket/.dockercfg?AWSAccessKeyId=foo&Expires=bar&Signature=baz"]
  ...
}

不幸的是，由于mesos-1686，上面的s3签名url策略不起作用，它观察到任何下载的文件都准确地保留了远程文件名，包括查询字符串，导致文件名类似“.dockercfg？awsaccesskeyid=foo&expires=bar&signature=baz”。由于docker客户端无法识别文件，除非文件名为“.dockercfg”，因此无法看到身份验证凭据。

将.dockercfg文件直接传输到每个从属服务器

可以将.dockercfg scp到每个mesos从机。虽然这是一个快速解决方案，但它：
需要事先了解所有的奴隶
不会随着新从属服务器添加到集群而扩展
需要ssh访问从属服务器，从属服务器在自己的vpc中配置（因此它们的ip地址通常在10.0.[blah]范围内）。
如果使用像chef这样的配置管理工具来实现自动化，这将成为一种更可行的生产方法，chef将在从属服务器上运行，并将.dockercfg文件拉到正确的位置。
这将导致如下配置：

{
  ...
  "uris": ["file:///home/core/.dockercfg"]
  ...
}

由于“core”是基于coreos的mesos从属服务器上的默认用户，并且根据约定，.dockercfg应该位于希望使用docker的当前用户的主目录中。
更新：这应该是最可靠的方法，但我还没有找到一个方法来做到这一点。就马拉松而言，该应用程序仍然永远停留在“部署”阶段。

使用密钥库服务

当我们处理用户名和密码时，aws密钥管理服务（甚至是cloudhsm）似乎应该是个好主意——但是afaik mesos没有内置的支持，我们处理的不是单个变量而是一个文件。

 故障排除

设置所选解决方案后，您可能会发现.dockercfg文件正在被下拉，但您的应用程序仍处于“部署”阶段。检查这些东西。。。

确保你的.dockercfg是mesos docker版本的正确格式

在某个时候，“auth”字段的格式被更改。如果您提供的.dockercfg与此格式不匹配，则docker pull将自动失败。群集从属服务器上的mesos docker版本所需的格式为：

{
  "https://index.docker.io/v1/": {
    "auth": [base64 of the username:password],
    "email": "your_docker_registry_user@yourdomain.com"
  }
}

不要将端口80用于应用程序

如果您正试图部署一个web应用程序，请确保您没有使用主机端口80—文档中没有任何地方写入该端口，但mesos web服务本身需要端口80，如果您尝试将80用于自己的应用程序，它将永远挂起。精明的读者会注意到，除其他原因外，这就是为什么中间层“oinker”web应用程序绑定到稍微不寻常的端口0。

您可以在集群中部署一个简单的s3代理服务，以便使用标准mesos fetcher从受凭据保护的s3 bucket下载：github.com/adyatlov/s3proxy。不需要hdfs或其他存储空间来存储机密。