很早就大致了解cloud_foundry有自己的ruby,而不是使用系统提供的ruby。并且还有两个版本的ruby,今天终于遇到了,大致搞清楚了。
他们在哪里
ruby下面有什么
cf是怎么使用这里的软件的
exec_cmd("#{ruby_binary} #{vcap_launch} #{command} #{vcap_components["components"].join(" ")} -c #{deployment_config_path} -v #{vcap_path} -l #{deployment_info["deployment_log_path"]}")这句话来执行start的,那么这里的ruby_binary其实就是我们上面提到的ruby的绝对路径。有兴趣可以去看下代码。归根到底,这个ruby的路径还是从前面提到的deployment_info.conf文件中取得的。而这个文件其实是vcap_dev_setup在安装的时候写入的。
cf的gem和bundle如何发生作用的
require "rubygems"
require "bundler/setup"
两行代码(可以看bundler官网:
http://gembundler.com/)
第一步
第二步
require 'rubygems'
require 'bundler/setup'
第二种要看vcap/cloud_controller/config/boot.rb文件了,这个文件的最前面有:
require 'rubygems'
require 'erb'
begin
require 'fiber'
rescue LoadError
$stderr.puts "CloudController requires a Ruby implementation that supports Fibers"
exit 1
end
# Set up gems listed in the Gemfile.
gemfile = File.expand_path('../../Gemfile', __FILE__)
begin
ENV['BUNDLE_GEMFILE'] = gemfile
require 'bundler'
Bundler.setup
rescue Bundler::GemNotFound => e
STDERR.puts e.message
STDERR.puts "Try running `bundle install`."
exit!
end if File.exist?(gemfile)
想必应该可以看懂了,就是在把bundle和gem加载进来。这个boot.rb被health manager调用到了,我们可以看health_manager.rb文件最前面的部分:
def self.setup
$:.unshift(lib_dir.to_s) unless $:.include?(lib_dir.to_s)
require root.join('config', 'boot')
require 'active_record'
require 'active_support/core_ext'
require 'yajl'
require 'eventmachine'
require 'nats/client'
require 'vcap/common'
require 'vcap/component'
require 'vcap/logging'
require 'vcap/rolling_metric'
require 'vcap/priority_queue'也是一目了然,把上面提到的boot.rb require进去了。
3万+



被折叠的 条评论
为什么被折叠?



