我们会通过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目录下对应的脚本，而这些脚本又会去相应组件的目录下执行更为详细的任务
|
