cloudfoundry dev setup 分析以及chef学习

长平狐 发布于 2012/08/24 10:07
阅读 412
收藏 0

cf通过chef可以部署单节点实例。只需要按照http://support.cloudfoundry.com/entries/20407923-single-multi-node-vcap-deployment-using-dev-setup的介绍即可安装。本文就尝试着分析一下整个部署的流程,同时也对chef进行一些学习。

vcap_dev_setup

好了,首先从最外部的脚本进入,就是bin/vcap_dev_setup。这是shell脚本,前面的内容全部忽略,到run_cmd apt-get $APT_CONFIG install -qym wget这一行开始,这里在安装wget,然后check下网络,关系不大。

然后开始安装chef,这里需要拿到一个key,如果失败,可以参看http://wiki.opscode.com/display/chef/Installing+Chef+Client+on+Ubuntu+or+Debian获取key。得到key之后update apt-get然后安装chef。

接下来会安装git,然后去github把最新版本的代码全部update下来。我们可以看代码:

cd $CLOUDFOUNDRY_HOME && git clone $VCAP_REPO && cd vcap && git submodule update --init && git checkout $VCAP_REPO_BRANCH

就是这句,如果想看所有源码,就可以通过这些命令获得源码,如果单纯只是git clone的话,有些代码是没有的,比如services、uaa等都是没有的。当然在update之前,脚本会查看目标目录是否已经有vcap这个目录,如果有了,就不会再update了,所以如果有人已经安装完毕了,就可以直接把vcap目录拷贝过来,这样可以节省不少时间。

然后使用gem安装了rake,根据其comments里面所讲:  Our deployment code needs this gem. Using bundler seems like an overkill for the deployment code. So for now just manually install the required gem。也不是太懂,意会好了。

然后就调用chefsolo_launch.rb执行接下来的操作了。这里遇到过一个permission denied,因为我们代码从svn check下来,结果没有x权限,这个自己加上去就好了

chefsolo_launch.rb

这个文件前面大部分代码都在处理文件路径,这里列几个重要路径的default设置,其实自己都可以更改的:
  • cloudfoundry_home: /root/cloudfoundry
  • cloudfoundry_domain: vcap.me
  • deployment_spec: /root/cloudfoundry/.deployment/devbox/devbox.yml
  • deployment_config_path: /root/cloudfoundry/.deployment/devbox/config
然后各种参数,包括文件路径都被传入了一个叫做spec的hash(map)。同时JobManager通过job_dependencies.rake文件来得出每个job的依赖(job就是一个组建,比如cloud controller、health manager等),这些信息也被放入了spec。最终这些spec信息全部被写入了/tmp/solo.json文件,通过-j参数传给chef,我们可以看一下这个文件的内容:
{
  "cloudfoundry":{
    "home":"/root/cloudfoundry"
  },
  "deployment":{
    "user":"root",
    "name":"devbox",
    "domain":"vcap.me",
    "group":0
  },
  "run_list":[
    "role[nats_server]",
    "role[cloudfoundry]",
    "role[router]",
    "role[ccdb]",
    "role[cloud_controller]",
    "role[health_manager]",
    "role[dea]",
    "role[uaa]",
    "role[uaadb]",
    "role[redis_node]",
    "role[mysql_node]",
    "role[mongodb_node]",
    "role[neo4j_node]",
    "role[rabbitmq_node]",
    "role[memcached_node]",
    "role[redis_gateway]",
    "role[mysql_gateway]",
    "role[mongodb_gateway]",
    "role[neo4j_gateway]",
    "role[rabbitmq_gateway]",
    "role[memcached_gateway]"
  ],
  "jobs":{
    "installed":null,
    "install":{
      "all":null
    }
  }
}
这个文件也比较简单,通俗易懂。唯一值得一提的是这个run list,它包含了所有需要安装的role(这个在下面的chef solo中会介绍,目前就认为是一个job即可),同时是根据依赖规则排列的,也就是被依赖的在前面。所以chef安装的时候会从上到下依次执行。比如先安装nats,然后是cloudfoundry。
然后呢,又用Dir.mktmpdir方式创建了一个solo.rb文件,这个文件是用-c参数传给chef-solo的,里面就配置了cookbook和role的路径,也就是dev_setup文件夹下面的两个同名文件夹。
最后,chefsolo_launch.rb将所有的任务交给chef了,自己向他传了几个参数,最终要的就是前面提到的solo.json以及solo.rb两个文件了。脚本就是
exec("sudo env #{proxy_env.join(" ")} chef-solo -c #{File.join(tmpdir, "solo.rb")} -j #{json_attribs} -l #{chef_log_level}")
那么接下来所有的任务就是chef-solo了

Chef solo

首先chef是什么:按照我的理解,chef就是一个无视环境的部署工具。安装脚本也就是recipes不需要写上具体如何操作(How),而只需要写明需要什么(What)。chef就可以在目标机器上面获取环境信息,然后根据脚本的需求自动安装配置部署。因此chef是一个非常强大的工具,同时chef有自己的server,上面有许多已经存在的部署脚本(叫cookbook),可以多加利用。
而chef分为两种使用方式,一种是和chef server交互,一种就是chef solo。第一种就是server可以提供脚本配置属性等数据。而solo就是完全自己配置。cf就是采用了solo方式。
Chef solo的主要使用方式是:建个cookbook,然后,然后就可以让chef干活了,很简单的样子。一个cookbook就是一个部署脚本,里面可以包含许多内容,在CF中一般包含了recipes、attributes、templates、provider以及resources。
那么recipes就是脚本了,也就是chef需要执行的一些脚本,也就是本cookbook所有需要做的行为都在recipe里面要写明。
attributes顾名思义就是一些属性定义,我们可以在deployment的cookbook的attributes中看到这样的代码:default[:deployment][:log_path] = File.join(deployment[:home], "log"),这个属性在recipe里面引用就会使用node[:deployment][:log_path]。这里有一个变量:ENV["HOME"],表示的是~目录,也就是HOME目录。
templates是一个比较有意思的东西,它里面是一些erb文件,我们先不看这些erb文件,因为会看不懂的。我们直接看使用的地方,也就是recipe里面的template块。举个例子:
  template "nats_server" do
    path File.join("", "etc", "init.d", "nats_server")
    source "nats_server.erb"
    owner node[:deployment][:user]
    mode 0755
    notifies :restart, "service[nats_server]"
  end
这个里的意思是这个template名字叫做nats_server,这个名字其实随便叫的,然后有一个path,是/etc/init.d/nats_server,你会发现:这不就是服务的文件吗?对的!然后看到source就是一个nats_server.erb文件,在template文件夹下面。后面的大致也能看懂,notifies应该就是消息通知,但是我暂时没找到说明文档,不懂。好了,现在再看erb文件,就可以发现,它很像server文件,其实它就是init.d下面的nats_server文件,只不过,里面某些参数使用了chef中的attributes来表示罢了。其他的template基本也如此,也就是说template是用来表示一个文件内容的,专业点讲叫做render。
provider:个人感觉cf中的使用和官方文档的说法不太一样,这里似乎就是提供了一些函数,给recipes调用而已。
resources:chef官网的说法就是work的basic unit,也是为recipe所用的

在CF中,chef会根据上文提到的run list的顺序依次安装执行。但是run list中提到的是role,而不是recipe,role其实是许多recipes的合集,一个role就是一个抽象的概念,每个node(就认为是一台机器好了)可以有多个role。其实挺像Java的interface的,每个接口定义了一个抽象的功能,一个类可以有多个接口。知道了role之后再看role的相关文件在哪里,因为总得有地方说明role要做些什么行为的。这个文件就在dev_setup\roles目录下。可以看到许多的json文件,以nats_server.json为例:
{
  "name": "nats_server",
  "default_attributes": {},
  "override_attributes": {},
  "json_class": "Chef::Role",
  "description": "NATS message bus server",
  "chef_type": "role",
  "run_list" : [ "recipe[deployment]",
                 "recipe[essentials]",
                 "recipe[ruby]",
                 "recipe[nats_server]" ]
}
上面一些参数关系也不大,主要是run_list,我们可以看到它需要四个recipe依次执行。也就是四个对应cookbook下的recipe文件。
下面来看看recipe的实例吧,首先可以看看deployment的recipe:
node[:nats_server][:host] ||= cf_local_ip
node[:ccdb][:host] ||= cf_local_ip
node[:acmdb][:host] ||= cf_local_ip
node[:uaadb][:host] ||= cf_local_ip
node[:postgresql][:host] ||= cf_local_ip

[
  node[:deployment][:home], File.join(node[:deployment][:home], "deploy"),
  node[:deployment][:log_path], File.join(node[:deployment][:home], "sys", "log"),
  node[:deployment][:config_path],
  File.join(node[:deployment][:config_path], "staging"),
  node[:deployment][:setup_cache],
].each do |dir|
  directory dir do
    owner node[:deployment][:user]
    group node[:deployment][:group]
    mode "0755"
    recursive true
    action :create
  end
end

var_vcap = File.join("", "var", "vcap")
[var_vcap, File.join(var_vcap, "sys"), File.join(var_vcap, "db"), File.join(var_vcap, "services"),
 File.join(var_vcap, "data"), File.join(var_vcap, "data", "cloud_controller"),
 File.join(var_vcap, "sys", "log"), File.join(var_vcap, "sys", "run"), File.join(var_vcap, "data", "cloud_controller", "tmp"),
 File.join(var_vcap, "data", "cloud_controller", "staging"),
 File.join(var_vcap, "data", "db"), File.join("", "var", "vcap.local"),
 File.join("", "var", "vcap.local", "staging")].each do |dir|
  directory dir do
    owner node[:deployment][:user]
    group node[:deployment][:group]
    mode "0755"
    recursive true
    action :create
  end
end

template node[:deployment][:info_file] do
  path node[:deployment][:info_file]
  source "deployment_info.json.erb"
  owner node[:deployment][:user]
  mode 0644
  variables({
    :name => node[:deployment][:name],
    :ruby_bin_dir => File.join(node[:ruby][:path], "bin"),
    :maven_bin_dir => File.join(node[:maven][:path], "bin"),
    :cloudfoundry_path => node[:cloudfoundry][:path],
    :deployment_log_path => node[:deployment][:log_path]
  })
end

file node[:deployment][:local_run_profile] do
  owner node[:deployment][:user]
  group node[:deployment][:group]
  content <<-EOH
    export PATH=#{node[:ruby][:path]}/bin:`#{node[:ruby][:path]}/bin/gem env gempath`/bin:#{node[:maven][:path]}/bin:$PATH
    export CLOUD_FOUNDRY_CONFIG_PATH=#{node[:deployment][:config_path]}
  EOH
end
最上面在赋一些参数,不理他,然后创建了deployment所需要许多许多目录,然后可以看到一个template,我们看名字可以知道是要给一个文件写一些值进去,因为source的文件就是一个简单的json文件。通过查找,可以找到这个文件就是:....../.deployment/devbox/config/deployment_info.json。这个路径定义在attributes里面。最后是写一个file,里面的content就是两句export。这个文件的路径也可以查到,是:/root/.cloudfoundry_deployment_local
再看一个recipe,这个是essential的recipe
%w{apt-utils build-essential libssl-dev
   libxml2 libxml2-dev libxslt1.1 libxslt1-dev git-core sqlite3 libsqlite3-ruby
   libsqlite3-dev unzip zip ruby-dev libmysql-ruby libmysqlclient-dev libcurl4-openssl-dev libpq-dev}.each do |p|
  package p do
    action [:install]
  end
end

if node[:deployment][:profile]
  file node[:deployment][:profile] do
    owner node[:deployment][:user]
    group node[:deployment][:group]
    content "export PATH=#{node[:ruby][:path]}/bin:`#{node[:ruby][:path]}/bin/gem env gempath`/bin:$PATH"
  end
end
这个和上一个有点不同了,第一部分在做install,我们可以看到许多的pkg需要安装,这些pkg其实可以在dev setup的时候看到他们的身影。第二部分不难,就是写了一个profile。
最后看一个实际组件的recipe,就选择cloudcontroller好了:
template node[:cloud_controller][:config_file] do
  path File.join(node[:deployment][:config_path], node[:cloud_controller][:config_file])
  source "cloud_controller.yml.erb"
  owner node[:deployment][:user]
  mode 0644

  builtin_services = []
  case node[:cloud_controller][:builtin_services]
  when Array
    builtin_services = node[:cloud_controller][:builtin_services]
  when Hash
    builtin_services = node[:cloud_controller][:builtin_services].keys
  when String
    builtin_services = node[:cloud_controller][:builtin_services].split(" ")
  else
    Chef::Log.info("Input error: Please specify cloud_controller builtin_services as a list, it has an unsupported type #{node[:cloud_controller][:builtin_services].class}")
    exit 1
  end
  variables({
    :builtin_services => builtin_services
  })
end
cf_bundle_install(File.expand_path(File.join(node["cloudfoundry"]["path"], "cloud_controller")))

staging_dir = File.join(node[:deployment][:config_path], "staging")
node[:cloud_controller][:staging].each_pair do |framework, config|
  template config do
    path File.join(staging_dir, config)
    source "#{config}.erb"
    owner node[:deployment][:user]
    mode 0644
  end
end
首先向config文件写下一个cc的配置文件cloud_controller.yml,然后呢有一个cf_bundle_install函数,这个函数在哪里呢?我们可以去cloudfoundry的cookbook的libraries里面找到它,因为cloudfoundry的cookbook的recipe会在cc的recipe之前执行,所以这个函数是找得到的。这个函数的代码是:
  def cf_bundle_install(path)
    bash "Bundle install for #{path}" do
      cwd path
      user node[:deployment][:user]
      code "#{File.join(node[:ruby][:path], "bin", "bundle")} install"
      only_if { ::File.exist?(File.join(path, 'Gemfile')) }
    end
  end
可以看到就是去vcap目录下面找cloud controller然后,使用bundle安装那个Ruby on Rails系统即可。

好了,至此已经把dev setup所有的工作都研究清楚了,中间还有一些细节需要深入一下,不过大致的概念已经比较清楚了。

原文链接:http://blog.csdn.net/cherry_sun/article/details/7711913
加载中
返回顶部
顶部