manifest文件的常用配置项

接下来，我们介绍一下manifest文件中几个常用的配置项。每个配置项都有一个对应的命令行参数，同时，命令行参数的优先级是高于manifest文件中的配置项。

一个典型的Java / SpringBoot应用程序的manifest文件如下所示，

---applications:- name: greeting-spring  path: target/gs-rest-service-0.1.0.jar  instances: 2  memory: 256M  disk_quota: 256M  random-route: true  stack: cflinuxfs2  buildpack: https://github.com/cloudfoundry/java-buildpack.git#v3.13  services:  - user-pg  - cache-redis  env:    newrelic: LICENSE-KEY

1. path配置项。通常，对于Java或者其他需要编译的应用程序，我们用path配置项指定编译后应用程序源码的路径。
2. instances配置项。instances配置项可以指定推送应用程序的实例个数。
3. memory配置项。memory配置项可以指定推送应用程序的内存容量。

4. disk_quota配置项。disk_quota配置项可以指定推送应用程序的磁盘空间。

   使用上述三个参数instances、memory、disk_quota的一个典型的应用场景是推送同一份源码到不同的环境时，我们在不同的manifest文件中设置不同的配置值。例如，对于生产环境的推送，我们可以设置为10GB内存，5个实例，而对于开发测试环境的推送，我们可以设置为2GB内存和1个应用实例。

5. random-route配置项。当我们没有特殊指定应用程序URL的时候，Predix Cloud会用应用程序名来生产对应的URL。这样做很容易造成URL的冲突，例如我们前面推送了一个hello的应用，假设，有另一个用户也推送了名为hello的应用。那么，后一个hello应用的推送就会失败。random-route配置项能很好的解决这个问题。如果在manifest文件中设置了这个配置项，Predix Cloud会在应用程序名后加上随机的单词来生成一个唯一的URL来避免冲突。

   如果，完全确定自己的应用程序的URL不会有冲突，我们可以不设置这个配置项。因为，一个固定的URL可以方便终端用户从一个固定的入口访问我们的应用程序。

6. services配置项。通过services配置项，我们可以在推送应用程序的同时绑定相应的服务实例。需要注意的是，服务实例必须在应用程序推送之前已经创建好了。每个服务实例名前面必须有一个短线和空格。从上面的例子我们可以看到，一个应用程序可以同时绑定多个服务实例，以实现丰富的功能。

7. env配置项。通过env配置项，我们可以传递额外的变量信息到应用程序。例如上面manifest文件中，我们将new relic监控服务的序列号通过环境变量传递给应用程序，然后应用程序就可以将自身的性能指标通过认证后的序列号传递给new relic服务。

   利用env配置项传递环境变量到应用程序的另一个典型使用场景是，我们可以动态的改变应用程序的某些配置，而不需要重启应用程序。我们可以通过cf set-env <应用程序名> <环境变量名> <新的环境变量值>来改变正在运行的应用程序的配置。例如，生产环境的应用程序默认的日志级别为INFO，当生产环境的应用出现了某种异常，当前的日志级别还不足以帮助工程团队定位问题的根源。我们可以通过更改环境变量的方式，动态的调整日志级别到DEBUG。这样，工程团队就可以获得更多的日志信息帮助定位问题的根源，而会不对生产环境的应用程序造成过大的影响。相对传统的做法需要重新编译源码，发布应用程序到生产环境才能使完成日志级别的变更，更改环境变量完成日志级别变更的方式就更灵活而高效。

8. buildpack和stack配置项。这两个配置项相对较复杂，我们以后会详细介绍。

作者：谢品，上海创新坊首席架构师，GE数字集团
专注于工业互联网，云计算，大数据，高性能分布式存储领域，对Cloud Foundry和传统应用向云端迁移有丰富的经验，曾供职于VMware，EMC，Autodesk等知名软件公司云计算部门。