Live data from Hacker News

Salt: Like Puppet, Except It Doesn’t Suck

blog.smartbear.com

51–60 of 274 posts

Re: Salt: Like Puppet, Except It Doesn’t Suck

#51
post #40

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

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

Re: Salt: Like Puppet, Except It Doesn’t Suck

#52
post #18

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…

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?

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

Re: Salt: Like Puppet, Except It Doesn’t Suck

#53

Personally, I don't think puppet sucks

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.

Re: Salt: Like Puppet, Except It Doesn’t Suck

#55
post #41
post #12

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.

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 lif…

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.

Re: Salt: Like Puppet, Except It Doesn’t Suck

#56
post #18

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…

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?

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

Re: Salt: Like Puppet, Except It Doesn’t Suck

#57
post #33
post #29

Earlier quoted context omitted.

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.

I forgot to mention that just installing ruby is a HUGE PITA on anything but the most common OSes. It took me 3h last week to get it on a CentOS installed. And I don't even want to try to get it running on our Solaris hosts... Point is: Python is the number one scripting language (after bash) for sysadmins just like Perl used to be.

I support Ruby apps so Ruby is on every server anyways.

With that said you can use Omnibus Chef Installer now which includes a copy of Ruby just for Chef. Good for servers where you don't need Ruby or small servers that would take awhile to compile a newer Ruby.

Re: Salt: Like Puppet, Except It Doesn’t Suck

#58
post #12

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.

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/

Re: Salt: Like Puppet, Except It Doesn’t Suck

#59
post #48

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 Vagra…

[deleted]

Re: Salt: Like Puppet, Except It Doesn’t Suck

#60
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.
Post reply on HN