Chef学习手记之叁：红宝石菜谱
March 2nd, 2011
有了一台 基本的服务器 ，现在我就要在上面配置Rails服务器。当然这件事已经有人干过了，但我不想用别人的菜谱，再怎么说我也是 RubyWorks 的开发者…
（还有，我觉得Fedora还是不如Ubuntu好用，所以我偷偷把EC2的机器换成了Ubuntu 10.04。）
新建一个菜谱真容易，用knife一下子就搞定了：
$ knife cookbook create my_rails_gig
菜谱放在 #{chef-repo}/cookbooks/my_rails_gig 下面。首先要看的是 recipes/default.rb ，缺省菜色的做法就写在里面。在我开始做自己的配置之前，我得先保证Apache和 Passenger 都配好了。
# default.rb include_recipe "passenger_apache2::mod_rails"
然后涅，我要用“railsapp”这个用户来部署Rails应用──不可以用root来跑服务。所以我得确保有这个用户（以及它独占的一个组）。
# default.rb group 'rails' do group_name 'rails' action :create end user 'railsapp' do username 'railsapp' action :create end
接下来，按照我们RubyWorks的传统，Rails应用应该部署在 /var/rails 目录下面。所以要确保有这个目录。
# default.rb deploy_to = '/var/rails' directory deploy_to do owner "railsapp" group "rails" mode "0755" action :create end
现在是最挑战的部分：配置Passenger…但是只要是像我一样经验丰富的Rails服务器管理员，这个也小菜一碟_ Apache2那本菜谱 讲了怎么在Apache里做web_app，你只要调用就行：
# default.rb
web_app 'rails_app' do
template "rails_app.conf.erb"
docroot "#{deploy_to}/current/public"
server_name "#{MY_COOL_HOSTNAME}"
rails_env 'production'
end
唯一的trick就是 rails_app.conf.erb 这个template：我需要把它放在 templates/default 目录下（规则和Rails有点像）。别的么…就再没啥啦～～（不信就 看代码 ）噢对了，别忘了在这台机器的角色里加上新的菜色：
"run_list": [
"recipe[passenger_apache2::mod_rails]",
"recipe[my_rails_gig]"
],
噢也～菜谱写完开始做菜～先把菜谱上传到服务器：
$ knife cookbook upload my_rails_gig
再跑到我的服务器上执行一下 chef-client …这就好了。用 railsapp 用户到 /var/rails/current 下面建一个应用（为什么要“current”？问 Capistrano ）。浏览器访问80端口，看后台日志，Rails已经开始工作了。
嗯，虽说写自己的菜谱挺好玩的，不过 这个菜谱 很值得学习──其实很多菜谱都值得学习，所以…
（未完待续）
Program? Me?
February 27th, 2011
这也不是新鲜事。这也不是中国特色。从前听的版本有几个：
- 业务分析师是不会写程序的。（所以 Cucumber 写出来要像自然语言。）
- 测试人员是不会写程序的。（所以 Selenium要有IDE 。）
- 界面设计人员是不会写程序的。（所以我们还得有个叫“前端程序员”的人用HTML+CSS把图片做成页面。）
- 项目经理是不会写程序的。（这个，大家都习以为常了…）
现在最新的版本是：系统管理员是不会写程序的，所以 Puppet 比 Chef 要好那么一点点（TWers请看这两天twswdev上的讨论），因为Puppet是声明性的DSL而Chef直接就是Ruby代码。Ruby代码会把笨笨的系统管理员吓倒云云。
扯淡。
所有这些人，只要还在从事软件开发相关的工作，他们都需要描述抽象的概念、把概念分别组织、用合适的词汇使概念描述可懂、关注概念中易变的部分和不变的部分、抽取概念中的共性、消除概念描述的重复。这个，就是编程。你可以逃避它，你可以拒绝学习它，但当你认真对待它，当你把它做好了，这就是编程。那时候你就会发现，Ruby是一种具有强大表现力因此更贴心的编程语言，HTML+CSS是比Photoshop更适合描述界面的语言 。
重点在于：如果你一直在用一种并非设计用于描述大量复杂抽象信息的表达方式来描述大量复杂抽象信息，你为什么不去学会一种本来就设计用来干这个的工具呢──那就是编程语言；另一方面，如果你并没有在描述大量复杂抽象信息，很可能你的工作可以被一个脚本取代。
毕竟，从前的系统管理员都是Perl和Shell的高手。现在突然说他们不会编程，这个对我来说实在太突兀了。
Chef学习手记之贰：基本套餐
February 20th, 2011
现在我要配置一台体面的Rails服务器。也许我会用它来跑 1.HourFor.me 。
要配置一台Rails服务器，首先要有一台服务器。于是我到 EC2 搞了一台服务器。EC2之于DevOps就像SourceForge之于轻量级J2EE：它让你有机会去尝试那些原来只有在超级大企业里才会出现的东西。你可以在自己家里、在业余时间积累经验，而且不花多少钱。我装了一台Fedora 8的机器。
在 学习手记之壹 里我说需要有一个Chef服务器。其实Chef有三种运行的方式：你自己装Chef服务器；压根不要Chef服务器（叫 Chef Solo ）；或者用OpsCode做你的Chef服务器。第三种方式蛮好，又不用自己多架台服务器，又可以在世界任何地方共享我的大餐。所以我就要这样做。
首先要在OpsCode注册，并创建一个组织（organization）。这部分蛮简单，照着网站的指示一步步做就行了。我创建了一个叫“thoughtworkers”的组织。创建组织的时候小心，有免费的plan可以用的。我现在还不需要收费plan那么强的功能。
紧跟着要搞定开发环境。我要在自己的机器上建一个 Chef Repository ，配置与Chef服务器连接的身份认证信息。基本上，按照 这个文档 来操作就可以了。
接下来要在EC2那台Fedora机器上安装Chef客户端。这也蛮简单，也有 一个文档 。其实关键就是要把RubyGems升级到1.3.7以上，然后就可以“gem install chef”啦。装好之后执行一下“chef-client”，应该会报错，需要从本地环境拷贝/etc/chef下面的client.rb和validation.pem去Fedora机器上。
现在可以写程序咯～在Chef Repository下面的roles目录里建一个base.json文件。先不管是Rails服务器还是Django服务器，我的体面服务器必须满足一些基本条件，比如有GCC啦，有Git啦，之类的。所以我在base.json里这样描述我的体面服务器：
{
"name": "base",
"default_attributes": {
"chef": {
"server_url": "https://api.opscode.com/organizations/thoughtworkers",
"cache_path": "/var/chef/cache",
"backup_path": "/var/chef/backup",
"validation_client_name": "thoughtworkers-validator",
"run_path": "/var/chef"
}
},
"json_class": "Chef::Role",
"run_list": [
"recipe[build-essential::default]",
"recipe[openssl::default]",
"recipe[chef::client]",
"recipe[chef::delete_validation]",
"recipe[git::default]"
],
"description": "Basic Server",
"chef_type": "role",
"override_attributes": {
}
}
然后涅…那台Fedora机器咋知道它自己应该有“base”这个角色呢？当然答案是它不知道。我得告诉它。Knife 是Chef的便利命令行工具。比如说，可以列出所有可管的节点（必须在Chef Repository目录下）：
$ knife node list # 下面是输出回显 [ "ip-10-130-9-17.ap-southeast-1.compute.internal", "jeffxiong3650" ]
有两台机器。下面这个是我自己的笔记本电脑，上面那个名字很长的就是在EC2的Fedora。我要让它知道，自己有“base”这个角色要扮演：
$ knife node run_list add \
ip-10-130-9-17.ap-southeast-1.compute.internal "role[base]"
# 下面是输出回显
{
"run_list": [
"role[base]"
]
}
好乖～现在ssh登录到Fedora上去，执行一把“chef-client”…体面的服务器就这样装好啦～试试git，没问题的说～嗯嗯，当然这只是第一步。接下来要配置好体面的Rails服务器才行呢。
（未完待续）
Chef学习手记之壹：概念
February 19th, 2011
Chef 据说是 DevOps 运动中的一个重要工具。现在我开始学它了。
首先是几个名词解释：
- Chef: 大厨。我就是个新手大厨。我想要烹调一桌服务器大餐，也就是一台体面的、可以用来满足某种用途的服务器，比如“一台高性能的Rails服务器”。
- Cookbook: 菜谱。别人写好的一本书，书上写着一堆相关菜色的做法（比如“家常川菜”）。一些出色的服务器大厨已经写了 很多菜谱 ，这些是我要学习和抄袭的。
- Recipe：菜谱里的一道菜色（比如“麻婆豆腐”）。服务器大餐里的某一部分该怎么做，都在菜色里写着呢。
所以，整个故事就是：作为一个服务器大厨（Chef），我想要从现成的很多菜谱（Cookbook）里挑选几道合适的菜色（Recipe），组合成一道大餐（服务器）来款待我的客人。
（等我的手艺熟练之后我还会写我自己的菜色和菜谱，这就是后面的故事了。）
Chef的主要目标是：把服务器配置变成源代码。这样做的好处有两个：
- 自动化。我可以很轻松地把一台服务器大餐的做法直接照搬到另一台服务器上，于是我就得到了另一台大餐。
- 配置管理。服务器的配置信息可以用SVN或者Git来管理，可以分享，可以多人协作，可以跟踪变化历史。
Chef使用服务器-客户端模式管理所有需要配置的机器。使用Chef涉及至少三台机器：一台开发机器，我会在上面编写大餐的做法；一台Chef服务器，它会管理所有要配置的机器，给它们下发配置信息；至少一台Chef客户端或“节点”（Node），它就是我要烹调的大餐。
理论上，只要支持Ruby的操作系统，都可以作为Chef节点来管理。不过 认真说起来 ，AIX、HP-UX和Windows不能算真的支持（个人认为这些到了21世纪10年代还没有体面的 包管理工具 的操作系统就应该自己去死）。另外，每个Cookbook对操作系统的支持也可能不同。我大概看了一下，Ubuntu和Debian应该是被支持得比较好的（再次说明一个体面的包管理工具有多重要）。
概念就是这些了。接下来我要自己动手做一顿服务器大餐。
（未完待续）
