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

111–120 of 274 posts

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

#111

Post by terminalmage »

gunmetal wrote: post #73

Salt is missing templates, the ability to use higher level programming language and all the environment/roles that I find the most powerful part of Chef.

jinja2 and mako are supported, and you can even write your own renderer without much effort if a templating language is not supported.

There's even a renderer for pure python, allowing one to write config files in python for more control and flexibility.

One wonders if you've ever actually tried Salt. It really is OK to have an approach of: "I like Chef and it works for me." More power to you. Everyone should use the tool that works for them.

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

#112

Post by chongli »

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.

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

#113

Post by terminalmage »

wunki wrote: post #6

I just released a open-source package which enables you to create a Django centric stack on Vagrant with the help of Salt. It was indeed very easy to write. You can check it out here: https://github.com/wunki/django-salted

Wow, this looks great. I've got a talk proposal submitted for DjangoCon this fall and might just integrate this into the presentation, should it get accepted.

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

#114

Post by emidln »

tptacek wrote: post #52
frankwiles wrote: post #36

Earlier quoted context omitted.

I don't understand why ZeroMQ outside of a data center would be a deal breaker for anyone. You do realize the data on the wire is encrypted right?

Awesome. How many people have reviewed it for flaws? How many people have reviewed OpenSSH?

How many people have reviewed Paramiko? In particular, how about that ecdsa patch[1] to Paramiko that you'll need to be accessing modern Ubuntu or Fedora (and before long, RHEL/CentOS). What about the python-ecdsa[2] (that paramiko's provisional support for modern Fedora and Ubuntu's default configs is based on)? This entry from its README seems pretty frightening:

    This library does not protect against timing attacks. 
    Do not allow attackers to measure how long it takes you 
    to generate a keypair or sign a message. This library
    depends upon a strong source of random numbers. Do not
    use it on a system where os.urandom() is weak.
I'm not saying Paramiko (or its patch sets) are insecure, just pointing out that the same arguments can be made against the libraries and code that Ansible is based on.

[1] - https://github.com/paramiko/paramiko/pull/152

[2] - https://github.com/warner/python-ecdsa

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

#115

Post by calpaterson »

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 think you're right that Salt/Puppet and to a lesser extent Chef take the wrong approach, but you make some confusing comments that make me suspect you might not understand what these existing approaches are about.

> 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

I think you mean "post-facto" as in: "run after everything is done"? This is not the way that people would advocate Puppet should be used. Puppet should be used from the start, not added as an afterthought once you are done.

> IMHO, a cleaner solution is to deploy configuration changes from scratch, by deploying clean-slate instances with those changes made

This isn't a cleaner solution, this is almost the solution you get when you use Puppet. With puppet the development workflow is like this:

- Span up a vagrant VM

- Run your manifests against this VM to test them

- To check in, run your manifests against your staging environment

- To deploy, spin up new clean production VMs and run puppet manifest against them

- Use a reverse proxy to route all traffic to new production VMs. Terminate old production VMs

> PFCT's deployment paradigm tends to be relative slow and error prone.

This much is true. Puppet's slow speed is particularly galling, but maybe that's just because I use it at work.

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

#116

Post by calpaterson »

23david wrote: post #88
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…

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.

You don't need to do this. SSH is secure enough. Require key-based authentication and leave SSH on port 22.

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

#117

Post by reinhardt »

lobo_tuerto wrote: post #15
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.

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…

I'm going to go on a limb here and say that the 700-1500 clients limitation is a non-problem for the vast majority. It's like the C10K "problem" all over again. Newsflash: most shops don't have more than a few dozen servers, if that, and the few ones that do must have already done their homework.

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

#119

Post by AaronBBrown »

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.

Try https://rvm.io if you're having difficulty getting Ruby somewhere.

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

#120

Post by contingencies »

calpaterson wrote: post #115
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 think you're right that Salt/Puppet and to a lesser extent Chef take the wrong approach, but you make some confusing comments that make me suspect you might not understand what these existing approaches are about. > 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 undocu…

> 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 remotely, en-masse, without any significant capacity to ensure that individual instances within a group have not subtly shifted in configuration. This is what I meant by configuration drift.

CSIEs, by contrast, are essentially the complete product of the entire generation process, thus ensuring that future instantiations are identical. A subtle difference, but an important one.

Post reply on HN