标签：不能 user container 支持 生命周期 共享文件 有一个 无法 Opens
OpenShift v3带来了许多架构变化，并引入了新的概念和组件。它围绕在Docker 容器中运行的应用程序 ，Kubernetes项目提供的调度和管理支持 以及顶部的增强部署，编排和路由功能构建。
围绕容器模型以及如何监控和互连最重要的变化。Kubernetes pod是一组容器，其行为类似于单个VM：它们具有单个IP地址，可以共享文件系统，并且它们通常具有类似的安全设置。将容器分组在一起大大增加了可以为OpenShift带来的应用程序数量。pod不是专注于微服务模型而是排除所有其他模式，而是使开发人员能够移植需要共享本地资源的现有应用程序，同时仍然受益于容器化模型。
其次，OpenShift容器应该是不可变的：图像包含应用程序代码及其依赖库的特定快照，而任何配置，机密或持久数据在运行时附加到容器。这允许管理员和集成商将代码和补丁与配置和数据分开。虽然仍然可以改变容器，但构建和部署的更高级别概念利用不可变容器来提供更高级别的保证，以确保在哪里运行代码。
第三个重要的变化是核心系统设计：OpenShift和Kubernetes是作为微服务集合构建的，它们通过通用REST API协同工作 来改变系统。系统集成商可以使用这些相同的API，并且可以禁用这些相同的核心组件以允许其他实现。一个很好的例子是 监视 API：客户端可以连接并接收对pod（或其他对象）的更改流，并在pod可用时对其进行操作（发出错误信号或记录对系统的更改）。OpenShift在REST API上公开了细粒度的访问控制以启用此集成，这意味着系统中没有任何操作也无法由集成商完成。
以下主题提供了有关新体系结构和概念的更多信息，以帮助您了解OpenShift v3中的新增功能。
OpenShift v2中的应用程序
应用程序一直是OpenShift的焦点。在OpenShift v2中，应用程序是一个单独的单元 - 它由一个Web框架组成，并且不超过任何给定的盒式磁带类型。例如，一个应用程序可以有一个PHP和一个MySQL，但它不能有一个Ruby，一个PHP和两个MySQL。它本身也不可能是一个MySQL盒式磁带。
应用程序的有限范围意味着OpenShift可以使用定义良好的环境变量为应用程序内的所有组件执行无缝链接。例如，每个Web框架都知道如何使用OPENSHIFT_MYSQL_DB_HOST和OPENSHIFT_MYSQL_DB_PORT变量连接到MySQL。但是这种链接仅限于应用程序内部，并且仅适用于协同工作的盒式磁带。没有什么可以帮助跨应用程序组件链接，例如跨两个应用程序共享MySQL实例。
OpenShift v3中的应用程序
从OpenShift v2可以清楚地看出，解决整个应用程序的问题至关重要。大多数其他PaaS仅限于Web框架，并依赖于其他类型组件的外部服务。OpenShift v3通过使更多应用程序拓扑成为可能并使现有拓扑更易于管理而采取后续步骤。
实现此目的所需的第一步是将“应用程序”作为关键字删除，因为“应用程序”可能意味着每个人都有所不同。相反，您可以根据需要包含任意数量的组件，由项目包含 ，灵活地链接在一起，并可选择标记以提供任何分组或结构。这个新模型允许独立的MySQL实例，或JBoss组件之间共享的实例，或者您可以想象的任何组件组合。
灵活链接意味着您可以将任意两个任意组件链接在一起 只要一个组件可以导出环境变量而第二个组件使用这些环境变量中的值，并使用潜在的变量名称转换，就可以将任何两个组件链接在一起，而无需更改它们所基于的图像。因此，可以直接使用所需数据库和Web框架的最佳容器化实现，而不是必须将它们分叉并重新编写它们以实现兼容。
结果意味着您可以在OpenShift上构建任何内容。这就是OpenShift真正要解决的问题：一个基于容器的平台，可以让您在可重复的生命周期中构建整个应用程序
标签：不能 user container 支持 生命周期 共享文件 有一个 无法 Opens
原文地址：https://www.cnblogs.com/mascot1/p/9571618.html
