Cloud Foundry中DEA启动应用实例时环境变量的使用

前言

在Cloud Foundry v2中,当应用用户需要启动应用的实例时,用户通过cf CLI向cloud controller发送请求,而cloud controller通过NATS向DEA转发启动请求。真正执行启动事宜的是DEA,DEA主要做的工作为启动一个warden container, 并将droplet等内容拷贝进入container内部,最后配置完指定的环境变量,在这些环境变量下启动应用的启动脚本。

本文将从阐述Cloud Foundry中DEA如何为应用实例的启动配置环境变量。

DEA接收应用启动请求及其执行流程

在这部分,通过代码的形式来说明DEA对于应用启动请求的执行流程。

1.首先DEA订阅相应主题的消息,主题为“dea.#{bootstrap.uuid}.start”,含义为“自身DEA的应用启动消息”:

2.当收到订阅主题之后,执行bootstrap.handle_dea_directed_start(message),含义为“通过bootstrap类实例来处理应用的启动请求”:

3.可以认为处理的入口,即为以上代码中的start_app方法:

4.在start_app方法中,首先通过instance_manager类实例来创建一个instance对象,通过执行instance实例的类方法start,可以看到自始至终,传递的参数的原始来源都是通过NATS消息传递来的message,也就是1中的message:

5.其中真正关于应用启动的执行在promise_start方法中实现:

可以看到在第5步中,DEA涉及到了应用的ENV环境变量等信息,最后通过container.spawn方法实现了应用的启动。

DEA环境变量的配置

在以上步骤的第5步,首先创建了环境变量env = Env.new(StartMessage.new(@raw_attributes), self),Env类的初始化方法如下:

可见,实际是创建了一个RunningEnv类的实例,参数主要为cloud controller发送来的信息。

在promise_start方法中,创建env变量之后,通过判断staged_info来选择start_script变量的构建。

现在分析staged_info的代码实现:

主要是通过指定路径,然后从路径中提取出变量。下面以一个ruby的应用为例,其staging_info.yml文件的内容为:

因此,最终@staged_info的内容如上,在instance.start方法中,command为bundle exec rackup config.ru -p $PORT。有了command变量之后,接着是构建start_script变量:

可以看到,DEA通过StartupScriptGenerator类来创建start_script,其中参数为三个,第一个为刚才涉及到的command,后两个均需要通过env变量来生成。

现在看exported_user_environment_variables方法的实现:

该方法实现从message中提取中属性为env的信息,作为用户的环境变量。

进入env.exported_system_environment_variables的方法实现:

可见在生成系统的环境变量的时候,首先创建一个env数组变量,其中有信息VCAP_APPLICATION, VCAP_SERVICES, MEMORY_LIMIT三种,其中VCAP_APPLICATION的信息如下:

这部分信息中包含了应用的name,uris,users,version等一系列内容。其中需要特别注意的是代码hash = strategy_env.vcap_application,该代码的作用为调用了RunningEnv类中vcap_application方法,如下:

可见在以上代码中,vcap_application信息中记录了很多关于应用实例的信息,包括instance_id, instance_index, host, port, started_at, started_at_timestamp, start, state_timestamp等。

VCAP_SERVICES的信息如下:

这部分内容主要从message中寻找是否存在和WHITELIST_SERVICES_KEYS中值作为键的值,若存在的话,加入services_hash该变量。

随后,DEA在运行代码env << [“DATABASE_URL”, DatabaseUriGenerator.new(message.services).database_uri] if message.services.any?,该部分代码的作用主要要理解DatabaseUriGenerator的含义,这部分笔者仍不是很清楚。

再后来,DEA执行代码to_export(env + strategy_env.exported_system_environment_variables),这部分的内容非常重要,主要要进入strategy_env对象所在的类中查看exported_system_environment_variables方法:

可以看到,这里主要包含运行信息的环境变量,比如说HOME目录,TMP临时目录,应用实例运行的host地址,应用实例运行的端口号。其中最为重要的就是应用实例运行的端口号,在我的另一篇博文Cloud Foundry中DEA与warden通信完成应用端口监听 中,有涉及到如何通过warden server来开辟端口,最终为DEA所用,并通过环境变量的形式传递给应用实例的启动脚本。其中VCAP_APP_PORT和PORT都是warden container开启那个端口号。

分析完了StartupScriptGenerator的三个参数,需要进入StartupScriptGenerator类的generate方法:

以上的代码即为创建启动脚本的过程。其中@system_envs为之前分析的env.exported_system_environment_variables, @user_envs为env.exported_user_environment_variables。还有两个脚本是EXPORT_BUILDPACK_ENV_VARIABLES_SCRIPT和START_SCRIPT,EXPORT_BUILDPACK_ENV_VARIABLES_SCRIPT脚本的代码如下,其意为执行某路径下的所有sh脚本:

而START_SCRIPT代码如下:

以上即创建完了start_script,回到instance.rb中的promise_start方法中,即执

即完成应用实例的启动工作。详情可以进入container类中的spawn方法实现。

转载请注明出处。

这篇文档更多出于我本人的理解,肯定在一些地方存在不足和错误。希望本文能够对接触Cloud Foundry v2中dea_ng如何启动应用实例的人有些帮助,如果你对这方面感兴趣,并有更好的想法和建议,也请联系我。

Hongliang Sun

作者介绍:孙宏亮,浙江大学VLIS实验室硕士研究生。读研期间在云计算方面主要研究PaaS领域的相关知识与技术,活跃在PaaS和Docker开源社区,擅长底层平台代码分析,对分布式平台的架构有一定经验,撰写了大量有深度的技术博客。

浙江大学SEL实验室是本网站上所有页面设计、页面内容的著作权人,对该网站所载的作品,包括但不限于网站所载的文字、数据、图形、照片、有声文件、动画文件、音视频资料等拥有完整的版权,受著作权法保护。严禁任何媒体、网站、个人或组织以任何形式或出于任何目的在未经本实验室书面授权的情況下抄袭、转载、摘编、修改本网站內容,或链接、转帖或以其他方式复制用于商业目的或发行,或稍作修改后在其它网站上使用,前述行为均将构成对本网站版权之侵犯,本网站將依法追究其法律责任。
本网站与他人另有协议授权下载的或法律另有规定的,在下载使用时必须注明“稿件来源:浙江大学SEL实验室”。

Leave a Reply

Your email address will not be published. Required fields are marked *