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

241–250 of 274 posts

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

#241

Post by contingencies »

tech-dragon wrote: post #238
contingencies wrote: post #221

Earlier quoted context omitted.

You're thinking along the right path. But you can't fully control the environment on all third party hosts/cloud providers, so how do you ensure that the code works on all target infrastructure? There needs to be a unifying abstraction to tie them together, something static enough to maintain a fixed target for service authors.

I would hazard that for a given set of axes in the multivarial formula we will call "control" for short. You definitely can be fully in control. The question is "does what I'm doing fit within the bounding space I can exert full control over. Salt as an 'ecosystem' has capabilities that extend more into this area. Salt Cloud and the Salt Bootstrap script are 2 of the things that I feel invalidate some of the argument…

You definitely can be fully in control. The question is "does what I'm doing fit within the bounding space I can exert full control over.

Right. It's probably fair to say that lots of present-era PaaS doesn't give you a large bounding space. Perhaps cloud providers always limit your space. Your own hardware can even provide limitations. But within that which you control, it's extremely important to version, package and test configuration sets .. or you wind up with a wide class of tangential issues.

Salt Cloud and the Salt Bootstrap script [are] capable of operating much closer to your aim than you give them credit for.

You may be right.

... waste any time trying to ensure I can recreate it...

If you can't automate the generation of your environment, you want to maintain the systems that you produce, and they of reasonable complexity, then IMHO you are asking for trouble in the long run. This is something that took me awhile to learn.

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

#242

Post by contingencies »

brown9-2 wrote: post #187
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…

this sounds like what Martin Fowler calls "immutable servers": http://martinfowler.com/bliki/ImmutableServer.html

Yeah, this is pretty much the exact same idea.

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

#243

Post by contingencies »

srgpqt wrote: post #228
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…

Allow me to introduce you guys to NixOS, and its ops counterpart, NixOps. http://nixos.org/nixos/ https://github.com/NixOS/nixops It's a young project but it already solves most of these issues.

This project looks interesting but I would be wary of any single tool whose scope includes the kernel configuration, boot loader, and userspace and network configuration management.

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

#244

Post by contingencies »

rdtsc wrote: post #223
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…

It seems that 1) You have not dealt with large enough data, since you advocate just creating VM copies or snapshots. Try that on 10 or 100 TB of data. 2) You haven't thought about what and how those initial CSIE configurations are generated. Do you hand tweak everything, make && make install onto a particular installation of a particular OS all the software then just spawn those? It seems that should go to the dustbi…

you advocate just creating VM copies or snapshots. Try that on 10 or 100 TB of data

There are many ways to take an image of an environment, not only VMs or snapshots. But if your system image includes 10-100TB, it could be argued that the problem of size really lies in earlier design decisions.

You haven't thought about what and how those initial CSIE configurations are generated.

On the contrary, generation should be automated. In the same way that a service to deploy to such an environment is maintained as an individual service project, the environment itself is similarly maintained, labelled, tested and versioned as a platform definition.

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

#245

Post by contingencies »

Goladus wrote: post #212
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…

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. CSIEs are still a generative process. The difference with what you call PCFT is that the generative process isn't swept under the rug and codified into a versioned image unless it's…

I fully advocate the description of build steps for environments, just as PFCTs encourage. However, the use of PFCTs to prepare and manage environments seems .. suboptimal, in terms of potential for issues. I suppose a PFCT could be useful as a means to automate the generation of environments, but ... IMHO ... it should not be used for the live instantiation/configuration of real infrastructure (which should be more atomic, from some versioned/known quantity). A subtle difference, but important.

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

#246

Post by contingencies »

rektide wrote: post #157
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…

Having a Clean-Slate Identifiable Environment is well and good from a usage standpoint, but from a creation & maintainability standpoint any bucket of bits qualifies as an identifiable environment. The very purpose of most of these tools is to make state visible, to be able to see what has been poured in. That visibility contributes to extensibility, the ability to take that known configuration starting place and to…

any bucket of bits qualifies as an identifiable environment

Sure.

The very purpose of most of these tools is to make state visible

Right, but they do a poor (ie. post-facto, limited granularity) job of it. This is why IMHO their paradigm is inelegant.

infrastructure in mind for how your CSIEs are constructed

We use scripts with exit values that execute within the target environment to bring it from a base configuration (eg. some AMI or some distro) through to the desired config, plus validation tests. I think most people's approaches will be similar. PFCTs essentially provide this, and could be used for this step without issue.

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

#247

Post by StavrosK »

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

Same thing for Ansible: http://www.stavros.io/posts/example-provisioning-and-deploym...

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

#248

Post by contingencies »

drivebyacct2 wrote: post #154
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…

If used properly they should have an identical result.

Perhaps. The problem is, if you use PFCT on a bunch of hosts and something subtle changes that can cause issue, the granularity of the PFCT doesn't necessarily equate to that required for detecting the cause. With a CSIE-style atomic approach to deployment and a properly segregated monitoring system, you can, say, 'roll back' to the last known good version. PFCTs leak state, and will not always allow you this reverse pathway (random examples might include kernel feature or compiler version migration).

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

#249

Post by grandalf »

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 tools are overly complicated and offer little value for installations with fewer than hundreds of servers.

Checkout fabric.py and cuisine.py, both are small, simple, elegant approaches.

Combined with a native package manager (like apt), fabric+cuisine is nearly as powerful as puppet or chef.

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

#250

Post by grandalf »

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…

Did you check out cuisine.py by any chance?
Post reply on HN