Chef源码组织
最后更新于：2022-04-01 02:42:47
# Chef源码组织
我们这里讲的Chef源码，是指opscode发布在github的那个名为chef的项目 [chef in github: https://github.com/opscode/chef](https://github.com/opscode/chef)
chef本身就是一个gem，它的源码组织结构，首先是一个gem的组织结构：
### 组织结构
基本上Chef的组织结构是一个标准的gem包。
一个gem包的主要元素：
-
**lib/**
lib下面，是这个gem的核心代码
-
**.gemspec文件**
这里是这个gem的规格文件，里面包含了gem的作者信息、lib的目录位置、bin目录位置、运行时依赖包以及开发时依赖包等
-
**bin/**
如果你的gem有终端命令，那么就放到这个目录下面吧
-
**tasks/**
放置Rack任务的目录。
-
**spec/**
Rspec测试目录
-
**Gemfile**
bunlder的包管理文件。
回到我们的Chef源码目录里面：
### chef.gemspec
这是chef这个gem的规格文件，
~~~
Gem::Specification.new do |s|
s.name = 'chef'
s.version = Chef::VERSION
s.platform = Gem::Platform::RUBY
#...
s.required_ruby_version = ">= 1.9.3"
s.add_dependency "mixlib-config", "~> 2.0"
s.add_dependency "mixlib-cli", "~> 1.4"
s.add_dependency "mixlib-log", "~> 1.3"
s.add_dependency "mixlib-authentication", "~> 1.3"
s.add_dependency "mixlib-shellout", ">= 2.0.0.rc.0", "< 3.0"
s.add_dependency "ohai", ">= 7.6.0.rc.0"
#...
s.bindir = "bin"
#...
s.require_path = 'lib'
#...
end
~~~
一个gemspec文件，必须是按照这种格式来写。实际上是初始化了一个Gem::Specification类的对象。你也可以理解为，chef这个gem，就是一个gem对象。这个文件指定了chef这个gem的各种属性。
### bin
我们再来看下bin目录。 bin里面放置的是chef这个gem所包含的命令：
我们看到chef常用的几个命令了：chef-client、knife、chef-shell、chef-solo等。我们打开chef-client文件看看：
~~~
require 'rubygems'
$:.unshift(File.join(File.dirname(__FILE__), "..", "lib"))
require 'chef'
require 'chef/application/client'
Chef::Application::Client.new.run
~~~
再打开knife文件看看:
~~~
require 'rubygems'
$:.unshift(File.expand_path(File.join(File.dirname(__FILE__), "..", "lib")))
require 'chef/application/knife'
Chef::Application::Knife.new.run
~~~
~~~
require 'rubygems'
$:.unshift(File.join(File.dirname(__FILE__), "..", "lib"))
require 'chef/application/apply'
Chef::Application::Apply.new.run
~~~
我们依次打开这个几个bin文件看了下，除了chef-shell和shef文件之外，结构基本都差不多， 都和上面的代码类似，都是加载了rubygems， 在加载路径里面添加了lib目录， 然后又把lib/chef/applications/下面的相关文件加载，最后用了几乎统一的方法：
~~~
Chef::Application::Xxx.new.run
~~~
我们学过Ruby的基础知识，可以看得出来，Chef::Application::Xxx肯定是被定义在 chef/application/目录下面的Xxx类。
而chef-shell和shef文件，我们打开后，惊异的发现，这俩文件中代码几乎一模一样：
chef-shell:
~~~
begin
require "rubygems"
rescue LoadError
end
require "irb"
require "irb/completion"
require 'irb/ext/save-history'
$:.unshift(File.expand_path(File.join(File.dirname(__FILE__), "..", "lib")))
require "chef/shell"
# On Windows only, enable irb --noreadline because of input problems --
# See CHEF-3284.
IRB.conf[:USE_READLINE] = false if Chef::Platform::windows?
Shell.start
~~~
shef：
~~~
begin
require "rubygems"
rescue LoadError
end
require "irb"
require "irb/completion"
require 'irb/ext/save-history'
$:.unshift(File.expand_path(File.join(File.dirname(__FILE__), "..", "lib")))
require "chef/shell"
Chef::Log.warn("DEPRECATED: The 'shef' program is renamed to 'chef-shell'")
Shell.start
~~~
当我们看到shef中倒数第二行代码的时候：
~~~
Chef::Log.warn("DEPRECATED: The 'shef' program is renamed to 'chef-shell'")
~~~
可以看得出来，Chef::Log.warn ，应该是Chef的日志输出，warn代表一个警告，里面的字符串意思是：过期声明： 这个shef程序已经被重命名为chef-shell了。
好了，我们已经破案了。 只需要看chef-shell就好了。
chef-shell代码中，require了irb及其组件，并且也加载了chef/shell文件，最后启动了Shell.start命令。
chef-shell命令，实际上是开启了一个加载了chef环境的irb交互shell界面。我们在安装了chef的终端输入这个命令就知道了：
~~~
$ chef-shell
loading configuration: none (standalone session)
Session type: standalone
Loading.....done.
This is the chef-shell.
Chef Version: 11.16.0
http://www.opscode.com/chef
http://docs.opscode.com/
run `help' for help, `exit' or ^D to quit.
Ohai2u vagrant@chef-node!
chef >
~~~
你可以输入help查看帮助。
### lib
我们通过查看bin下面的文件，了解到，一个chef命令的执行，必须先加载lib/chef下面的相关文件，那么我们就去lib目录下面看看。
lib目录下面的文件组织也是有规范的：
这样的组织结构，意味着，当我们使用这个gem的时候，直接：
~~~
require 'chef'
~~~
就可以了。 require 'chef'， 这个命令会直接加载chef gem lib下面的chef.rb，我们看看chef.rb中的代码：
~~~
require 'chef/version'
require 'chef/nil_argument'
require 'chef/mash'
require 'chef/exceptions'
require 'chef/log'
require 'chef/config'
require 'chef/providers'
require 'chef/resources'
require 'chef/shell_out'
require 'chef/daemon'
require 'chef/run_status'
require 'chef/handler'
require 'chef/handler/json_file'
require 'chef/monkey_patches/tempfile'
require 'chef/monkey_patches/string'
require 'chef/monkey_patches/numeric'
require 'chef/monkey_patches/object'
require 'chef/monkey_patches/file'
require 'chef/monkey_patches/uri'
~~~
chef.rb中就是一堆require， 加载了lib/chef目录下的全部文件。
所以，chef.rb，算是一个入口。核心的代码还在chef目录下面。
但是我们从chef.rb文件中加载的文件名称中，也可以看出chef整体架构的一个大概。
chef分为四部分，由空行来分隔：
~~~
#第一部分：
require 'chef/version'
require 'chef/nil_argument'
require 'chef/mash'
require 'chef/exceptions'
require 'chef/log'
require 'chef/config'
require 'chef/providers'
require 'chef/resources'
require 'chef/shell_out'
~~~
这部分似乎定义了Chef的版本、配置、日志、resources、providers、shell等应用层面的东西。
~~~
# 第二部分
require 'chef/daemon'
~~~
这一部分，似乎是定义了chef daemon的功能代码。我们知道，chef-client可以以daemon模式运行。
~~~
# 第三部分
require 'chef/run_status'
require 'chef/handler'
require 'chef/handler/json_file'
~~~
这一部分，似乎是定义了chef的运行状态、handler的信息， 用于处理chef的内部状态信息。
~~~
require 'chef/monkey_patches/tempfile'
require 'chef/monkey_patches/string'
require 'chef/monkey_patches/numeric'
require 'chef/monkey_patches/object'
require 'chef/monkey_patches/file'
require 'chef/monkey_patches/uri'
~~~
这一部分，我们看到了monkey_patches 以及熟悉的Ruby内部类同名的文件，几乎可以肯定，这是chef自己对于Ruby提供的类进行了monkey patch，添加了自己要用的方法。 我们在前面讲类与模块那一节，也用这个代码举过例子。
当然，以上都是目测， 让我们继续查看lib/chef下面的文件吧。
### lib/chef
我们打开lib/chef目录，发现里面很多文件和文件夹， 跟我们上面根据chef.rb的猜想有点差别。那么我们把chef.rb中require的文件一个个看一下吧，看完后发现，并没有囊括完chef目录中的所有文件。
那这些文件都是干嘛的呢？
先来剧透一下吧。
如果你看过chef-server-webui，应该可以知道，在chef-server-webui里面也用到了chef，主要是用到了chef/rest这部分文件。
还有上面说过的bin目录下的的命令，也需要用到chef/application.rb以及 chef/application/， chef/api_client/等下面的各种文件。
lib/chef下面还有一部分文件是用于测试的，那些我们就暂时不关心了。
我们继续看看chef最重要的东西。
### Knife
knife是chef中不可或缺的工具。 我们通过knife命令和chef server、node交互。那么让我们来看下knife的工作机制：
### 相关文件
knife 相关的最主要的文件是：
- lib/chef/knife.rb
- lib/chef/knife/*.rb
我们打开lib/chef/knife/目录，可以看到里面定义了很多rb文件， 这里几乎定义了全部的knife的命令实现，以及辅助方法。
如果想深入了解的话，具体看代码吧。
### Chef Client
chef client的所有行为都在lib/chef/client.rb中。
### Chef中的DSL方法
构成recipe的那些chef resource，都在chef/resource.rb和chef/resource/目录下面被定义。
尤其是在chef/resource/目录下面，定义了我们常用的resource：
- file
- template
- execute
- directory
- template
- user
等等。具体可以再深入研究源码。