汇总一周容器圈热点资讯，让开发者了解最 in 的容器技术，让企业熟知最实时的国内外容器行业动态
1.针对 Kubernetes 进行优化的容器运行时环境 – CRI-O 1.0 正式发布
2.Notary 是什么项目？为什么他对 CNCF 来说如此重要？
3.Oracle 开源 Fn，加入 Serverless 之争
针对 Kubernetes 进行优化的容器运行时环境 – CRI-O 1.0 正式发布
10 月 26 日，基于Kubernetes容器运行时接口（CRI）和 Open Container Initiative（OCI）标准容器的 CRI-O 1.0 版本发布。这是一个轻量级的，专门对 Kubernetes 进行优化的容器运行时环境。它是将 Docker 用作 Kubernetes 的运行时的一种轻量级的替代方案。
对于 CRI-O 团队而言今天是一个激动的日子。 就在一年前，Antonio Murdaca 和我们研发团队的 Antonio Murdaca 创建了一个名为 OCID 的项目，后来改名为 CRI-O。
我们的目标是为了确认我们是否可以构建一个简单的后台程序，这个程序既可以同时支持基于 Kubernetes 容器运行时接口（CRI）和 Open Container Initiative（OCI）标准的容器。也因如此，这个项目才会命名为 CRI-O。
当时我们认为由于上游的 Docker 项目变化太快，导致了 Kubernetes 的不稳定。因此我们认为通过简化容器运行时环境我们应该可以做的更好。
我们的第一个版本的 CRI-O v1.0 是基于Kubernetes 1.7版本。 工程团队希望有一个1.0版本。这是 OpenShift 3.7 中正在构建的版本。我们还计划近期发布 CRI-O 1.8，未来 CRI-O所有的版本都会与它们所支持的 Kubernetes 版本保持一致。
CRI-O 项目的另一个目标是与其他项目共享技术。 我们知道我们自己无法构建一切。 首先，我们需要能够支持与基于 OCI 标准的运行时环境如 runC 以及 Intel 的 Clear Containers 一起工作。
我们也希望使用像 containers/storage 以及 containers/image 这样的库，这样我们可以有效的取长补短。同时我们并不希望像其他的容器运行时环境一样将所有的锁以及容器状态放在内存当中，这种做法会阻止系统中的其它进程与镜像和及存储系统协同工作。因此 CRI-O 能够与 Skepeo 和 Buildah 这样的工具一起很好的工作。对于未来，我们很乐意能够看到其它项目能够分享这些内容。
对于这个项目而言，我们另外的一个目标是能够比其它的容器运行时环境更轻。能够占用更小的内容空间，以及相比其他容器运行时环境对 Kubernetes 提供更好的性能表现。
CRI-O 也非常感谢处于（容器生态系统）上游的 Docker 项目。正如 Isaac Newton 所说：“如果我能够看得更远，那一定是站在巨人的肩膀上”。同样，CRI-O 项目的工程师也从 Docker 项目中学习到了许多的经验。同时，我们也相信我们能够从他们过去的错误中吸取教训。由于开源，他们也能够借用一些其他的技术了。我们的工程师也会继续对Moby（原名 Docker）项目做出贡献，并且希望所有容器相关的项目都能够继续蓬勃发展。
V1.0 只是一个开始。我们对于 CRI-O 的未来还有很多大的计划。做出一些新的尝试，并且一如既往的欢迎贡献者们的加入。
Notary 是什么项目？为什么他对 CNCF 来说如此重要？
正如你听说的那样，Notary 项目正式加入云原生计算基金会（Cloud Native Computing Foundation，CNCF）。也如 notary(公证人)本意一样，Notary 是一个用于建立内容之间信任的平台。
在现实生活中，想买房子这样重要的事，一般由一个被称作“公证人”的值得信赖的第三方所促成。当你在购买房子时，“公证人”通常受雇于贷款人以验明你的身份，并作为你在抵押协议上签名的见证人。“公证人”携带特别的印章，并签署文件作为确认，核实与借款人有关的所有必要信息。
以类似的方式，最初由 Docker 赞助的 Notary 项目，旨在通过强大的加密签名提供对数字内容的高度信任。除了确保软件的来源之外，他还能提供保证：在供应链中的任何地方，未经作者批准，内容都不会被修改。这样就可以让附带 Docker Content Trust（使用 Notary）的 Docker 的产品建立更高级别的系统来制定明确的内容使用的政策。比方说，可以设置策略，只有签名的内容可以在运行时使用，并由 Docker 平台中的业务流程部署。总体来说，Notary 是 Docker 安全供应链的核心部分，其安全性无缝地统一嵌入到从开发到运营的工作流程中。
Notary 是一个写在 Go 中的 The Update Framework (TUF) 的执行，TUF 与 Notary 都被提交加入 CNCF 项目。这两个项目的综合性质吸引了大量的注资 – 规范和最广泛部署的实施将在 CNCF 的主持下进行。
诸如容器化和 Kubernetes 等技术已经成为 CNCF 的项目，Notary 和 TUF是首批与 CNCF 相关的安全项目。今年，数据安全方面的进展有着显著的上升，我们相信 CNCF 正通过 Notary 和 TUF 的加入，让自己置身于这方面的前列位置。我们希望随着时间的推移，CNCF 能增加更多以安全为重点的项目。
Oracle 开源 Fn，加入 Serverless 之争
Oracle 发布了Fn，Fn是一个新开源的、云平台无关的Serverless平台。它初始启动时拥有广泛的Java能力和一个JUnit测试框架，但也支持”任何编程语言”。
Fn 包含四个主要的组件：Fn 服务器、Fn FDK、Fn Flow 和 Fn 负载均衡器。Fn 服务器以 Go 编写，是运行代码的平台。
开发人员可以根据偏爱的语言使用一种 FDK（Function Development Kit），构建和测试实现业务功能的函数。函数打包之后，就部署到 Fn 服务器。Fn Flow 提供了一个用于工作流的时序控制和编排的工具，因此函数可以链接在一起以实现更高级别的业务流程。这消除了微服务架构由于服务需要彼此调用而导致的常见的耦合问题。负载均衡器是运营团队部署Fn服务器群集并将流量路由到其中的工具。
与最近发布的 Spring Cloud Function 项目一样，Oracle 的 Fn 提供了一个云平台无关的框架。函数打包成容器，可以在任何支持Docker的平台上运行。“container native”是Fn项目开发团队的具体目标，使其开源也是他们的目标。在一篇博文中，Oracle 软件开发副总裁 Chad Arimura 表示，Fn 团队认为开源是现在软件交付和采用的方式。因此，Fn 项目使用 Apache 2.0 许可证开源，而这一战略似乎正在取得成效。
Arimura 是 Iron.io 的前创始人兼 CIO。他以及开发 IronFunctions（开创性的 Serverless 平台之一）的团队去年搬到了 Oracle，然后就开发了 Fn 项目。尽管 Arimura 将Fn 平台无关性视为将其与其他 Serverless 框架区分开来的因素之一，但也许不足为奇的是，Fn 路线图的后续步骤之一是将其作为 Oracle Cloud 的服务。他还列出了 container-native、拥有更完整的开发人员支持并且 orchestrator 无关的关键特征，这些特征有助于 Fn 项目在 Serverless 领域脱颖而出。
这一期的『航海日志』就到这里，下期再浪～
参考链接
2.blog.docker.com/2017/10/not…
