我试图在手动配置和自动化之间找到一个愉快的媒介.我有两个很好的问题：
1)为每个应用程序设置一个带有烹饪书和角色的厨师服务器是否更明智？或者我们应该隔离每个项目,并为每个应用程序配备一个厨师服务器？
2)(如果我们有多个厨师服务器)我应该如何管理多个厨师服务器？与另一个厨师服务器？厨师独奏？
我看到许多文章记录了如何设置厨师或覆盖功能,但我还没有看到一个非常好的文件记录了某人在中大型生产环境中实际使用厨师的方式.这方面的一些提示可能很好.
谢谢！
主要问题有点棘手.关于多少抽象“不太多,但不是太少”的滑稽回答.只是稍微认真一点,这是你真正需要自己解决的问题,因为它取决于很多因素.一个很好的第一步是创建一个“basenode”配置(角色和环境属性),让所有节点都由Chef管理.这可能包括一堆现有的社区食谱,例如：
> build-essential
> chef-client
> users(虽然我更喜欢fnichol的chef-user cookbook)
在此阶段,您的应用程序将在基本节点上手动配置和安装.
现在您应该更好地了解Chef的工作原理,以便您可以开始考虑更多特定于域的烹饪书.继续自下而上并编写食谱来安装应用程序所需的软件包,并使用属性和数据包进行配置.您提到的20个应用程序(例如,它们大多数是Rails应用程序)之间可能存在一些共性,您可以将其分解为一组通用的配方.
您在寻找手动配置和自动化之间的介质方面做得很好.我与Chef开始时陷入困境的其中一个陷阱是尽可能地尝试自动化.这最终变成了角落案件的噩梦和通过手动重启服务或重启节点而修复的奇怪错误.维护和调试并不好玩.这些天我尽可能地坚持包,文件和模板资源.
拥有100个角色确实听起来有点过头,但我不知道有关你的情况的更多细节.我倾向于使用更多通用角色,如“Apache-Server”或“RabbitMQ-Server”,然后使用属性,数据包和更具体角色的各种组合来个性化每个节点.