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

131–140 of 274 posts

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

#131

Post by bfrog »

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?

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 why I like the idea, not necessarily the resulting applications that have been created so far for the task.

Shell scripts could do the same and have for years if your only interested in from scratch setups.

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

#132

Post by danudey »

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 took me 3h last week to get it on a CentOS installed

This matches my experience with a significant amount of software on CentOS. Since CentOS is just a rebuild of RHEL, and RHEL is extremely conservative when it comes to new software, CentOS tends to be out of date at release and get progressively worse.

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

#133

Post by contingencies »

mechanical_fish wrote: post #125
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…

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.

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

#134

Post by akoumjian »

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

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

#135

Post by pessimizer »

terminalmage wrote: post #67
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…

reads article about A I've tried B, C, D, and E, and I like E.

The title of the article is "A: like D, except it doesn't suck."

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

#137

Post by whodoneit »

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…

> we should be _very_ clear that puppet does a spectacularly bad job of solving a very ordinary problem that I have

Well, yes. If you want to use a tool for something it was _very_ clearly not created for, you're going to have a bad time.

If you had used even a few minutes reading about puppet, you would know about MCollective[1] which _can_ help you with these kinds of problems.

MCollective integrates pretty well with puppet and hiera, but there's nothing stopping you from using puppet + ansible for example.

1: http://docs.puppetlabs.com/mcollective/

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

#138

Post by peterwwillis »

darkarmani wrote: post #127
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. Why are you exposing VPN ports in public anyhow? Put them behind a VPN. Seriously though, there isn't anything to say a VPN is any more secure than SSH.

SSH is secure. The configuration of SSH, and the system that it's running on, its operating system, accounts and applications, might not be. It all comes down to how secure you want to be.

There is a longer conversation that can be had to explain this. There are lots of mistakes one can make in managing a box with SSH that will easily lead to an account compromise, not even considering universal methods like 0-days, stack attacks, mitm, phishing, etc. The simplest defense to all these problems is a hardened VPN device on a separate network segment with separate authentication and strictly defined ACLs.

If you just run a personal VPS, I wouldn't worry about it. But if you ever start handling customer data, get serious about security and don't run SSH in the open.

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

#139

Post by nodesocket »

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 operations. SandBOx, if you'd like to try out Commando.io, let me know, and I'll get you a private beta invite.

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

#140

Post by contingencies »

chongli wrote: post #112
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…

Do you have any resources where one might learn about CSIEs? Where to get started, available tools, best practices, etc.

To be honest nobody else uses the term... I just made it up! But I've been wanting to further publicly elucidate my thinking in this area for some time... maybe soon I'll get around to more. I would say the responses to this post have been sort of comfirmative (not barking up entirely wrong tree; others can see the logic of my thinking to some extent).

I personally believe that this area is going to expand rapidly, building off of the trajectory begun by present first-generation of cloud infrastructure. Perhaps for someone who wanted to practice thinking in this area, I would a say exercise is to limit yourself purely to third party and cloud based infrastructure but demand high performance and global (multiple cloud provider) availability, and challenge yourself to write a multi-service system including a deployment tool that automates your solution and actually produces maintainable infrastructure. If you follow through, you will understand the problems.

Post reply on HN