我们已经在私有(private)VPC上与AWS上的Mesosphere建立了测试集群。我们有一些公开的Docker镜像,这些镜像很容易部署。但是,我们的大多数服务都是私有(private)镜像,托管在Docker Hub私有(private)计划上,并且需要身份验证才能访问。

Mesosphere能够进行私有(private)注册表身份验证,但是它以不完全理想的方式实现了此目的:需要在所有Mesos/Marathon任务定义中指定指向.dockercfg文件的HTTPS URI。

顾名思义,问题基本上是:.dockercfg文件应如何托管在AWS内,以便尽可能严格地将访问限制为仅对Mesos主服务器+从服务器进行访问?

请您参考如下方法:

由于Mesos文档在此方面相当差,因此我将回答这种Wiki样式并在进行时更新此答案。

可行的策略
将其托管在S3上(具有基于网络的访问限制)
将.dockercfg文件托管在S3上。为了提高安全性,您应该考虑将其放在自己的存储桶中,或者放在专用于存储 secret 信息的存储桶中。这在创建安全策略时会带来一些有趣的挑战,该策略实际上将锁定S3存储桶,以便只有Mesos可以看到它,但是可以做到。
Mesos任务配置:

{ 
  ... 
  "uris": ["https://s3-eu-west-1.amazonaws.com/my-s3-bucket-name/.dockercfg"] 
  ... 
} 
S3存储桶策略(使用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存储桶条件。 (我猜如果您不使用VPC端点,您可以只在VPC ID上进行匹配吗?)
您可以转到Mesos UI(如果使用的是DCOS,这不是漂亮的DCOS UI)并观察具有应用名称的任务是否出现在“事件任务”或“已完成任务”列表中,以检查其是否有效。
诱人的策略不起作用(尚未)
将其托管在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之类的配置管理工具自动化该方法,它将变成一种更可行的生产方法,该工具将在从属服务器上运行,并将.dockercfg文件拖到正确的位置。
    这将导致如下配置:
    { 
      ... 
      "uris": ["file:///home/core/.dockercfg"] 
      ... 
    } 
    
    由于'core'是基于CoreOS的Mesos从站的默认用户,因此按惯例,.dockercfg应该位于要使用Docker的当前用户的主目录中。
    更新:这应该是最可靠的方法,但是我还没有找到一种方法。就马拉松而言,该应用程序始终处于“部署”阶段。
    使用 keystore 服务
    由于我们正在处理用户名和密码,因此,AWS key 管理服务(或什至是CloudHSM)似乎应该是一个好主意-但是AFAIK Mesos没有对此的内置支持,因此我们不处理个人问题。变量,而是一个文件。

    故障排除
    设置完您选择的解决方案后,您可能会发现.dockercfg文件已被下拉正常,但您的应用程序仍停留在“部署”阶段。检查这些东西...
    确保您的.dockercfg是适用于Mesos Docker版本的正确格式
    在某些时候,“身份验证”字段的格式已更改。如果您提供的.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,它会永远挂着。精明的读者会注意到,除其他原因外,这就是为什么Mesosphere“Oinker” Web应用绑定(bind)到端口0的稍微不同寻常的选择的原因。


    评论关闭
    IT干货网

    微信公众号号:IT虾米 (左侧二维码扫一扫)欢迎添加!