Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Salt: Like Puppet, Except It Doesn’t Suck

blog.smartbear.com

Post reply on HN
Print view View original

171–180 of 274 posts

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

#171

Post by ecopoesis »

AaronBBrown wrote: post #167

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

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.

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

#172

Post by knowshan »

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

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

#173

Post by spudlyo »

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.

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

#175

Post by hexedpackets »

calpaterson wrote: post #116
23david wrote: post #88

Earlier quoted context omitted.

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.

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

Switching SSH to any other port is a good idea as it will reduce the random attacks against it.

Sure, those drive-by attacks are pretty weak and not much of a threat against a hardened configuration and the real attackers will find the new port anyway, but it reduces noise significantly.

Cleaner logs are easier to parse, so the net result is that you can spot attacks that you care about much more easily.

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

#176

Post by calpaterson »

contingencies wrote: post #120
calpaterson wrote: post #115

Earlier quoted context omitted.

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

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

> This is what I meant by configuration drift.

I forgot to mention this before, it is strange that you credit yourself with defining this term when it has been well defined for some time in ops.

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

But this adds a significant weight over and above the "generative process" of running manifests. Yes, running manifests against your VMs can "fail or change in unexpected ways due to xyz" - don't do it against VMs that are currently in production! I'm not sure you've ended up with anything less error prone and you're still going to need a way to get from a fresh VM image and your output images - which is where Puppet would come in.

I'd really rather not make the entire disk image my build artefact, for fairly obvious reasons (ie: size).

You might like this, which is written by a colleague of mine, except that it is not in "opposition" to Puppet/Chef/etc:

http://martinfowler.com/bliki/ImmutableServer.html

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

#177

Post by Goladus »

sciurus wrote: post #84
Goladus wrote: post #31

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.

You can also run puppet without a master server.

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

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

#178

Post by knowshan »

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.

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

#179

Post by saintx »

SandB0x wrote: 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…

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

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

#180

Post by falcolas »

njs12345 wrote: post #39
tptacek wrote: 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…

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

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.

Post reply on HN