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

141–150 of 274 posts

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

#141

Post by coolsunglasses »

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…

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

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

#142

Post by halayli »

nodesocket wrote: post #139
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…

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

My Ansible learning curve was 5 minutes.

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

#143

Post by JoachimSchipper »

ipmb wrote: post #102
tptacek wrote: post #85

Earlier quoted context omitted.

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

Why?

I'm not tptacek, but note that IP addresses are not exactly cryptographically secured. If you only restrict access by IP address, you tend to lose your whole intranet as soon as one host falls.

(Then again, that's how it usually goes anyway.)

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

#144

Post by mncolinlee »

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?

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

#145

Post by mateuszf »

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…

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.

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

#146

Post by pestaa »

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…

> can you package your ami for your developers to use

SuSE Studio lets you do exactly that. (Though exporting to AMIs is just a feature, not the main objective.)

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

#147

Post by apenney »

druiid wrote: post #106
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).

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

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

#148

Post by Shish2k »

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…

> I want to stop a service

You WANT to stop the service? Really? Stopping the service is an actual headline-level goal, and not a behind-the-scenes detail?

Personally I tell puppet "make sure that the latest version of X is running", because that's what I actually want, and I don't care how it does it...

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

#149

Post by dysinger »

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.

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

#150

Post by tieTYT »

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.

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