4.4. Cartridges 和镜像的比较

在 OpenShift v3 中，镜像（image） 代替了 OpenShift v2 中的 cartridge 的概念。

在 OpenShift v2 中，cartridge 是构建应用程序的中心。每个 cartridge 都提供所需的库、源代码、构建机制、连接逻辑和路由逻辑，以及预配置的运行应用程序组件的环境。

但是，Cartridges 有一定的缺陷。在使用 cartridge 时，开发者的内容和 cartridge 内容之间没有明显的区别，而且您对每个应用程序的 gear 中的家目录中并没有所有者权限。另外，对于大型的二进制代码，Cartridge 也不是一个的最佳的发布方式。用户虽然可以使用 cartridge 以外的外部依赖关系，但这样做会失去封装所带来的益处。

从打包的视角来看，镜像与 cartridge 相比会执行更多的任务，并提供更好的封装和灵活性。但是，cartridge 还包括了构建、部署和路由的逻辑，这些逻辑在镜像中并不存在。在 OpenShift v3 中，这些额外的需求由 Source-to-Image(S2I) 和 配置模板来满足。

依赖项

在 OpenShift v2 中，cartridge 的依赖项通过 cartridge 清单中的 Configure-Order 或 Requires 定义。OpenShift v3 使用声明模型（declarative model）， pod 能够与预定义状态保持一致。应用的显式依赖项是在运行时进行的，而不是只使用安装时的顺序。

例如，在启动前，您可能需要一个特定的服务可用。这种依赖关系的检查一直会适用，而不只是您创建这两个组件时。因此，将依赖性检查放到运行时中进行，可使系统保持健康状态。

集合(Collection)

在 OpenShift v2 中，cartridge 在 gears 中进行托管，而在 OpenShift v3 中，镜像 和 容器 有一对一的映射关系，容器使用 pod 作为托管机制。

源代码

在 OpenShift v2 中，应用程序必须至少有一个带有 Git 存储库的 Web 框架。在 OpenShift v3 中，可以选择哪些镜像通过源进行构建，并且该源可以位于 OpenShift 本身之外。由于源并不与镜像相连接，选择镜像和选择源的操作是独立的，其中源是可选的。

Build

在 OpenShift v2 中，构建在应用程序的 gear 中进行。这意味着，非扩展的应用程序会因为资源限制造成停机。在 v3 中，构建发生在不同的独立容器中。另外，OpenShift v2 构建结果使用 rsync 对 gear 进行同步。在 v3 中，构建结果首先作为不可变镜像提交，并发布到内部 registry。然后，该镜像就可以在集群中的任何节点上启动，或者在以后使用它来把系统回滚到特定的时间。

路由

在 OpenShift v2 中，您必须预先选择应用程序是否可扩展，以及应用程序的路由层是否启用了高可用性(HA)。在 OpenShift v3 中，路由是一个对象，只要通过将应用程序组件扩展到两个或多个副本即可实现 HA。不需要重新创建应用程序或更改其 DNS 条目。

路由本身与镜像是不连接的。在以前的版本中，cartridge 定义了一组默认的路由，您可以为您的应用程序添加其他别名。对于 OpenShift v3，您可以使用模板为镜像设置任意数量的路由。这些路由可让您根据需要修改 scheme、主机和路径，系统路由和用户别名并没有区别。