Bes*_*ces 83 puppet configuration-management chef-infra cloud-init
我们计划使用非"预烘烤"的AMI EC2实例.即,当它们被旋转时,它们只是AWS linux的安装.我们的引导过程将引入我们需要的各种安装,例如python,tomcat.我们最少有3个实例,最多8个实例.
鉴于这些要求,使用Puppet/Chef是否有用而不是使用Amazon Cloud Formation(CloudInit)？
我能看到的最好的是如果我们使用Puppet,那么我们就会进行声明性编程,这样可以更容易地进行审计,以查看脚本发生了什么.此外,CloudInit有一个16k的脚本大小限制,我们可能会或可能不会遇到.
有没有人从CloudInit转移到Puppet或Chef,因为他们可以在这里回答我的问题？
cze*_*vik 80
比CloudInit有优势吗？是的,绝对是他们中的很多人!
当然,一旦CloudInit脚本配置服务器,您就可以从上到下编写.但是,当您需要更改配置文件,添加用户,更新软件包或安装新软件包时会发生什么？您将最终登录服务器或编写脚本来执行此操作,并且不可避免地会出现一种不协调的服务器状态.
CloudInit不是配置管理.如果您选择开始使用配置管理软件,请仅使用cloud init执行一项任务:启动Puppet/Chef /其他代理.
Puppet不仅可以帮助您自动安装软件包,设置ssh密钥或调整Tomcat堆.它确保了事物的状态.当开发人员在凌晨3点对Java应用程序进行故障排除并更改Tomcat配置时,Puppet会将其更改回来.您可以快速更改所有节点或节点组的Python版本,如果有人安装了不同的版本,Puppet会将其更改回来.
当您的应用程序堆栈发生变化并开始使用时,例如RabbitMQ,Jetty或新的RDBMS,您可以轻松地在数十或数千台服务器上测试和部署这些更改.
使用配置管理软件还有许多其他原因,例如后端报告,审核和安全合规性.
Chr*_*her 63
配置管理的整个要点是以可预测和一致的方式启动机器.当您完全受限于AWS时,CloudFormation和cloudinit非常棒(尽管调试CloudFormation模板是一种悲惨的经历),但是同时使用数据中心资源和AWS,本地测试环境或开发机器的应用程序呢？
如果您纯粹存在于AWS中,我认为您可以使用cloudinit而不是其他任何东西,但我不相信它对于任何规模的应用程序都是现实的(例如,Netflix,使用他们编写的OSS技术预烧AMI)并向全世界发布;请考虑此视频了解详情).高度可用的应用程序是跨区域的,通常基于VPC,倾向于备份到VPN上的数据中心,这甚至不涉及演示,登台,测试或开发环境.作为一个负责配置机器的人,我想做的最后一件事就是重复工作或者调试多种配置方法.
因此厨师或木偶.它们对AWS的工作方式与对我的数据中心的工作方式一样,对于运行Vagrant的开发机器也同样适用于我偶尔需要的演示环境.我宁愿从cloudinit推出Chef或Puppet而不是同时维护cloudinit和Chef或Puppet.
小智 5
对于扔掉服务器,比如在自动缩放组后面跑,我会说cloudinit可能已经足够了.linux shell脚本或windows powershell脚本应该可以解决问题.
如果它是一个长期运行的服务器,你计划管理厨师,木偶或码头工人可能会给你一个优势,如接受的答案所述.如果在使用它们后看不到优势,那么您可能不需要该工具.