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

181–190 of 274 posts

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

#181

Post by stevekemp »

susi22 wrote: 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.

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.

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

#182

Post by uggedal »

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

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

#183

Post by gyepi »

bfrog wrote: post #131
the1 wrote: post #129

Earlier quoted context omitted.

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

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

This is not a difficult problem. I recently had to stand up a cluster of EC2 instances for a job that required a cluster of them and used these three steps:

1. Write a script to configure an instance and run it when the instance starts.

2. Clone the instance to an image

3. Run instances based on the image.

It's quite straightforward to do. See http://github.com/gyepisam/fcc-textify for more details.

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

#184

Post by gchpaco »

misiti3780 wrote: post #153

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

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

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

#185

Post by [deleted] »

saintx wrote: post #179
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…

[deleted]

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

#186

Post by avtar »

fmstephe wrote: post #110
AlexanderDhoore wrote: post #64

Earlier quoted context omitted.

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…

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.

Perhaps I'm missing some obvious detail but I would think you would just update your repository with the new version of your application and/or Tomcat package and that would cause the service to restart on the next Puppet run, after the new version has been installed.

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

#187

Post by brown9-2 »

contingencies wrote: post #108

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

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

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

#188

Post by terminalmage »

3am wrote: post #128
[deleted] wrote: post #118

[deleted]

If someone can't get over the Ansible startup costs, then they have no business managing a system... I can't speak for Salt (last time I tried to use it was in 2010, and it was atrocious then and I haven't gone back).

That would be an impressive feat, given that the first commit for the project was in February of 2011.

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

#189

Post by [deleted] »

mitchellh wrote: post #96
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…

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.

[deleted]

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

#190

Post by justincormack »

rektide wrote: post #163
justincormack wrote: post #82

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

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

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