Hacker News new | past | comments | ask | show | jobs | submit login
Chef, Puppet, Salt, Ansible. What do you use for server setup and deployment?
23 points by alfor on Nov 22, 2013 | hide | past | web | favorite | 19 comments

(not the kind of answer OP is looking for, but...)

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've been dabbling with three of the four for the past year. My needs are modest: 4-8 servers, plus a few dev environments. Something to simplify management, and have a replicable environment in the case of a server crash, migration, upgrades, etc.

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.

Custom deployment Script for VMware & Kickstart for system imaging with post deployment configuration being Salt.

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.

When you say VMware & Kickstart do you mean you're using the VMware scripted installer? I did the design for that and was the lead engineer for a long time.

I'm not familiar with the scripted installer or if it would have fit our needs.

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.

Very compelling. I am filling in some of the content gaps for SaltConf (SLC, Jan. 28-30, 2014, www.saltconf.com) and would love to have you talk at the conference. This topic is a really good fit for content I am looking for. Speakers get a free conference pass. If you would be interested, please send a note to saltconf at saltstack dot com and I'll be in touch with next steps.


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.

Disclaimer: I haven't used Docker, not even once. I'll blame the current workload, because it's very much on my todo list, as I love(d) dotCloud.

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 .`

For my company's server infra automation I evaluated Chef, Puppet, Salt, Ansible, Fabric. The deciding factors for me were a stable software with a good ecosystem. I found that Puppet is much better than the rest when it comes to having an active community, but I like the scriptability, hackability and simplicity of Fabric. Chef was nice too but found it cumbersome to setup and write recipes compared to Puppet's module.

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.

At work we use cfengine/puppet to maintain systems, but we've started experimenting with Ansible to perform simple setup of hosts.

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


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.

Have you tried http://www.rexify.org/ ?

Tech-wise, they all have pros/cons, but really, this isn't a tech question imo. It is business/organization specific;

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)

CFEngine due to its maturity (in its 3rd generation and is based on science (promise theory)), portability (it's written in C so it can work on any UNIX-like system, even old or small) and power and flexibility.

Disclaimer: I offer CFEngine training, http://www.verticalsysadmin.com

"oh no I have so many amazing tools to choose from?", I use puppet at the moment.

Any of them will make your deploy/config life great.

Using Chef Solo and learning about Docker recently. As soon as possible, I would like to read more about Ansible.

Both Ansible and Chef combined. Ansible for provisioning/orchestration of Chef cookbooks/recipes.

puppet current job, chef at last

Any pros/cons you're willing to share?

Puppet at work, mostly; I've spent the past five years working with both puppet and chef for various clients and jobs. Working on trying out ansible for my own private host, setting up.

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 }

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact