Cloud Foundry中应用实例生命周期过程中的文件目录分析

在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}")

        该部分的代码产生应用在所在DEA上的压缩包文件目录以及具体执行的文件目录，并在后续的success = stage_app_dir(bits_file, bits_uri, sha1, tgz_file, instance_dir, runtime)中实现下载应用源码至instance_dir。启动完成之后，以上的instance_dir，就是该应用的文件路径。

        总结：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) }

        在process_dea_stop中，主要执行的便是该应用的停止，包括该应用的所有实例，代码实现如下：

 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

         首先现在@droplets这个hash对象中找到所在停止的应用id，然后再遍历该应用的所有实例，在对应用实例进行状态处理之后，随即执行stop_droplet方法。也就是说真正实现停止应用实例的操作在stop_droplet方法，以下进入该方法的代码实现：

     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

        可以看到在该方法中，主要是通过执行该应用的停止脚本来实现stop an app请求。其中，stop_script = File.join(instance[:dir], 'stop')为找到停止脚本所在的位置，insecure_stop_cmd = "#{stop_script} #{instance[:pid]} 2> /dev/null"未生成脚本命令，然后通过@secure变量重生成stop_cmd，最后执行Bundler.with_clean_env { system(stop_cmd) }，实现为启动一个全新环境来让操作系统执行脚本stop_cmd。

        其实本文最关心的是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

        在该方法中，检查应用实例状态后，如果应用的状态不为：CRASHED或者instance[:flapping]不为真时，在@droplets这个hash对象中删除所要停止的应用实例ID，随后进行schedule_snapshot操作，该方法的实现于作用稍后会进行分析。然后通过以下代码实现应用实例文件目录删除：

 unless @disable_dir_cleanup
    @logger.debug("#{instance[:name]}: Cleaning up dir #{instance[:dir]}#{instance[:flapping]?' (flapping)':''}")
    EM.system("rm -rf #{instance[:dir]}")
 end

        也就在是说@disable_dir_cleanup变量为真话，不会执行脚本命令 rm -rf #{instance[:dir]} ，如果为假，则执行脚本命令 rm -rf #{instance[:dir]} ，换句话说会将应用实例的文件目录全部删除。在默认情况下，Cloud Foundry关于@disable_dir_cleanup变量的初始化，在agent类的intialize()方法中，初始化读取配置config['disable_dir_cleanup']，而该配置默认为空，即为假。

        现在分析刚才涉及的方法schedule_snapshot方法，在stop_droplet方法中，删除了@droplets中关于要删除应用实例的信息后，随即调用该schedule_snapshot方法。该方法的实现如下：

 def schedule_snapshot
   return if @snapshot_scheduled
   @snapshot_scheduled = true
   EM.next_tick { snapshot_app_state }
 end

        可以看到主要是实现了snapshot_app_state方法，现在进入该方法：

 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

        首先，该方法获取了当前时间，并以tmp = File.new("#{@db_dir}/snap_#{Time.now.to_i}", 'w')创建了一个文件，通过将@droplets变量json化，随后将json信息写入tmp文件；关闭该文件后，通过命令FileUtils.mv(tmp.path, @app_state_file)实现将该tmp文件重命名为@app_state_file，该变量为@app_state_file = File.join(@db_dir, APP_STATE_FILE)，其中APP_STATE_FILE = 'applications.json'：。

        总结，当stop an app时，DEA的操作流程如下：

1. 删除该app的所有实例在@droplets中的信息；
2. 对该app的所有实例执行stop脚本；
3. 将删除指定记录后的@droplets对象中的所有记录写入@app_state_file；
   
4. 对该app的所有实例的文件目录，进行删除处理。

delete an app

        delete an app主要是指应用用户发起一个删除应用的请求，该请求由Cloud Controller捕获，Cloud Controller首先 将该应用的所有实例停止，然后再将该应用的droplet删除掉。因此，在操作该请求的时候，有相关该应用的所有信息都会被删除，自然包括该应用实例在DEA上的文件目录。

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

        而send_exited_message方法中的代码实现如下：

 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

       首先先在router中注销该应用实例的url，由于对于一个异常终止的应用实例来说，肯定不会有instance[:exit_reason]值，所以正如正常逻辑，应该将该应用实例的:exit_reason以及:state设置为:CRASHED。

        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

        到目前为止，crashed应用的状态只是被标记为:CRASHED,而其文件目录还是存在于DEA的文件系统中，并没有删除。

        但是可以想象的是，对于一个崩溃的应用实例，没有将其删除的情况是不合理的，当时Cloud Foundry的设计者肯定会考虑这一点。实际情况中，DEA的执行时，会添加一个周期性任务crashes_reaper，实现代码如下：

 EM.add_periodic_timer(CRASHES_REAPER_INTERVAL) { crashes_reaper }

        而CRASHES_REAPER_INTERNAL的数值设定为3600，也就是每隔一小时都是执行一次crashes_reaper操作，现在进入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

        该代码的实现很简单，也就是如果一个应用实例的状态为：CRASHED，那就删除该应用实例的文件目录。

        总结，当一个应用实例crash的时候，应用实例将不能被访问，而且其文件目录依然会存在与DEA所在节点的文件系统中 ，DEA会将应用实例的状态标记为：CRASHED，随后通过周期为1小时的任务crashes_reaper将其文件目录删除。

stop DEA

        stop DEA主要是指，Cloud Foundry的开发者用户通过Cloud Foundry中指定的脚本命令，停止DEA组件的运行。当开发者用户发起该请求时，DEA组件会捕获这个请求：

 ['TERM', 'INT', 'QUIT'].each { |s| trap(s) { shutdown() } }

        捕获到这个请求时，DEA会执行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

        看以上代码可知，执行shutdown方法的时候，对于@droplets中的每一个应用的每一个非CRASHED状态的实例，将:exit_reason设置为:DEA_SHUTDOWN之后，随后执行stop_droplet方法以及cleanup_droplet方法，也就是说会将这些应用实例的文件目录全部删除。删除完之后，DEA会选择结束进程。当然关于这些进程信息的application.json文件中，也会删除那些正常运行的应用实例信息。

        总结：stop一个DEA的时候，会先停止所有正常应用实例的运行，随后这些正应用实例的文件目录会被删除。

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中应用实例生命周期中文件目录变化的人有些帮助，如果你对这方面感兴趣，并有更好的想法和建议，也请联系我。

我的邮箱：[email protected]
新浪微博： @莲子弗如清