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
path
配置项。通常,对于Java或者其他需要编译的应用程序,我们用path
配置项指定编译后应用程序源码的路径。instances
配置项。instances
配置项可以指定推送应用程序的实例个数。memory
配置项。memory
配置项可以指定推送应用程序的内存容量。disk_quota
配置项。disk_quota
配置项可以指定推送应用程序的磁盘空间。使用上述三个参数
instances
、memory
、disk_quota
的一个典型的应用场景是推送同一份源码到不同的环境时,我们在不同的manifest文件中设置不同的配置值。例如,对于生产环境的推送,我们可以设置为10GB内存,5个实例,而对于开发测试环境的推送,我们可以设置为2GB内存和1个应用实例。random-route
配置项。当我们没有特殊指定应用程序URL的时候,Predix Cloud会用应用程序名来生产对应的URL。这样做很容易造成URL的冲突,例如我们前面推送了一个hello的应用,假设,有另一个用户也推送了名为hello的应用。那么,后一个hello应用的推送就会失败。random-route
配置项能很好的解决这个问题。如果在manifest文件中设置了这个配置项,Predix Cloud会在应用程序名后加上随机的单词来生成一个唯一的URL来避免冲突。如果,完全确定自己的应用程序的URL不会有冲突,我们可以不设置这个配置项。因为,一个固定的URL可以方便终端用户从一个固定的入口访问我们的应用程序。
services
配置项。通过services
配置项,我们可以在推送应用程序的同时绑定相应的服务实例。需要注意的是,服务实例必须在应用程序推送之前已经创建好了。每个服务实例名前面必须有一个短线和空格。从上面的例子我们可以看到,一个应用程序可以同时绑定多个服务实例,以实现丰富的功能。env
配置项。通过env
配置项,我们可以传递额外的变量信息到应用程序。例如上面manifest文件中,我们将new relic监控服务的序列号通过环境变量传递给应用程序,然后应用程序就可以将自身的性能指标通过认证后的序列号传递给new relic服务。利用
env
配置项传递环境变量到应用程序的另一个典型使用场景是,我们可以动态的改变应用程序的某些配置,而不需要重启应用程序。我们可以通过cf set-env <应用程序名> <环境变量名> <新的环境变量值>
来改变正在运行的应用程序的配置。例如,生产环境的应用程序默认的日志级别为INFO,当生产环境的应用出现了某种异常,当前的日志级别还不足以帮助工程团队定位问题的根源。我们可以通过更改环境变量的方式,动态的调整日志级别到DEBUG。这样,工程团队就可以获得更多的日志信息帮助定位问题的根源,而会不对生产环境的应用程序造成过大的影响。相对传统的做法需要重新编译源码,发布应用程序到生产环境才能使完成日志级别的变更,更改环境变量完成日志级别变更的方式就更灵活而高效。buildpack
和stack
配置项。这两个配置项相对较复杂,我们以后会详细介绍。
作者:谢品,上海创新坊首席架构师,GE数字集团
专注于工业互联网,云计算,大数据,高性能分布式存储领域,对Cloud Foundry和传统应用向云端迁移有丰富的经验,曾供职于VMware,EMC,Autodesk等知名软件公司云计算部门。