41–50 of 71 posts
For a non-Puppet and non-Chef user, would someone explain why you'd limit your choices to puppet and chef?
Some highlights:
• Python based
• Uses SSH key-based auth
• No central server required
• Only requires SSH and a Posix shell on the client
I recently had occasion to look at Cfengine, Chef and Puppet. I chose Puppet. http://chester.id.au/2012/06/27/a-not-sobrief-aside-on-reign... (scroll down if you don't enjoy my windbaggery). The short version is: Puppet best fits the way I think about how such systems should work. Despite ostensibly belonging to the same genre of system, the three of them have subtle but very important differences.
See "Relative Origins of Puppet, Chef and CFEngine" http://verticalsysadmin.com/blog/uncategorized/relative-orig...
Why not add: or Fabric or Ansible or something else? I haven't found much that Fabric won't do for me and I haven't found much reason to install Ruby on my system [Python is a system package]. For a non-Puppet and non-Chef user, would someone explain why you'd limit your choices to puppet and chef?
Why not add: or Fabric or Ansible or something else? I haven't found much that Fabric won't do for me and I haven't found much reason to install Ruby on my system [Python is a system package]. For a non-Puppet and non-Chef user, would someone explain why you'd limit your choices to puppet and chef?
I'm not familiar with Ansible, but Fabric seems more like SSH with a for loop. Puppet and Chef are not about automating the typing as much as they are about ensuring consistency. In my Apache example above, if someone goes and changes a vhost file by hand, that file will be replaced with a good one and Apache will be restarted, even if that file was made by a complicated template.
Why not add: or Fabric or Ansible or something else? I haven't found much that Fabric won't do for me and I haven't found much reason to install Ruby on my system [Python is a system package]. For a non-Puppet and non-Chef user, would someone explain why you'd limit your choices to puppet and chef?
One huge advantage that puppet and chef offer is abstraction from the underlying system. So if you write a configuration that says "Apache should be running, have PHP installed, and have the following 3 virtual hosts installed", then you don't care if you're running on Solaris, Debian, or CentOS. The manifest/recipe takes care of figuring out what the package is called and where the config files go. I'm not familiar…
We started off writing the bulk of our server setup/deployment automation in chef, and have since completely abandoned it The core problems we had with chef were: • worse than ruby: the chef ruby DSL is like some bastardized, crippled ruby - e.g. ruby_block{}, just uggh • way too slow & resource intensive: chef itself uses a lot of memory and CPU, has a slow boot time, and does stuff like execute apt for each desired…
I have used both extensively. I found Puppet much easier to get started with but the custom Puppet DSL becomes very quickly constraining. I know that a new pure Ruby DSL is in the works. I found that Chef has a steeper learning curve but many times greater productivity. I do feel that their is much better tooling support for Chef than Puppet, in large part because Chef's pure Ruby approach is much friendlier to Ruby…
http://puppetlabs.com/blog/ruby-dsl/ http://puppetlabs.com/blog/gsoc-project-ruby-dsl-for-puppet/
Why not add: or Fabric or Ansible or something else? I haven't found much that Fabric won't do for me and I haven't found much reason to install Ruby on my system [Python is a system package]. For a non-Puppet and non-Chef user, would someone explain why you'd limit your choices to puppet and chef?
One huge advantage that puppet and chef offer is abstraction from the underlying system. So if you write a configuration that says "Apache should be running, have PHP installed, and have the following 3 virtual hosts installed", then you don't care if you're running on Solaris, Debian, or CentOS. The manifest/recipe takes care of figuring out what the package is called and where the config files go. I'm not familiar…
then you don't care if you're running on Solaris,
Debian, or CentOS.
Fabric seems more like SSH with a for loop.
if someone goes and changes a vhost file by hand, that file
will be replaced with a good one and Apache will be restarted,
even if that file was made by a complicated template.