Chef, Puppet, Salt, Ansible. What do you use for server setup and deployment? - alfor
======
beagle3
(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](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...](http://news.idg.no/cw/art.cfm?id=D21968B0-EE1C-1249-85D672B34C0DA5BB)

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

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

~~~
Patrick_Devine
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.

~~~
jlawer
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.

~~~
rglauser
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.

------
Lazare
Ansible.

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.

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

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

------
stevekemp
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

[http://steve.org.uk/Software/slaughter/](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.

~~~
xdanger
Have you tried [http://www.rexify.org/](http://www.rexify.org/) ?

------
makerops
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)

------
atsaloli
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](http://www.verticalsysadmin.com)

------
gpurkins
"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.

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

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

------
sesteel
puppet current job, chef at last

~~~
xfax
Any pros/cons you're willing to share?

------
namecast
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 }

