I was trying to figure out which of these is best for me, by asking users and looking online. Consensus seems to be that:
Ansible is the easiest to grok/deploy unless you're a Ruby person. All the users are happy with what it provides, only complaints I could find were about its speed in large-y deplyoments (>500) - and that seemed to be addressed by Fireball mode in the past, and the new daemon mode in newer versions - though I haven't actually found testaments for that.
Salt seems to click for some people, is too complicated for others. Had a couple of security issues (e.g. http://www.openwall.com/lists/oss-security/2013/07/01/1 since addressed - but it is a smell when people who shouldn't roll their own crypto)
Chef and Puppet seem to work great, and you can find lots of support for them, but are heavier and seem to require more setup (e.g. chef "minions" which are agents on the managed machines, even though there's some kind of no-setup-needed mode)
Windows seems to be an outcast as far as management servers go. Some people get it to work, non recommend it. But I don't care about provisioning Windows, so I didn't delve into what's actually possible.
relevant: http://news.idg.no/cw/art.cfm?id=D21968B0-EE1C-1249-85D672B3...
I had similar experiences with Puppet and Chef. First and foremost, a steep learning curve. You spend several days learning a new DSL, concepts, available recipes, and understanding all the magic that happens behind the scenes.
The server side is also a pain. Opscode's Chef Server (free till 5 nodes) is painfully slow, and Puppet Server is rather heavy (it requires a medium EC2 instance). I tried also running only with chef-solo, but it defeats the purpose of using Chef.
Authentication can be also confusing, particularly for Puppet, with host-specific certificates, cache, etc.
I just started using Ansible last month, and it has been a pleasant surprise so far. Very easy to learn, even easier to maintain, no DSL (it's just YAML files), and extensible via Python or Bash modules. The key management is also a piece of cake: SSH keys, instead of the pain of custom certificates like Puppet.
Ansible probably isn't the best option for someone with hundreds or thousands of nodes (that's the primary market for Puppet/Chef), but seems perfect for someone that has outgrown ssh and shell scripts.
Haven't played with Salt much, but seems closer to Ansible than to Chef/Pupper.
Salt was picked because it was both simple to get up and running and fairly powerful. Chef & Puppet were both evaluated first but salt clicked better with our environment. Additionally being packaged in EPEL, and running on the older system versions of python made it a lot easier to manage. Having a strong API opens up more opportunities.
The custom scripts are there to automate the system provisioning in VMWare.
Our infrastructure is run on our own hardware and use VMWare vSphere for virtualisation. As our workloads use larger instances (24gb of ram) and higher then average IOPS, we found it cheaper to run our own hardware (including labour costs). This is further helped by the fact our usage is fairly consistent and as such we are able to run much of our infrastructure at capacity (with a reasonable safety margin).
I am currently working building an interface that will combine the deployment, management, monitoring (performance and fault), networking and configuration across all the components of our infrastructure to make it more "Cloud Like" as the younger developers seem unable to perform even basic administration tasks that were expected of the older developers.
No, the script is a python one using PySphere to interface with the vSphere server. It creates a new vm with appropriate disk, ram, vcpu and networking to the right networks. The script also creates a PXELinux config file so when the system boots it gets a custom PXE configuration with directs it to boot the CentOS installer with a kickstart file that has been created for it. This kickstart file specifies the hostname, network configuration, default packages, system password and Salt configuration. The system does an unattended install.
Once the system boots it binds to the Salt Master and pulls down its configuration which configures the server to its role (App server, database, redis, etc).
It was done this way mostly because I was familiar with it from my days as a red hatter, but there also was a bit of a desire to not get too tied into VMWare. We are relatively small (though run ~ 50 servers), and only afforded VMware through the Essentials Plus package. We are not a VMware shop by any measure, and will be looking for the best option (be it physical systems, virtual infrastructure or cloud providers) when our hardware support & software licenses expire.
We know Python, we don't know Ruby, and we have waaaay less than a dozen servers all up, including staging and dev environments. We don't need anything too complex or over-engineered, but we do need something that'll work, is quick to get started with, and is at least better than the mess of fabric scripts we had before. And ideally it should integrate well with what we already have, and scale as far as we need it to.
Ansible works for this very well. Install it on the machine you want to control everything (my laptop, right now), add all your servers to a manifest, hack together some simple playbooks using a very clear YAML-based DSL, and...you're done. It works via SSL, so no crazy issues with certificates, no complicated server infrastructure, nothing to install on the clients. The barriers to entry are vastly lower than they are for Chef or Puppet; even Chef Solo is kind of overkill. And being in Python is nice; I can hack on a Ansible module if I need to. People love the fact that Chef cookbooks are "just Ruby!" but if you don't know Ruby that's not a good thing; it's much easier to learn Ansible's DSL than Ruby.
At the moment we're using DO, so the process right now is to log in to DOs control panel, create a new droplet, add the IP address to the Ansible inventory, and then hit go, and Ansible will configure everything magically.
Deployment we're still ironing the kinks out of. We're using Dokku for one part of our stack, which is working...okay. Another part is using an Ansible playbook to grab a custom docker image and deploy it, which is a bit nicer. I'm still trying to decide how useful a role Docker is playing; I know it's the new hotness but it's not 100% clear to me that cloning a git repo locally, building docker image, pushing it to a docker repo, pulling it back out of a docker repo on a remote server, and firing it up is that much better than just, you know, cloning a git repo and building the app.
Anyhow, out of Chef, Puppet, Salt, Ansible, etc. we're using Ansible 'cause it solves our problems quickly and easily. If you've ever growled to yourself "christ, I could write a shell script to solve this so easily, why is this HARD?!", well, with Ansible it's not hard, but it still solves stuff you could never do with shell scripts or Fabric.
With dotCloud though, deployments don't have any of that nonsense. Well, I suppose it does, but it was all part of the process. A simple `dotcloud push .` in a directory would run a script that 1) checked to see what servers and services (mysql, postgres, python, nginx, etc.) needed to be pushed to, 2) synced the code up to the server (can't remember if it was scp or rsync -- I think scp), 3) run migrations, 4) pip install requirements.txt.
My own process had a script in front of that to ensure that pushes came from commits, and I also had post-commit hooks that ran other tasks, but the act of deploying code to a dotCloud instance (which is essentially a Docker container) was never more complicated than `dotcloud push .`
I wanted a masterless setup where there would be no central master so I use Puppet as a git repo with Fabric, where Fabric takes care of parallel ssh keys management with Gitlab (git hosting software, used internally) and deployments. I've added custom python modules to manage continuous deployment of code as well, I really like the basic command and programmable interfaces it offers, roles and just programming in Python. The whole setup thus uses a masterless Puppet (git) + Fabric, works on an exclusive private network across datacenters.
Personally I use Slaughter, which is serverless and applies policies located on github. (Disclaimer I wrote it). I consider it a server-less cfengine-lite, but with the added freedom of allowing arbitrary perl
http://steve.org.uk/Software/slaughter/
When it comes to any automation you need to set your limits, and decide what you're doing:
* Just setting up an initial stack of services, etc. * Maintaining the system going forward. Reverting local changes, etc.
how large is your company (human-wise/not servers)? what technology is your org most familiar with? Do you have a budget? Is enterprise support important to your company? are you dealing with any rules/regs (HIPPA, etc)
Disclaimer: I offer CFEngine training, http://www.verticalsysadmin.com
Any of them will make your deploy/config life great.
Puppet isn't that heavy - I use the agent to bootstrap my laptops, e.g. on ubuntu, apt-get install puppet, create a file with this contents named laptop.pp and then run 'puppet apply laptop.pp':
$tools = [ 'aptitude', 'at', 'elinks', 'mtp-tools', 'mtpfs', 'libxml-devel', 'puppet-lint', 'msmtp','rxvt-unicode', 'python-dev', 'python-pip', 'xclip', 'xsel', 'vagrant', 'virtualbox', 'unrar', 'p7zip-full', 'netcat', 'socat', 'zsh', 'screen', 'strace', 'sudo', 'tmux', 'scapy', 'ruby1.9.1-dev','rubygems', 'git', 'git-annex'] package { $tools: ensure => 'installed' }
$window_manager = [ 'xmonad', 'ttf-inconsolata', 'dmenu','dzen2', 'libghc-xmonad-contrib-dev','libghc-xmonad-dev', 'xmobar']
package { $window_manager: ensure => 'installed' }
$audio_video = [ 'vlc', 'moc'] package { $audio_video: ensure => 'installed' }
$games = [ 'mame', 'mame-tools', 'gnome-video-arcade', 'sdlmame', 'sdlmame-tools', 'mednafen'] package { $games: ensure => 'installed' }
$productivity = [ 'mutt-patched', 'rtorrent', 'irssi', 'bitlbee'] package { $productivity: ensure => 'installed' }
$python_pip = [ 'zipline', 'blueprint', 'ansible', 'salt', 'grc'] package { $python_pip: ensure => 'installed', provider=> pip}
$gem = [ 'jekyll', 'knife-ec2', 'chef', 'rake'] package { $gem: ensure => 'installed', provider=> gem}
file { '/home/username/.xmonad/': ensure=>'directory' }
file{ '/home/username/.xmonad/xmonad.hs': ensure=> 'present', source=> '/home/username/bootstrap/templates/xmonad.hs', owner=> 'username' }
file { '/home/username/.xmobarrc': ensure=> 'present', source=> '/home/username/bootstrap/templates/xmobar-rc', owner=> 'username' }
exec { '/usr/bin/xmonad --recompile': subscribe=> File['/home/username/.xmonad/xmonad.hs'], refreshonly=> true }