应用程序
https://github.com/oam-dev/spec/blob/master/7.application.md
本节描述了应用程序如何被设计和部署。
直到当前模型的v0.3.0,Application 被称为ApplicationConfiguration。
应用
Application实体定义了一旦应用被部署就会被实例化的组件列表。
用户将指定每个组件的最终参数化以及应用于增强其功能或改变其行为的特性。此外,还可以指定一组范围,将不同的组件子集分组。
顶层属性
应用程序的顶级属性定义了它的元数据、版本、种类和规格。
Attribute | Type | Required | Default Value | Description |
---|---|---|---|---|
apiVersion |
string |
Y | A string that identifies the version of the schema the object should have. The core types uses core.oam.dev/v1beta1 in this version of documentation. |
|
kind |
string |
Y | Must be Application |
|
metadata |
Metadata |
Y | Information about the application. | |
spec |
Spec |
Y | A specification for application attributes. |
Spec
应用程序的规范定义了要创建的组件、附着在每个组件上的特征以及组件所投放的一组作用域。
Attribute | Type | Required | Default Value | Description |
---|---|---|---|---|
components |
[\]Component |
Y | Component specification. |
Component
Attribute | Type | Required | Default Value | Description |
---|---|---|---|---|
name |
string | Y | The name of the component instance. | |
type |
string | Y | 对将被应用程序实例化的组件定义的引用。可以选择以<namespace>/<component_name> 的形式来引用一个被命名的组件。命名空间的含义是具体实施的,取决于正在使用的运行时和创建实体的目标平台。在Kubernetes的情况下,“namespace” 的概念与Kubernetes的现有概念相匹配。 |
|
properties |
Properties |
Y | 一组分配给组件示意图中暴露的参数的值。 | |
traits |
[\]Trait |
N | 要附加到这个组件实例的特性。 | |
scopes |
map[string]string |
N | 包含组件所属的作用域的映射。该映射使用限定的作用域定义名称作为键(例如,“scope.company.com”),而作用域的名称作为值(例如,“myscope”)。注意,这个引用意味着目标作用域的一个具有特定名称的实体存在。 |
该 name
必须遵循这些命名规则:
name字段是必需的,必须是63个字符或更少,以字母数字字符([a-z0-9A-Z])开头和结尾,中间有破折号(-)、下划线(_)、点(.)和字母数字。
Trait
Attribute | Type | Required | Default Value | Description |
---|---|---|---|---|
type |
string | N | 对特质定义名称的引用。对于一种类型的特质,一个组件中可能只有一个配置。 | |
properties |
Properties |
Y | 使用该特性的属性值。 |
请注意,Traits不需要名字,因为是OAM运行时负责实例化traits。组件的名称被期望用于相关的特征。
Properties
属性(Properties)指定与实体属性相关的值。
当与组件关联时,设置的值将覆盖组件的参数,遵循组件原理图中定义的原理图。
当属性被用于特质或作用域时,它们会设置这些实体所需的值,以便被实例化。结构是由定义引用决定的。它可能是一个简单的值,也可能是一个复杂的对象。属性会根据适合于特质或作用域的模式进行验证。
示例
下面是一个完整的YAML文件的例子,它表达了组件、特性和作用域。这个例子说明了一个组件的四个可配置元素:它的类型、属性、特征和作用域。
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: my-example-app
annotations:
version: v1.0.0
description: "Brief description of the application"
spec:
components:
- name: publicweb
type: web-ui
properties: # properties targeting component parameters.
image: example/web-ui:v1.0.2@sha256:verytrustworthyhash
param_1: "enabled" # param_1 is defined on the web-ui component
traits:
- type: ingress # ingress trait providing a public endpoint for the publicweb component of the application.
properties: # properties are defined by the trait CRD spec. This example assumes path and port.
path: /
port: 8080
scopes:
"healthscopes.core.oam.dev": "app-health" # An application level health scope including both components.
- name: backend
type: company/test-backend # test-backend is referenced from other namespace
properties:
debug: "true" # debug is a parameter defined in the test-backend component.
traits:
- type: scaler # scaler trait to specify the number of replicas for the backend component
properties:
replicas: 4
scopes:
"healthscopes.core.oam.dev": "app-health" # An application level health scope including both components.
上面的例子说明了一个完整的应用程序,包括它的作用域、组件和它们的特质。这个应用程序假定存在两个组件定义,分别代表网络用户界面和一个假想的应用程序的后台。两个特性被用来增强组件的功能。首先是后端设置复制因子的扩展器,以及将应用程序暴露给外部世界的入口器。此外,HealthScope被用来有一个共同点来检查网络和后端组件的状态。这是一个任意的组件集,不一定需要所有的组件。
在应用实例化时,运行时有望根据目标系统(如Kubernetes)生成所需的实体,并强制执行与每个实体(如trait)相关的模式。由于特质可以作为扩展添加到现有环境中,运行时必须能够创建任何通过特质定义(TraitDefinition)在系统上注册的特质实体。
组件实例
组件实例是在应用程序的部署过程中创建的。它是在一个组件与配置一起部署时创建的。
- 每次部署一个组件时,它必须与一个应用程序一起部署。本规范的这一部分描述了配置。
- 组件的每一次后续升级都会修改给定的实例,或者如果有任何修订意识的特征附加到组件上,则会产生一个新的修订实例。
- 当一个实例第一次被创建时,它处于初始修订状态。每次发生升级操作时,我们就说该实例发生了新的修订。(然而,并没有假设一定有一个相应的修订对象存储在某个地方)。
发布
在十二因素应用中,发布(release)被定义为 构建加上一组配置。也就是说,对构建或配置的任何改变都会产生一个新的版本。在开放应用模型中,类似的情况是,组件、特质和作用域对象与应用相结合,共同构成一个发布。
对于OAM应用程序,发布是这样定义的:
发布是一个命名的应用程序,连同其相关的组件、作用域和特性的描述。
此外,当一个应用程序被发布时,它的组件实例也被发布。
为了适应这个发布的定义,OAM平台应该做出以下假设:
-
应用程序是可变的。
-
对应用程序的任何改变都会导致(从概念上讲)一个新的发布,取代旧的发布。
- 如果应用程序被更新,并且新版本包括原始应用程序中不存在的组件,则必须创建组件实例。
- 如果应用程序被更新,而新版本中没有以前的应用程序所包含的组件的记录,那么该组件实例必须被删除。
- 同样,特性也应该根据同样的准则被附加和分离。
- 组件与应用范围的关系应根据同样的准则来应用或删除。