Salt: Like Puppet, Except It Doesn’t Suck

http://blog.smartbear.com/devops/a-taste-of-salt-like-puppet-except-it-doesnt-suck/

by Baustin • 13 years ago

354 260 13 years ago

blog.smartbear.com

boothead• 13 years ago

This is timely! I've just started writing a set of salt states to capture the set up of my new dell xps 13 (sputnik) so I never have to go through the pain of setting up xmonad, emacs and various other development environment stuff again.

What I really like about salt is that everything is in one place and all goes towards building the same data structure that everything runs off.

jtreminio2• 13 years ago

I was frustrated with Puppet when I first started. All I wanted was a VM to install a few things so I could do some development and not have to worry about managing my VM.

It turned out to be a rabbit hole. As soon as I thought I learned just enough to get it running, something else popped up that stopped me.

That's why I created PuPHPet [1]. So far the reception has been fairly positive.

At one point in my learning, I got fed up and tried Salt. I couldn't get the Salt hello-world running. I followed the directions to a T. If your tutorial is incorrect, or hard to follow just to get the most basic version up and running, it will turn people away.

Also, this was all on top of Vagrant.

[1] PuPHPet - https://puphpet.com

joemaller1• 13 years ago

PuPHPet works very well for getting basic Vagrant boxes up and running. Thank you.

nkuttler• 13 years ago

Interesting. I find the salt documentation excellent and haven't found any serious bug in it. Too bad it didn't work for you and that you gave up so soon.

tr46562• 13 years ago

This is a pretty quick way of setting up basic vagrant boxes. Nice to see this exists.

dave1010uk• 13 years ago

PuPHPet looks really good. What's the default PHP setup? It would be great to be able to switch between and configure mod_php, fastcgi, fcgid, PHP-FPM, suPHP, suExec, etc.

jtreminio2• 13 years ago

Default is:

* Ubuntu Precise 64 Bit (12.04.2 LTS)

* Apache

* PHP 5.4

You can switch between Apache/Nginx and PHP 5.4/5.3 (5.5 coming today!)

gaadd33• 13 years ago

Is communication to/from ZeroMQ encrypted? If not it seems like this wouldn't be a very secure way to configure or distribute files over anything other than a VPN or LAN?

kinofcain• 13 years ago

Yes, they encrypt the messages in the application layer before sending them over zmq.

the_mitsuhiko• 13 years ago

It's encrypted but why do you do configuration management through anything else than LAN/VPN?

DASD• 13 years ago

They use AES and RSA but their implementation has had vulnerabilities.

http://docs.saltstack.com/topics/releases/0.15.1.html

https://github.com/saltstack/salt/commit/5dd304276ba5745ec21...

Here's a good article( http://missingm.co/2013/06/ansible-and-salt-a-detailed-compa...) with a comparison to Ansible that others are also mentioning here. Ansible uses KeyCzar which which seems more sane than rolling your own crypto as many readers here on HN know.

wunki• 13 years ago

I just released a open-source package which enables you to create a Django centric stack on Vagrant with the help of Salt. It was indeed very easy to write. You can check it out here:

https://github.com/wunki/django-salted

terminalmage4• 13 years ago

Wow, this looks great. I've got a talk proposal submitted for DjangoCon this fall and might just integrate this into the presentation, should it get accepted.

StavrosK3• 13 years ago

Same thing for Ansible: http://www.stavros.io/posts/example-provisioning-and-deploym...

hi2usir• 13 years ago

"Salt’s approach was far simpler."

Funny, that's how I feel about Ansible compared to everything else including Salt.

crdoconnor6• 13 years ago

Funny, that's how I feel about salt compared to ansible.

cowmix• 13 years ago

For years I have been trying to spread the gosspel of bcfg2 because, while not perfect, I thought was a more complete system over Puppet or Chef. Bcfg2, however has some big warts of its own AND it never really caught on.

In the past few months I've been slowing converting to SaltStack and it really is everything I ever dreamed of for a CM system. Fast, easy, real-time. Lovin' it.

Goladus9• 13 years ago

If bcfg2 was a complete system, it never caught on because the documentation was entirely missing. Every time I looked at it, I blocked on actually getting anything done because I couldn't find an equivalent to these reference manuals:

http://docs.puppetlabs.com/references/latest/type.html

http://docs.opscode.com/resource.html

https://cfengine.com/archive/manuals/cf-manuals/cf2-Referenc...

susi227• 13 years ago

IMO, ansible is even better:

https://github.com/ansible/ansible/

It doesn't require any deamon and does all its work over the good old unix fashion way: SSH. And it's python too.

ch0wn• 13 years ago

And if you don't like Python, you usually don't have to touch it. The tasks you run on the server can be any kind of executable. They read some JSON from stdin, do their action and write some JSON to stdout. Whether that program is a Python/Perl/Ruby/LUA script or go binary doesn't matter.

lobo_tuerto• 13 years ago

From the article:

"Chef works atop ssh, which – while the gold standard for cryptographically secure systems management – is computationally expensive to the point where most master servers fall over under the weight of 700-1500 clients. Salt’s approach was far simpler."

Does that assertion about Chef somehow don't apply to Ansible?

On the use case:

"I have this command I want to run across 1,000 servers. I want the command to run on all of those systems within a five second window. It failed on three of them, and I need to know which three."

tomaac• 13 years ago

Ansible can use SSH or ZeroMQ, which is much faster.

dbarlett• 13 years ago

Two solutions: pull-mode playbooks [1] and fireball mode [2] (temporary ØMQ daemon).

[1] http://www.ansibleworks.com/docs/playbooks2.html#pull-mode-p...

[2] http://www.ansibleworks.com/docs/playbooks2.html#fireball-mo...

susi227• 13 years ago

Well, ansible by default runs with paramiko which is a python implementation of SSH protocol. It will also keep connections open for multiple commands. It also has a pull mode and it also has a fireball mode which uses 0mq:

http://jpmens.net/2012/10/01/dramatically-speeding-up-ansibl...

However, you're not forced to use this. In the beginning, you can just seed your CentOS or debian with a Kickstarter or seed file and then run your inital thing with ansible simply over ssh (using all the goodies, ssh-agent, password less ssh etc..).

One huge plus for ansible is also that it used yaml which is rather simple. I've been following both project for >1 year and it seems that recently ansible has picked up a lot and will probably make the "race" (IMO).

reinhardt• 13 years ago

I'm going to go on a limb here and say that the 700-1500 clients limitation is a non-problem for the vast majority. It's like the C10K "problem" all over again. Newsflash: most shops don't have more than a few dozen servers, if that, and the few ones that do must have already done their homework.

hashtree• 13 years ago

Agreed! The ability to both push and pull is beautiful. Push for most things, pull for deploys via git.

INTPenis• 13 years ago

I came from building a large puppet environment to loving ansible. I much prefer push method in daily operations.

cpdean• 13 years ago

After reading Ender's Game over the weekend, I want to use this.

jdboyd• 13 years ago

While I would prefer ansible as well, the author does show why ansible is problematic for some people:

Chef works atop ssh, which – while the gold standard for cryptographically secure systems management – is computationally expensive to the point where most master servers fall over under the weight of 700-1500 clients

That said, unless you must have 700+ simultaneous slave connections, you should probably make life easier on yourself and choose ansible.

justinsb• 13 years ago

I think that "limit" is just FUD - can anyone explain where it comes from? With persistent SSH connections, the overhead of SSH encryption should be comparable to other encryption methods.

sciurus4• 13 years ago

FWIW, Chef doesn;t work atop ssh. It and puppet both use HTTP.

mjackson• 13 years ago

Browsing around ansible's website, I found the "quickstart" link. From that page[0]:

We’ve recorded a free 2-hour presentation designed to ...

Wait. The quickstart presentation is 2 hours?!

Looking for an easier way to get started...

[0] http://www.ansibleworks.com/quickstart/

silasb• 13 years ago

Maybe this? http://ansibleworks.com/docs/gettingstarted.html

statenjason• 13 years ago

I started with cdist, but ansible won me over. I bootstrap ansible-pull using cloudinit. It's been an excellent experience so far.

crdoconnor6• 13 years ago

It doesn't require any deamon and does all its work over the good old unix fashion way: SSH. And it's python too

Salt is all of these things as well.

stevekemp• 13 years ago

And now I'll say if you like Perl then there's a simple CFEngine-lite-like project I started called Slaughter:

http://www.steve.org.uk/Software/slaughter/guide/

Policies (read "perl scripts" + "file templates") are fetched from a central location, which could be a git repository, a SSH server, an rsync export, or similar. Then they're compiled and executed locally.

Surprisingly powerful, plus you get the power of Perl + CPAN.

moe• 13 years ago

Dead-end. Use ansible.

memset2• 13 years ago

I think salt is neato, but I also find it very frustrating to use! (Possibly through no fault of salt itself - I feel like I must be missing something.)

I am generally able to SSH into a box and get things configured the way I need. However, I have huge amounts of trouble translating that into salt scripts.

Consider logrotate. Here is the only documentation I can find on the topic [1]. From this, I have no idea what to put in init.sls to make sure a given log file is being rotated correctly. It seems this would work on the cmdline, but not necessarily in a salt script.

And that's just for logrotate! My uswgi + nginx configuration - translating that into salt - I don't know where to begin.

How do I make sure things get installed in a certain order? (Answer seems to be having 10 directives, for 10 packages, each depending on another, to enforce order.)

Is there anything that more closely mirrors what I actually do when configuring the box? SSH in, set certain values, etc? I guess I could write a shell script (or use fabric) but then I seem to have lost the point of configuration management.

[1] http://docs.saltstack.com/ref/modules/all/salt.modules.logro...

Jedd• 13 years ago

Hey memset - these sound like pretty straightforward questions (with straightforward answers). Perhaps asking on the mailing list, or hop onto the #salt channel on freenode IRC?

memset2• 13 years ago

That is a great suggestion. I almost never do this for fear of sounding like a noob, but I ought to try giving it a shot more often.

crdoconnor6• 13 years ago

You should probably forget about the salt modules for now. Just look at the states.

And that's just for logrotate! My uswgi + nginx configuration - translating that into salt - I don't know where to begin.

For nginx you just need a package: nginx installed state and a few states for the conf files.

uswgi will need something similar.

danudey7• 13 years ago

Consider logrotate. Here is the only documentation I can find on the topic [1].

Using Salt's logrotate module might be more than you need. You can always just have salt manage a file in /etc/logrotate.d/ and keep it up to date, which would be a lot easier.

The salt module is meant for more complex, fine-grained tuning of logrotate files, but I'm not really sure why I would use it.

My uswgi + nginx configuration - translating that into salt - I don't know where to begin.

The approach that I use: check your entire nginx configuration into git (e.g. your whole /etc/nginx directory) and then you can configure salt to check it out and keep it updated.

Also, if you're custom-compiling nginx into /opt/local/nginx or something, you can actually have salt recursively copy the entire directory to your slaves.

tptacek4• 13 years ago

I've used Fabric, Chef, Puppet, and Ansible, and have settled on Ansible; it's a sort of middle ground between Fabric and Chef that does more than just run commands on servers but doesn't require me to buy into a whole elaborate universe of configuration management servers and whatnots. Ansible is great.

The ZeroMQ stuff makes sense if you're pushing configurations inside a data center, but it's a dealbreaker for us having things hosted externally.

etherael• 13 years ago

Ansible can do the zeromq stuff anyway, that's what fireball is for.

frankwiles2• 13 years ago

I don't understand why ZeroMQ outside of a data center would be a deal breaker for anyone. You do realize the data on the wire is encrypted right?

tptacek4• 13 years ago

Awesome. How many people have reviewed it for flaws? How many people have reviewed OpenSSH?

stonemetal• 13 years ago

At one point in time ZeroMQ was not hardened and direct exposure to the internet wasn't a good thing. It appears they have fixed it, but it hasn't proved it self so the perception lingers on.

http://www.zeromq.org/area:faq#toc8

danudey7• 13 years ago

ZeroMQ used to be full of assert() calls that would fail on bad data and crash whatever was listening. It was trivially easy to cause problems for someone's ZMQ socket-listening service. It's been fixed, but the perception lingers on.

ishbits3• 13 years ago

A few years back it was common practice NOT to expose ZeroMQ to the wide open internet as it was built for that. I think they says it OK now, but its left a bitter sense for some of us.

njs12345• 13 years ago

If you don't want to run a master, you can use Salt in masterless mode: https://salt.readthedocs.org/en/latest/topics/tutorials/stan...

falcolas• 13 years ago

One important difference: you don't have to install Ansible on the nodes you're managing, just Python >= 2.4 with a JSON module installed (default for 2.6 and later, available through simplejson for previous versions).

Also, Ansible does not require you to mess around with dependency lists to ensure that packages/files are installed in the right order - the order is built into the yaml config file. You don't lose any capability, you just gain (and this is my personal opinion) ease of understanding the order that operations will occur in.

mechanical_fish3• 13 years ago

It's ridiculous how much more pleasant it is to use Ansible than Puppet or Chef. Its invention solves a big pain for me: As a veteran user of Puppet I'm a firm believer in using a tool like Puppet, but Puppet-and-Chef are overdesigned for small jobs (and, arguably, for most other jobs as well) so actually recommending them to a beginner has always felt like this:

A: "I just set up a cloud instance by running some shell commands by hand."

B: "You shouldn't do that, because of X and Y and Z. You should learn Puppet or Chef."

A: "Wait... did you just tell me to go spend thirty hours banging my head against solid objects, in exchange for nebulous benefits that I can't even perceive yet?"

B: "Why, yes, I believe I did!"

Ansible feels much less embarrassing to advocate.

nailer• 13 years ago

Link: http://www.ansibleworks.com/ and https://github.com/ansible/ansible

terminalmage4• 13 years ago

reads article about A

I've tried B, C, D, and E, and I like E.

tptacek4• 13 years ago

Salt includes characteristics of C and D that didn't work for me.

23david3• 13 years ago

Lol. And I do consulting. Hire me!!!!

And if you criticize me, I down-vote you. Classy.

pessimizer• 13 years ago

The title of the article is "A: like D, except it doesn't suck."

23david3• 13 years ago

you care about network security, why are you exposing ssh ports in public anyhow? Put them behind a VPN.

There are ways to configure salt with masterless or behind vpcs or with syndics that are perhaps an enhanced security model. But defaults are for regular use cases, and for most cases the defaults are fine.

I suggest checking it out.

calpaterson3• 13 years ago

you care about network security, why are you exposing ssh ports in public anyhow? Put them behind a VPN.

You don't need to do this. SSH is secure enough. Require key-based authentication and leave SSH on port 22.

darkarmani• 13 years ago

you care about network security, why are you exposing ssh ports in public anyhow? Put them behind a VPN.

Why are you exposing VPN ports in public anyhow? Put them behind a VPN.

Seriously though, there isn't anything to say a VPN is any more secure than SSH.

ishbits3• 13 years ago

At some point, to gain any form of remote access you have to put your trust in one piece of software. Being it VPN, ssh, or something.

For many people ssh is considered secure enough. And any secure issues get immediate attention so you can be updated pretty quickly.

Now any software could have unpublished zero days, which is why I also do some other host based security.

zhynn• 13 years ago

After working in Chef for several years and fighting with both gem-rot and managing colliding chef-client and application ruby+rubygems+gem environments with RVM... I was ready for something else. Also, our group just started working alongside another group that does not use cfg management; I wanted something that would be unobtrusive. At first I thought Salt would work, but the minionless mode was not really recommended. You lose a lot of the power of Salt when you do that. Ansible, however, is designed to be minionless. After using it for the last few months, I am (frankly) in love. The last time I felt butterflies like this for a tool was when I grokked git.

Look, I can maintain my own ansible configurations (inventories, playbooks and roles), and the other groups need not be the wiser. They don't need to worry that servers are going to be reconfigured out from under them, since I am running my configurations explicitly. All they see is that I ssh'd in and did a bunch of stuff really fast. To work with my other groupmates, we just keep the files in git (just flatfiles, yes: just flatfiles). With git I have an audit log of everything that has changed (hosts that have moved environments, configurations that have been updated, etc). And like git it is as distributed as you want it to be. Want to run it from a central server only? Fine. Want to have your admins all run it from their workstations? Fine. Go for it.

Even if the server is ancient or weird (ie. no python), I can still manage it with the raw module.

Ansible gives me everything I want, with no fuss. It is so basic that I can do things the way I want to.

grumps• 13 years ago

I've recently been working to get a set of Puppet scripts running along side of Vagrant so both Server side and Client side devs can get working on projects faster.

Personally I've found dealing with Ruby and the various versions rather irritating. I kind of wish I had started with Salt or Ansible because I know far more Python, than I do Ruby. I started down this bunny trail before Vagrant support Ansible and/or Salt. I guess it's not to late to start over... hahaha Maybe I will after the initial release.

I guess the only advantage of Puppet was that I'm able to do most of what I want using major modules...

grandalf2• 13 years ago

Did you check out cuisine.py by any chance?

cultureulterior• 13 years ago

Personally, I don't think puppet sucks

susi227• 13 years ago

The problem is most dev-ops and sysadmins don't know ruby and that's a HUGE disadvantage. In the end configuration management will often by done by sysadmins.

pilif2• 13 years ago

I'm only managing 24 machines with puppet, so nothing fancy, but I managed to do all of the stuff I needed without writing a single line of Ruby code.

That was handy for me too as while I'm somewhat familiar with Ruby, I'm no expert at all. I can read Ruby no problem and I can write ruby that's not-quite-idiomatic and I'm terribly slow at it.

Argorak2• 13 years ago

Puppet doesn't require you to do any Ruby.

Also, Salt is written in python, for which the same argument holds as well for almost all environments.

Goladus9• 13 years ago

One doesn't need much ruby to get going with puppet. You need to learn the declarative puppet DSL, which is arguably an even bigger barrier. Automatic list expansion, for example, is a nice feature. But you can't have independent or nested variables, as with an imperative loop. So you wind up having to break each list into its own definition and then combine them all. The sysadmins I worked with were definitely not keen on having to think that way on a regular basis just to get some things done.

That said, I also disagree that puppet "sucks." It's good at what it claims to be good at so long as you can deal with its quirks.

pwelch2• 13 years ago

Agreed. I work with Chef and it is my tool of choice but don't think that Puppet sucks.

The important thing is someone uses some form of Configuration Management. If people find Salt easier than Chef/Puppet/CFEngine/Ansible then great. At least they have something to build/scale their infrastructure.

abtinf• 13 years ago

Yet another un-googlable project name. Pretty much kills it for me.

frankwiles2• 13 years ago

Have you tried Googling salt stack? I've had zero problems finding tutorials and documentation.

a3n• 13 years ago

https://duckduckgo.com/?q=salt+configuration

Goladus9• 13 years ago

I'm still looking for a configuration management system that doesn't assume that the first step towards managing servers is to add a new "master" server. From the thread, ansible looks promising. In the meantime I'll keep using chef-solo until opscode kills it.

crdoconnor6• 13 years ago

http://docs.saltstack.com/topics/tutorials/quickstart.html

sciurus4• 13 years ago

You can also run puppet without a master server.

Goladus9• 13 years ago

Indeed. The reason I am currently using chef instead of puppet doesn't have much to do with relative technical merits.

tbatchelli• 13 years ago

Pallet is a library and thus it is serverless.

http://palletops.com

edit: link

akoumjian• 13 years ago

You can run salt masterless. See the quickstart.

http://docs.saltstack.com/topics/tutorials/quickstart.html

Goladus9• 13 years ago

Thanks, it may even be that a salt master is lightweight worth configuring. But I should note there's a difference between "can run" and "intended to run."

It's as much a semantic thing as a technical thing. Instead of thinking about an unconfigured node as a "minion" awaiting orders and provisions from central command, I prefer to think of a node like a stem cell, fully capable of differentiating itself based on signals that it receives. You need a way to update the DNA and a way to send the signals, that's it.

This may seem like a meaningless difference, since there is still value in centralized services (package repositories, security, reporting, monitoring). But it's still a subtly different focus and over time yields different results.

For my part I think the distributed, organic "stem cell" way of thinking will win out over "master/minion" in the long run.

UtahDave• 13 years ago

SaltStack also won at Gigaom Structure last week!

http://gigaom.com/2013/06/20/devops-player-saltstack-wins-st...

(I'm a SaltStack employee)

jemeshsu• 13 years ago

Whole article about SaltStack winning the award, and not a link back to SaltStack website.

crb• 13 years ago

MCollective (which Puppet Labs acquired several years ago) was (and remains!) fiendishly complex to set up.

I didn't find MCollective hard at all - you just install some debs, a message queue server (Stomp was easiest at the time - it's now deprecated, but surely is not much different to RabbitMQ?) and it Just Worked for me. And there was a great screencast.

Did it get far more complicated since I used it last?

daenney• 13 years ago

To be honest, I've never had an MCollective deployment Just Work(tm). It's always taken some serious debugging to figure out what the heck went wrong this time.

RabbitMQ works but is slightly problematic since the authors have a morbid penchant for not wanting to support anything but Apache ActiveMQ. Ask a question about MCollective and RabbitMQ and the answer you get is 'switch to ActiveMQ'.

druiid2• 13 years ago

Well, rabbitmq is kind of a pain to get working with it. Additionally, the modules for rabbitmq and mcollective, for puppet, don't really work that well together (read: I had to re-write the ones I found to get them working).

apenney• 13 years ago

I'm starting work at Puppetlabs in exactly a week's time as part of a brand new "module team" and I personally promise you here and in the open that I am going to tackle the puppetlabs-rabbitmq module and fix it so that it actually works and isn't an abandoned wasteland.

Come to that I'm hoping we can start building out a full set of mcollective modules to replace the existing ones that will be fully supported and kept up to date so that getting mcollective running will be as easy as including a class and waiting.

A huge part of this job is ensuring community patches get merged in and contributors get treated as I would like to be treated when contributing to a project. I hope we can reverse your experience with modules within a few months (I took this job because I've been in exactly your position, grabbing official modules and having them not work at all!)

1gor• 13 years ago

https://github.com/seattlerb/rake-remote_task is all you need if you use ruby.

  require 'rake/remote_task'

  set :domain, 'abc.example.com'

  remote_task :foo do
    run "ls"
  end

danudey7• 13 years ago

State management is about a lot more than 'execute this command on a server' (which is discussed in the article). It's about creating a set of rules and performing idempotent actions.

If you're just running shell commands, it's easy to screw up and waste your time or break your server by accidentally having the same commands run twice.

otterley• 13 years ago

When used with Chef Server 11 (or Hosted Chef), Chef scales reasonably well. You install a client on each node, and the client speaks to the server via HTTPS + REST.

The unqualified assertion that Chef uses ssh is inaccurate. You can run chef-solo via ssh if you like, but you'll run into the same scalability ceiling as with any other ssh-based solution.

SandB0x2• 13 years ago

I'm not a web developer but I have a side-project that runs on a cobbled together EC2 instance. The server state is in theory documented in a set of of shell scripts and virtualenv requirements files.

I know that I should be doing this in a more robust way but whenever I try and read up on configuration management tools like Puppet and Chef, they're all described in comparative terms - Puppet does X better than Vagrant which does Y better than Chef, etc. I quickly lose patience and get back to digging myself into a deeper technical hole.

Is there a non-recursive explanation of what these tools are able to do and where someone like me should start?

Edit: Thanks for the helpful responses!

crdoconnor6• 13 years ago

They basically let you write, using a declarative language, what state the server should be in. The software figures out how to set that up for you.

When you want to change the state, you edit the file - say, to add a package.

At any point you can set up an entirely new server from scratch using that same code.

You can't do that easily with bash scripts.

(you could if they worked like virtualenv requirements files but that only works for python's virtualenv...)

AlexanderDhoore• 13 years ago

I just now (past few days) started learning about this stuff. I've been doing the "Learning Puppet" tutorials [1].

The most important thing about it is that you describe the state of the server. And puppet applies it for you. It's idempotent (you might know this term from REST). You can run puppet multiple times and the end result would be the same.

Normally (without config management) you would write scripts that do the configuration. If you ran them twice, things could go wrong, or they would overwrite the stuff from last time. Scripts are descriptions of what steps to take. Puppet manifests are descriptions of what state you want the server to be in.

[1] http://docs.puppetlabs.com/learning/index.html

fmstephe• 13 years ago

Ok, the declarative and idempotency sounds great. But consider this one use case. I want to stop a service, upgrade it to a new version, restart that service. The service is an application which I wrote that runs in apache tomcat.

    1: Stop Service
    2: Upgrade
    3: Start Service

Right now I have just made three non-declarative statements about my tomcat server. I am describing a process that runs through a series of steps to reach a new conclusion.

So puppet has these beautiful (sounding) properties. But declaratively describing the state of my servers isn't a real problem I have.

I need to deal with the way that my servers change. I need to upgrade services, including starting and stopping. Puppet absolutely fails at this. Any attempt to describe a process is antagonistic to puppet at a fundamental level.

Whenever people seek a solution to these problems they always get fed that line. That puppet is declarative and idempotent, which is fine. But we should be _very_ clear that puppet does a spectacularly bad job of solving a very ordinary problem that I have, and which I would expect almost everyone else working with large numbers of servers to have too.

danudey7• 13 years ago

These tools allow you to specify a state and then specify which servers should have that state. A 'state', loosely speaking, is a collection of definitions of 'X should be Y'.

For example:

Package 'libapache2-mod-php' should be installed. File '/etc/apache2/sites-available/customersite' should be the contents of this file we have on the master server. File '/etc/apache2/sites-enabled/customersite' should be a symlink to above. Directory '/var/www/customersite' should be the contents of this git repository. Command 'apache2ctl graceful' should be run if any of the above change.

With these five rules, you can turn a default install of Ubuntu into a webserver providing client files in a matter of seconds.

Once you have those rules written, you then apply them. You can wildcard, so that hosts matching 'www*.yourhostingco.com' get these rules.

Now, when you want to add a new webserver to your cluster, you install a new Ubuntu instance, you register it with the Salt master server, and then trigger a state update, and you're done. No SCP'ing files, no manual git checkouts, no copy-paste-edit configuration management.

Then, once you've got all that, you can get into templating. You can do templating both on the contents of files (e.g. for memcached config, insert the machine's internal IP address instead of having one config per server) as well as the rules themselves to avoid having a ton of boilerplate (for module in 'list','of','python','modules', install the module via pip with these rules).

One of my favourite benefits of something like Salt is that if you use Salt to do all of your configuration, then just back up your salt config to github or wherever, then you always have a record of how you did things. You don't get the incomplete documentation or missing steps that happen with most approaches.

As a sysadmin managing a cluster of systems, it can be life-changing.

nwmcsween• 13 years ago

But the problem that all of the configuration managers have and also why they all suck is that the state you specify has no guarantee of being the end state. A much better alternative would be to manage state in chunks and test those chunks, e.g an http-server transaction would require responding on port 80 if not fail or roll it back. Rolling back could be using namespaces, jails, etc.

mitchellh• 13 years ago

The other responses are awesome, but I just want to nitpick one thing (as the creator of Vagrant): Vagrant isn't a configuration management tool, so it can't really be compared with Chef/Puppet.

Vagrant actually works with Chef, Puppet, CFEngine, Ansible, Salt, and more.

tieTYT• 13 years ago

You told us what it "isn't" but you didn't tell us what it "is". Yes, I could just google, but I don't care enough. I think you missed out on a little bit of marketing here.

the1• 13 years ago

if you're using EC2, why not just create an AMI and forget about configuration tools?

bfrog• 13 years ago

Having done this a dozen or more times... can you package your ami for your developers to use? Can you remake your image exactly the same way again as it was when you first imaged it should it be lost in the cloud (100% reliability isn't something AWS provides).

Provisioning tools let you create it, and incrementally update your image in a way that lets you redo it from scratch at any time.

That alone is the reason why I like the idea, not necessarily the resulting applications that have been created so far for the task.

Shell scripts could do the same and have for years if your only interested in from scratch setups.

billeh• 13 years ago

You can, certainly create an AMI preconfigured with all of your libraries, packages and services ready to go, but the issues arise over time with package updates, system updates, one-off configuration changes .. the list goes on.

The actual configuration of your system will drift further and further away from that templated AMI, leaving you to constantly have to build a new template every time you deploy a new machine, or manually make all of those differential changes to your new system.

Config management can be tailored to rapidly update the configurations of certain classes of systems at a greater interval than the constant cycle of blowing away machines, updating templates, redeploying, etc , etc.

joelhooks• 13 years ago

We use Chef for distributed team. They download a very basic VM, run Chef, and are off to the races in minutes. When updates or config changes, they update from VCS and everything is configured and good to go. This is especially awesome for more UI focused devs that aren't as comfortable with Unixy tools.

ef4• 13 years ago

That doesn't really solve the problem, it just moves it.

If AMIs are your deployment method of choice, you still need to build a repeatable process for applying updates and changes to your previous base AMI, testing that it still works under all your realistic configurations, and then gracefully deploying it to your production infrastructure.

Which is all doable, but not trivial. And the processes you build will be very Amazon-centric.

penguindev• 13 years ago

Because a lot of people don't use their brain, and realize that linux package management / image creation has been a solved problem since forever (I've been doing this since redhat kickstart circa 2001, and I'm a young guy).

However, there are some common sense tiers:

3rd party dependencies that changes infrequently = put in ami Common ops daemons and boot scripts = put in ami your application code and your configs = deploy via python/ssh client side

Also, one simply has to use ec2 instance tags to name things.

Result, you can have bit-for-bit identical instances fired up in no time with high confidence without need for a full OS package mirror. Without, of course, a ridiculously over-engineered configuration server framework, DSL, SPOF, security holes...

nodesocket• 13 years ago

Founder of https://commando.io here. We are a web based interface for doing remote executions via SSH. Our approach is a beautiful web interface with no external dependencies (agents). Salt and Ansible are amazing, but they still have a bit of a learning curve and setup "costs". Our target market also tends to be less technically proficient, and thus not willing to dive into more robust solutions. Think cPanel for operations. SandBOx, if you'd like to try out Commando.io, let me know, and I'll get you a private beta invite.

halayli• 13 years ago

My Ansible learning curve was 5 minutes.

dsl2• 13 years ago

A giant database of SSH keys from people who can't setup basic operational tools?

Jesus, and I thought the CDCs "big vault full of things that will kill you" was a terrible idea...

coolsunglasses• 13 years ago

Fabric can make for a nice midway point between a pile of scripts and using Chef/Puppet.

saintx• 13 years ago

Reading through many of the responses, they're almost all phrased in terms of "X does Y better than Z" comparisons, directly ignoring your amusing and insightful comment.

At this point, the only thing that could save ordinary users from the melee of competing Open Source configuration management frameworks is an illustration by Randall Munroe.

(My hacker senses are tingling. If you listen very carefully, you can just barely hear a new eponymous law being born.)

StavrosK3• 13 years ago

Here's a small, concrete example I wrote to showcase ansible: http://www.stavros.io/posts/example-provisioning-and-deploym...

grandalf2• 13 years ago

The tools are overly complicated and offer little value for installations with fewer than hundreds of servers.

Checkout fabric.py and cuisine.py, both are small, simple, elegant approaches.

Combined with a native package manager (like apt), fabric+cuisine is nearly as powerful as puppet or chef.

dmohjoryder• 13 years ago

What I prefer about ansible above all others, besides its simplicity, is that its use case scales up and out. By that I mean ansible can be used for platform/app stack provisioning while OS/infra sys admins maybe another tool. To often an agent based approach causes a conflict with OS sys admins and platform/app team regarding ownership/sharing. I want to offer self service as much as possible. Further, most cfg mgmt tools are monolithic in that they want to manage all servers as tho a single team/overload manages them all, rather than various independent sys admin teams. With various independent teams its just too much hassle trying to share roles appropriately or setup separate master/agents. Ansible does not have these issues.

terminalmage4• 13 years ago

http://docs.saltstack.com/ref/clientacl.html

kapilvt• 13 years ago

The thing that bugs me about salt is the almost complete lack of testing/coverage. They had tons of egg-face releases for crypto bugs, upgrade issues, things a basic test suite would have solved. I'd rather not trust my production environments to something that's a roll of the dice of whether its working, secure, or upgradable on a given release.

WickyNilliams2• 13 years ago

Is there a comparable tool for Windows?

Powershell works great for executing commands on arbitrary servers (which sounds like the basis of Salt), but it'd be great to declaratively say "I want the server in this state" like the config management side of salt. I assume there is a tool built atop of Powershell like this somewhere?

ipmb3• 13 years ago

Salt can configure Windows machines, but you need to have the master running on *nix iirc.

WickyNilliams2• 13 years ago

OK thanks for the heads up. I'll check it out, but I worry people will resist bringing in a *nix machine. It's unfamiliar and therefore must be feared!

sciurus4• 13 years ago

Puppet and Chef both support Windows.

http://projects.puppetlabs.com/projects/1/wiki/Puppet_Window...

http://wiki.opscode.com/display/chef/Fast+Start+Guide+for+Wi...

lmickh2• 13 years ago

As mentioned, this can be done with Chef, Puppet, and Salt, but be careful about how you go about it. It is important to recognize when it is best to leverage AD for your Windows configs.

It is easy to fall down the rabbit hole of trying to implement things in a CM tool/Powershell combo that could be done in AD far easier.

drummer32• 13 years ago

Genuine question: Why would you have Windows servers joined in an AD domain? Or are you talking about pushing changes to workstations?

gunmetal• 13 years ago

Salt is missing templates, the ability to use higher level programming language and all the environment/roles that I find the most powerful part of Chef.

crdoconnor6• 13 years ago

Salt has jinja2 templates.

Game_Ender• 13 years ago

You are wrong on all counts here. Salt supports Jinja2 template engine, so you can template your states [1]. You define custom states in python [2]. In the root configuration file (top.sls) you target configuration based on host name, grains (machine specific information) [3].

1 - http://docs.saltstack.com/topics/tutorials/states_pt3.html

2 - http://docs.saltstack.com/ref/states/writing.htm

3 - http://docs.saltstack.com/ref/states/top.html

pestaa2• 13 years ago

That statement is very very wrong. Salt has templates, renderers, grains, while supporting all the data structure languages you can dream of.

In fact, it is the most flexible software I've seen recently.

terminalmage4• 13 years ago

jinja2 and mako are supported, and you can even write your own renderer without much effort if a templating language is not supported.

There's even a renderer for pure python, allowing one to write config files in python for more control and flexibility.

One wonders if you've ever actually tried Salt. It really is OK to have an approach of: "I like Chef and it works for me." More power to you. Everyone should use the tool that works for them.

v0land• 13 years ago

I use SaltStack for managing a render farm consisting of 73 Ubuntu nodes. My requirements are rather simple, really: most states just install some packages, put configuration files into place (sometimes using a template) and enable/start services. However, I can't recall a single problem when setting everything up. SaltStack is clean, simple, and just works.

justincormack2• 13 years ago

I much prefer the immutable server model [1] to the puppet model. Build a new tested server with the new config and roll that out.

[1] http://martinfowler.com/bliki/ImmutableServer.html

rektide2• 13 years ago

There's words written about "automatic configuration" in that link but I don't see any guidance or information on what those configuration tools are. The focus is certainly not on automatic configuration: the focus is on use and re-use of images, on taking images, doing something to them, and getting new images.

The notion is deeply flawed to me: using an image as a precondition for making an image, over time, becomes an intractable mess and requires very careful supporting documentation to prevent the scheme from devolving into a bunch of "buckets of bits" with no transparency into what work has gone on to make it that way.

The #1 thing that I enjoy about automated tooling is that I can take a bare OS and spin up a complete new system in a matter of minutes, and I get to watch that entire process happen before my eyes. There's no mystery, no external dependencies, no existing work I'm riding off of: everything that happens is visible to me in an immediate way.

There's a value & use to immutable images, but please decouple your image making from past images made: no one wants to root around to figure out what twelve horrible things you did to install Java 9 image instances back whenever, nor are they going to have any fun reproducing it on the twenty nine active variants of that ancestor image when there's a security fix to be done.

justincormack2• 13 years ago

I think most people use puppet to build their immutable images at present. It is still rather different from running it on production. Sure you should not start from a non reproducible point.

contingencies19• 13 years ago

Salt/Puppet/whatever. I ignore them all. Why? I have put a lot of thought in to this area.

IMHO, the overwhelming problem with salt/cfengine/puppet style solutions (which I will refer to as 'post-facto configuration tinkerers', or PFCT's) is that they potentially accrue vast amounts of undocumented/invisible state, therefore creating what I refer to as configuration drift.

IMHO, a cleaner solution is to deploy configuration changes from scratch, by deploying clean-slate instances with those changes made. In addition, versioning one's environment in this way creates an identifiable point against which to execute automated tests. (This class of solution I refer to as 'Clean-slate, Identifiable Environments' or CSIES.) Examples are Amazon AMI's, and any other kind of versioned/identified VMs.

PFCT's deployment paradigm tends to be relative slow and error prone. CSIE's tend to be fast and atomic. PFCTs are headed for the dustbin of history. They are temporary hacks that clearly grew from old-school sysadmins' will to script. CSIEs embrace modern day devops, as more holistic entities that embrace virtualization and recognize the integrity of the environment as critical to preventing ridiculous numbers of environment-induced, service-level issues that are an expensive tangent to service development, testing and deployment. Thus, I would argue that what we are looking at with PFCT's is a failed paradigm, and with CSIEs, the now real and current opportunity for something far more elegant.

(Disclaimer: Haven't tried ansible or vagrant first hand, but they do seem to be PFCT's to me.)

chongli2• 13 years ago

Do you have any resources where one might learn about CSIEs? Where to get started, available tools, best practices, etc.

contingencies19• 13 years ago

To be honest nobody else uses the term... I just made it up! But I've been wanting to further publicly elucidate my thinking in this area for some time... maybe soon I'll get around to more. I would say the responses to this post have been sort of comfirmative (not barking up entirely wrong tree; others can see the logic of my thinking to some extent).

I personally believe that this area is going to expand rapidly, building off of the trajectory begun by present first-generation of cloud infrastructure. Perhaps for someone who wanted to practice thinking in this area, I would a say exercise is to limit yourself purely to third party and cloud based infrastructure but demand high performance and global (multiple cloud provider) availability, and challenge yourself to write a multi-service system including a deployment tool that automates your solution and actually produces maintainable infrastructure. If you follow through, you will understand the problems.

calpaterson3• 13 years ago

I think you're right that Salt/Puppet and to a lesser extent Chef take the wrong approach, but you make some confusing comments that make me suspect you might not understand what these existing approaches are about.

IMHO, the overwhelming problem with salt/cfengine/puppet style solutions (which I will refer to as 'post-facto configuration tinkerers', or PFCT's) is that they potentially accrue vast amounts of undocumented/invisible state

I think you mean "post-facto" as in: "run after everything is done"? This is not the way that people would advocate Puppet should be used. Puppet should be used from the start, not added as an afterthought once you are done.

IMHO, a cleaner solution is to deploy configuration changes from scratch, by deploying clean-slate instances with those changes made

This isn't a cleaner solution, this is almost the solution you get when you use Puppet. With puppet the development workflow is like this:

- Span up a vagrant VM

- Run your manifests against this VM to test them

- To check in, run your manifests against your staging environment

- To deploy, spin up new clean production VMs and run puppet manifest against them

- Use a reverse proxy to route all traffic to new production VMs. Terminate old production VMs

PFCT's deployment paradigm tends to be relative slow and error prone.

This much is true. Puppet's slow speed is particularly galling, but maybe that's just because I use it at work.

contingencies19• 13 years ago

isn't a cleaner solution, this is almost the solution you get when you use Puppet

The difference betwen deploying an instance of a stored environment and generating that environment from some prior state is the generative process, which can fail or change in unexpected ways due to network conditions and other factors.

More importantly, PFCTs enable and to some extent encourage modification of generated environments remotely, en-masse, without any significant capacity to ensure that individual instances within a group have not subtly shifted in configuration. This is what I meant by configuration drift.

CSIEs, by contrast, are essentially the complete product of the entire generation process, thus ensuring that future instantiations are identical. A subtle difference, but an important one.

mechanical_fish3• 13 years ago

a cleaner solution is to deploy configuration changes from scratch, by deploying clean-slate instances with those changes made.

All of us who have built big cloud-server clusters have dreamed of this plan at least once. But there are big practical problems.

Relaunching infrastructure is easy in theory, but from time to time it becomes very difficult. There is nothing like being blocked on a critical upgrade because your Amazon region has temporarily run out of your size of instance, or because the control layer is having a bad day, or because you've accidentally hit your instance limit in the middle of a deployment, or...

A much bigger issue is that bandwidth is finite, so "big" data is hard to move. This is a matter of physical law. It's all well and good to declare that you're never going to apply a MySQL patch in place: You're just going to launch a new instance with the new version and then switch over. But however fast you manage to launch the new instance (and you will be hard put to launch an instance faster than you can apply a patch and restart a daemon...) you will be limited by the need to copy over the data. Have you ever tried copying half a terabyte of data over a network in an emergency while the customer is on the phone? It is very annoying. Because it is often physically impossible to do it quickly: Cloud infrastructure isn't generally built for that, and when it is it costs money that your customer will not want to spend for the luxury of faster, cleaner patch-application.

A solution to this is to use cloud storage like EBS. Now your data sits in EBS and you just detach its drive and reattach it to a new instance. That actually works okay, provided you're happy with the bandwidth and reliability of EBS, which lots of people aren't – and, as those people will cheekily point out, you have now solved the "relaunches are slow" problem by replacing it with an "everything is uniformly slow" problem. Moreover, detaching and reattaching EBS volumes isn't instantaneous either. You have to cleanly shut down and cleanly detach and cleanly restart, and there's like 12 states to that process, and all of them occasionally fail, and if you don't want your service to go down for thirty seconds every time you apply a patch you need a ton of engineering.

Which brings us to the other problem: Complexity. Most programmers are not running replicated services with three-nines-reliable failover that never breaks replication. But even if you are, because you've got the budget for excellent infrastructure and a great team, it will always - for values of "always" measured in several more years, anyway - be more complicated and risky to fail over a critical production service than to apply, say, a security patch to 'vi' in place on a running server. 'vi' is not in your critical path. If you accidentally break 'vi' on a live server (and you won't, because vi is older than dirt and solid as a rock), you will have a good laugh and roll it back. Why risk a needless failover, which always has a chance of failure, when you could just apply the damn patch and thereby mitigate risk?

At Google scale that argument probably stops applying. But most people don't run at that scale and it will take decades to migrate everyone to a system that does, if that even happens.

So, "dustbin of history", maybe, someday, but in the long run we are all retired, and I will be retired before our dream becomes reality. ;)

contingencies19• 13 years ago

The bulk of your comment - your second, third and fourth paragraphs - focus on issues of speed, bandwidth and reliability in a third party hosting/cloud-based architecture, which are a design-time tradeoff, so I don't see them as strictly relevant (though anecdotally informative).

Your fifth paragraph describes problems related to operations process, which are entirely avoidable.

mateuszf• 13 years ago

I also think that rebuilding from scratch is way better than some idemponent CM solution. I work at small scale - just need to have some services working on a vps and also manage my linux box. This is why I think that docker will be a great solution to me. Spinning lxc container from existing image is really fast - I have made some tests recently. Now I'm setting up a system where I will have portable containers for specific tasks - a nodejs container for a webapp, a postgres db, tor machine for anonymous work, etc. All of them will be built using Ansible and versioned using git. Then I can put them all on a vps and redeploy independently and just use one machine.

rektide2• 13 years ago

Having a Clean-Slate Identifiable Environment is well and good from a usage standpoint, but from a creation & maintainability standpoint any bucket of bits qualifies as an identifiable environment.

The very purpose of most of these tools is to make state visible, to be able to see what has been poured in. That visibility contributes to extensibility, the ability to take that known configuration starting place and to be able to branch and create new configurations.

If you have infrastructure in mind for how your CSIEs are constructed, I'm all ears, but I'm envisioning more sh scripts posted on the corporate wiki as your CSIE implementation.

contingencies19• 13 years ago

any bucket of bits qualifies as an identifiable environment

Sure.

The very purpose of most of these tools is to make state visible

Right, but they do a poor (ie. post-facto, limited granularity) job of it. This is why IMHO their paradigm is inelegant.

infrastructure in mind for how your CSIEs are constructed

We use scripts with exit values that execute within the target environment to bring it from a base configuration (eg. some AMI or some distro) through to the desired config, plus validation tests. I think most people's approaches will be similar. PFCTs essentially provide this, and could be used for this step without issue.

_bpo2• 13 years ago

Computer systems in the wild are stochastic - that's the fundamental assumption that leads to the design of tools that you call "PFCTs" here.

This type of design leads to tooling which is relatively slow and often obtuse, but there are well-reasoned (and researched, start maybe with [1]) assumptions behind those tools. In particular: systems modeled by these tools are designed to run for years, include a large variety of hardware and software, to be worked on by a lot of different people, and to be able to grow to massive size.

The "clean slate" idea is a good one, and has been in use for a long time (the idea of gold images goes way, way back). But that's for initial system state, not dynamic system modeling. The cfengine family of tools grew out of limitations in the "clean slate" approach for real-world system models.

If your concern is "how can I deploy my Rails site to EC2 quickly and reliably," you'll have different goals and assumptions on the tools you need, than if your concern is "how can I grow a resilient infrastructure". (edited to add: both are completely legitimate goals)

All that aside, I definitely agree that the tools still suck :)

[1] http://cfengine.com/markburgess/papers/sysadmtheory3.pdf

contingencies19• 13 years ago

Computer systems in the wild are stochastic

Try telling a client who wants 100% uptime that! Computer systems can be many things - it could be (and probably has been) argued that we as progammers fundementally aim to reduce random qualities and increase stability within our programs.

there are well-reasoned (and researched) assumptions behind these tools

I can see where PFCT's came from. I took a look at the paper (which is exclusively about policy-driven management systems), but don't think this invalidates my points, re: paradigm failure. Taking the same policy based management systems and applying them to a CSIE environment (say, with corosync/pacemaker) is one way to combine their benefits. (That's what we do on our own infrastructure, actually.)

If your concern is...

Right, differing concerns. You also have different life expectencies for instances, purposes (dev/staging/prod), availability expectations, etc. But these are tangents! Developing good software comes down to consistently carrying out fundamental practices regardless of the particular technology. - Paul Duvall.

We attempt to remove an entire class of issues related to deployment environment by changing our platform engagement paradigm to one that is less procedural/'stochastic' to something that is more atomic/reliable. At the same time, this facilitates a clean segregation (and versioning!) of deployment environments versus service development (which may target one or more CSIE).

brown9-2• 13 years ago

this sounds like what Martin Fowler calls "immutable servers": http://martinfowler.com/bliki/ImmutableServer.html

contingencies19• 13 years ago

Yeah, this is pretty much the exact same idea.

cortesoft• 13 years ago

CSIE sounds great for a certain class of users.

For me, however, it seems like it would be impossible. My team has to manage 10,000+ physical servers. We can't possibly wipe and provision from scratch every time we change configurations.

In other words, if your servers are ON Amazon's platform, use CSIE. If you are RUNNING the Amazon servers, you need something else.

contingencies19• 13 years ago

PXE boot is a great way to automatically re-provision physical servers.

Karunamon• 13 years ago

I may be missing your point here, so forgive me if this seems ignorant, but I do not see how something like Puppet accrues this "invisible state".

I'm in the midst of a large puppet enterprise deployment at my day job, and it seems they've taken great pains to prevent any drift from happening. You get a dashboard webapp that shows you every puppet run on every machine, and a large overview that gives you states like "nonresponsive / changed / unchanged / pending / error".

When a puppet run makes a change to a systems, that run is marked as changing the server. If you're getting lots of "changed" runs on a system, you immediately know to go look at that server because something is making that box deviate from your defined baseline.

You write your configurations (manifests), add them by name to the webapp, add those to groups, and then add machines to the groups, which define what set of manifests to apply.

On my admittedly newbish level, it would seem this system is completely immune from any drift-over-time, provided you bother to glance at the dashboard occasionally. We're going to put it in our NOC as soon as the deployment is done :)

srgpqt• 13 years ago

Allow me to introduce you guys to NixOS, and its ops counterpart, NixOps.

http://nixos.org/nixos/ https://github.com/NixOS/nixops

It's a young project but it already solves most of these issues.

contingencies19• 13 years ago

This project looks interesting but I would be wary of any single tool whose scope includes the kernel configuration, boot loader, and userspace and network configuration management.

dmourati• 13 years ago

It seems most people miss the fact that any sufficiently large system is going to require both a pull-based and a push-based solution.

So, take ansible. Primary use: push. But has ansible-pull.

Look at puppet.

Primary use: pull. But has mcollective.

IMO, and I am not there yet but soon to be. The gold standard is to combine two strong players that specialize one each in push/pull. For me, it is looking like ansible/puppet.

tegansnyder• 13 years ago

I use Salt to run commands across our EC2 environment to do things like restart Varnish, clear logs, and run updates. Paired with Unison for file synchronization it works well when your auto-scaling kicks in and you need your new AMI to be synched from staging.

mncolinlee2• 13 years ago

We're actually a Windows-centric shop and have been actively evaluating configuration management solutions for Windows-based virtual machines. Initially, we were only looking at Puppet, Chef, and a commercial product called uProvision along with Vagrant. I was surprised to find that Salt had a real community behind it.

Our greatest challenge has been coming up with a tool which can manage images for both VMWare and Microsoft Hyper-V. This article introduced a web integration between Salt and libvirt called Salt-virt. Has anyone tried this interface for managing images? Does it work better than the young integration between Vagrant and libvirt?

mncolinlee2• 13 years ago

For anyone else looking, I just found Foreman. This seems to do exactly what we're looking for, but it uses Puppet instead of Salt. Even if it requires a Linux server, making our solution more complicated, it appears to meet our needs very nicely.

http://theforeman.org/

dysinger• 13 years ago

Puppet is mature and has tons of cookbooks & community. You may not like it but saying it "sucks" is not right. It works and is used tons.

Chef doesn't run over SSH in any environment I've used that wasn't a toy (vagrant w/ chef-solo). Please fact check.

Fanboy article.

misiti3780• 13 years ago

I use fabric for everything just because I dont have time to learn another one of these technologies. This salt article seems great - but at the end of the day (and I may be way off base here) all I want to do is install a given version of a piece of software on my server. I dont want to create a receipt (chef), or learn another configuration format (sounds like I would need to do this with Salt stack), etc. My fabric file really seems to do only three things: use pip to install shit that is python (I use Django), use apt-get to install anything that is ubuntu specific, and make wget calls to various pieces of software, pull them down, and build them from source. Until there is an easy way for me to do this without needing to learn yet another technology, I will continue to use fabric (or, until the job of doing this gets so big I can hire a dev ops guy that actually already knows, but I am not there yet :) ). Sorry for the rant, it's just every time I see these articles I wish I had time to learn the technology but then I realize I don't.

So - is it just me or is there seem to be a big/huge learning curve for all of these dev ops technologies?

gchpaco• 13 years ago

These technologies come into their own when you are managing large fleets of servers; but by the same right, you need to offer a lot of sophistication to make large fleets of heterogeneous servers work. When you have five servers these seem baroque and overly complicated, but when you have five thousand servers...

tech-dragon4• 13 years ago

Yaml is a hair above "properly indenting my templates" as far as complexity goes. You write django templates, you can handle Yaml ;-)

As current 'devops guy' on a django project myself, salt works wonderfully. Salt has states available that let you setup all that software, create the virtualenv you need (including telling it you want to use the requirements.txt that you pulled down with your django project source code - Salt gives me my own little Heroku :D ) and for anything left in those wgets you can throw a block of salt cmd.run calls using specified ordering to enable them to run neatly in the sequence you desire.

AaronBBrown2• 13 years ago

This article makes a claim (...Puppet...Suck(s)), but does not take even attempt to explain what it is that sucks.

What, specifically, "sucks" about Puppet and Chef and what is so much "simpler" about Salt or Ansible? As an Ops guy who has been running Puppet since 2008 (and Chef most recently) against hundred of servers, I don't see the simplicity reflected in the documentation, nor do I find Puppet or Chef particularly complicated.

(Ok, Chef's attributes system is a bit confusing at first, but it is hugely powerful.)

fusiongyro• 13 years ago

From the article:

Chef works atop ssh, which – while the gold standard for cryptographically secure systems management – is computationally expensive to the point where most master servers fall over under the weight of 700-1500 clients. Salt’s approach was far simpler.

I think I'm with you (without the experience): I find "it works over ssh" a lot simpler than "we wrote a custom protocol on 0mq." Simplicity apparently has lots of interpretations. I couldn't care less if ssh performs well enough to support a trillion connections. In practice, you only need a handful, usually one.

Maybe Salt is fantastic. I'm not really in a position to judge. The article made it sound interesting to me, but I'm not sure attacking Chef/Puppet was really necessary, especially since it wasn't really expounded on.

ecopoesis• 13 years ago

The main reasons I dislike Puppet:

1) It's slow. Puppet runs take forever and use a lot of resources.

2) The Puppet language is terrible. Basically it looks like someone took Ruby and hit it with the stupid stick. Trying to build reusable components nearly impossible without resorting to hackery.

I have no idea is Salt/Ansible/Chef are any better, but I'd be willing to give any of them a try based on just these issues.

knowshan2• 13 years ago

Both Salt and Ansible look interesting. It's much easier to define system state using Ansible or Salt than Puppet.

However, I am not sure how would one use Ansible where VMs get launched dynamically (private cloud/virtualization fabric where devs can instantiate systems) and then receive their configuration without any manual steps.

For example, one can create kickstart/VM-images which get a hostname based on certain regex pattern, register with a Puppet master, the Puppet master auto-signs certs matching this specific hostname pattern and then client nodes receive their catalog. This is really useful pattern wherein systems pull their configuration state almost immediately after boot. It requires manual setup only while writing kickstart/VM-iamge profile and Puppet master configuration.

Ansible's SSH keys setup requires manual intervention, however, I think it can be automated using pre-defined keys in kickstart/VM-images. Haven't tried it yet though...

killing_time• 13 years ago

Yes, having predefined keys in your VM images does the trick, and is exactly what we do for (almost) zero-intervention deployments of our servers in my particular environment.

We tend to destroy and recreate servers more often than we scale out, so we haven't bothered to remove the manual step of adding the server's hostname to the ansible inventory_hosts file. However, that's easily automatable...

Ansible will _execute_ your inventory_hosts file if it's executable, and IIRC it just needs to return a JSON or YML data structure representing all your servers and the groups they're in. So, as long as you have a library which can query your infrastructure (e.g. boto for EC2 etc) it's not hard to automate this.

spudlyo• 13 years ago

Chef works atop ssh, which – while the gold standard for cryptographically secure systems management – is computationally expensive to the point where most master servers fall over under the weight of 700-1500 clients.

It doesn't have to be this way. The situation where one host repeatedly needs to talk to hundreds via SSH is precisely where the SSH ControlMaster socket shines. This saves you a ton of overhead by not having to start up and tear down the session every time you want to issue a command via SSH.

I often use this trick on busy Nagios servers that execute many active checks via SSH -- it works well.

knowshan2• 13 years ago

Good to see tools that work as a system configuration framework and also allow command execution.

[ControlTier](http://www.controltier.org/) had (don't think it's actively developed now) options to execute general system commands, configure systems and application deployment. But it was fairly complex and required [ant](http://ant.apache.org/) skills.

uggedal• 13 years ago

I used Puppet for a few years (and created a few modules for it https://github.com/puppetmodules). I switched to Salt a year ago. My main motivation were its simplicity (YAML+jinja), lower memory consumption, easier source code both to read and contribute to, and its support for both push and pull based architectures.

If you want to get a feel for how salt looks like when managing some servers and laptops you can take a look at my states: https://github.com/uggedal/states

frio2• 13 years ago

From skimming the top level of comments, it seems most people don't like these tools. Fair enough.

That said, on-topic, I just wanted to say that having tried Puppet, Chef and Salt, I've found Salt the easiest to use. Straightforward installation (no messing with Ruby versions/rvm/etc.), really simple setup (systemctl start salt-master; systemctl start salt-minion; salt-keys -L; salt-keys -A yourbox; done), and the YAML-based configuration syntax has been a breeze to work with.

Really quite pleased with it; it's made getting a few of my hairer boxes under control much easier than I expected (and much easier than I found with Chef or Puppet).

ishbits3• 13 years ago

I've recently been thinking I need to learn Chef or Puppet. This thread has convinced me to pick up and try Ansible first.

tetsusoh• 13 years ago

emm, Private chef also use zeromq to implement the pub job feature.

Puppet has MCollective (with ActiveMQ) to implement the similar feature.

WestCoastJustin• 13 years ago

I've thrown together a little puppet demo if anything is interested. Highlights what puppet is, and how it works.

http://sysadmincasts.com/episodes/8-learning-puppet-with-vag...

Salt: Like Puppet, Except It Doesn’t Suck

Related Stories