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应该是被支持得比较好的（再次说明一个体面的包管理工具有多重要）。
概念就是这些了。接下来我要自己动手做一顿服务器大餐。
（未完待续）
