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

201–210 of 274 posts

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

#201

Post by xorgar831 »

falcolas wrote: post #180
njs12345 wrote: post #39

Earlier quoted context omitted.

If you don't want to run a master, you can use Salt in masterless mode: https://salt.readthedocs.org/en/latest/topics/tutorials/stan...

One important difference: you don't have to install Ansible on the nodes you're managing, just Python >= 2.4 with a JSON module installed (default for 2.6 and later, available through simplejson for previous versions). Also, Ansible does not require you to mess around with dependency lists to ensure that packages/files are installed in the right order - the order is built into the yaml config file. You don't lose any…

Actually ansible doesn't even need python installed initially, it has a "raw" mode which you can use to boot strap the installation of python.

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

#202

Post by nbouscal »

SandB0x wrote: post #194
nbouscal wrote: post #152

Earlier quoted context omitted.

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

The quote seemed pretty clear to me, but I suppose that could be because I already know what it does. Vagrant wraps VM software (VirtualBox, VMWare, etc — the "existing virtualization providers" in the quote) to create disposable development environments. It also allows you to connect with configuration management tools like Chef or Puppet, which then configure that disposable environment to mirror your production environment. It doesn't really do configuration on its own (unless you count running shell commands), so it isn't a configuration management tool itself. It does one thing well.

I agree that we should be evangelizing DevOps and bringing more people into the loop. I was simply saying that Vagrant itself doesn't really need any marketing. It's hard to read much of anything about the field without seeing it mentioned.

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

#203

Post by nuclear_eclipse »

hexedpackets wrote: post #175
calpaterson wrote: post #116

Earlier quoted context omitted.

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

Switching SSH to any other port is a good idea as it will reduce the random attacks against it. Sure, those drive-by attacks are pretty weak and not much of a threat against a hardened configuration and the real attackers will find the new port anyway, but it reduces noise significantly. Cleaner logs are easier to parse, so the net result is that you can spot attacks that you care about much more easily.

Install fail2ban, leave ssh on port 22, and have clean logs.

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

#204

Post by frio »

From skimming the top level of comments, it seems most people don't like these tools. Fair enough.

That said, on-topic, I just wanted to say that having tried Puppet, Chef and Salt, I've found Salt the easiest to use. Straightforward installation (no messing with Ruby versions/rvm/etc.), really simple setup (systemctl start salt-master; systemctl start salt-minion; salt-keys -L; salt-keys -A yourbox; done), and the YAML-based configuration syntax has been a breeze to work with.

Really quite pleased with it; it's made getting a few of my hairer boxes under control much easier than I expected (and much easier than I found with Chef or Puppet).

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

#205

Post by dzderic »

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?

After finishing the Cousera crypto course, I did a quick review of their approach and found 2 issues which completely broke their authentication protocol (https://github.com/saltstack/salt/issues/2239 & https://github.com/saltstack/salt/issues/2916).

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

#206

Post by penguindev »

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?

Because a lot of people don't use their brain, and realize that linux package management / image creation has been a solved problem since forever (I've been doing this since redhat kickstart circa 2001, and I'm a young guy).

However, there are some common sense tiers:

3rd party dependencies that changes infrequently = put in ami Common ops daemons and boot scripts = put in ami your application code and your configs = deploy via python/ssh client side

Also, one simply has to use ec2 instance tags to name things.

Result, you can have bit-for-bit identical instances fired up in no time with high confidence without need for a full OS package mirror. Without, of course, a ridiculously over-engineered configuration server framework, DSL, SPOF, security holes...

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

#207

Post by ishbits »

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.

At some point, to gain any form of remote access you have to put your trust in one piece of software. Being it VPN, ssh, or something.

For many people ssh is considered secure enough. And any secure issues get immediate attention so you can be updated pretty quickly.

Now any software could have unpublished zero days, which is why I also do some other host based security.

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

#208

Post by ishbits »

frankwiles wrote: post #36
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…

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?

A few years back it was common practice NOT to expose ZeroMQ to the wide open internet as it was built for that. I think they says it OK now, but its left a bitter sense for some of us.

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

#209

Post by zhynn »

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…

After working in Chef for several years and fighting with both gem-rot and managing colliding chef-client and application ruby+rubygems+gem environments with RVM... I was ready for something else. Also, our group just started working alongside another group that does not use cfg management; I wanted something that would be unobtrusive. At first I thought Salt would work, but the minionless mode was not really recommended. You lose a lot of the power of Salt when you do that. Ansible, however, is designed to be minionless. After using it for the last few months, I am (frankly) in love. The last time I felt butterflies like this for a tool was when I grokked git.

Look, I can maintain my own ansible configurations (inventories, playbooks and roles), and the other groups need not be the wiser. They don't need to worry that servers are going to be reconfigured out from under them, since I am running my configurations explicitly. All they see is that I ssh'd in and did a bunch of stuff really fast. To work with my other groupmates, we just keep the files in git (just flatfiles, yes: just flatfiles). With git I have an audit log of everything that has changed (hosts that have moved environments, configurations that have been updated, etc). And like git it is as distributed as you want it to be. Want to run it from a central server only? Fine. Want to have your admins all run it from their workstations? Fine. Go for it.

Even if the server is ancient or weird (ie. no python), I can still manage it with the raw module.

Ansible gives me everything I want, with no fuss. It is so basic that I can do things the way I want to.

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

#210

Post by frio »

SandB0x wrote: post #194
nbouscal wrote: post #152

Earlier quoted context omitted.

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

With vagrant, I can create a vagrantfile. This says: "create a VM using this basic distribution, this networking configuration, these forwarded ports, and this hardware exposed". It defines the basic machine.

I can then use "vagrant up". This creates a new VM using Virtualbox, VMware, or whatever I have installed (I think there's even EC2 providers now!). It configures that VMs hardware as above.

Then, vagrant can use one of many tools in the configuration space -- Chef, Puppet, Salt -- to configure the software in the VM.

I guess the distinction lies there: vagrant configures hardware. Salt et all configure the software.

Post reply on HN