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

101–110 of 274 posts

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

#101

Post by danudey »

susi22 wrote: post #24
lobo_tuerto wrote: post #15

Earlier quoted context omitted.

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…

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

Salt also uses yaml for its configuration backend (by default). You can also write your state in Python if you prefer, with all the power that that brings (including pulling data from databases, remote API calls, or whatever you like).

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

#102

Post by ipmb »

tptacek wrote: post #85
ipmb wrote: post #69

Earlier quoted context omitted.

If it's a concern, just lock it up behind iptables. Only let your master talk to your minions and your minions can only talk to your master.

I'm not telling you it's malpractice to use it that way, but we wouldn't.

Why?

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

#103

Post by danudey »

justinsb wrote: post #55
jdboyd wrote: post #41

Earlier quoted context omitted.

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.

The overhead of spawning hundreds of SSH processes can be pretty extreme as well.

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

#104

Post by tr4656 »

susi22 wrote: post #50
yxhuvud wrote: post #44

Earlier quoted context omitted.

yum install ruby took you 3h? It may take slightly longer if you want 1.9, but it still exists in fedora so it should not take 3h to solve.

Yes I needed 1.9.3 for this silly software. And I had a little special setup so rvm failed to compile. I'm also very overwhelmed by rvm,gem,bundler etc... Python has pip,easy_install(old) and virualenv. Which are just easier to understand for me. Ruby is too much magic and is trying to do everything automatically (IMO).

Have you tried rbenv? Its easier to setup than rvm and doesn't take too long.

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

#105

Post by lmickh »

WickyNilliams wrote: post #68

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?

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.

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

#106

Post by druiid »

crb wrote: 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?

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

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

#107

Post by susi22 »

danudey wrote: post #103
justinsb wrote: post #55

Earlier quoted context omitted.

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.

The overhead of spawning hundreds of SSH processes can be pretty extreme as well.

By default it won't spawn SSH processes but use paramiko instead (python module that implements SSH).

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

#108

Post by contingencies »

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

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

#109

Post by dmourati »

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.

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

#110

Post by fmstephe »

AlexanderDhoore wrote: post #64
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…

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…

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.

Post reply on HN