Cloud Foundry vcap_dev start过程分析

我们会通过bin/vcap_dev start命令来启动所有的cf组件，当然，也可以指定某些组件，比如bin/vcap_dev start health_manager。

下面大致研究下流程。

1. vcap_dev文件

首先是vcap_dev文件，前面主要处理了命令参数以及路径等问题。最后可以看到

exec_cmd("#{ruby_binary} #{vcap_launch} #{command} #{vcap_components["components"].join(" ")} -c #{deployment_config_path} -v #{vcap_path} -l #{deployment_info["deployment_log_path"]}")

exec_cmd意思就是执行cmd，而ruby_binary是ruby，vcap_launch就是和vcap_dev同位置的vcap文件，后面的command就是我们的启动指令start，当然可能是stop，restart之类的。

2. vcap文件

所以我们就可以跑去vcap文件看个究竟了。

因为本文研究start，所以直接看vcap文件的start函数：

  def start
    if !running?

      pid = fork do
        # Capture STDOUT when no log file is configured
        if !log_file?
          stdout = File.open(log_file, 'a')
          stdout.truncate(0)
          STDOUT.reopen(stdout)
          stderr = File.open(log_file, 'a')
          STDERR.reopen(stderr)
        end
        # Make sure db is setup, this is slow and we should make it faster, but
        # should help for now.
        if is_cloud_controller?
          cc_dir = File.expand_path(File.join(DIR, '..', 'cloud_controller'))
          Dir.chdir(cc_dir) { `bundle exec rake db:migrate` }
        end
        exec("#{component_start_path}")
      end

      Process.detach(pid)

      start = Time.now
      while ((Time.now - start) < 20)
        break if running?
        sleep (0.25)
      end
    end

    status

    if !running?
      if File.exists?(log_file)
        log = File.read(log_file)
        STDERR.puts "LOG:\n #{log}" if !log.empty?
      end
    end
  end

其他的不理会，重点语句是exec("#{component_start_path}")，当然cc还需要做一个db migrate。那么我们看component_start_path，这也是个函数。这个函数所做的事情就是跑去vcap的相应目录下面，然后执行bin目录下的同名文件。以health manager为例，它执行vcap/bin/health_manager文件，同时以-c传入.deployment/devbox/config下面的health_manager.yml文件。那么vcap_dev start任务就交接完成了，接下来由bin下面的脚本执行了。

这里的vcap路径下有bin目录，而vcap/health manager下面也有bin，vcap脚本调用的是vcap下的bin。之前搞错了。那么看health manager的bin脚本：

exec(File.expand_path("../../health_manager/bin/health_manager", __FILE__), *ARGV)

他就直接调用vcap/health_manager/bin/health_manager脚本了

3. bin脚本

然后我们看看bin下面的脚本都在做什么：

home = File.join(File.dirname(__FILE__), '/..')
ENV['BUNDLE_GEMFILE'] = "#{home}/Gemfile"
require File.join(home, 'lib/health_manager')

很简单，就是设置了bundle gemfile的环境变量，然后指向lib下的health_manager文件。Lib下的health_manager.rb主要有三个部分，第一个部分是module CloudController，用来添加非常多的依赖(require)，目前不清楚这么做的意义。第二部分是HealthManager类，那就不提了。重要的是第三部分，也就是文档末尾的一些代码：

if $0 == __FILE__ || File.expand_path($0) == File.expand_path(File.join(File.dirname(__FILE__), '../bin/health_manager'))

  config_path = ENV["CLOUD_FOUNDRY_CONFIG_PATH"] || File.join(File.dirname(__FILE__), '../config')
  config_file = File.join(config_path, "health_manager.yml")
  options = OptionParser.new do |opts|
    opts.banner = 'Usage: healthmanager [OPTIONS]'
    opts.on("-c", "--config [ARG]", "Configuration File") do |opt|
      config_file = opt
    end
    opts.on("-h", "--help", "Help") do
      puts opts
      exit
    end
  end
  options.parse!(ARGV.dup)

  begin
    config = YAML.load_file(config_file)
  rescue => e
    $stderr.puts "Could not read configuration file:  #{e}"
    exit 1
  end

  EM.epoll

  EM.run { HealthManager.start(config) }
end

首先去读config file，然后解析了options参数，我们知道bin脚本已经传入了-c参数，所以在options解析中，config会覆盖掉。在读取config之后，就使用Event Machine启动HealthManager了。EM.epoll是一个linux下的调用命令，对我们没有意义。EM.run就是我们要看的，可以看到这里只调用了HealthManager.start函数。后面就不再深入了，大致的流程就是完成配置，然后开启NATS，订阅NATS事件，然后发送NATS消息。

总结一下：vcap_dev和vcap脚本都用来处理安装之后的启动停止等任务，他们会调用vcap/bin目录下对应的脚本，而这些脚本又会去相应组件的目录下执行更为详细的任务