On Wed, Nov 12, 2014 at 4:42 PM, Edward Ned Harvey (lopser) <lop...@nedharvey.com> wrote: > I'd like to build a VM on my local vmware or virtualbox or whatever, and then > essentially clone it to AWS or vice versa... Make some change on a > development machine, test it, and then after it's validated, replicate that > change to the production environment by sending essentia > lly the snapshot differential of the configuration. > > For some reason, this is what I thought puppet/chef/etc did. Am I wrong? Is > this a pipe dream?
This sounds more like Docker than Configuration Management. I've used CfEngine 2 for many years and Puppet for several. I know people who use Chef, Ansible, and Salt. Here are my impressions: TL;DR: it depends I would use Puppet when I have a wide variety of configurations and systems tend to stay in use for months or years. I would use Chef when I build a lot of similar systems and keep them up for days or weeks. I would use Ansible when I need to push changes to a system "right now" but don't need to manage the state of that system. I would use Salt when I need to build full application stacks including many dependent types of systems, and don't need to manage the state of the systems. Puppet is good for maintaining the state of your systems. It is, more than any other tool, it is a description of how the system should be configured. It is difficult to scale up to large scale (thousands of systems), mostly because all the work of building the catalog is centralized on the PuppetMaster. Because the PuppetMaster knows everything about all your systems it is trivial to do things like "create a Nagios check for all systems with Apache installed." Only the puppet master knows the secrets of all the systems, each system doesn't know anything about other systems; that makes it difficult to do something like "build the application server as soon as the databases server is built"; aka "orchestration" Puppet implements a DSL, so it is "easy" to rebuild it in other languages if the need presents itself. Chef is good for deploying systems. Chef is essentially an extension of Ruby, using Ruby syntax and libraries to create "executable documentation" about the system. You will *always* need Ruby on every Chef-managed system. Chef scales because all the work is done on the client, so the work is distributed. It can be easy to "accidentally" bleed secrets between systems because, typically (although I believe there has been work to correct this) each system gets the full set of instructions for every system. Ansible is, literally, "ssh in a for loop"; sometimes that is what you want. Ansible is great at deploying systems and at making instant changes to a group of systems. Ansible sends commands to each managed system or group or systems, runs the commands, and returns the output of the commands. You run Ansible manually, I haven't talked to anybody who runs Ansible on an automatic schedule like Puppet and Chef are typically used. I know people who use Puppet and Ansible together. I understand Salt uses a message queue to deliver configuration to systems, similar to how Ansible uses SSH. Salt is able to orchestrate configurations. It knows as soon as the database server is built and can start building the application server. I have a lot of love for CfEngine3, although I've never used it and don't know anybody who is. -- Perfection is just a word I use occasionally with mustard. --Atom Powers-- _______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
