Linux 容器正在改变 IT 从业者的工作方式。相比于庞大、沉重的虚拟机，一些组织发现把他们的应用部署在容器中更有效，可以提供更快的速度，更加密集，提升他们操作的敏捷性。

从安全的角度看，容器带来了一些优势，但是也面临着它们自己的一些安全挑战。和传统的基础设施一样，为了避免安全缺陷，确保运行在一个容器内的组件和系统库的定期更新是至关重要的。但是你如何知道什么东西运行在你的容器内？为了帮助你应对这些的安全挑战，一个名为 Anchore的初创公司正在开发一个同名的开源项目，它用来帮助展示 Linux 容器中的内容。

为了了解更多关于 Anchore，我找到了 Anchore 的市场和产品的发言人 Andrew Cathrow，来了解更多关于这个开源项目背后的公司。

简而言之 Anchore 是什么? 它如何工作?

Anchore 的目标是提供一套工具，允许开发人员、运营团队、安全团队在容器的整个开发周期中保持对“监管链（Chain of Custody）”的全程可见，并提供生产部署所需的可见性、可预测性和控制性。Anchore 的引擎通过插件可以进行分析（通过提取镜像数据和元数据）、查询（允许对容器进行分析）、以及策略评估（这里的策略指可以被指定的管理的图像）。

虽然市场上有很多扫描工具，但是大部分不开源。我们认为安全合规的产品应该是开源的，否则你怎么才能信任他们。

Anchore 除了开源以外，还有两大优势，使它可以区别于市场中的商业产品。

首先，我们看的不止是操作系统的镜像。如今的扫描工具专注于操作系统的软件包，比如“你的 RPM 或 DEB 包中有CVE（安全漏洞）么？”这虽然是很重要的，你不希望你的镜像中有不安全的包，但是操作系统包只是镜像的基础。其他的层次都需要进行验证，包括配置文件、语言模块、中间件等等。你可以用的全是最新的软件包，但是可能一个配置文件配置出现错误，不安全就出现在里面。第二个不同就是允许用户添加自己的数据、查询或策略来扩展这个引擎。

什么推动了容器的校验和分析工具的需求出现？这个工具可以解决运营面临的什么问题呢？

企业使用 Docker 首要关注的就是安全，特别是他们正在部署的容器的分配和合规性。在生产环境中，从公共镜像库拉取一个镜像，运行它，并在几秒钟部署，是非常简单的，甚至不知道下面可能发生什么。终端用户在部署应用时，必须信任他们所部署的是安全、高效和易于维护的。

容器是不透明的，它们是一个包含应用程序的可部署的“黑盒”。虽然非常容易把这些镜像看作“打包的应用程序”，但是它们包括了系统的镜像和多达数百个包和成千上万个文件。如同所有在物理服务器、虚拟机或者云上的操作系统一样，镜像也需要维护。镜像或许包含了未补丁的安全缺陷、带有 bug 和错误配置的过期软件。

要对您的容器部署有信心，你需要知道底层是什么，并基于容器镜像的内容来做出决定。

如今容器的创新基本上都是开源的，你认为是为什么呢？是什么促使了它们开源呢？

在过去的 20 年中，各个组织已经经历了开源带来的优势，节省成本，减少锁定，提高了安全性和更快的创新。容器，特别是 Docker，都是非常好的例子。Docker 公司的团队不能在专有系统上创建一个新的软件部署模式，他们不能要求在修改专有系统的代码，而是与行业领导者比如谷歌、IBM、英特尔、红帽合作，朝着一个共同的目标。开源和 Linux 总是开启创新和激励产业困境。在过去，实现一个大的想法需要一个大的团队和很多资源。在开源世界，一个有着很大的创意的小公司可以工作在一个更大的社区中，通过知识共享的力量来协作，提供真正的企业创新。

为了深入的说明开源的使用，Anchroe 团队最近刚从多伦多的 LinuxCon 回来，在哪里，令人难以相信的是，微软作为钻石级的赞助商，展示了他们用在 Linux 上的产品投入的增长。Linus Toravlds 曾说过，“如果微软为 Linux 开发应用就意味着我赢了”。我要把这句话改为“开源赢了”。

容器领域的通用标准的创建还需要时间，在容器的几乎所有部分，仍有许多挑战。在这个领域，创业公司有哪些挑战？

这里有个很重要的点，就是没有开放的标准和开源，我们不可能看到快速推动容器的采用和改变行业格局的创新。开放容器倡议（OCI）由 Linux 和容器行业的行业领导者组成，正在为运行环境和镜像格式创造标准，这将使我们能够看到更多的创新。Anchore 很自豪能成为 OCI 的新成员，我们期待帮助形成标准。

你将如何围绕 Anchor 项目建立一个开源社区？

Anchore 团队来自 Ansible、Eucalyptus Systems 和 Red Hat 的领导团队，在开源社区中拥有丰富的工作经验。从一开始，Anchore 就准备创建一个强大的开源社区，我们正在应用我们在开源世界中学到的经验和教训。第一课，当然，发布要尽早尽快。我们在 6 月开源我们的检测和分析引擎，远远早于我们的商用产品，以便了确保开源项目能够独立运行，使更多的直接用户能够使用它，而无需购买 Anchore 的商用产品。通过支持、服务和增强型的数据源，有很多机会给商用产品创造更多价值，但是如果开源引擎本身没有用，我们将看不到活跃的社区。

我们将 Anchore 模块化，允许添加分析、报告和策略插件，而不需要更改核心的引擎。我们希望保证任何人都可以创建插件，所以我们选择了 Python 作为项目的基本语言，因为 Python 被开发者和系统管理员广泛应用。但是，即使你不熟悉 Python，你仍然可以使用任何你喜欢的语言或者脚本环境创建插件。如果你可以创建一个 Bash 脚本，那么你也可以创建一个 Anchore 插件。我们的目标是最大化的吸引社区的参与。虽然我们鼓励用户将贡献回馈给社区，但是我们也为这个项目构建并进行了授权，来确保可以独立创建和维护私有的插件和模块。

容器的用途不止是在服务器上更大密度的部署应用程序或者技术层面更快的速度，而且还有不同工具的组合，这些工具提供了一种不同的方式来拉近开发者和操作者共同工作。作为在这个领域工作的公司，你们希望提供一个什么样的消息来让开发者和运营产生共鸣？

随着越来越多的运行环境、编排、监控和集成产品，容器的生态系统正在快速发展。所以，我们的架构中的第一个考虑因素不是限定 Anchore 的部署和使用。我们需要确保我们可以适应任何 CI/CD 工作流，无论是私有部署还是云端部署。一个经常问到我们的问题是，Anchore 是否将提供一个包含了镜像扫描和分析的容器仓库。虽然这将大大简化我们的工作，但是这会迫使用户进入特定的部署架构，并限制了用户部署他们自己最好的组件的能力。我们已经确保 Anchore 可以和所有领先的仓库、运行环境平台、 CI/CD 平台和编排工具配合使用。

一些开发者掌握了运营技能，并转换为 DevOps 角色，我们看到系统管理员/运营团队也在更多的了解开发，转换成 DevOps 角色。我们也看到了具有混合能力的团队。我们设计了可供开发运营和安全团队使用的 Anchore ，以便他们共同定义规则和策略来评估开发周期中的任何一个环节。另外一个例子是插件/模块的架构，使任何人都可以在他们喜欢的环境中轻松创建一个模块 —— 无论是以 Python、Go、Perl、C 甚至是一个 Bash 脚本。