Puppet部署、迁移与代码工作流管理
1. Puppet的优势与常见问题
Puppet的操作具有持久性，系统重装后仍可应用，且操作本身具有文档记录性。而手动快速修复容易被遗忘，在需要复制操作时会浪费大量时间，且无法追溯操作的方式、位置和原因。
引入Puppet时，许多恼人且危险的问题源于未能真正接受该工具所需的思维方式和技术。人们进行手动更改却未在清单中实现，Puppet首次运行时更改会被还原，若出现问题，Puppet会被归咎。在某些情况下，人们会选择禁用Puppet并手动修改系统，这在紧急情况下可能合理，但手动修复后，必须将更改集成到Puppet并重新启用。若不这样做，基础设施中禁用Puppet的服务器会增多，配置基线的偏差会越来越大，重新启用服务会变得更加困难、危险且耗时。
2. 设计Puppet友好型基础设施
Puppet在管理文件、包和服务方面表现出色，但在执行普通命令时效果不佳，尤其是偶尔执行的命令。引入Puppet时，应尽可能采用有利于其实施的方式。
例如，在管理Java应用时，开发者认为良好的API是更好的配置方式，但系统管理员和Puppet用户更倾向于使用普通配置文件，因为能用文件表达的内容，Puppet更易管理，而执行命令的操作即便可行，也常受到怀疑。
软件安装应通过操作系统原生包进行，使用自定义定义来获取、解压和编译tarball的方式不受欢迎，因为它是过程式和非声明式的，难以实现幂等性，且用Puppet DSL表达效果不佳。服务管理应遵循操作系统原生方法，使用自定义启动脚本执行命令来管理服务并非Puppet友好的方式。对于常见应用栈的配置文件，应加以利用，例如管理应用服务器上的Java设置时，应在同一位置
