【问题标题】:Maintaining and supporting container base images维护和支持容器基础镜像
【发布时间】:2017-07-01 00:01:28
【问题描述】:

我们的大部分基础设施都基于容器,我们正在成长中的公司。目前,每个开发组都管理自己的基础镜像(框架等),但在不久的将来,这似乎是一场管理噩梦。感觉必须有一些集中的解决方案来管理所有更新、漏洞监控等,因为我们对我们的开发人员做这项工作不太感兴趣,而是更专注于他们的主要职责。

我们最关心的是如何照顾

  • 使用开发框架(python、node.js)更新图像
  • 发现漏洞并提供更新后修补
  • 这一切都在规模

为了解决这个问题,我们公司不想管理所有的基础层和框架层,而是只专注于我们创建的应用程序层。

更新:

我们不改变框架和基础镜像,只改变上层,因为它们是我们的实际应用程序。上游的问题,例如 Python 图像:

  • 谁负责更新其操作系统层?
  • 谁负责更新其 Python(框架)层?
  • 谁能确保操作系统层是基于上游或任何其他标准操作系统层?

在很多情况下,框架层维护者关心的是框架而不是操作系统。

我们正在考虑外包给第三方公司,他们将为我们进行维护和支持。

感谢您对此的想法/想法。

【问题讨论】:

  • 这个范围很广,不同组织的解决方案会有所不同。您在谈论多少个基本图像?您在与上游官方镜像不同的基础镜像中自定义了什么?前两点主要是通过使用官方图像来处理的。然后更新补丁和漏洞就变成了更新FROM 图像(类似于您在应用程序中更新 Node.js 或 Python 依赖项的方式)。
  • 我已经更新了帖子。

标签: docker containers


【解决方案1】:

看起来您正在搜索的是企业级注册表。

您应该使用 Docker EE 检查 Docker Trusted Registry。它会处理你需要的大部分事情。

https://docs.docker.com/datacenter/dtr/2.0/

【讨论】:

  • 这个地址如何? OP 对安全补丁的担忧?
  • Docker 可信注册表确实有 CVE 检测。我想这可能会有所帮助。顺便说一句,无论如何我都不隶属于 Docker。还要注意,OP的问题非常广泛。我只是想给出一些解决方案。
  • DTR 的问题是我们仍然需要在内部对基础镜像进行所有更新,而这正是我们试图规避的。
  • 好吧,我明白了,您真正想要的不是软件,而是管理所有图像的公司/服务。除了 PaaS 提供商(即使它不是您真正要搜索的内容),我看不到任何解决方案。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2021-07-11
  • 2018-04-29
  • 2019-04-03
  • 1970-01-01
  • 2020-02-26
  • 2017-04-16
相关资源
最近更新 更多