Skip to content

使用单个 Manifest 配置多个应用

MindSphere Cloud Foundry 需要用单个 Manifest 文件描述的多个应用。 此文件包含所有应用的属性,例如应用名称、内存限制、服务绑定和路由,并允许使用单个 cf push 命令部署这些属性。

Operator Cockpit 使用单个 manifest 在生产系统中自动注册您的应用。 本节描述 manifest 中的必要属性,并提供一个简短的清单,用于将应用转移到生产系统。

应用组件和 Cloud Foundry 应用

您可以使用 MindSphere 将软件设计和创建为服务。 大多数应用由多个服务组成,这些服务组合在一起可以通过单个入口点访问,例如,过单击 Launchpad 上的图标。 在访问应用时,将加载多个资源并发出许多请求。 这些请求和资源可能由不同内部服务在后台提供,客户或客户端无法看到这些请求和资源。

为了实现这种行为,MindSphere 有一个集成的应用网关,位于客户端和服务之间。 其充当反向代理,将请求从客户端路由到不同的服务。 当将其映射到 Cloud Foundry 时,服务是在相同的 Cloud Foundry 空间中运行的各 Cloud Foundry 应用。

在部署期间,每个应用都得到一个分配的路由,除非您希望有一个完全内部的、仅与后端服务通信的服务。 为了避免不受保护的服务意外暴露在 Internet 上,您必须在 Developer Cockpit 中注册每个路由才能对其进行访问。 在 Developer Cockpit 中,我们使用术语“组件”来命名映射到一个 Cloud Foundry 应用的单个服务。 组件的名称必须与 Cloud Foundry 应用的名称匹配,该应用的名称在 Cloud Foundry manifest 配置文件中定义。

配置 manifest 文件

定义随机路由和显式路由

Cloud Foundry 提供了多种为应用定义路由的方法。 您可以使用 CLI 或 Manifest 中的 routes 属性来定义应用的路由。定义路由的首选方法是使用从应用名称自动生成的随机路由。

注意

弃用 manifest 文件中的 hostdomainroute 属性。只支持 routesrandom-route

China 1的离线 Buildpacks

MindSphere Cloud Foundry 在 China1的服务应使用离线 Buildpacks 来避免由于从不稳定的国际网络访问下载外部依赖项而导致潜在的失败。

您可以运行 cf buildpacks 来检查 manifest 文件中使用的 build pack 名称。例如,您应该使用 java_buildpack_offline 而不是 java_buildpack 来 manifest文件。

例如,如果您有一个名为 monitorservice 的应用,配置可能如下所示:

applications:
- name: monitorservice
  stack: cflinuxfs3
  instances: 1
  random-route: true
  buildpacks: 
    - java_buildpack
  path: /monitorservice/target/monitorservice-0.0.1.BUILD-SNAPSHOT.jar
  memory: 1GB
  services:
    - mymongodb
- name: monitorui
  stack: cflinuxfs3
  instances: 1
  random-route: true
  buildpacks: 
    - staticfile_buildpack
  path: /monitorui/www
  memory: 1GB

我们使用上述配置部署了应用后,Cloud Foundry 将创建一个类似于此 monitorservice-grateful-jaguar.apps.myRegion.mindsphere.io 的路由。 只要应用或路由未被删除,生成的随机路由就会被重复使用。

在下一个示例中,我们将为我们的应用之一使用诸如 monitorservice-myTenant.apps.myRegion.mindsphere.io 之类的显式路由定义。 如果您需要在 Cloud Foundry 应用之间进行调用,这十分有利。但是,这需要您在路由中添加租户名称,以避免路由冲突。 将此步骤应用于上一个示例时,我们最终得到以下配置:

applications:
- name: monitorservice
  stack: cflinuxfs3
  instances: 1
  buildpacks: 
    - java_buildpack
  routes:
  - route: monitorservice-myTenant.apps.myRegion.mindsphere.io
  path: /monitorservice/target/monitorservice-0.0.1.BUILD-SNAPSHOT.jar
  memory: 1GB
  services:
    - mymongodb
- name: monitorui
  instances: 1
  routes:
  - route: monitorui-myTenant.apps.myRegion.mindsphere.io
  buildpacks: 
    - staticfile_buildpack
  path: /monitorui/www
  memory: 1GB

在最后一步中,定义或生成的路由用于配置 Developer Cockpit 中的组件。 每个组件都需要

  • 一个必须与 Cloud Foundry 应用名称匹配的名称以及
  • 一个 Cloud Foundry URL,即路由。

双重路由

请注意,您不能在开发和生产系统中重复使用相同的路由。因此,我们建议使用随机路由或在路由后加上租户名称。您可以使用 cf check-route ROUTE 命令来检查是否可用。

为后端服务添加绑定

在路由配置旁边,manifest 还可能包含一个或多个后端服务的绑定。 确保在 manifest 文件中添加所有绑定,并在 Developer Cockpit 中使用正确的实例名称配置所需的后端服务计划。

目录结构

我们建议使用一个目录结构,其中每个应用都留在一个子目录中。 您可以使用 路径 属性指向每个应用的正确目录。 上一节中的示例路由配置已经反映了此结构,并使用了正确的 路径 值。

├───monitorservice
│ ├───src
│ └───target
├───monitorui
│ └───www
├───.cfignore
└───manifest.yml

二进制上传

使用相同的结构创建 ZIP 文件,以避免在生产系统上部署时出现任何问题。

为操作员部署准备应用

在成功地测试了应用之后,您可以将其转移到应用仓库中,以供生产使用。 下面的清单和目录结构指南将帮助您准备一个生产版本。

准备清单

若要将应用转移至应用仓库,并最终将其分配给操作员,您应检查以下各点,以避免出现任何问题:

  • [ ] 每个组件名称都有一个匹配的 Cloud Foundry 应用(名称),如 manifest 文件中定义的那样
  • [ ] 所有绑定都存在于 manifest 文件中。
  • [ ] Cloud Foundry manifest 不包含 hostdomainroute 属性。只支持 routesrandom-route
  • [ ] 路由仍然可用,并且/或者通知操作员所需的路由更改(例如替换租户名称)。
  • [ ] 为每个应用配置正确的内存大小。
  • [ ] 设置了所有需要的环境参数。
  • [ ] 所有 路径 值都与目录结构匹配。
  • [ ] 定义 stack 以此来使用您的应用。
  • [ ] 明确定义 buildpack,特别是在使用 staticfile buildpack 时。
  • [ ] 将固定的依赖关系设置为特定版本,或对补丁版本使用通配符。
  • [ ] 避免将下列格式的二进制文件移交给操作员租户: .cfignore, _darcs, .DS_Store, .git, .gitignore, .hg, manifest.yml, .svn. 否则,部署后会产生不可预知的行为。
  • [ ] Test the deployment at least once with the single manifest file.
  • [ ] 使用单个 manifest 文件至少测试一次部署。
  • [ ] 使用上面提到的目录结构。

还有问题?

向社区提问


除非另行声明,该网站内容遵循MindSphere开发许可协议.


Last update: April 1, 2020