容器是 2017 年的大新闻,无论是在 Opensource.com 还是在整个 IT 基础设施社区。 在过去的一年中,三个主要故事情节主导了容器新闻
- 第一个是 Kubernetes。 Kubernetes 作为将开放容器倡议 (OCI) 格式的容器组合成构成应用程序的托管集群的主要手段,获得了巨大的发展势头。 Kubernetes 越来越广泛的接受度很大程度上归功于其庞大而活跃的社区。
- 第二个是组件的标准化和解耦。 OCI 发布了其容器镜像和容器运行时格式规范的 1.0 版本。 CRI-O 现在提供了一种轻量级的替代方案,可以使用 Docker 作为 Kubernetes 编排的运行时。
- 第三个故事情节是安全性,人们普遍认识到需要从多个层面保护容器,以抵御由未修补的上游代码、对底层平台的攻击以及未快速更新的生产软件造成的威胁。
让我们来看看这些故事情节在开源世界中是如何发展的。
Kubernetes 和编排
对于在笔记本电脑上工作的单个开发人员来说,单独的容器很好。 但是,正如 Dan Walsh 在 Linux 容器是如何演变的 中指出的那样
当您开始同时运行多个容器并将它们连接到一个更强大的应用程序时,容器的真正力量就体现出来了。 设置多容器应用程序的问题在于,复杂性迅速增加,并且使用简单的 Docker 命令进行连接会失败。 如何管理跨资源有限的节点集群的容器应用程序的放置或编排? 如何管理他们的生命周期等等?
各种编排和容器调度项目都试图解决这个基本问题; 其中一个是 Kubernetes,它源于 Google 的内部容器工作(称为 Borg)。 Kubernetes 不断快速增加技术能力。
但是,正如 Anurag Gupta 在 为什么 Kubernetes 如此受欢迎? 中写道,这不仅仅是技术。 他说
Kubernetes 在最近几个月超越其他系统的原因之一是系统背后的社区和支持:它是最大的开源社区之一(GitHub 上超过 27,000 颗星); 有来自数千个组织(1,409 名贡献者)的贡献; 并且位于大型中立的开源基金会 Cloud Native Computing Foundation (CNCF) 中。
Google 的 Sarah Novotny 进一步深入了解了使 Kubernetes 成为一个充满活力的开源社区需要什么; 她在 4 月份的播客中的讲话在 Kubernetes 如何让贡献变得更容易 中进行了总结。 她说,它始于“成为一个成功的项目,因此找到采用,扩大采用,找到贡献者,发展他们需要的最佳工具集或他们的最终用户需要的平台。 这是根本。”
标准化和解耦
OCI 是 Linux 基金会的一部分,于 2015 年启动,“旨在围绕容器格式和运行时创建开放行业标准。” 目前有两个规范:运行时和镜像,这两个规范都在 2017 年发布了 1.0 版本。
这里的基本思想非常简单。 通过在这个层面上进行标准化,您可以提供一种合同,允许在其他领域进行创新。
OCI 的执行董事 Chris Aniszczyk 在 2 月份的开源领导力峰会上这样说
人们已经吸取了教训,我认为他们希望在能够让市场增长的事情上进行标准化。 每个人都希望容器能够非常成功,在任何地方运行,拓展业务,然后在实际的更高层次上竞争,围绕它销售服务和产品。 不要试图以一种人们不会采用容器的方式来分割市场,因为他们担心容器还没有准备好。
以下是这种方法使之成为可能的几个具体示例。
CRI-O 项目最初是一种创建专门用于 Kubernetes 的最小可维护运行时的方法。 正如 Mrunal Patel 在 CRI-O:Kubernetes 需要的所有运行时 中描述的那样
CRI-O 是 Kubernetes CRI [容器运行时接口] 的一个实现,它允许 Kubernetes 使用任何符合 OCI 的运行时作为容器运行时来运行 pod... 它是使用 Docker 作为 Kubernetes 运行时的轻量级替代方案。
通过这种方式,CRI-O 允许混合和匹配容器软件堆栈的不同层。
一个更新的社区项目是 Buildah。 它使用底层容器存储来构建镜像,并且不需要运行时。 因此,它还使用主机的包管理器来构建镜像,因此,生成的镜像可以小得多,同时仍然满足 OCI 规范。 William Henry 的 Buildah 入门(发表在 Project Atomic 上)提供了更多详细信息。
正如 William 和我在我们的免费电子书 从罐和桶到程序和应用程序:软件如何学会打包自己 (PDF) 中讨论的那样,更大的重点是 OCI 标准化已经在软件堆栈的更高级别上释放了大量的创新。 许多镜像构建、注册表拉取和推送服务以及容器运行时服务现在都由 OpenShift 等更高级别的工具自动执行。
多层容器安全
容器安全发生在许多层面上; Daniel Oh 列出了 10 层 Linux 容器安全。 它从熟悉的基础设施层面开始。 这是 SELinux、cgroup 和 seccomp 等技术特性发挥作用的地方。 平台的安全性只是我之所以说 操作系统在 2017 年更加重要的原因之一,因为它涉及到容器的许多方面。
但是,Daniel 也观察到您需要考虑的许多其他容器层。 “容器内的东西很重要。” 他补充说,“与您从外部来源下载的任何代码一样,您需要知道软件包的来源、谁构建了它们,以及其中是否包含任何恶意代码。”
对于传统的软件开发流程来说,不太熟悉的可能是保护构建环境,即软件部署管道本身。 Daniel 指出,
管理此构建过程是保护软件堆栈的关键。 坚持“构建一次,随处部署”的理念可确保构建过程的产品与生产环境中部署的产品完全相同。 保持容器的不可变性也很重要——换句话说,不要修补正在运行的容器; 而是重建并重新部署它们。
其他值得关注的领域包括保护 Kubernetes 集群、隔离网络、保护持久性和临时存储以及管理 API。
展望 2018 年
我预计所有这三个领域在 2018 年仍将是重要的主题。 但是,我认为最大的新闻之一将是围绕容器的开源生态系统的持续扩展。 来自云原生计算基金会的 landscape 文档 对整体范围有所了解,但它包括从容器运行时到编排到监控到配置到日志记录到分析的所有内容。
它可以很好地说明围绕容器的开源社区中发生的活动水平以及开源开发模型创建良性活动循环的力量。
评论已关闭。