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

191–200 of 274 posts

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

#191

Post by dave1010uk »

jtreminio wrote: post #3

I was frustrated with Puppet when I first started. All I wanted was a VM to install a few things so I could do some development and not have to worry about managing my VM. It turned out to be a rabbit hole. As soon as I thought I learned just enough to get it running, something else popped up that stopped me. That's why I created PuPHPet [1]. So far the reception has been fairly positive. At one point in my learning,…

PuPHPet looks really good. What's the default PHP setup? It would be great to be able to switch between and configure mod_php, fastcgi, fcgid, PHP-FPM, suPHP, suExec, etc.

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

#192

Post by jtreminio »

dave1010uk wrote: post #191
jtreminio wrote: post #3

I was frustrated with Puppet when I first started. All I wanted was a VM to install a few things so I could do some development and not have to worry about managing my VM. It turned out to be a rabbit hole. As soon as I thought I learned just enough to get it running, something else popped up that stopped me. That's why I created PuPHPet [1]. So far the reception has been fairly positive. At one point in my learning,…

PuPHPet looks really good. What's the default PHP setup? It would be great to be able to switch between and configure mod_php, fastcgi, fcgid, PHP-FPM, suPHP, suExec, etc.

Default is:

* Ubuntu Precise 64 Bit (12.04.2 LTS)

* Apache

* PHP 5.4

You can switch between Apache/Nginx and PHP 5.4/5.3 (5.5 coming today!)

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

#193

Post by ef4 »

the1 wrote: post #129
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…

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

That doesn't really solve the problem, it just moves it.

If AMIs are your deployment method of choice, you still need to build a repeatable process for applying updates and changes to your previous base AMI, testing that it still works under all your realistic configurations, and then gracefully deploying it to your production infrastructure.

Which is all doable, but not trivial. And the processes you build will be very Amazon-centric.

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

#194

Post by SandB0x »

nbouscal wrote: post #152
tieTYT wrote: post #150

Earlier quoted context omitted.

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.

I don't think Mitchell really needs to worry much at this point about marketing Vagrant. Everyone in the DevOps space is already plenty well familiar with it (mostly because it's incredibly awesome). Also, TFA explains what it is: “Vagrant is an established project that wraps around a number of existing virtualization providers to allow for extremely quick provisioning of disposable, consistent environments.”

TFA, or any least the quote you have selected, does not explain what it is. It states (in quite ambiguous terms) what the combination of Vagrant and "existing virtualization providers" can achieve but not what Vagrant's role is.

From http://www.vagrantup.com: "Create a single file for your project to describe the type of machine you want, the software that needs to be installed, and the way you want to access the machine. Store this file with your project code"

That, and http://docs.vagrantup.com/v2/why-vagrant/, sounds quite similar to a configuration management tool to me (I believe you that it's not, I'm just saying I wouldn't have understood that). Seems geared to launching instances/VMs too perhaps. Maybe it's my lack of domain knowledge and maybe I have unfair expectations but I think that the sales pitch should be accessible to a developer who's not solely in the "DevOps space".

Accessibility is good because I'm sure it is incredibly awesome and may well be useful to a broader set of people who aren't yet in the loop.

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

#195

Post by Goladus »

akoumjian wrote: post #134
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 run salt masterless. See the quickstart. http://docs.saltstack.com/topics/tutorials/quickstart.html

Thanks, it may even be that a salt master is lightweight worth configuring. But I should note there's a difference between "can run" and "intended to run."

It's as much a semantic thing as a technical thing. Instead of thinking about an unconfigured node as a "minion" awaiting orders and provisions from central command, I prefer to think of a node like a stem cell, fully capable of differentiating itself based on signals that it receives. You need a way to update the DNA and a way to send the signals, that's it.

This may seem like a meaningless difference, since there is still value in centralized services (package repositories, security, reporting, monitoring). But it's still a subtly different focus and over time yields different results.

For my part I think the distributed, organic "stem cell" way of thinking will win out over "master/minion" in the long run.

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

#196

Post by _bpo »

calpaterson wrote: post #176
contingencies wrote: post #120

Earlier quoted context omitted.

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

"Immutable Server" seems like an oxymoron.

Frequent refreshes are great, but your system is only doing something useful once it has "mutated" (i.e. accepted external data to operate on).

The tradeoff system designers have to make is frequency of refreshes vs the cost of transferring interesting data to that server.

Seems like your organization has just coined a new synonym for "gold master"

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

#197

Post by 3am »

terminalmage wrote: post #188
3am wrote: post #128

Earlier quoted context omitted.

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.

What a bonehead I am. This is what happens when you say to yourself, "that was about 2 years ago" and you base it on 2012. My only excuse is that I was working on a system config & management product and that I'm having a busy day... I upvoted you for correcting my record.

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

#198

Post by cortesoft »

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…

CSIE sounds great for a certain class of users.

For me, however, it seems like it would be impossible. My team has to manage 10,000+ physical servers. We can't possibly wipe and provision from scratch every time we change configurations.

In other words, if your servers are ON Amazon's platform, use CSIE. If you are RUNNING the Amazon servers, you need something else.

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

#199

Post by Confusion »

contingencies wrote: post #133
mechanical_fish wrote: post #125

Earlier quoted context omitted.

a cleaner solution is to deploy configuration changes from scratch, by deploying clean-slate instances with those changes made. All of us who have built big cloud-server clusters have dreamed of this plan at least once. But there are big practical problems. Relaunching infrastructure is easy in theory, but from time to time it becomes very difficult. There is nothing like being blocked on a critical upgrade because y…

The bulk of your comment - your second, third and fourth paragraphs - focus on issues of speed, bandwidth and reliability in a third party hosting/cloud-based architecture, which are a design-time tradeoff, so I don't see them as strictly relevant (though anecdotally informative). Your fifth paragraph describes problems related to operations process, which are entirely avoidable.

In the parlance of our times: "Do you even lift?"

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

#200

Post by bensummers »

susi22 wrote: post #33
pilif wrote: 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.

It's not that hard to get Ruby running on Solaris. Email me if you need help.
Post reply on HN