在Cloud Foundry中,应用在DEA上运行,而应用在自身的生命周期中,自身的文件目录也会随着不同的周期,做出不同的变化。
本文将从创建一个应用(start an app),停止一个应用(stop an app),删除一个应用(delete an app),重启一个应用(restart an app),应用crash,关闭dea,启动dea,dea异常退出后重启,这几个方面入手,进行分析应用实例目录的变化。
本文所讲述的Cloud Foundry仅限于v1版本,v2版本会后续跟进。
start an app
start an app主要是指应用用户发出请求,让Cloud Foundry创建一个应用,或者启动一个应用。需要注意的是,在start an app之前,Cloud Foundry的每一个DEA中都不会存有该app的文件。在某一个DEA接受到start an app的请求后,该DEA必须从存放droplet的地方,下载droplet,并在DEA所在节点的某个文件路径下解压改droplet,最终启动解压后的droplet的应用启动脚本。这样的话,该DEA的文件系统中就会有一个该应用相应的文件目录存在。
以上操作的代码实现,在/dea/lib/dea/agent.rb的process_dea_start方法中:
- tgz_file = File.join(@staged_dir, "#{sha1}.tgz")
- instance_dir = File.join(@apps_dir, "#{name}-#{instance_index}-#{instance_id}")
总结:start an app创建应用在某一个DEA上的文件目录并启动该应用。
stop an app
stop an app主要是指应用用户发出请求,让Cloud Foundry停止一个应用的运行。需要注意的是,在stop an app之前,肯定是必须要在运行的该应用,该应用的文件目录以及源码已经存在于某一个DEA的文件系统中。Cloud Controller收到用户的stop an app请求后,首先会找到该应用所在运行的DEA节点,并对该DEA发送stop该应用的请求。当DEA接收到该请求后,执行process_dea_stop方法,如下:
- NATS.subscribe('dea.stop') { |msg| process_dea_stop(msg) }
- return unless instances = @droplets[droplet_id]
- instances.each_value do |instance|
- version_matched = version.nil? || instance[:version] == version
- instance_matched = instance_ids.nil? || instance_ids.include?(instance[:instance_id])
- index_matched = indices.nil? || indices.include?(instance[:instance_index])
- state_matched = states.nil? || states.include?(instance[:state].to_s)
- if (version_matched && instance_matched && index_matched && state_matched)
- instance[:exit_reason] = :STOPPED if [:STARTING, :RUNNING].include?(instance[:state])
- if instance[:state] == :CRASHED
- instance[:state] = :DELETED
- instance[:stop_processed] = false
- end
- stop_droplet(instance)
- end
- end
- def stop_droplet(instance)
- return if (instance[:stop_processed])
- send_exited_message(instance)
- username = instance[:secure_user]
- # if system thinks this process is running, make sure to execute stop script
- if instance[:pid] || [:STARTING, :RUNNING].include?(instance[:state])
- instance[:state] = :STOPPED unless instance[:state] == :CRASHED
- instance[:state_timestamp] = Time.now.to_i
- stop_script = File.join(instance[:dir], 'stop')
- insecure_stop_cmd = "#{stop_script} #{instance[:pid]} 2> /dev/null"
- stop_cmd =
- if @secure
- "su -c \"#{insecure_stop_cmd}\" #{username}"
- else
- insecure_stop_cmd
- end
- unless (RUBY_PLATFORM =~ /darwin/ and @secure)
- Bundler.with_clean_env { system(stop_cmd) }
- end
- end
- ………………
- cleanup_droplet(instance)
- end
其实本文最关心的是DEA接下来的操作cleanup_droplet操作,因为该操作才是真正于应用在DEA文件系统目录相关的部分。以下进入cleanup_droplet方法:
- def cleanup_droplet(instance)
- remove_instance_resources(instance)
- @usage.delete(instance[:pid]) if instance[:pid]
- if instance[:state] != :CRASHED || instance[:flapping]
- if droplet = @droplets[instance[:droplet_id].to_s]
- droplet.delete(instance[:instance_id])
- @droplets.delete(instance[:droplet_id].to_s) if droplet.empty?
- schedule_snapshot
- end
- unless @disable_dir_cleanup
- @logger.debug("#{instance[:name]}: Cleaning up dir #{instance[:dir]}#{instance[:flapping]?' (flapping)':''}")
- EM.system("rm -rf #{instance[:dir]}")
- endFileUtils.mv(tmp.path, @app_state_file)
- else
- @logger.debug("#{instance[:name]}: Chowning crashed dir #{instance[:dir]}")
- EM.system("chown -R #{Process.euid}:#{Process.egid} #{instance[:dir]}")
- end
- end
- unless @disable_dir_cleanup
- @logger.debug("#{instance[:name]}: Cleaning up dir #{instance[:dir]}#{instance[:flapping]?' (flapping)':''}")
- EM.system("rm -rf #{instance[:dir]}")
- end
现在分析刚才涉及的方法schedule_snapshot方法,在stop_droplet方法中,删除了@droplets中关于要删除应用实例的信息后,随即调用该schedule_snapshot方法。该方法的实现如下:
- def schedule_snapshot
- return if @snapshot_scheduled
- @snapshot_scheduled = true
- EM.next_tick { snapshot_app_state }
- end
- def snapshot_app_state
- start = Time.now
- tmp = File.new("#{@db_dir}/snap_#{Time.now.to_i}", 'w')
- tmp.puts(JSON.pretty_generate(@droplets))
- tmp.close
- FileUtils.mv(tmp.path, @app_state_file)
- @logger.debug("Took #{Time.now - start} to snapshot application state.")
- @snapshot_scheduled = false
- end
总结,当stop an app时,DEA的操作流程如下:
- 删除该app的所有实例在@droplets中的信息;
- 对该app的所有实例执行stop脚本;
- 将删除指定记录后的@droplets对象中的所有记录写入@app_state_file;
- 对该app的所有实例的文件目录,进行删除处理。
delete an app
restart an app
restart an app主要是指应用用户发起一个重启应用的请求,该请求在vmc处的实现就是分解为两个请求,一个stop请求,一个start请求。因此,stop请求在一个DEA上停止该应用的运行,并且删除该应用的文件目录;而start请求在一个DEA上现下载该应用的源码,也就是创建一个文件目录,最后将该应用启动起来。需要特别注意的是,执行stop请求的DEA和执行start请求的DEA不一定是同一个DEA。执行stop请求的DEA为当前需要停止的应用所在的DEA,而执行start请求的DEA,需要由Cloud Controller决策而出。
app crashes
app crashes主要是指应用在运行过程中出现了崩溃的请求。换句话说,应用崩溃,DEA是事先不知晓的,这和stop an app有很大的区别,在具体集群中可以通过强制杀死应用进程来模拟应用的崩溃。
首先由于应用的崩溃不经过DEA,所以DEA不会执行stop_droplet方法以及cleanup_droplet方法,理论上该应用的文件目录依然会存在于DEA的文件系统中,据许占据DEA文件系统的磁盘空间。可以想象,如果应用长此以往的话,对系统磁盘空间的浪费是很明显的。而关于这个话题,Cloud Foundry中DEA会采取定期执行清除crashed应用的操作,将已经崩溃的应用文件目录删除。
具体来讲,由于应用崩溃,那么关于之前该应用的pid也就不会存在了(理论上是这样),在DEA定期执行monitor_app方法的时候,将所有进程的信息保存起来,随后执行monitor_apps_helper方法,对于@droplets中的每一个应用的每一个实例,将其的pid信息于实际在DEA节点处的进程pid进行对比,如果失败,则说明@droplets中的该应用实例已经不在运行,可以认为是不正常的退出执行。实现代码如下:
- def monitor_apps_helper(startup_check, ma_start, du_start, du_all_out, pid_info, user_info)
- …………
- @droplets.each_value do |instances|
- instances.each_value do |instance|
- if instance[:pid] && pid_info[instance[:pid]]
- …………
- else
- # App *should* no longer be running if we are here
- instance.delete(:pid)
- # Check to see if this is an orphan that is no longer running, clean up here if needed
- # since there will not be a cleanup proc or stop call associated with the instance..
- stop_droplet(instance) if (instance[:orphaned] && !instance[:stop_processed])
- end
- end
- end
- …………
- end
当发现该应用实例实际情况下已经不再运行的话,DEA就会执行代码 instance.delete(:pid) 以及 stop_droplet(instance) if (instance[:orphaned] && !instance[:stop_processed]) ,可以如果(instance[:orphaned] && !instance[:stop_processed]) 为真的话,那就执行stop_droplet方法,在执行stop_droplet方法的时候,由于先执行send_exited_message方法,如下:
- def stop_droplet(instance)
- # On stop from cloud controller, this can get called twice. Just make sure we are re-entrant..
- return if (instance[:stop_processed])
- # Unplug us from the system immediately, both the routers and health managers.
- send_exited_message(instance)
- ……
- cleanup_droplet(instance)
- end
- def send_exited_message(instance)
- return if instance[:notified]
- unregister_instance_from_router(instance)
- unless instance[:exit_reason]
- instance[:exit_reason] = :CRASHED
- instance[:state] = :CRASHED
- instance[:state_timestamp] = Time.now.to_i
- instance.delete(:pid) unless instance_running? instance
- end
- send_exited_notification(instance)
- instance[:notified] = true
- end
stop_droplet方法中执行完send_exit_message方法之后,最后会执行cleanup_droplet方法。进入cleanup_droplet方法中,由于该应用实例的:state已经被设定为:CRASHED,所以该应用实例不会进入删除文件没有的命令中,而是执行chown命令,代码如下:
- def cleanup_droplet(instance)
- ……
- if instance[:state] != :CRASHED || instance[:flapping]
- ……
- else
- @logger.debug("#{instance[:name]}: Chowning crashed dir #{instance[:dir]}")
- EM.system("chown -R #{Process.euid}:#{Process.egid} #{instance[:dir]}")
- end
- end
但是可以想象的是,对于一个崩溃的应用实例,没有将其删除的情况是不合理的,当时Cloud Foundry的设计者肯定会考虑这一点。实际情况中,DEA的执行时,会添加一个周期性任务crashes_reaper,实现代码如下:
- EM.add_periodic_timer(CRASHES_REAPER_INTERVAL) { crashes_reaper }
- def crashes_reaper
- @droplets.each_value do |instances|
- # delete all crashed instances that are older than an hour
- instances.delete_if do |_, instance|
- delete_instance = instance[:state] == :CRASHED && Time.now.to_i - instance[:state_timestamp] > CRASHES_REAPER_TIMEOUT
- if delete_instance
- @logger.debug("Crashes reaper deleted: #{instance[:instance_id]}")
- EM.system("rm -rf #{instance[:dir]}") unless @disable_dir_cleanup
- end
- delete_instance
- end
- end
- @droplets.delete_if do |_, droplet|
- droplet.empty?
- end
- end
总结,当一个应用实例crash的时候,应用实例将不能被访问,而且其文件目录依然会存在与DEA所在节点的文件系统中 ,DEA会将应用实例的状态标记为:CRASHED,随后通过周期为1小时的任务crashes_reaper将其文件目录删除。
stop DEA
- ['TERM', 'INT', 'QUIT'].each { |s| trap(s) { shutdown() } }
- def shutdown()
- @shutting_down = true
- @logger.info('Shutting down..')
- @droplets.each_pair do |id, instances|
- @logger.debug("Stopping app #{id}")
- instances.each_value do |instance|
- # skip any crashed instances
- instance[:exit_reason] = :DEA_SHUTDOWN unless instance[:state] == :CRASHED
- stop_droplet(instance)
- end
- end
- # Allows messages to get out.
- EM.add_timer(0.25) do
- snapshot_app_state
- @file_viewer_server.stop!
- NATS.stop { EM.stop }
- @logger.info('Bye..')
- @pid_file.unlink()
- end
- end
start DEA
start DEA主要是指,Cloud Foundry的开发者用户通过Cloud Foundry指定的脚本命令,启动DEA组件的运行。当开发者发起该请求时,DEA组件启动,重要的部分为agent对象的创建与运行,现在进入agent实例对象的运行代码,主要关注与应用实例文件目录的部分:
- # Recover existing application state.
- recover_existing_droplets
- delete_untracked_instance_dirs
可以看到的是首先进行recover_existing_droplets方法,代码实现如下:
- def recover_existing_droplets
- …………
- File.open(@app_state_file, 'r') { |f| recovered = Yajl::Parser.parse(f) }
- # Whip through and reconstruct droplet_ids and instance symbols correctly for droplets, state, etc..
- recovered.each_pair do |app_id, instances|
- @droplets[app_id.to_s] = instances
- instances.each_pair do |instance_id, instance|
- …………
- end
- end
- @recovered_droplets = true
- # Go ahead and do a monitoring pass here to detect app state
- monitor_apps(true)
- send_heartbeat
- schedule_snapshot
- end
该方法主要根据@app_state_file文件中的信息,还原@droplets信息,随后执行monitor_apps,send_heartbeat以及schedule_snapshot方法。
随后会执行delete_untracked_instance_dirs方法,主要是删除与@droplets不相符的应用实例文件目录。
总结,如果之前DEA为正常退出的话,且正常退出前已经清除所有crashed应用实例的话,aplication_json文件中不会有任何信息,而存放应用文件目录的路径下不会有任何应用实例,因此该方法不会文件目录删除;如果DEA正常退出之前,还有crashed应用实例还没有删除的话,启动的时候该应用实例还是会存在,等待crashes_reaper操作将其删除;如果DEA崩溃退出时,存在应用实例文件目录的路径下与DEA崩溃前出现不一致,而application.json也与实际的应用实例不一致时,会将不匹配的应用实例的文件目录进行删除。
实现如下:
- # Removes any instance dirs without a corresponding instance entry in @droplets
- # NB: This is run once at startup, so not using EM.system to perform the rm is fine.
- def delete_untracked_instance_dirs
- tracked_instance_dirs = Set.new
- for droplet_id, instances in @droplets
- for instance_id, instance in instances
- tracked_instance_dirs << instance[:dir]
- end
- end
- all_instance_dirs = Set.new(Dir.glob(File.join(@apps_dir, '*')))
- to_remove = all_instance_dirs - tracked_instance_dirs
- for dir in to_remove
- @logger.warn("Removing instance dir '#{dir}', doesn't correspond to any instance entry.")
- FileUtils.rm_rf(dir)
- end
- end
DEA crashes
DEA crashes主要是指,DEA在运行过程崩溃,非正常终止,可以是用强制结束DEA进程来模拟DEA crashes。
由于DEA进程退出后,并不会直接影响到应用实例的运行,所以应用的文件目录还是会存在的,应用还是可以访问。当重新正常启动DEA进程的时候,由于和start DEA操作完全一致。需要注意的是,假如重启的时候,之前运行的应用都正常运行的话,那么通过recover_existing_droplets方法可以做到监控所有应用实例,通过monitor_apps方法。随后又可以通过send_heartbeat以及schedule_snapshot方法,实现与外部组件的通信。假如DEA重启的时候,之前运行的应用实例有部分已经crashes掉了,那在monitor_apps方法的后续执行中会将其文件目录删除。
以上便是我对Cloud Foundry中应用实例生命周期中文件目录的变化分析。
关于作者:
孙宏亮,DAOCLOUD软件工程师。两年来在云计算方面主要研究PaaS领域的相关知识与技术。坚信轻量级虚拟化容器的技术,会给PaaS领域带来深度影响,甚至决定未来PaaS技术的走向。
转载请注明出处。
这篇文档更多出于我本人的理解,肯定在一些地方存在不足和错误。希望本文能够对接触Cloud Foundry中应用实例生命周期中文件目录变化的人有些帮助,如果你对这方面感兴趣,并有更好的想法和建议,也请联系我。
我的邮箱:allen.sun@daocloud.io新浪微博: @莲子弗如清